Re: BUG #16577: Segfault on altering a table located in a dropped tablespace

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16577: Segfault on altering a table located in a dropped tablespace
Date: 2021-01-12 15:08:04
Message-ID: 20210112150804.GA27528@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 2021-Jan-12, Michael Paquier wrote:

> + /*
> + * If a tablespace is specified, removal of that tablespace is normally
> + * protected by the existence of a physical file; but for relations with
> + * no files, add a pg_shdepend entry to account for that.
> + */
> + if (!create_storage && reltablespace != InvalidOid)
>
> On HEAD, could we consider using this dependency link even for
> relations that have physical files, and remove the physical file
> check? Could that make the dependency handling cleaner?

That would bloat the catalog with a lot of entries for stuff that can be
detected with the current method. Did you notice that the code is
removing an "#ifdef NOT_USED" line to enable existing code? Well, when
I wrote this code in 2005 (59d1b3d99e69) it was doing things as you
suggest, but in the end we decided that it wasn't necessary so it was
taken out.

--
Álvaro Herrera 39°49'30"S 73°17'W
"Someone said that it is at least an order of magnitude more work to do
production software than a prototype. I think he is wrong by at least
an order of magnitude." (Brian Kernighan)

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2021-01-12 17:15:59 Re: pg_upgrade test for binary compatibility of core data types
Previous Message Amit Kapila 2021-01-12 13:42:34 Re: SnapBuildSerialize function forgot pfree variable ondisk_c