Florian G. Pflug wrote:
> I'm currently working on splitting StartupXLog into smaller
> parts, because I need to reuse some of the parts for concurrent
> wal recovery (for my GSoC project)
> The function recoveryStopsHere in xlog.c checks if we should
> stop recovery due to the values of recovery_target_xid and
> recovery_target_time. For recovery_target_xid, we stop if
> we see a commit or abort record for the given xid.
> Now I wonder what happens if an (admittely rather confused) DBA
> uses an xid of a transaction that was aborted because of a
> crash of the master as recovery_target_xid. The way I read the
> code, postgres will just recover until it reaches the end of
> the xlog in that case because neither an COMMIT nor an ABORT
> for that xid exists in the WAL.
> I'm not sure if this is worth fixing - it seems like a rather
> contrived corner case - but I though I'd bring it up...
I think you meant to send that to pgsql-hackers, not pgadmin-hackers...
In response to
pgadmin-hackers by date
|Next:||From: Florian G. Pflug||Date: 2007-06-04 16:27:53|
|Subject: Re: recovery_target_xid & crashes on the master|
|Previous:||From: Florian G. Pflug||Date: 2007-06-04 16:14:45|
|Subject: recovery_target_xid & crashes on the master|