Results 1 to 8 of 8
  1. #1
    Join Date
    Feb 2002
    Posts
    4

    Unhappy Unanswered: Postmaster won't start

    Relatively new to PostgreSQL and have encountered a start up problem that I've not yet experienced. Any guidance in pointing me in the right direction to recovering the database and getting it back online would be greatly appreciated.

    ------
    Configuration
    ------

    Windows NT 4.0 Service Pack 6
    Cygwin 1.3.9
    IPC-Daemon 1.09-2
    PostgreSQL 7.1.3
    PostgreSQL ODBC driver 7.01.00.09
    Perl 5.6.1 Build 631


    ------
    Database condition prior to shutdown
    ------

    The database seemed to be functioning fine with the exeption that it would not accept any new records. When an attempt was made to insert a new record the ODBC driver would provide the following error:

    "Error while executing the query;
    No response from the backend;
    Error while reading from the socket."

    I shutdown the server and restarted it as the first action to correct the problem.

    ------
    Current State
    ------

    When I attempt to bring the postmaster service back online it generates the following error:

    invoking IpcMemoryCreate(size=1245184)FindExec: searching PATH ...ValidateBinary: can't stat "/usr/local/bin/postmaster"FindExec: found "/usr/bin/postmaster" using PATHDEBUG: database system shutdown was interrupted at 2002-02-11 19:55:46 DEBUG: CheckPoint record at (5, 550325976)DEBUG: Redo record at (5, 550325976); Undo record at (0, 0); Shutdown TRUEDEBUG: NextTransactionId: 4278018; NextOid: 8532790DEBUG: database system was not properly shut down; automatic recovery in progress...DEBUG: redo starts at (5, 550326040)DEBUG: ReadRecord: record with zero len at (5, 550981112)DEBUG: redo done at (5, 550981072)FATAL 2: XLogFlush: request is not satisfiedDEBUG: proc_exit(2)DEBUG: shmem_exit(2)DEBUG: exit(2)postmaster: reaping dead processes...postmaster: Startup proc 108 exited with status 512 - abort

    I've got another log which is that generated with wal_debug = 1

    Since the log was quite a bit bigger I've posted it to a URL:

    http://www.webspawner.com/postgresql...pgsql.log.html

    Where is my next step in remedying this problem?

    Regards,

    Art Conner

  2. #2
    Join Date
    Feb 2002
    Posts
    4
    Some additional data - here is the results gathered from pg_controldata:

    pg_control version number: 71
    Catalog version number: 200101061
    Database state: SHUTDOWNING
    pg_control last modified: Mon Feb 11 19:58:12 2002
    Current log file id: 5
    Next log file segment: 33
    Latest checkpoint location: 5/20CD4ED8
    Prior checkpoint location: 5/20C81FC8
    Latest checkpoint's REDO location: 5/20CD4ED8
    Latest checkpoint's UNDO location: 0/0
    Latest checkpoint's StartUpID: 353
    Latest checkpoint's NextXID: 4278018
    Latest checkpoint's NextOID: 8532790
    Time of latest checkpoint: Mon Feb 11 17:15:45 2002
    Database block size: 8192
    Blocks per segment of large relation: 131072
    LC_COLLATE: C
    LC_CTYPE: C

    Is my only option at this point to execute a pg_resetxlog and then attempt a pg_dump and restore?

    Regards,

    Art Conner

  3. #3
    Join Date
    Sep 2001
    Location
    Vienna
    Posts
    400

    postgresql - cygwin

    This looks like a strange problem
    If you are in a hurry to get teh postmaster running again then dump and backup the data

    I'm not so familiar with the cygwin package

    But I will see what I can do
    http://www.postgresql.org
    --Postgresql is the only kind of thing--

  4. #4
    Join Date
    Feb 2002
    Posts
    4
    Thank you for responding to me...

    I ended up running pg_resetxlog and had to utilize the -f just to get it to complete successfully.

    I of course was able to get postmaster up and running at that point and able to view the data.

    I immediately ran pg_dump but it was unable to complete successfully and generated the following error.


    ERROR: unexpected chunk size 1159 in chunk 0 for toast value 8532788


    I then began looking for a way to extract any data that has been changed since the last backup copy of the database and was able to run SQL commands and output some recent data into a delimited ascii file.

    Occassionally that same error would be generated while executing those commands. During the course of running those various SQL commands I was able to pinpoint specific records and columns (fields) that would generate the error when requested.

    Now my question(s).

    By way of SQL commands I believe that I have located all of the troubled records. (I don't know enough about PostgreSQL to even know if that is a valid/plausible statement. How much is corrupt that I just can't see - or isn't causing and error?) Additionally there are some records that are duplicated (even though they violate unique definitions set in the database structure).

    Is it at all conceivable to be able to replace/fix those troubled records by way of deleting the records and re-entering the data by hand? At least to the point where I can get pg_dump to complete successfully?

    If not, is it possible to define a set of records by way of SQL statement for pg_dump to use during backup?

    Just trying to recover what data I can.

    Regards,

    Art Conner

  5. #5
    Join Date
    Sep 2001
    Location
    Vienna
    Posts
    400

    ANSWERS !?

    First of all I hope this will help you a little bit.

    The duplicate entries are not the problem.If you have a sequence or an unique index the db returns an error and do not insert the duplicate entry


    But attention this only works if you have dumped this with

    pg_dump -D .....

    the -D dumps teh data in as insert statements
    When you reinsert this file it may take a while but you have no duplicates over an index.

    Have you tried a vacuum over the database??

    You cannot specify a set of records to be dumped
    only a table can be selected
    look at the optinos
    pg_dump --help
    http://www.postgresql.org
    --Postgresql is the only kind of thing--

  6. #6
    Join Date
    Feb 2002
    Posts
    4
    I just attempted to do the

    pg_dump -D (etc.)

    And after just a few minutes it aborted and pg_dump provided a stackdump.

    I have been careful to avoid doing anything that would change the state of the data so I have not performed a vacuum on the database. Would you recommend at this point doing that? Could it solve my problem? Or just make it worse?

    Your assitance and replies are greatly appreciated.

    Regards,

    Art Conner

  7. #7
    Join Date
    Sep 2001
    Location
    Vienna
    Posts
    400

    vacuum

    The problem is I don't know exactly what the problem is
    but vacuum can solve many problems
    it only cleans transactions
    if there was the problem data will be lost

    I think the best thing will be if you dump the data as you can and try to reimport it in a test database
    and clean the wrong things manually

    This is a horrible work but if this data is important anything else will be dangerous.
    http://www.postgresql.org
    --Postgresql is the only kind of thing--

  8. #8
    Join Date
    Sep 2001
    Location
    Vienna
    Posts
    400

    mailing list

    As I have said before I'm not an expert on cygwin systems

    Perhaps you will get more help when you mail to the cygwin mailing list on www.postgresql.org
    http://www.postgresql.org
    --Postgresql is the only kind of thing--

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •