| From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
|---|---|
| To: | cca5507(at)qq(dot)com |
| Cc: | suryapoondla4(at)gmail(dot)com, nathandbossart(at)gmail(dot)com, michael(at)paquier(dot)xyz, pgsql-hackers(at)lists(dot)postgresql(dot)org, bharath(dot)rupireddyforpostgres(at)gmail(dot)com, pgsql(at)j-davis(dot)com |
| Subject: | Re: Handle concurrent drop when doing whole database vacuum |
| Date: | 2026-07-02 06:03:39 |
| Message-ID: | 20260702.150339.697006934252601284.horikyota.ntt@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello,
At Wed, 1 Jul 2026 15:21:06 +0800, "cca5507" <cca5507(at)qq(dot)com> wrote in
> > 2. The silent skip in get_all_vacuum_rels produces a different user-visible
> > behavior than vacuum_open_relation's WARNING for
> > what's essentially the same race (concurrent drop during a database-wide
> > VACUUM).
> > I think the silent path is fine here, as the user didn't explicitly ask for
> > that table.
>
> I personally think it's worth a WARNING because the relation is exist when
> we scan pg_class. I'm also OK if most people think the WARNING is useless.
I think that from the immediate caller's point of view, there is no
distinction between a relation disappearing before or after the
pg_class scan. Personally, I think vacuum_open_relation() could also
be silent in that case, although I don't see any particular need to
change its current behavior.
Regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kyotaro Horiguchi | 2026-07-02 06:03:49 | Re: Handle concurrent drop when doing whole database vacuum |
| Previous Message | Srinath Reddy Sadipiralla | 2026-07-02 05:54:40 | Re: SQL/JSON: JSON_TRANSFORM (SQL standard, subclause 6.44) |