Re: [HACKERS] snapbuild woes
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] snapbuild woes |
Дата | |
Msg-id | 20170505000004.gihrtl7bhxeolf3q@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] snapbuild woes (Petr Jelinek <petr.jelinek@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] snapbuild woes
Re: [HACKERS] snapbuild woes |
Список | pgsql-hackers |
Hi, On 2017-05-02 08:55:53 +0200, Petr Jelinek wrote: > Aah, now I understand we talked about slightly different things, I > considered the running thing to be first step towards tracking aborted > txes everywhere. > I think > we'll have to revisit tracking of aborted transactions in PG11 then > though because of the 'snapshot too large' issue when exporting, at > least I don't see any other way to fix that. FWIW, that seems unnecessary - we can just check for that using the clog. Should be very simple to check for aborted xacts when exporting the snapshot (like 2 lines + comments). That should address your concern, right? > If you think that adding the SNAPBUILD_BUILD_INITIAL_SNAPSHOT would be > less invasive/smaller patch I am okay with doing that for PG10. Attached is a prototype patch for that. What I decided is that essentially tracking the running xacts is too unrealiable due to the race, so I decided that just relying on oldestRunningXid and nextXid - which are solely in the procArray and thus racefree - is better. It's not perfect yet, primarily because we'd need to take a bit more care about being ABI compatible for older releases, and because we'd probably have to trigger LogStandbySnapshot() a bit more frequently (presumably while waiting for WAL). The change means we'll have to wait a bit longer for slot creation, but it's considerably simpler / more robust. Could you have a look? Regards, Andres
В списке pgsql-hackers по дате отправления: