From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Richard Huxton <dev(at)archonet(dot)com> |
Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Hot Standby query cancellation and Streaming Replication integration |
Date: | 2010-02-26 17:46:15 |
Message-ID: | 407d949e1002260946i69eb58eej82415f9a6b5a7854@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 26, 2010 at 4:43 PM, Richard Huxton <dev(at)archonet(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2010-02-26 18:00:22 | Re: ecpg tests broken by pgindent run |
Previous Message | Robert Haas | 2010-02-26 17:45:33 | Re: Hot Standby query cancellation and Streaming Replication integration |