On Mon, Mar 28, 2011 at 05:29:22PM -0500, Kevin Grittner wrote:
> I have a theory. Can you try it in what would be the failure case,
> but run an explicit a CHECKPOINT on the master, wait for
> pg_controldata to show that checkpoint on the slave, and (as soon as
> you see that) try to trigger the slave to come up in production?
=$ ( pg_controldata master/; pg_controldata slave2/ ) | grep "Latest checkpoint
location:"
Latest checkpoint location: 0/2D000058
Latest checkpoint location: 0/2C000058
=$ psql -p 54001 -c "checkpoint"
CHECKPOINT
=$ ( pg_controldata master/; pg_controldata slave2/ ) | grep "Latest checkpoint
location:"
Latest checkpoint location: 0/2E000058
Latest checkpoint location: 0/2C000058
... ~ 1.5 minute later
=$ ( pg_controldata master/; pg_controldata slave2/ ) | grep "Latest checkpoint
location:"
Latest checkpoint location: 0/2E000058
Latest checkpoint location: 0/2E000058
=$ touch /home/depesz/slave2/finish.recovery
it worked. now the slave2 is working as stand alone.
what does it tell us? will any work happening after checkpoint break it anyway?
Best regards,
depesz
--
The best thing about modern society is how easy it is to avoid contact with it.
http://depesz.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
