Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> 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.
Sorry, I don't get your point. What do you mean by "loosing a large
fraction of transactions in progress". You wouldn't loose them - the
master would be running as usual. And after the slave replayed the
wal past their commit record, they would be visible on the slave too.
The point of my argument was just to convice (myself) that wal-logging of
locking requests is not necessary, as long as you don't want to playback
archived wal _and_ run read-only queries on the slave at the same time.
I also don't understand what you mean by "Nor will queries on the slave
that's behaving like that provide an accurate model of what the same
queries would produce if issued on the master". Sureley they won't -
after all, this is a kind of asynchronous replication. The most
you can hope fore is to eventually catch up with the master.
And I don't propose that my serialization of wal-replay and running
queries is how PITR master-slave replication should ultimatly look
like. But's it's something that can be done _now_, without changing
what kind of operations are wal-logged. And something that I believe
I can finish in the timeframe of a SoC project.
After I'm done with implementing this limited read-only mode, I'd be very
interested in trying to extend it, by allow wal-replay and queries
to run concurrently.
greetings, Florian Pflug
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
