On Wed, Jul 8, 2015 at 3:20 AM, Ashutosh Bapat < ashutosh.ba...@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) Is this reasonable? Regards, -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL >> Timbira: http://www.timbira.com.br >> Blog: http://fabriziomello.github.io >> Linkedin: http://br.linkedin.com/in/fabriziomello >> Twitter: http://twitter.com/fabriziomello >> Github: http://github.com/fabriziomello
