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
