Re: xlog switch & last record before the switch
От | Florian G. Pflug |
---|---|
Тема | Re: xlog switch & last record before the switch |
Дата | |
Msg-id | 4696428C.9000201@phlo.org обсуждение исходный текст |
Ответ на | Re: xlog switch & last record before the switch ("Simon Riggs" <simon@2ndquadrant.com>) |
Список | pgsql-hackers |
Simon Riggs wrote: > On Thu, 2007-07-12 at 16:17 +0200, Florian G. Pflug wrote: > >> To test my PITR-slave readonly-query patch, I continously do >> insert into test ... >> pg_switch_xlog() >> sleep 1 >> on the master, and let the slave process the generated xlogs >> >> The log output on the slave looks the following (unnecessary lines remove)>>>> <snipped log output>> >> >> As you can see, the COMMIT records seems to end up being logged *after* >> the xlog switch. I would have expected the order >> "heap-insert, commit, switch, heap-insert, commit, switch, ...", not >> "heap-insert, switch, commit, heap-insert, switch, commit, ...". >> >> Is this the expected behaviour, or just an artefact of the implementation >> of xlog switches? > > Can you show the exact SQL executed? > > If you do INSERT ... ;select pg_switch_xlog() then the COMMIT will occur > after the switch. If you do: > INSERT ...; > select pg_switch_xlog(); > then the COMMIT will occur before the switch. Ah, you caught me - I had forgotten that pgsql -c "<statement>" executes the statement in one transaction. I was just going to suggest that pg_start_backup, pg_stop_backup and pg_switch_xlog emit a warning or even an error if called from within a larger transaction, because that's quite certainly not what the user wants. But since those are just plain functions, I guess checking for that might not be trivial... > If it were otherwise this would imply statements were executed prior to > the previous commit, which I hope and pray is never the case. You can relax, the bug was located in front of the screen :-) greetings, Florian Pflug
В списке pgsql-hackers по дате отправления: