Re: Hot Standby query cancellation and Streaming Replication integration

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

In response to

Browse pgsql-hackers by date

  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