Re: Proposal for Implenting read-only queries during wal replay (SoC 2007)

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

In response to

Responses

Browse pgsql-hackers by date

  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