Skip site navigation (1) Skip section navigation (2)


From: Noah Misch <noah(at)leadboat(dot)com>
To: Leonardo Francalanci <m_lists(at)yahoo(dot)it>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: switch UNLOGGED to LOGGED
Date: 2011-05-27 10:19:22
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, May 27, 2011 at 10:49:13AM +0100, Leonardo Francalanci wrote:
> > From: Noah Misch <noah(at)leadboat(dot)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.


In response to


pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2011-05-27 10:37:54
Subject: Re: Online base backup from the hot-standby
Previous:From: Pavel StehuleDate: 2011-05-27 10:12:52
Subject: Re: compatibility issue with DirectFunctionCall1

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group