| From: | "Merlin Moncure" <mmoncure(at)gmail(dot)com> |
|---|---|
| To: | "Gregory Stark" <stark(at)enterprisedb(dot)com> |
| Cc: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Richard Huxton" <dev(at)archonet(dot)com>, "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Transaction Snapshots and Hot Standby |
| Date: | 2008-09-11 12:10:23 |
| Message-ID: | b42b73150809110510m1cced7ccy71c3e83781dc914c@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Sep 11, 2008 at 7:18 AM, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
> a) transactions with live snapshots on the slave prevent the master from being
> able to vacuum tuples (which defeats the purpose of having a live standby
> server for some users).
>
> or
>
> b) vacuum on the server which cleans up a tuple the slave has in scope has to
> block WAL reply on the slave (which I suppose defeats the purpose of having
> a live standby for users concerned more with fail-over latency).
There is nothing stopping you from setting up two (or more) slave
servers, with one designated as failover that doens't serve queries,
right? Option b seems pretty reasonable to me, although I'd prefer to
block wal replay vs canceling queries...although it might be nice to
manually be able to force wal replay 'with query cancel' via a
checkpoint.
merlin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2008-09-11 12:16:49 | Re: New FSM patch |
| Previous Message | Tom Lane | 2008-09-11 12:09:54 | Re: Interesting glitch in autovacuum |