From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Marc Munro <marc(at)bloodnok(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Hot Standby query cancellation and Streaming Replication integration |
Date: | 2010-03-03 01:56:45 |
Message-ID: | 1267581405.21887.603.camel@ebony |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2010-03-02 at 12:47 -0800, Marc Munro wrote:
> IIUC this is only a problem for WAL from HOT updates and vacuums. If no
> vacuums or HOT updates have been performed, there is no risk of
> returning bad data. So WAL that does not contain HOT updates or vacuums
> could be applied on the standby without risk, even if there are
> long-running queries in play. This is not a complete solution but may
> reduce the likelihood of queries having to be cancelled. I guess the
> approach here would be to check WAL before applying it, and only cancel
> queries if the WAL contains HOT updates or vacuums.
That's what we do.
> Taking the idea further, if WAL records contained the tid of the latest
> tuples that were overwritten, even more WAL could be applied without
> having to cancel queries.
>
> To take it further still, if vacuum on the master could be prevented
> from touching records that are less than max_standby_delay seconds old,
> it would be safe to apply WAL from the very latest vacuum. I guess HOT
> could be handled similarly though that may eliminate much of the
> advantage of HOT updates.
Thanks for your ideas.
--
Simon Riggs www.2ndQuadrant.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2010-03-03 02:00:03 | Re: plperl _init settings |
Previous Message | Tom Lane | 2010-03-03 01:53:17 | pgsql: Instead of trying (and failing) to allow <<label>> at the end of |