Thread: Infrastructure changes for recovery
I would like to propose some changes to the infrastructure for recovery. These changes are beneficial in themselves, but also form the basis for other work we might later contemplate. Currently * the startup process performs restartpoints during recovery * the death of the startup process is tied directly to the change of state in the postmaster following recovery I propose to * have startup process signal postmaster when it starts Redo phase (if it starts it) * have startup process signal postmaster again when it has completed recovery, so that the change of state is via explicit signal rather than death of the child process Decoupling things in this way allows us to 1. arrange for the bgwriter to start during Redo, so it can: i) clean dirty blocks for the startup process ii) perform restartpoints in background Both of these aspects will increase performance of recovery 2. provide a starting point for other changes in both startup process and postmaster. These would include i) have startup process do other work after startup completes, such as executing transactions to rebuild damaged indexes, etc ii) have postmaster allow connections while Redo is taking place, as one part of allowing query access to standby database The above two points have not been discussed and require separate justification. However, any work on them is impossible without these infrastructure changes. These changes are part of a general strategy of moving in beneficial steps towards various other goals, rather than attempting to create a super-patch on 1 Nov that conflicts with other patches incoming at that time. These parts are likely to conflict with synch replication work, so I want to resolve as much as possible on Sept Commitfest. The patch would include the required changes for bgwriter also. Any objections/alterations to these proposals, please? -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
Simon Riggs <simon@2ndquadrant.com> writes:
> I propose to
> * have startup process signal postmaster when it starts Redo phase (if
> it starts it)
Doesn't seem like "starts recovery" is the point at which you can start
letting clients into the DB. What you want is to reach a point at which
you're sure that the DB is internally consistent, though perhaps not
fully synced with the master. In a PITR recovery scenario this would
correspond to reaching the minimum safe stop point. In true crash
recovery I don't think you can let people in till you're done.
regards, tom lane
Simon Riggs wrote: > I propose to > * have startup process signal postmaster when it starts Redo phase (if > it starts it) I think the first is a good idea -- at least, if you can get the startup process to use the normal ReadBuffer code path instead of XLogReadBuffer. I don't really know what's needed for this to work, but there seem to be several layers of stuff that need to be up for this to work. > * have startup process signal postmaster again when it has completed > recovery, so that the change of state is via explicit signal rather than > death of the child process I'm not sure that this is very useful, because the startup process cannot do anything much. It is an auxiliary process, which means it can't connect to a database and it can't run transactions. This other idea: > ii) have postmaster allow connections while Redo is taking place, as one > part of allowing query access to standby database is interesting and I'm sure it would be very welcome. Of course, it is first necessary to be able to run transactions in true "read only" mode, which perhaps is nowadays not so difficult given the work with VXids. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Thu, 2008-08-07 at 10:48 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndquadrant.com> writes: > > I propose to > > * have startup process signal postmaster when it starts Redo phase (if > > it starts it) > > Doesn't seem like "starts recovery" is the point at which you can start > letting clients into the DB. What you want is to reach a point at which > you're sure that the DB is internally consistent, though perhaps not > fully synced with the master. In a PITR recovery scenario this would > correspond to reaching the minimum safe stop point. In true crash > recovery I don't think you can let people in till you're done. Ack to both, no worries: just worded it a little too loosely. For crash recovery we could let them in earlier, but I think its going to recover faster if we don't. So, yes, only during archive recovery and therefore only from min safe stopping point. That will mean bgwriter is only active during archive recovery, but that's not important, since we (almost) never perform restartpoints during crash recovery. For other background I should also mention that this architecture proposal is different from Florian's SoC proposals, which had a separate recovery process to perform the work after the min safe stopping point. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
On Thu, 2008-08-07 at 10:56 -0400, Alvaro Herrera wrote: > > * have startup process signal postmaster again when it has completed > > recovery, so that the change of state is via explicit signal rather than > > death of the child process > > I'm not sure that this is very useful, because the startup process > cannot do anything much. It is an auxiliary process, which means it > can't connect to a database and it can't run transactions. Yes, but its going to be a lot easier to make it do transactions than it will be to spawn something else that does? Or so I thought... Specifically, I want to have a rmgr_post_cleanup() call to perform such actions. Who do you think should run those calls? They might need transactions, or not, depending upon the rmgr. I envisage initially that rmgrs could mark indexes as Invalid in pg_class, which requires a transaction (or does it?). If we did alter rmgrs to allow them to actually rebuild an index, then it would be desirable to have them do it in parallel, just like AV workers. Would it be possible to use have startup to run rmgr_post_cleanup, then provide a facility to have them run tasks through AV workers? Sounds like a separate patch anyway. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
On Thu, 2008-08-07 at 10:56 -0400, Alvaro Herrera wrote: > Simon Riggs wrote: > > ii) have postmaster allow connections while Redo is taking place, as > one > > part of allowing query access to standby database > > is interesting and I'm sure it would be very welcome. Of course, it > is first necessary to be able to run transactions in true "read only" > mode, which perhaps is nowadays not so difficult given the work with > VXids. Maybe I am assuming that part is easier than I thought. Florian's contribution with the VXid work should not be understated. I was going to spread the setting of the global variable InRedo to all backends, so they would be able to answer the question IsInRedo(). Anybody attempting to assign a new TransactionId would check this and then exit with an ERROR. There would also be a check in XLogInsert(), in case the first case doesn't catch everything or everyone. Transactions would also run as read-only transactions to keep the front door locked. Anything else you think needs bolting down? -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
On Tue, 2008-09-16 at 15:45 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndQuadrant.com> wrote: > > Testing takes a while on this, I probably won't complete it until > > Friday. So enclosed patch is for eyeballs only at this stage. > > What's the status on that patch? Having some trouble trying to get a clean state change from recovery to normal mode. Startup needs to be able to write WAL at the end of recovery so it can write a ShutdownCheckpoint, yet must not be allowed to write WAL before that. Other services are still not fully up yet. So every other process apart from Startup musn't write WAL until Startup has fully completed its actions, which is sometime later. bgwriter needs to know about the impending state change so it can finish off any checkpoint its currently working on. But then can't start doing normal processing yet either. So it must have a third state that is between recovery and normal processing. When normal processing is reached, it *must* write WAL immediately from that point onwards, yet using the new timeline that startup decides upon. So the idea of a single database-wide boolean state seems impossible. We need a local canInsertWAL flag that is set at different times in different processes. Global states changes are now not started started - postmaster process then startup process safestoppingpoint - bgwriter starts startup_does_shutdown_checkpoint - bgwriter finishes up, just waits, startup is now allowed to insert WAL for checkpoint record startup completes StartupXLog - bgwriter begins normal processing startup exits - postmaster in normal state We *might* solve this by making the final checkpoint that Startup writes into an online checkpoint. That would then allow a straight and safe transition for bgwriter from just one state to the other. But that leaves some other ugliness that I don't want to deal with, 'cos there's other fish frying. Feels like I should shutdown the bgwriter after recovery and then allow it to be cranked up again after normal processing starts, and do all of this through postmaster state changes. That way bgwriter doesn't need to do a dynamic state change. Comments anyone? -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
On Thu, 2008-09-18 at 09:05 +0100, Simon Riggs wrote: > Feels like I should shutdown the bgwriter after recovery and then > allow it to be cranked up again after normal processing starts, and do > all of this through postmaster state changes. That way bgwriter > doesn't need to do a dynamic state change. This approach appears to be working nicely so far. Some ugly bits of former patch removed. Patch passes basic tests and changes state cleanly. Restarting test cycle on this patch now, confirm tomorrow. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
Attachment
Simon Riggs <simon@2ndQuadrant.com> writes:
> Having some trouble trying to get a clean state change from recovery to
> normal mode.
> Startup needs to be able to write WAL at the end of recovery so it can
> write a ShutdownCheckpoint, yet must not be allowed to write WAL before
> that. Other services are still not fully up yet. So every other process
> apart from Startup musn't write WAL until Startup has fully completed
> its actions, which is sometime later.
> ...
> We *might* solve this by making the final checkpoint that Startup writes
> into an online checkpoint.
Do we really need a checkpoint there at all? I can't recall right now
if there was a good reason why Vadim made it do that. I have a feeling
that it might have had to do with an assumption that the recovery
environment was completely distinct from live environment; which is a
statement that's certainly not going to be true in a query-answering
slave.
regards, tom lane
On Thu, 2008-09-18 at 09:06 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: > > Having some trouble trying to get a clean state change from recovery to > > normal mode. > > > Startup needs to be able to write WAL at the end of recovery so it can > > write a ShutdownCheckpoint, yet must not be allowed to write WAL before > > that. Other services are still not fully up yet. So every other process > > apart from Startup musn't write WAL until Startup has fully completed > > its actions, which is sometime later. > > ... > > We *might* solve this by making the final checkpoint that Startup writes > > into an online checkpoint. > > Do we really need a checkpoint there at all? I can't recall right now > if there was a good reason why Vadim made it do that. I have a feeling > that it might have had to do with an assumption that the recovery > environment was completely distinct from live environment; which is a > statement that's certainly not going to be true in a query-answering > slave. Hmm, a question I hadn't considered. We definitely don't want to do PreallocXlogFiles(). "Timelines only change at shutdown checkpoints". But its just as easy to write a short timeline change record rather than the checkpoint itself, so we can sort that out. It should be sufficient to request bgwriter to perform an immediate checkpoint, rather than have startup process perform it. That way startup can exit and we can change to normal processing faster. If we crash before the next checkpoint then we would revert to archive recovery or crash recovery. The last restartpoint might well be somewhere else. In streaming mode we would presumably have that data locally, so not really a problem. But we musn't mark control file in production yet, but we can do so following the next checkpoint. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
Simon Riggs <simon@2ndQuadrant.com> writes:
> On Thu, 2008-09-18 at 09:06 -0400, Tom Lane wrote:
>> Do we really need a checkpoint there at all?
> "Timelines only change at shutdown checkpoints".
Hmm. I *think* that that is just a debugging crosscheck rather than a
critical property. But yeah, it would take some close investigation,
which maybe isn't warranted if you have a less-invasive solution.
regards, tom lane
On Thu, 2008-09-18 at 10:09 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: > > On Thu, 2008-09-18 at 09:06 -0400, Tom Lane wrote: > >> Do we really need a checkpoint there at all? > > > "Timelines only change at shutdown checkpoints". > > Hmm. I *think* that that is just a debugging crosscheck rather than a > critical property. But yeah, it would take some close investigation, > which maybe isn't warranted if you have a less-invasive solution. The important thing is that everybody uses the new timelineid. AFAICS we actually write new timelineids into the WAL file if the previous timelineid, so it can't be that risky. Ignore v5 then and look for v6 on Monday. Hopefully the final one :-) -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
On Thu, 2008-09-18 at 10:09 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: > > On Thu, 2008-09-18 at 09:06 -0400, Tom Lane wrote: > >> Do we really need a checkpoint there at all? > > > "Timelines only change at shutdown checkpoints". > > Hmm. I *think* that that is just a debugging crosscheck rather than a > critical property. But yeah, it would take some close investigation, > which maybe isn't warranted if you have a less-invasive solution. OK, new patch, version 6. Some major differences to previous patch. * new IsRecoveryProcessingMode() in shmem * padding in XLogCtl to ensure above call is cheap * specific part of bgwriter shmem for passing restartpoint data * avoid Shutdown checkpoint at end of recovery, with carefully considered positioning of statements (beware!) * only one new postmaster mode, PM_RECOVERY * bgwriter changes state without stopping/starting Modes I have tested so far * make check * Start, Stop * Crash Recovery * Archive Recovery * Archive Recovery, switch in middle of restartpoint Modes not yet tested * EXEC_BACKEND Ready for serious review prior to commit. I will be performing further testing also. backend/access/transam/multixact.c | 2 backend/access/transam/xlog.c | 328 ++++++++++++---!!!!!!!!!!!! backend/postmaster/bgwriter.c | 371 +++++---!!!!!!!!!!!!!!!!!!!!! backend/postmaster/postmaster.c | 62 ++++!! backend/storage/buffer/README | 5 backend/storage/buffer/bufmgr.c | 34 +!! include/access/xlog.h | 14 ! include/access/xlog_internal.h | 3 include/catalog/pg_control.h | 2 include/postmaster/bgwriter.h | 2 include/storage/bufmgr.h | 2 include/storage/pmsignal.h | 1 12 files changed, 279 insertions(+), 56 deletions(-), 491 mods(!) There's a few subtle points along the way. I've tried to explain them all in code comments, but questions welcome. At v6, most things are now done a particular way for a specific reason. Look especially at InRecovery, which is used extensively in different parts of the code. The meaning of this has been subdivided into two meanings, so only *some* of the places that use it have been changed. All have been checked. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
Attachment
On Mon, 2008-09-22 at 23:06 +0100, Simon Riggs wrote: > On Thu, 2008-09-18 at 10:09 -0400, Tom Lane wrote: > > Simon Riggs <simon@2ndQuadrant.com> writes: > > > On Thu, 2008-09-18 at 09:06 -0400, Tom Lane wrote: > > >> Do we really need a checkpoint there at all? > > > > > "Timelines only change at shutdown checkpoints". > > > > Hmm. I *think* that that is just a debugging crosscheck rather than a > > critical property. But yeah, it would take some close investigation, > > which maybe isn't warranted if you have a less-invasive solution. > > OK, new patch, version 6. Some major differences to previous patch. > Ready for serious review prior to commit. I will be performing further > testing also. Version 7 I've removed the concept of interrupting a restartpoint half way through, I found a fault there. It was more ugly than the alternative and less robust. The code now waits at the end of recovery if we are in the middle of a restartpoint, but forces a do-it-more-quickly also. That means we won't always get a fast start even though we skip the shutdown checkpoint, but at least we're sure there's no chance of breakage because of concurrent activiy, state changes etc.. I'm happy with this now. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
Attachment
Simon Riggs <simon@2ndQuadrant.com> writes:
> Version 7
After reading this for awhile, I realized that there is a rather
fundamental problem with it: it switches into "consistent recovery"
mode as soon as it's read WAL beyond ControlFile->minRecoveryPoint.
In a crash recovery situation that typically is before the last
checkpoint (if indeed it's not still zero), and what that means is
that this patch will activate the bgwriter and start letting in
backends instantaneously after a crash, long before we can have any
certainty that the DB state really is consistent.
In a normal crash recovery situation this would be easily fixed by
simply not letting it go to "consistent recovery" state at all, but
what about recovery from a restartpoint? We don't want a slave that's
crashed once to never let backends in again. But I don't see how to
determine that we're far enough past the restartpoint to be consistent
again. In crash recovery we assume (without proof ;-)) that we're
consistent once we reach the end of valid-looking WAL, but that rule
doesn't help for a slave that's following a continuing WAL sequence.
Perhaps something could be done based on noting when we have to pull in
a WAL segment from the recovery_command, but it sounds like a pretty
fragile assumption.
Anyway, that's sufficiently bad that I'm bouncing the patch for
reconsideration. Some other issues I noted before giving up:
* I'm a bit uncomfortable with the fact that the
IsRecoveryProcessingMode flag is read and written with no lock.
There's no atomicity or concurrent-write problem, sure, but on
a multiprocessor with weak memory ordering guarantees (eg PPC)
readers could get a fairly stale value of the flag. The false
to true transition happens before anyone except the startup process is
running, so that's no problem; the net effect is then that backends
might think that recovery mode was still active for awhile after it
wasn't. This seems a bit scary, eg in the patch as it stands that'll
disable XLogFlush calls that should have happened. You could fix that
by grabbing/releasing some spinlock (any old one) around the accesses,
but are any of the call sites performance-critical? The one in
XLogInsert looks like it is, if nothing else.
* I kinda think you broke XLogFlush anyway. It's certainly clear
that the WARNING case at the bottom is unreachable with the patch,
and I think that means that you've messed up an important error
robustness behavior. Is it still possible to get out of recovery mode
if there are any bad LSNs in the shared buffer pool?
* The use of InRecovery in CreateCheckPoint seems pretty bogus, since
that function can be called from the bgwriter in which the flag will
never be true. Either this needs to be IsRecoveryProcessingMode(),
or it's useless because we'll never create ordinary checkpoints until
after subtrans.c is up anyway.
* The patch moves the clearing of InRecovery from after to before
StartupCLOG, RecoverPreparedTransactions, etc. Is that really a
good idea? It makes it hard for those modules to know if they are
coming up after a normal or recovery startup. I think they may not
care at the moment, but I'd leave that alone without a darn good
reason to change it.
* The comment about CheckpointLock being only pro forma is now wrong,
if you are going to use locking it to implement a delay in exitRecovery.
But I don't understand why the delay there. If it's needed, seems like
the path where a restartpoint *isn't* in progress is wrong --- don't you
actually need to start one and wait for it? Also I note that if the
LWLockConditionalAcquire succeeds, you neglect to release the lock,
which surely can't be right.
* The tail end of StartupXLOG() looks pretty unsafe to me. Surely
we mustn't clear IsRecoveryProcessingMode until after we have
established the safe-recovery checkpoint. The comments there seem to
be only vaguely related to the current state of the patch, too.
* Logging of recoveryLastXTime seems pretty bogus now. It's supposed to
be associated with a restartpoint completion report, but now it's just
out in the ether somewhere and doesn't represent a guarantee that we're
synchronized that far.
* backup.sgml needs to be updated to say that log_restartpoints is
obsolete.
* There are a bunch of disturbing assumptions in the SLRU-related
modules about their StartUp calls being executed without any concurrent
access. This isn't really a problem that needs to be dealt with in this
patch, I think, but that will all have to be cleaned up before we dare
allow any backends to run concurrently with recovery. btree's
suppression of relcache invals for metapage updates will be a problem
too.
regards, tom lane
On Thu, 2008-09-25 at 18:28 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > Version 7
> Anyway, that's sufficiently bad that I'm bouncing the patch for
> reconsideration.
No problem, I understand this needs discussion.
There's less detail here than first appears. There are some basic points
to consider from which all else follows.
> After reading this for awhile, I realized that there is a rather
> fundamental problem with it: it switches into "consistent recovery"
> mode as soon as it's read WAL beyond ControlFile->minRecoveryPoint.
> In a crash recovery situation that typically is before the last
> checkpoint (if indeed it's not still zero), and what that means is
> that this patch will activate the bgwriter and start letting in
> backends instantaneously after a crash, long before we can have any
> certainty that the DB state really is consistent.
>
> In a normal crash recovery situation this would be easily fixed by
> simply not letting it go to "consistent recovery" state at all, but
> what about recovery from a restartpoint? We don't want a slave that's
> crashed once to never let backends in again. But I don't see how to
> determine that we're far enough past the restartpoint to be consistent
> again. In crash recovery we assume (without proof ;-)) that we're
> consistent once we reach the end of valid-looking WAL, but that rule
> doesn't help for a slave that's following a continuing WAL sequence.
>
> Perhaps something could be done based on noting when we have to pull in
> a WAL segment from the recovery_command, but it sounds like a pretty
> fragile assumption.
Seems like we just say we only signal the postmaster if
InArchiveRecovery. Archive recovery from a restartpoint is still archive
recovery, so this shouldn't be a problem in the way you mention. The
presence of recovery.conf overrides all other cases.
> Some other issues I noted before giving up:
All of these issues raised can be addressed, but I think the main
decision we need to make is not so much about running other processes
but about when it can start and when they have to change mode.
When they can start seems solvable, as above.
When/how they must change state from recovery to normal mode seems more
difficult. State change must be atomic across all processes, but also
done at a micro level so that XLogFlush tests for the state change. The
overhead of continually checking seems high, so I am tempted to say lets
just kick 'em all off and then let them back on again. That's easily
accomplished for bgwriter without anybody noticing much. For Hot Standby
that would mean that a failover would kick off all query backends. I can
see why that would be both desirable and undesirable.
Anyway, from here I propose:
* we keep the shutdown checkpoint
* we kick off bgwriter (and any children) then let 'em back on again so
they can initialise in a different mode.
To do that, I just need to dust off a previous version of the patch. So
we can sort this out quickly if we have a clear way to proceed.
------------------------------------------------------------------
other comments relate to this current patch, so further discussion of
the points below may not be required, if we agree how to proceed as
above.
> * I'm a bit uncomfortable with the fact that the
> IsRecoveryProcessingMode flag is read and written with no lock.
> There's no atomicity or concurrent-write problem, sure, but on
> a multiprocessor with weak memory ordering guarantees (eg PPC)
> readers could get a fairly stale value of the flag. The false
> to true transition happens before anyone except the startup process is
> running, so that's no problem; the net effect is then that backends
> might think that recovery mode was still active for awhile after it
> wasn't. This seems a bit scary, eg in the patch as it stands that'll
> disable XLogFlush calls that should have happened. You could fix that
> by grabbing/releasing some spinlock (any old one) around the accesses,
> but are any of the call sites performance-critical? The one in
> XLogInsert looks like it is, if nothing else.
Agreed.
It's not a dynamic state, so I can fix that inside
IsRecoveryProcessingMode() with a local state to make check faster.
bool
IsRecoveryProcessingMode(void)
{
if (!IsRecoveryProcessingMode)
return false;
{
/* use volatile pointer to prevent code rearrangement */
volatile XLogCtlData *xlogctl = XLogCtl;
SpinLockAcquire(&xlogctl->mode_lck);
RecoveryProcessingMode = XLogCtl->IsRecoveryProcessingMode;
SpinLockRelease(&xlogctl->mode_lck);
}
return IsRecoveryProcessingMode;
}
This only applies if we decide not to kick everybody off, change state
and then let them back on again.
> * I kinda think you broke XLogFlush anyway. It's certainly clear
> that the WARNING case at the bottom is unreachable with the patch,
> and I think that means that you've messed up an important error
> robustness behavior. Is it still possible to get out of recovery mode
> if there are any bad LSNs in the shared buffer pool?
Perhaps. But the WARNING could only occur during shutdown checkpoints.
This specifically patch avoids those, so the case would never arise with
this patch and needs no avoidance. Yes, you can still leave recovery
mode if there are bad LSNs with this patch, but you won't know what they
are because of the lack of the shutdown checkpoint. Probably an argument
in favour of allowing shutdown checkpoints.
> * The use of InRecovery in CreateCheckPoint seems pretty bogus, since
> that function can be called from the bgwriter in which the flag will
> never be true. Either this needs to be IsRecoveryProcessingMode(),
> or it's useless because we'll never create ordinary checkpoints until
> after subtrans.c is up anyway.
Exactly. bgwriter never needs this to be set because it writes
restorepoints before this, using different code path.
> * The patch moves the clearing of InRecovery from after to before
> StartupCLOG, RecoverPreparedTransactions, etc. Is that really a
> good idea? It makes it hard for those modules to know if they are
> coming up after a normal or recovery startup. I think they may not
> care at the moment, but I'd leave that alone without a darn good
> reason to change it.
I didn't move this as you say. It already was before StartupClog.
I moved it into exitRecovery() only, so it was unset in the same way
exitArchiveRecovery sets InArchiveRecovery to false. So refactoring, no
change of sequencing.
> * The comment about CheckpointLock being only pro forma is now wrong,
> if you are going to use locking it to implement a delay in exitRecovery.
> But I don't understand why the delay there. If it's needed, seems like
> the path where a restartpoint *isn't* in progress is wrong --- don't you
> actually need to start one and wait for it?
All of this ducking and diving is because of the bgwriter needing to
perform a state change. That's the ball to keep our eye on.
After much thrashing, I decided that interrupting a restartpoint is too
dangerous a thing to want to do. If we're in the middle of one, we
finish it, if not there's no need to interrupt it.
> Also I note that if the
> LWLockConditionalAcquire succeeds, you neglect to release the lock,
> which surely can't be right.
Doh. Thanks.
> * The tail end of StartupXLOG() looks pretty unsafe to me. Surely
> we mustn't clear IsRecoveryProcessingMode until after we have
> established the safe-recovery checkpoint. The comments there seem to
> be only vaguely related to the current state of the patch, too.
The whole point was to remove the ShutdownCheckpoint, but it sounds like
you're not keen on that any more.
I'm neutral on this point: I can see why people would want it removed -
it will speed up failover. I can see why people would want it kept -
there is a slight window where if we crash we will need to go back to
archive recovery.
I had a workable solution that kept it, so will revert to it.
> * Logging of recoveryLastXTime seems pretty bogus now. It's supposed to
> be associated with a restartpoint completion report, but now it's just
> out in the ether somewhere and doesn't represent a guarantee that we're
> synchronized that far.
That last one was there before so we knew where the log ended. It was
not supposed to be associated with a restartpoint, just with end of log
purely for information (by user request, for when a log file is
corrupted and we need to know "when" we are up to).
> * backup.sgml needs to be updated to say that log_restartpoints is
> obsolete.
Yes
> * There are a bunch of disturbing assumptions in the SLRU-related
> modules about their StartUp calls being executed without any concurrent
> access. This isn't really a problem that needs to be dealt with in this
> patch, I think, but that will all have to be cleaned up before we dare
> allow any backends to run concurrently with recovery.
Well spotted, thanks.
> btree's
> suppression of relcache invals for metapage updates will be a problem
> too.
Again thanks. This patch is stand-alone from later work, thats why.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
On Fri, 2008-09-26 at 11:20 +0100, Simon Riggs wrote: > > After reading this for awhile, I realized that there is a rather > > fundamental problem with it: it switches into "consistent recovery" > > mode as soon as it's read WAL beyond ControlFile->minRecoveryPoint. > > In a crash recovery situation that typically is before the last > > checkpoint (if indeed it's not still zero), and what that means is > > that this patch will activate the bgwriter and start letting in > > backends instantaneously after a crash, long before we can have any > > certainty that the DB state really is consistent. > > > > In a normal crash recovery situation this would be easily fixed by > > simply not letting it go to "consistent recovery" state at all, but > > what about recovery from a restartpoint? We don't want a slave that's > > crashed once to never let backends in again. But I don't see how to > > determine that we're far enough past the restartpoint to be consistent > > again. In crash recovery we assume (without proof ;-)) that we're > > consistent once we reach the end of valid-looking WAL, but that rule > > doesn't help for a slave that's following a continuing WAL sequence. > > > > Perhaps something could be done based on noting when we have to pull in > > a WAL segment from the recovery_command, but it sounds like a pretty > > fragile assumption. > > Seems like we just say we only signal the postmaster if > InArchiveRecovery. Archive recovery from a restartpoint is still archive > recovery, so this shouldn't be a problem in the way you mention. The > presence of recovery.conf overrides all other cases. Anticipating your possible reponses, I would add this also: There has long been an annoying hole in the PITR scheme which is the support of recovery using a crashed database. That is there to support split mirror snapshots, but it creates a loophole where we don't know the min recovery location, circumventing the care we (you!) took to put stop/start backup in place. I think we need to add a parameter to recovery.conf that people can use to specify a minRecoveryPoint iff there in no backup label file. They can work out what this should be by following this procedure, which we should document: * split mirror, so you have offline copy of crashed database * copy database away to backup * go to running database and run pg_current_xlog_insert_location() * use the value to specify recovery_min_location If they don't specify this, then bgwriter will not start and you cannot run in Hot Standby mode. Their choice, so we need not worry then about the loophole any more. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
Simon Riggs <simon@2ndQuadrant.com> writes:
> On Thu, 2008-09-25 at 18:28 -0400, Tom Lane wrote:
>> After reading this for awhile, I realized that there is a rather
>> fundamental problem with it: it switches into "consistent recovery"
>> mode as soon as it's read WAL beyond ControlFile->minRecoveryPoint.
>> In a crash recovery situation that typically is before the last
>> checkpoint (if indeed it's not still zero), and what that means is
>> that this patch will activate the bgwriter and start letting in
>> backends instantaneously after a crash, long before we can have any
>> certainty that the DB state really is consistent.
>>
>> In a normal crash recovery situation this would be easily fixed by
>> simply not letting it go to "consistent recovery" state at all, but
>> what about recovery from a restartpoint? We don't want a slave that's
>> crashed once to never let backends in again. But I don't see how to
>> determine that we're far enough past the restartpoint to be consistent
>> again. In crash recovery we assume (without proof ;-)) that we're
>> consistent once we reach the end of valid-looking WAL, but that rule
>> doesn't help for a slave that's following a continuing WAL sequence.
>>
>> Perhaps something could be done based on noting when we have to pull in
>> a WAL segment from the recovery_command, but it sounds like a pretty
>> fragile assumption.
> Seems like we just say we only signal the postmaster if
> InArchiveRecovery. Archive recovery from a restartpoint is still archive
> recovery, so this shouldn't be a problem in the way you mention. The
> presence of recovery.conf overrides all other cases.
What that implements is my comment that we don't have to let anyone in
at all during a plain crash recovery. It does nothing AFAICS for the
problem that when restarting archive recovery from a restartpoint,
it's not clear when it is safe to start letting in backends. You need
to get past the highest LSN that has made it out to disk, and there is
no good way to know what that is.
Unless we can get past this problem the whole thing seems a bit dead in
the water :-(
>> * I'm a bit uncomfortable with the fact that the
>> IsRecoveryProcessingMode flag is read and written with no lock.
> It's not a dynamic state, so I can fix that inside
> IsRecoveryProcessingMode() with a local state to make check faster.
Erm, this code doesn't look like it can allow IsRecoveryProcessingMode
to become locally true in the first place? I guess you could fix it
by initializing IsRecoveryProcessingMode to true, but that seems likely
to break other places. Maybe better is to have an additional local
state variable showing whether the flag has ever been fetched from
shared memory.
The other issues don't seem worth arguing about ...
regards, tom lane
On Sun, 2008-09-28 at 14:02 -0400, Tom Lane wrote: > It does nothing AFAICS for the > problem that when restarting archive recovery from a restartpoint, > it's not clear when it is safe to start letting in backends. You need > to get past the highest LSN that has made it out to disk, and there is > no good way to know what that is. > > Unless we can get past this problem the whole thing seems a bit dead > in > the water :-( I agree the importance of your a problem but don't fully understand the circumstances under which you see a problem arising. AFAICS when we set minRecoveryLoc we *never* unset it. It's recorded in the controlfile, so whenever we restart we can see that it has been set previously and now we are beyond it. So if we crash during recovery and then restart *after* we reached minRecoveryLoc then we resume in safe mode almost immediately. If we crash during recovery before we reached minRecoveryLoc then we continue until we find it. There is a loophole, as described on separate post, but that can be plugged by offering explicit setting of the minRecoveryLoc from recovery.conf. Most people use pg_start_backup() so do not experience the need for that. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
Simon Riggs <simon@2ndQuadrant.com> writes:
>> It does nothing AFAICS for the
>> problem that when restarting archive recovery from a restartpoint,
>> it's not clear when it is safe to start letting in backends. You need
>> to get past the highest LSN that has made it out to disk, and there is
>> no good way to know what that is.
> AFAICS when we set minRecoveryLoc we *never* unset it. It's recorded in
> the controlfile, so whenever we restart we can see that it has been set
> previously and now we are beyond it.
Right ...
> So if we crash during recovery and
> then restart *after* we reached minRecoveryLoc then we resume in safe
> mode almost immediately.
Wrong.
What minRecoveryLoc is is an upper bound for the LSNs that might be
on-disk in the filesystem backup that an archive recovery starts from.
(Defined as such, it never changes during a restartpoint crash/restart.)
Once you pass that, the on-disk state as modified by any dirty buffers
inside the recovery process represents a consistent database state.
However, the on-disk state alone is not guaranteed consistent. As you
flush some (not all) of your shared buffers you enter other
not-certainly-consistent on-disk states. If we crash in such a state,
we know how to use the last restartpoint plus WAL replay to recover to
another state in which disk + dirty buffers are consistent. However,
we reach such a state only when we have read WAL to beyond the highest
LSN that has reached disk --- and in recovery mode there is no clean
way to determine what that was.
Perhaps a solution is to make XLogFLush not be a no-op in recovery mode,
but have it scribble a highest-LSN somewhere on stable storage (maybe
scribble on pg_control itself, or maybe better someplace else). I'm
not totally sure about that. But I am sure that doing nothing will
be unreliable.
regards, tom lane
On Sun, 2008-09-28 at 21:16 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: > >> It does nothing AFAICS for the > >> problem that when restarting archive recovery from a restartpoint, > >> it's not clear when it is safe to start letting in backends. You need > >> to get past the highest LSN that has made it out to disk, and there is > >> no good way to know what that is. > > > AFAICS when we set minRecoveryLoc we *never* unset it. It's recorded in > > the controlfile, so whenever we restart we can see that it has been set > > previously and now we are beyond it. > > Right ... > > > So if we crash during recovery and > > then restart *after* we reached minRecoveryLoc then we resume in safe > > mode almost immediately. > > Wrong. OK, see where you're coming from now. Solution is needed, I agree. > What minRecoveryLoc is is an upper bound for the LSNs that might be > on-disk in the filesystem backup that an archive recovery starts from. > (Defined as such, it never changes during a restartpoint crash/restart.) > Once you pass that, the on-disk state as modified by any dirty buffers > inside the recovery process represents a consistent database state. > However, the on-disk state alone is not guaranteed consistent. As you > flush some (not all) of your shared buffers you enter other > not-certainly-consistent on-disk states. If we crash in such a state, > we know how to use the last restartpoint plus WAL replay to recover to > another state in which disk + dirty buffers are consistent. However, > we reach such a state only when we have read WAL to beyond the highest > LSN that has reached disk --- and in recovery mode there is no clean > way to determine what that was. > > Perhaps a solution is to make XLogFLush not be a no-op in recovery mode, > but have it scribble a highest-LSN somewhere on stable storage (maybe > scribble on pg_control itself, or maybe better someplace else). I'm > not totally sure about that. But I am sure that doing nothing will > be unreliable. No need to write highest LSN to disk constantly... If we restart from a restartpoint then initially the current apply LSN will be potentially/probably earlier than the latest on-disk LSN, as you say. But once we have completed the next restartpoint *after* the value pg_control says then we will be guaranteed that the two LSNs are the same, since otherwise we would have restarted at a later point. That kinda works, but the problem is that restartpoints are time based, not log based. We need them to be deterministic for us to rely upon them in the above way. If we crash and then replay we can only be certain we are safe when we have found a restartpoint that the previous recovery will definitely have reached. So we must have log-based restartpoints, using either a constant LSN offset, or a parameter like checkpoint_segments. But if it is changeable then it needs to be written into the control file, so we don't make a mistake about it. So we need to: * add an extra test to delay safe point if required * write restart_segments value to control file * force a restartpoint on first valid checkpoint WAL record after we have passed restart_segments worth of log -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
Simon Riggs <simon@2ndQuadrant.com> writes:
> ... That kinda works, but the problem is that restartpoints are time based,
> not log based. We need them to be deterministic for us to rely upon them
> in the above way.
Right, but the performance disadvantages of making them strictly
log-distance-based are pretty daunting. We don't really want slaves
doing that while they're in catchup mode.
regards, tom lane
On Mon, 2008-09-29 at 08:46 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: > > ... That kinda works, but the problem is that restartpoints are time based, > > not log based. We need them to be deterministic for us to rely upon them > > in the above way. > > Right, but the performance disadvantages of making them strictly > log-distance-based are pretty daunting. We don't really want slaves > doing that while they're in catchup mode. I don't think we need to perform restartpoints actually, now I think about it. It's only the LSN that is important. I think we can get away with writing the LSN value to disk, as you suggested, but only every so often. No need to do it after every WAL record, just consistently every so often, so it gives us a point at which we know we are safe. We will need to have Startup process block momentarily while the value is written. Propose Startup process writes/flushes LSN to pg_control every time we change xlogid. That's independent of WAL file size and fairly clear. When we reach that LSN + 1 we will know that no LSNs higher than that value can have reached disk. OK? -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
Simon Riggs <simon@2ndQuadrant.com> writes:
> I think we can get away with writing the LSN value to disk, as you
> suggested, but only every so often. No need to do it after every WAL
> record, just consistently every so often, so it gives us a point at
> which we know we are safe.
Huh? How does that make you safe? What you need to know is the max
LSN that could possibly be on disk.
Hmm, actually we could get away with tying this to fetching WAL files
from the archive. When switching to a new WAL file, write out the
*ending* WAL address of that file to pg_control. Then process the WAL
records in it. Whether or not any of the affected pages get to disk,
we know that there is no LSN on disk exceeding what we already put in
pg_control. If we crash and restart, we'll have to get to the end
of this file before we start letting backends in; which might be further
than we actually got before the crash, but not too much further because
we already know the whole WAL file is available.
Or is that the same thing you were saying? The detail about using
the end address seems fairly critical, and you didn't mention it...
regards, tom lane
On Mon, 2008-09-29 at 10:13 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: > > I think we can get away with writing the LSN value to disk, as you > > suggested, but only every so often. No need to do it after every WAL > > record, just consistently every so often, so it gives us a point at > > which we know we are safe. > > Huh? How does that make you safe? What you need to know is the max > LSN that could possibly be on disk. > > Hmm, actually we could get away with tying this to fetching WAL files > from the archive. When switching to a new WAL file, write out the > *ending* WAL address of that file to pg_control. Then process the WAL > records in it. Whether or not any of the affected pages get to disk, > we know that there is no LSN on disk exceeding what we already put in > pg_control. If we crash and restart, we'll have to get to the end > of this file before we start letting backends in; which might be further > than we actually got before the crash, but not too much further because > we already know the whole WAL file is available. > > Or is that the same thing you were saying? The detail about using > the end address seems fairly critical, and you didn't mention it... Same! Just said safe point was "LSN + 1", and since end = next start. Looks we've got a solution, no matter how it's described. (I actually have a more detailed proof of safety using snapshots/MVCC considerations so I wasn't overly worried but what we've discussed is much easier to understand and agree. Proof of safety is all we need, and this simpler proof is more secure.) Don't want to make it per file though. Big systems can whizz through WAL files very quickly, so we either make it a big number e.g. 255 files per xlogid, or we make it settable (and recorded in pg_control). -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
Simon Riggs <simon@2ndQuadrant.com> writes:
> On Mon, 2008-09-29 at 10:13 -0400, Tom Lane wrote:
>> ... If we crash and restart, we'll have to get to the end
>> of this file before we start letting backends in; which might be further
>> than we actually got before the crash, but not too much further because
>> we already know the whole WAL file is available.
> Don't want to make it per file though. Big systems can whizz through WAL
> files very quickly, so we either make it a big number e.g. 255 files per
> xlogid, or we make it settable (and recorded in pg_control).
I think you are missing the point I made above. If you set the
okay-to-resume point N files ahead, and then the master stops generating
files so quickly, you've got a problem --- it might be a long time until
the slave starts letting backends in after a crash/restart.
Fetching a new WAL segment from the archive is expensive enough that an
additional write/fsync per cycle doesn't seem that big a problem to me.
There's almost certainly a few fsync-equivalents going on in the
filesystem to create and delete the retrieved segment files.
regards, tom lane
On Mon, 2008-09-29 at 11:24 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: > > On Mon, 2008-09-29 at 10:13 -0400, Tom Lane wrote: > >> ... If we crash and restart, we'll have to get to the end > >> of this file before we start letting backends in; which might be further > >> than we actually got before the crash, but not too much further because > >> we already know the whole WAL file is available. > > > Don't want to make it per file though. Big systems can whizz through WAL > > files very quickly, so we either make it a big number e.g. 255 files per > > xlogid, or we make it settable (and recorded in pg_control). > > I think you are missing the point I made above. If you set the > okay-to-resume point N files ahead, and then the master stops generating > files so quickly, you've got a problem --- it might be a long time until > the slave starts letting backends in after a crash/restart. > > Fetching a new WAL segment from the archive is expensive enough that an > additional write/fsync per cycle doesn't seem that big a problem to me. > There's almost certainly a few fsync-equivalents going on in the > filesystem to create and delete the retrieved segment files. Didn't miss yer point, just didn't agree. :-) I'll put it at one (1) and then wait for any negative perf reports. No need to worry about things like that until later. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
On Thu, 2008-09-25 at 18:28 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: > > Version 7 > > After reading this for awhile, I realized that there is a rather > fundamental problem with it: it switches into "consistent recovery" > mode as soon as it's read WAL beyond ControlFile->minRecoveryPoint. Just seen this patch has been bounced into November CommitFest, even though the new patch fixes all of the concerns raised. I'm concerned that this is going to make the final Hot Standby patch fairly large, which will make it even harder to review, test and generally get accepted. What's the best way to make this easier for you/others to review? -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
Simon Riggs wrote: > On Thu, 2008-09-25 at 18:28 -0400, Tom Lane wrote: > >> Simon Riggs <simon@2ndQuadrant.com> writes: >> >>> Version 7 >>> >> After reading this for awhile, I realized that there is a rather >> fundamental problem with it: it switches into "consistent recovery" >> mode as soon as it's read WAL beyond ControlFile->minRecoveryPoint. >> > > Just seen this patch has been bounced into November CommitFest, even > though the new patch fixes all of the concerns raised. > > I'm concerned that this is going to make the final Hot Standby patch > fairly large, which will make it even harder to review, test and > generally get accepted. > > What's the best way to make this easier for you/others to review? > > The fact that it's been put on the November list doesn't mean it can't be reviewed and committed before then. cheers andrew
On Thu, 2008-10-02 at 19:07 -0400, Andrew Dunstan wrote: > Simon Riggs wrote: > > Just seen this patch has been bounced into November CommitFest, even > > though the new patch fixes all of the concerns raised. > > > > I'm concerned that this is going to make the final Hot Standby patch > > fairly large, which will make it even harder to review, test and > > generally get accepted. > > > > What's the best way to make this easier for you/others to review? > The fact that it's been put on the November list doesn't mean it can't > be reviewed and committed before then. But that seems unlikely to be the case. A patch specifically marked as "required for other work" has been delayed by more than 5 weeks on queue and nobody was ever assigned to review it. That was exactly the problem CommitFests were supposed to resolve and from my perspective this is a systemic failure. If I had submitted the patch a month late it wouldn't have got reviewed any earlier, yet many people would cry foul (why?). The current system means I have to code up to the deadline, officially do nothing for a month, then respond within hours to code reviews or have the patch rejected for another month. It works great for minor patches, but its simply not working for bigger features. It's just not possible to be fully available to respond to reviews, yet at the same time not able to work more than about 25% of the development calendar. Luckily Tom reviewed it, but with no commit and no guidance on how to proceed this still leaves me in a difficult position. I'm forced now to leave much of this code behind, since I cannot now complete Hot Standby at the same time as having bgwriter active during recovery, if that code is at risk of causing the whole thing to be rejected. Are the two together a risk? No. Is developing them together harder? Yes. Do *I* trust my own code? Yes, but its reviewers that count. Is it a good thing for Postgres to leave this code behind? Probably not. Can I add it later? Maybe. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
Simon Riggs <simon@2ndQuadrant.com> writes:
> A patch specifically marked as "required for other work" has been
> delayed by more than 5 weeks on queue and nobody was ever assigned to
> review it. That was exactly the problem CommitFests were supposed to
> resolve and from my perspective this is a systemic failure.
To be blunt, that patch spent most of September in "waiting for author"
state. Looking in the archives, I see that
* Original patch was posted on 31-Aug.
* I reviewed that patch on 8-Sep.
* You posted a revised patch on 10-Sep, but it was explicitly marked
as not ready to be actioned.
* It was not until 23-Sep that a patch was posted that you stated
you were happy with.
* I reviewed that one on 25-Sep.
* The patch now in the queue was posted on 30-Sep (all of 8 minutes
before midnight).
I don't see any systemic failure here.
regards, tom lane
On Tue, 2008-10-07 at 10:08 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: > > A patch specifically marked as "required for other work" has been > > delayed by more than 5 weeks on queue and nobody was ever assigned to > > review it. That was exactly the problem CommitFests were supposed to > > resolve and from my perspective this is a systemic failure. > > To be blunt... The bluntness was mine, for which I apologise. The last review uncovered essential behaviour I was missing, no doubt about that. I'm just grumpy because I can't see a way to do the patch-on-patch-on-patch that I'll need to make this all work for Nov 1. So big patch here we come. But that's just the way it is and I'll stop honking about it. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
Simon Riggs wrote: > I'm just grumpy because I can't see a way to do the > patch-on-patch-on-patch that I'll need to make this all work for Nov 1. > So big patch here we come. But that's just the way it is and I'll stop > honking about it. This is one of the problems that DVCSs are supposed to solve ... have you tried Git? -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>> I'm just grumpy because I can't see a way to do the >> patch-on-patch-on-patch that I'll need to make this all work for Nov 1. >> So big patch here we come. But that's just the way it is and I'll stop >> honking about it. > > This is one of the problems that DVCSs are supposed to solve ... have > you tried Git? I think the other problem here is that the difficulty of getting the patch landed increases more than linearly with its size. If it's hard to get a patch of size X landed in one CommitFest, what are the chances of landing on three times as large, with three times as many changes to argue about? Getting things done in stages makes it easier to build on earlier work without worrying that you'll be asked to go back and redo everything. ...Robert
On Tue, 2008-10-07 at 10:37 -0400, Alvaro Herrera wrote: > Simon Riggs wrote: > > > I'm just grumpy because I can't see a way to do the > > patch-on-patch-on-patch that I'll need to make this all work for Nov 1. > > So big patch here we come. But that's just the way it is and I'll stop > > honking about it. > > This is one of the problems that DVCSs are supposed to solve ... have > you tried Git? I have no doubt there's a better way, but no, I don't know it. My braintime is devoted to databases not computing per se. Most of the time that's a good time allocation decision. Not convinced this is the right time to invest in side activities, but if you think so, I'll look into it. Anybody wanting to write or link to a Simon's Guide, most welcome. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
"Robert Haas" <robertmhaas@gmail.com> writes:
>>> I'm just grumpy because I can't see a way to do the
>>> patch-on-patch-on-patch that I'll need to make this all work for Nov 1.
>>> So big patch here we come. But that's just the way it is and I'll stop
>>> honking about it.
>>
>> This is one of the problems that DVCSs are supposed to solve ... have
>> you tried Git?
> I think the other problem here is that the difficulty of getting the
> patch landed increases more than linearly with its size.
Yeah. Tools aren't really the key problem there IMHO.
I agree with Simon that it would be a good thing if this patch got
landed before he went on to the next part. But personally I'm a bit
burned out from commitfest and am not eager to go take a third look
at the patch right now. Does anyone else want to review it?
regards, tom lane
On Tue, Oct 7, 2008 at 4:08 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > > Not convinced this is the right time to invest in side activities, but > if you think so, I'll look into it. > > Anybody wanting to write or link to a Simon's Guide, most welcome. Heikki will be presenting a talk about GIT + PG at PGDay next week. Might be useful. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Alvaro Herrera wrote: > Simon Riggs wrote: >> I'm just grumpy because I can't see a way to do the >> patch-on-patch-on-patch that I'll need to make this all work for Nov 1. >> So big patch here we come. But that's just the way it is and I'll stop >> honking about it. > > This is one of the problems that DVCSs are supposed to solve ... have > you tried Git? Yeah, I maintained a relforks patch + FSM patch on top of that for quite some time using git. It's still a bit of work, for sure, but it's possible. The bottom line is that hot standby is a big feature, and probably a big patch. No amount of version control will work around that. Finishing all that in a few weeks is a very ambitious goal. I wish you luck, and I wish I could do more to help you with that; it's a feature I'd really like to see in 8.4. Given how many iterations just this part of the patch needed, and it's still not there, the little project manager in me says that we really need to be seeing the complete patch or patches very soon, and do a first round of review well before the commit fest. The risk that we have to drop it as unfinished in November is very high otherwise. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
On Tue, 2008-10-07 at 18:19 +0300, Heikki Linnakangas wrote: > The bottom line is that hot standby is a big feature, and probably a big > patch. No amount of version control will work around that. Finishing all > that in a few weeks is a very ambitious goal. I wish you luck, and I > wish I could do more to help you with that; it's a feature I'd really > like to see in 8.4. Given how many iterations just this part of the > patch needed, and it's still not there, the little project manager in me > says that we really need to be seeing the complete patch or patches very > soon, and do a first round of review well before the commit fest. The > risk that we have to drop it as unfinished in November is very high > otherwise. Agreed and understood. The coding isn't the problem, its the risk of being blindsided by a showstopper. Coding is quick when you know exactly what you are trying to achieve. That's one reason to strip out the bgwriter stuff. It's the postmaster state change stuff that's most needed. Anyway, watch this space. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
(replying to a very old message, since I just bumped into this in review) Alvaro Herrera wrote: > Simon Riggs wrote: >> On Fri, 2008-09-12 at 14:14 -0400, Alvaro Herrera wrote: >>> Simon Riggs wrote: >>> >>>> --- 5716,5725 ---- >>>> CheckpointStats.ckpt_sync_end_t, >>>> &sync_secs, &sync_usecs); >>>> >>>> ! elog(LOG, "%s complete: wrote %d buffers (%.1f%%); " >>>> "%d transaction log file(s) added, %d removed, %d recycled; " >>>> "write=%ld.%03d s, sync=%ld.%03d s, total=%ld.%03d s", >>>> + (checkpoint ? " checkpoint" : "restartpoint"), >>>> CheckpointStats.ckpt_bufs_written, >>>> (double) CheckpointStats.ckpt_bufs_written * 100 / NBuffers, >>>> CheckpointStats.ckpt_segs_added, >>> Very minor nit: this really needs a rework. >> All I changed was the word "restartpoint"... its otherwise identical to >> existing message. I'd rather not change that. > > The new message is not translatable, the original was. Doesn't really matter since it's an elog(), not ereport(). -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> (replying to a very old message, since I just bumped into this in review)
> Alvaro Herrera wrote:
>> The new message is not translatable, the original was.
> Doesn't really matter since it's an elog(), not ereport().
... which is wrong in itself, since it's certainly meant as a
user-facing (or at least DBA-facing) message. elog should generally
only be used for debugging or "can't happen" messages, not for stuff
that users are expected to see on a routine basis.
regards, tom lane