On Tue, 2009-04-21 at 15:55 +0300, Heikki Linnakangas wrote: > Fujii Masao wrote: > > On Tue, Apr 21, 2009 at 8:28 PM, Heikki Linnakangas > > <heikki.linnakan...@enterprisedb.com> wrote: > >> Simon Riggs wrote: > >>> What you propose is *better* than raw pg_standby is now, but still not > >>> enough in all cases, as I think you know. > >> No, I don't. What is the case where it doesn't work? > > > > It's the case which I described as the 2nd comment to your > > proposal. > > > > 1. pg_standby tries to restore a non-existent file > > 1-1. remove the trigger file > > 1-2. pg_standby exits with non-zero code > > 2. the startup process tries to read it from pg_xlog > > 2-1. it is applied > > 3. the startup process tries to restore the next file using pg_standby > > 3-1. pg_standby gets *stuck* since the requested file and trigger file > > don't exist. > > Ahh, ok, I didn't understand the issue correctly before. > > But wait a minute, we already have exactly the same problem with the > current 8.2/8.3 pg_standby, don't we? [tests]. Yes, we do. > > Simon's suggestion of a separate restore_completion_command is very > attractive as it would provide an explicit place to hook up the deletion > of the trigger file. It seems useful anyway, you might want to put a > command there to e.g update a log file or launch some custom daemon > software when the recovery ends. The question then is what to do with > 8.2 and 8.3? Even if we decided to keep the behavior that the failover > is triggered immediately (fast mode), pg_standby getting stuck if you > copy any WAL files directly into pg_xlog seems like a bug that needs to > be fixed. > > Fujii's idea of deleting the trigger file when history file is requested > is the only proposal this far that works and doesn't require changes to > people's config files, so I guess that's what we'll have to do at least > for back-branches.
Agreed. Fujii-san's proposal is the only one that covers all the important things. The assumptions need careful documentation, as you say. The idea of a restore_completion_command does still sound attractive, easy to implement and non-intrusive enough to do so right now. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
