pg.ddx.io pgsql-hackers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
From: Stephen Frost <sfrost@snowman.net>
To: Corey Huinker <corey.huinker@gmail.com>
Cc: Matthias van de Meent <boekewurm+postgres@gmail.com>
Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Peter Smith <smithpb2250@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>
Subject: Re: Statistics Import and Export
Date: Wed, 13 Mar 2024 08:10:37 -0400
Message-ID: <ZfGXvRd8Nq9mwdm0@tamriel.snowman.net> (raw)
In-Reply-To: <CADkLM=daBsKfo3CO1gP0HQ17wFzDKW+gha=2z_fSaa9Fs5csTA@mail.gmail.com>
References: <Zei1xMGH8SJS9yoc@tamriel.snowman.net>
<CADkLM=dB-qbU81LuAQVSQxAabYXghXe6ptaatTYmQAzVT44V_g@mail.gmail.com>
<Zer+8KR36gzST29w@tamriel.snowman.net>
<CADkLM=eM7rqJpArtRrxsVbOn=3GBRUyKtQbC_TxtFe010QLR8Q@mail.gmail.com>
<Ze7WQBMPvzXoRCCj@tamriel.snowman.net>
<CADkLM=d3XhRSySPX+CHL7KmBCgt7ZpqL-0NLxdSWNYHx=MBjag@mail.gmail.com>
<Ze9SD2gPVwklwvEZ@tamriel.snowman.net>
<CADkLM=eo4rmN8fFnxNycQtzTnsKwBxdXbAJMTvMC_A1_7HzRdA@mail.gmail.com>
<ZfAXln76MPzwtkLU@tamriel.snowman.net>
<CADkLM=daBsKfo3CO1gP0HQ17wFzDKW+gha=2z_fSaa9Fs5csTA@mail.gmail.com>
Greetings,
* Corey Huinker (corey.huinker@gmail.com) wrote:
> > No, we should be keeping the lock until the end of the transaction
> > (which in this case would be just the one statement, but it would be the
> > whole statement and all of the calls in it). See analyze.c:268 or
> > so, where we call relation_close(onerel, NoLock); meaning we're closing
> > the relation but we're *not* releasing the lock on it- it'll get
> > released at the end of the transaction.
>
> If that's the case, then changing the two table_close() statements to
> NoLock should resolve any remaining concern.
Note that there's two different things we're talking about here- the
lock on the relation that we're analyzing and then the lock on the
pg_statistic (or pg_class) catalog itself. Currently, at least, it
looks like in the three places in the backend that we open
StatisticRelationId, we release the lock when we close it rather than
waiting for transaction end. I'd be inclined to keep it that way in
these functions also. I doubt that one lock will end up causing much in
the way of issues to acquire/release it multiple times and it would keep
the code consistent with the way ANALYZE works.
If it can be shown to be an issue then we could certainly revisit this.
Thanks,
Stephen
Attachments:
signature.asc (application/pgp-signature, 832B) download
view thread (543+ messages) latest in thread
Message-ID: <ZfGXvRd8Nq9mwdm0@tamriel.snowman.net> Permalink: ../ZfGXvRd8Nq9mwdm0@tamriel.snowman.net/ Also on: postgresql.org/message-id/ZfGXvRd8Nq9mwdm0@tamriel.snowman.net ·
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: pgsql-hackers@postgresql.org Cc: sfrost@snowman.net, corey.huinker@gmail.com, boekewurm+postgres@gmail.com, ashutosh.bapat.oss@gmail.com, smithpb2250@gmail.com, pgsql-hackers@lists.postgresql.org, tomas.vondra@enterprisedb.com Subject: Re: Statistics Import and Export In-Reply-To: <ZfGXvRd8Nq9mwdm0@tamriel.snowman.net> * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox