On Fri, May 27, 2011 at 10:49:13AM +0100, Leonardo Francalanci wrote: > > From: Noah Misch <n...@leadboat.com> > > > - 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. > > > So, it's ok to have a log item that is replayed only if > > WalRcvInProgress() > > is true?
No, that checks for WAL streaming in particular. A log-shipping standby needs the same treatment. > Is it a correct approach? I couldn't find any other way to > find out if we are in a standby or a master... InArchiveRecovery looks like the right thing, but it's currently static to xlog.c. Perhaps exporting that is the way to go. > > > - 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. > > ok, but that would mean that a transaction that aborts a conversion > would try to reset all unlogged relations (traversing all the FS)... > I don't know if that's acceptable performance-wise. I'm not sure, either, but I don't figure such operations will be at all common. nm -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
