On Wed, 2025-02-05 at 23:01 -0500, Corey Huinker wrote: > And here's an update to the pg_dump code itself. This currently has > failing TAP tests for statistics in the custom and dir formats, but > is working otherwise.
This thread got slightly mixed up, so I'm replying to the v45-0001 posted here, and also in response to Michael's and Corey's comments from: https://www.postgresql.org/message-id/Z5H0iRaJc1wnDVLE%40paquier.xyz On Thu, 2025-01-23 at 16:49 +0900, Michael Paquier wrote: > On Tue, Jan 21, 2025 at 10:21:51PM -0500, Corey Huinker wrote: > > After some research, I think that we should treat partitioned > > indexes like > > we were before, and just handle the existing special case for > > regular > > indexes. > > Hmm, why? Sounds strange to me to not have the same locking > semantics > for the partitioned parts, and this even if partitioned indexes don't > have stats that can be manipulated in relation_stats.c as far as I > can see. These stats APIs are designed to be permissive as Jeff > says. > Having a better locking from the start makes the whole picture more > consistent, while opening the door for actually setting real stat > numbers for partitioned indexes (if some make sense, at some point)? v45-0001 addresses this by locking both the partitioned index, as well as its table, in ShareUpdateExclusive mode. That satisfies the in-place update requirement to take a ShareUpdateExclusiveLock on the partitioned index, while otherwise being the same as normal indexes (and therefore unlikely to cause a problem if ANALYZE sets stats on partitioned indexes in the future). That means: * For indexes: ShareUpdateExclusiveLock on table and AccessShareLock on index * For partitioned indexes: ShareUpdateExclusiveLock on table and ShareUpdateExclusiveLock on index * Otherwise, ShareupdateExclusiveLock on the relation which makes sense to me. The v45-0001 patch itself could use some cleanup, but I can take care of that at commit time if we agree on the locking scheme. Regards, Jeff Davis
