Re: Proposal for Implenting read-only queries during wal replay (SoC 2007)
От | Florian G. Pflug |
---|---|
Тема | Re: Proposal for Implenting read-only queries during wal replay (SoC 2007) |
Дата | |
Msg-id | 45E06442.40209@phlo.org обсуждение исходный текст |
Ответ на | Re: Proposal for Implenting read-only queries during wal replay (SoC 2007) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > "Florian G. Pflug" <fgp@phlo.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. 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
В списке pgsql-hackers по дате отправления: