From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
Cc: | josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
Subject: | Re: Proposal for Implenting read-only queries during wal replay (SoC 2007) |
Date: | 2007-02-24 05:23:34 |
Message-ID: | 12574.1172294614@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Florian G. Pflug" <fgp(at)phlo(dot)org> writes:
> My line of reasoning is that stopping wal replay at a arbitrary point,
> and then starting a read-only transaction with an "empty snapshot" (meaning
> that all exactly those transactions marked as comitted in the clog are
> assumed to be visible to the transaction) is exactly the same as sending
> the backend a SIGKILL when it just wrote the wal record in question,
> and then restarting postgres, and starting a transaction.
The hole in that reasoning is that no one would be satisfied with the
behavior of a Postgres database that was being forcibly restarted every
few seconds. Yeah, we won't lose transactions that have been promised
committed, but losing a large fraction of transactions-in-progress won't
please anyone. Nor will queries on a slave that's behaving like that
provide an accurate model of what the same queries would produce if issued
on the master.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2007-02-24 06:10:50 | Re: SCMS question |
Previous Message | Warren Turkal | 2007-02-24 03:21:07 | Re: SCMS question |