On Wed, Jul 8, 2015 at 3:20 AM, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> wrote: > >> >> My intention for the 6th step is all recorded to wal, so if a crash occurs the recovery process clean the mess. >> > > AFAIU, PostgreSQL recovery is based on "redo"ing WAL. What you described earlier, "undo"ing based on the WAL does not fit in the current framework.
>
Understood!
>> >> During the recovery to check the status of a transaction can I use src/backend/access/transam/clog.c:TransactionIdGetStatus ? I'm asking because I don't know this part of code to much. > > > AFAIU, not unless all WALs (or atleast WALs till the commit/abort record of the transaction in question) are replayed. >
So we'll need to execute this procedure after replay, then the "ResetUnloggedTables" should be executed in two phases:
1) Before the replay checking just the datafiles with the init fork (_init)
2) After the replay checking the datafiles with the stamped init fork ( _init_XID, or something else)
