Re: switch UNLOGGED to LOGGED

From: Leonardo Francalanci <m_lists(at)yahoo(dot)it>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: switch UNLOGGED to LOGGED
Date: 2011-05-27 09:49:13
Message-ID: 877544.35185.qm@web29010.mail.ird.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Is it a correct approach? I couldn't find any other way to
find out if we are in a standby or a master...

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2011-05-27 10:10:41 Re: compatibility issue with DirectFunctionCall1
Previous Message Pavel Stehule 2011-05-27 09:06:39 compatibility issue with DirectFunctionCall1