Re: [HACKERS] GSoC 2015 proposal: Improve the performance of “ALTER TABLE .. SET LOGGED / UNLOGGED” statement

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)

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