Josh Berkus wrote:
>> People weren't very interested in having a read-only mode. I think it
>> would be a nice feature if it's not too complicated.
>
> Actually, I think there's high demand for it off this list. Effectively it
> would allow our "warm backup mode" to become a "hot backup mode". As SoC
> admin, I'd vote for such a proposal unless someone explains to me why it's
> impossible.
From my point of view, the most subtle point of the whole proposal is
if not doing
wal-replay _and_ quries at the same time, but rather one after the other,
really solves all the locking issues.
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.
Since later won't lead to problems today, doing the formed for hot standby
should not lead to problems too.
There reason that I put "Process wal in chucks such that all
*_safe_restartpoint" functions return true at the end of a chunk" was
the be on the safe side, not because I could find any actual problem
if that requirement was dropped.
Can anyone find a flaw in those arguments?
greetings, Florian Pflug
