From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
Cc: | pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
Subject: | Re: recovery_target_xid & crashes on the master |
Date: | 2007-06-04 16:24:17 |
Message-ID: | 46643CB1.9060609@hagander.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgadmin-hackers |
Florian G. Pflug wrote:
> Hi
>
> 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...
//Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | Florian G. Pflug | 2007-06-04 16:27:53 | Re: recovery_target_xid & crashes on the master |
Previous Message | Florian G. Pflug | 2007-06-04 16:14:45 | recovery_target_xid & crashes on the master |