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.


>> 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?


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

Reply via email to