Re: pgsql: Avoid duplicate XIDs at recovery when building initialsnapshot
От | Michael Paquier |
---|---|
Тема | Re: pgsql: Avoid duplicate XIDs at recovery when building initialsnapshot |
Дата | |
Msg-id | 20181101060911.GG1727@paquier.xyz обсуждение исходный текст |
Ответ на | Re: pgsql: Avoid duplicate XIDs at recovery when building initialsnapshot (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: pgsql: Avoid duplicate XIDs at recovery when building initial snapshot
Re: pgsql: Avoid duplicate XIDs at recovery when building initial snapshot |
Список | pgsql-hackers |
On Tue, Oct 23, 2018 at 10:43:38AM +0900, Michael Paquier wrote: > Well, following the same kind of thoughts, txid_current_snapshot() uses > sort_snapshot() to remove all the duplicates after fetching its data > from GetSnapshotData(), so wouldn't we want to do something about > removal of duplicates if dummy PGXACT entries are found while scanning > the ProcArray also in this case? What I would think we should do is not > only to patch GetRunningTransactionData() but also GetSnapshotData() so > as we don't have duplicates also in this case, and do things in such a > way that both code paths use the same logic, and that we don't need to > have sort_snapshot() anymore. That would be more costly though... My apologies it took a bit longer than I thought. I got a patch on my desk for a couple of days, and finally took the time to finish something which would address the concerns raised here. As long as we don't reach more than hundreds of thousands of entries, there is not going to be any performance impact. So what I do in the attached is to revert 1df21ddb, and then have GetRunningTransactionData() sort the XIDs in the snapshot and remove duplicates only if at least one dummy proc entry is found while scanning, for xids and subxids. This way, there is no need to impact most of the instance deployments with the extra sort/removal phase as most don't use two-phase transactions. The sorting done at recovery when initializing the standby snapshot still needs to happen of course. The patch is added to the upcoming CF for review. Thanks, -- Michael
Вложения
В списке pgsql-hackers по дате отправления: