From: Yura Sokolov <y.sokolov@postgrespro.ru>
To: Andres Freund <andres@anarazel.de>
Cc: Miles Delahunty <miles.delahunty@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-bugs@lists.postgresql.org, Robert Haas <robertmhaas@gmail.com>
Subject: Re: can't drop table due to reference from orphaned temp function
Date: Wed, 13 Jul 2022 12:16:38 +0300
Message-ID: <2ac628a335ed13b77904f8dd6e5a4e5bee2fbec6.camel@postgrespro.ru> (raw)
In-Reply-To: <20220712192454.3p42auoul4lniyys@awork3.anarazel.de>
References: <CAOFAq3BU5Mf2TTvu8D9n_ZOoFAeQswuzk7yziAb7xuw_qyw5gw@mail.gmail.com>
<20220219180002.6tubjq7iw7m52bgd@alap3.anarazel.de>
<20220219213139.2gpsrqwp7hlmn634@alap3.anarazel.de>
<24a26615b66d84abf2083a10ff1ca59933a7b4e2.camel@postgrespro.ru>
<20220712192454.3p42auoul4lniyys@awork3.anarazel.de>
В Вт, 12/07/2022 в 12:24 -0700, Andres Freund пишет:
> Hi,
>
> On 2022-07-12 17:13:28 +0300, Yura Sokolov wrote:
> > В Сб, 19/02/2022 в 13:31 -0800, Andres Freund пишет:
> > > Hi,
> > >
> > > On 2022-02-19 10:00:02 -0800, Andres Freund wrote:
> > > > See backtrace below [1]. The same problem does *not* exist when starting to
> > > > use the same temp schema in a new session (which drops the old contents
> > > > first), which kind of explains why we've not previously noticed this.
> > > >
> > > > But even so, I'm surprised we haven't noticed this before.
> > >
> > > Ah, there's a reason for that. In many cases we'll have a catalog snapshot
> > > registered, which is enough for init_toast_snapshot(). But in Miles' example,
> > > the object dropped just prior ends with catalog invalidations.
> > >
> > > Proposed bugfix and test attached.
> > >
> > > I think it's ok to backpatch the test. There might be a slight change in
> > > output due to 618c16707a6d6e8f5c83ede2092975e4670201ad not being backpatched,
> > > but that's OK I think.
> > >
> > >
> > > I think it is dangerous that we return a cached catalog snapshot for things
> > > like GetOldestSnapshot() unless they're also registered or active - we can't
> > > rely on catalog snapshots to be present. Indeed, if we didn't, this bug would
> > > have been found before, as some added assertions confirm.
> > >
> > > I don't think we can just ignore the catalog snapshot though, it can be
> > > registered in the future, so it actually is the oldest snapshot. But at least
> > > we should assert that there's some snapshot registered/active. In the attached
> > > patch I've added HaveRegisteredOrActiveSnapshot() and used that in
> > > init_toast_snapshot().
> >
> > Reading your message and HaveRegisteredOrActiveSnapshot's body, I can't get its logic:
> > - if it is dangerous to have CatalogSnapshot alone in RegisteredSnapshots,
> > then why we return 'false' if RegisteredSnapshots is NOT singular?
>
> IIRC that was a bug that since was fixed. Did you check the current
> definition?
Ah, sorry. I really looked at old definition. New one is correct.
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-bugs@postgresql.org
Cc: y.sokolov@postgrespro.ru, andres@anarazel.de, miles.delahunty@gmail.com, tgl@sss.pgh.pa.us, robertmhaas@gmail.com
Subject: Re: can't drop table due to reference from orphaned temp function
In-Reply-To: <2ac628a335ed13b77904f8dd6e5a4e5bee2fbec6.camel@postgrespro.ru>
* 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