public inbox for [email protected]
help / color / mirror / Atom feedFrom: Michael Paquier <[email protected]>
To: Jeff Davis <[email protected]>
Cc: Corey Huinker <[email protected]>
Cc: jian he <[email protected]>
Cc: Nathan Bossart <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: Matthias van de Meent <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Magnus Hagander <[email protected]>
Cc: Stephen Frost <[email protected]>
Cc: Ashutosh Bapat <[email protected]>
Cc: Peter Smith <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: [email protected]
Subject: Re: Statistics Import and Export
Date: Fri, 7 Feb 2025 15:07:18 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CADkLM=fe4f=YVGHbOGiXV+W2SoJZtcNw1Ta8gYh5UUhxndaVgw@mail.gmail.com>
<CACJufxGuRPfd70NwogkRE26cZcKGrR9gjG4OiH18tu=BnyezHA@mail.gmail.com>
<CADkLM=fMuVwcxr2aocz4H=LVf2PZsvTNenqEod2PoY1OyCU+kw@mail.gmail.com>
<[email protected]>
<CADkLM=cQi+sYpLY6BqybZ8ZWffSU4+1-aEQsShSGbrh3M=Dtcg@mail.gmail.com>
<[email protected]>
<CACJufxG6K4EAUROhdr0wkzMh5QyFLmdLZeAoh7Vh0-VbuAtHcw@mail.gmail.com>
<CADkLM=fihosVw7fJak6Jq1AdCX8fuZ+7s1_-+AUZR=sdD13zAQ@mail.gmail.com>
<CADkLM=cnYxaNFbAQRMLeOOga0j5pY_V6Tfcn+vjm_rXL=WOF7Q@mail.gmail.com>
<[email protected]>
On Wed, Feb 05, 2025 at 08:45:06PM -0800, Jeff Davis wrote:
> 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.
Fine by me.
The regression tests of v45 and v46 are a bit fuzzy regarding the
tests around locking for partitioned tables. For example, with v46
applied on top of HEAD, if I manipulate the internals of the patch in
stats_check_arg_pair() so as we don't take a lock on the parent table,
then a make check is still happy and passes even if the internals are
clearly broken.
I would recommend to work a bit more the tests by updating the stats
of a relation with the SQL functions in a transaction and add some
queries on pg_locks for locktype = 'relation' that are able to check
the locks we are taking when running these operations (return pairs of
relation::regclass and mode, for example). Doing that for
non-partitioned relations is also something I would do, so as the
locking schema we are using is clearly tracked and that future
manipulations of the area would help one in tracking problems. Bonus
points: scans of pg_locks are cheap tests.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../[email protected]/2-signature.asc)
download
view thread (60+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Statistics Import and Export
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox