On Fri, May 20, 2011 at 09:37:20AM +0100, Leonardo Francalanci wrote: > I'll try to sum up what I understood: > > 1) the standby keeps the lock, so no problem with > stray files coming from the unlogged->logged log > reply, as the table can't be read during the operation > > 2) calling ResetUnloggedRelations before > ProcArrayApplyRecoveryInfo would remove the problem > of the stray files on the standby in case of master crash > before commit/abort > > 3) promoting the standby shouldn't be an issue, > since ResetUnloggedRelations is already called in > ShutdownRecoveryTransactionEnvironment
All correct, as far as I can tell. > Now, to move forward, some questions: > > - the patch is missing the "send all table pages to the > standby" part; is there some code I can use as base? Nothing comes to mind as especially similar. > I guess I have to generate some special log type that > is only "played" by standby servers. What you described in your followup mail seemed reasonable. > - on the standby, the commit part should be played as it > is on the master (that is, removing the INIT fork). > The abort case is different though: it would mean > doing nothing on the master, while removing every forks > but the INIT fork on the standby. > Would it be ok to add to xl_xact_abort a new array of > RelFileNode(s), where for each one at abort all the forks, > except the init fork, have to be deleted by the standby > (while the master shouldn't do anything with them)? > I bet there's a cleaner solution... Your "use less space in xl_xact_commit patch" seems to be going in a good direction here. It would probably also be okay to do a ResetUnloggedRelations() on the standby at every abort of a transaction that had started an UNLOGGED -> LOGGED conversion. That is, just a flag might be enough. nm -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
