Re: Online base backup from the hot-standby

From: Jun Ishiduka <ishizuka(dot)jun(at)po(dot)ntts(dot)co(dot)jp>
To: masao(dot)fujii(at)gmail(dot)com
Cc: ssinger_pg(at)sympatico(dot)ca, simon(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org, magnus(at)hagander(dot)net, robertmhaas(at)gmail(dot)com, cedric(dot)villemain(dot)debian(at)gmail(dot)com, heikki(dot)linnakangas(at)enterprisedb(dot)com
Subject: Re: Online base backup from the hot-standby
Date: 2011-10-13 09:39:09
Message-ID: 201110130940.p9D9eRJf013397@ccmds32.silk.ntts.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


>
> > > > ERROR: full_page_writes on master is set invalid at least once since
> > > > latest checkpoint
> > > >
> > > > I think this error should be rewritten as
> > > > ERROR: full_page_writes on master has been off at some point since
> > > > latest checkpoint
> > > >
> > > > We should be using 'off' instead of 'invalid' since that is what is what
> > > > the user sets it to.
> > >
> > > Sure.
> >
> > What about the following message? It sounds more precise to me.
> >
> > ERROR: WAL generated with full_page_writes=off was replayed since last
> > restartpoint
>
> Okay, I changes the patch to this messages.
> If someone says there is a idea better than it, I will consider again.
>
>
> > > I updated to patch corresponded above-comments.
> >
> > Thanks for updating the patch! Here are the comments:
> >
> > * don't yet have the insert lock, forcePageWrites could change under us,
> > * but we'll recheck it once we have the lock.
> > */
> > - doPageWrites = fullPageWrites || Insert->forcePageWrites;
> > + doPageWrites = Insert->fullPageWrites || Insert->forcePageWrites;
> >
> > The source comment needs to be modified.
> >
> > * just turned off, we could recompute the record without full pages, but
> > * we choose not to bother.)
> > */
> > - if (Insert->forcePageWrites && !doPageWrites)
> > + if ((Insert->fullPageWrites || Insert->forcePageWrites) && !doPageWrites)
> >
> > Same as above.
>
> Sure.
>
>
> > XLogReportParameters() should skip writing WAL if full_page_writes has not been
> > changed by SIGHUP.
> >
> > XLogReportParameters() should skip updating pg_control if any parameter related
> > to hot standby has not been changed.
>
> YES.
>
>
> > In checkpoint, XLogReportParameters() is called only when wal_level is
> > hot_standby.
> > OTOH, in walwriter, it's always called even when wal_level is not hot_standby.
> > Can't we skip calling XLogReportParameters() whenever wal_level is not
> > hot_standby?
>
> Yes, It is possible.
>
>
> > In do_pg_start_backup() and do_pg_stop_backup(), the spinlock must be held to
> > see XLogCtl->lastFpwDisabledLSN.
>
> Yes.
>
>
> > What about changing the error message to:
> > ERROR: WAL generated with full_page_writes=off was replayed during online backup
>
> Okay, too.

> Sorry.
> I was not previously able to answer fujii's all comments.
> This is the remaining answers.
>
>
> > + LWLockAcquire(WALInsertLock, LW_EXCLUSIVE);
> > + XLogCtl->Insert.fullPageWrites = fullPageWrites;
> > + LWLockRelease(WALInsertLock);
> >
> > I don't think WALInsertLock needs to be hold here because there is no
> > concurrently running process which can access Insert.fullPageWrites.
> > For example, Insert->currpos and Insert->LogwrtResult are also changed
> > without the lock there.
> >
>
> Yes.
>
> > The source comment of XLogReportParameters() needs to be modified.
>
> Yes, too.

Done.
I updated to patch corresponded above-comments.

Regards.

--------------------------------------------
Jun Ishizuka
NTT Software Corporation
TEL:045-317-7018
E-Mail: ishizuka(dot)jun(at)po(dot)ntts(dot)co(dot)jp
--------------------------------------------

Attachment Content-Type Size
standby_online_backup_09base-04fpw.patch application/octet-stream 14.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kohei KaiGai 2011-10-13 10:48:10 Re: [v9.2] Object access hooks with arguments support (v1)
Previous Message Martijn van Oosterhout 2011-10-13 07:20:26 Re: patch: move dumpUserConfig call in dumpRoles function of pg_dumpall.c