Re: Hot Standby query cancellation and Streaming Replication integration - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Hot Standby query cancellation and Streaming Replication integration
Date
Msg-id 407d949e1002260946i69eb58eej82415f9a6b5a7854@mail.gmail.com
Whole thread Raw
In response to Re: Hot Standby query cancellation and Streaming Replication integration  (Richard Huxton <dev@archonet.com>)
List pgsql-hackers
On Fri, Feb 26, 2010 at 4:43 PM, Richard Huxton <dev@archonet.com> wrote:
> Let's see if I've got the concepts clear here, and hopefully my thinking it
> through will help others reading the archives.
>
> There are two queues:

I don't see two queues. I only see the one queue of operations which
have been executed on the master but not replayed yet on the slave.
Every write operation on the master enqueues an operation to it and
every operation replayed on the slave dequeues from it. Only a subset
of operations create conflicts with concurrent transactions on the
slave, namely vacuums and a few similar operations (HOT pruning and
btree index pruning).

There's no question we need to make sure users have good tools to
monitor this queue and are aware of these tools. You can query each
slave for its currently replayed log position and hopefully you can
find out how long it's been delayed (ie, if it's looking at a log
record and waiting for a conflict to clear how long ago that log
record was generated). You can also find out what the log position is
on the master.




-- 
greg


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Hot Standby query cancellation and Streaming Replication integration
Next
From: Bruce Momjian
Date:
Subject: Re: ecpg tests broken by pgindent run