Marco Colombo wrote:
> I'll try that out. Maybe my ideas are so far from the truth that I'm
> having a hard time in explaing them to people who actually know how
> things work. I'll be back with results. Meanwhile, thanks for your time.
I think I finally got it.
Segment 34 in my pg_xlog got archived and recycled. It became segment
39, but PG is still working on segment 35, after some hours. Now pg_xlog
contains 5 segments, from named from 35 to 39, 35 being the most
recently modified. 39 won't be used yet for about a couple of days.
Now I see what you mean for "recycled": I thought it meant "marked free
for later use", but it means "renamed for future use". My mistake was
assuming that the rename part happens lazily when PG starts using the
file. Instead, it happens right after (the eventual) archiving.
That makes the strategy in my original post somehow unfeasable. Still, I
was not completely wrong:
# cmp /var/lib/pgsql/data/pg_xlog/000000010000000100000039
/u1/pg_wal_archive/000000010000000100000034 && echo "Yes"
Yes
They do contain the same data, that of segment 34, and the *39 file will
stay there, untouched, for quite a while after the backup. So the WAL
segment I need *is* there, just with a different name.
The only problem is figuring out what segment that data actually belongs
to. I know only because I can compare it with the archived one. Now, I
could still make some educated guesses, by looking at modification
times, but definitely a guessing game is not something you want to play
when restoring your precious data. :) Archiving the WAL segments and
letting the recovery procedure handle them at restore time is easier anyway.
Again, thanks a lot.
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@ESI.it