Обсуждение: PostGreSQL (7.3?) recovery, Mac OS X (10.3.8)

After an extended vacation from development activities on my computer,
I tried to get back to work, but the PostGreSQL backend was no longer
running.  (Normally its part of my startup scripts.)

I tried su'ing over to postgres and running pg_ctl start.  No luck,
seems like it lost the path.  Type the full path /usr/local/bin/pg_ctrl
start, complains about missing PGDATA.  Looks like all the environment
variables are gone.  (I had read that 10.3 had some issues with shared
memory, but this seems unusual? )  Providing the full path to the data
directory

/usr/local/bin/pg_ctl -D /usr/local/pgsql/data start
LOG:  database system shutdown was interrupted at 2005-04-12 20:11:05
EDT
LOG:  checkpoint record is at 0/2363FC0
LOG:  redo record is at 0/2363FC0; undo record is at 0/0; shutdown TRUE
LOG:  next transaction id: 38330; next oid: 36038
LOG:  database system was not properly shut down; automatic recovery in
progress
LOG:  ReadRecord: unexpected pageaddr 0/364000 in log file 0, segment
2, offset 3555328
LOG:  redo is not required
PANIC:  XLogWrite: write request 0/2364000 is past end of log 0/2364000
LOG:  startup process (pid 784) was terminated by signal 6
LOG:  aborting startup due to startup process failure

The startup fails.  The timestamp on the first log appears to be during
the boot process of the computer.

PG_VERSION reports 7.3.  This is just a "play" database that I use for
random testing.  I believe its the version that came with the
PowerBook, unless its been updated by "Software Update", which I would
doubt.  I believe I last used the database back around January.

I believe everything of "use" was already migrated a beta server;
however I would like to attempt any sort of recovery possible first, if
possible.  What should I do next?

Eric

On Tue, Apr 12, 2005 at 08:30:39PM -0400, Eric D. Nielsen wrote:

> LOG:  ReadRecord: unexpected pageaddr 0/364000 in log file 0, segment
> 2, offset 3555328
> LOG:  redo is not required
> PANIC:  XLogWrite: write request 0/2364000 is past end of log 0/2364000
> LOG:  startup process (pid 784) was terminated by signal 6
> LOG:  aborting startup due to startup process failure
>
> The startup fails.  The timestamp on the first log appears to be during
> the boot process of the computer.
>
> PG_VERSION reports 7.3.  This is just a "play" database that I use for
> random testing.  I believe its the version that came with the
> PowerBook, unless its been updated by "Software Update", which I would
> doubt.  I believe I last used the database back around January.

What version is this exactly?  IIRC there was a version of 7.3 that
would refuse to start if the last XLog record fell at the edge of a
segment.  I may be misremembering though (i.e. maybe it was one of the
7.4 series), plus I can't find the relevant entry in the release notes.

--
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"Para tener más hay que desear menos"

"Eric D. Nielsen" <nielsene@mit.edu> writes:
> PANIC:  XLogWrite: write request 0/2364000 is past end of log 0/2364000

This is a known corner-case bug in some 7.3 releases.  If you care about
getting the data out of it, you can update-in-place to the latest 7.3
release.  If not, well, 7.3 was a long time ago ...

            regards, tom lane

Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> What version is this exactly?  IIRC there was a version of 7.3 that
> would refuse to start if the last XLog record fell at the edge of a
> segment.  I may be misremembering though (i.e. maybe it was one of the
> 7.4 series), plus I can't find the relevant entry in the release notes.

If I'm reading the CVS history correctly, the bug existed only in the
7.3.3 release; here's the CVS log entry for the fix:

2003-07-17 12:45  tgl

    * src/backend/access/transam/xlog.c (REL7_3_STABLE): Repair
    boundary-case bug introduced by patch of two months ago that fixed
    incorrect initial setting of StartUpID.  The logic in XLogWrite()
    expects that Write->curridx is advanced to the next page as soon as
    LogwrtResult points to the end of the current page, but
    StartupXLOG() failed to make that happen when the old WAL ended
    exactly on a page boundary.  Per trouble report from Hannu Krosing.

and this seems to be what Bruce boiled it down to in the 7.3.4 release
notes:

* Prevent rare possibility of server startup failure (Tom)

Personally I always look at the CVS history when searching for bug
histories.  cvs2cl.pl is a wonderful tool ...

            regards, tom lane

Thank you. I'm used to installing from source or Debian packages.  I
haven't poked around too much at the console level of the Mac.  I would
assume I install from source and just point the install to the old data
directory? Any gotchas to watch for that aren't in the manual? I would
assume I should "upgrade" to 7.3.4, and see if that fixes enough that I
can generate a database dump.  Afterwards bring it forward t0 the 8.0
series.

Eric


On Apr 12, 2005, at 10:09 PM, Tom Lane wrote:

> "Eric D. Nielsen" <nielsene@mit.edu> writes:
>> PANIC:  XLogWrite: write request 0/2364000 is past end of log
>> 0/2364000
>
> This is a known corner-case bug in some 7.3 releases.  If you care
> about
> getting the data out of it, you can update-in-place to the latest 7.3
> release.  If not, well, 7.3 was a long time ago ...
>
>             regards, tom lane