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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
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-13 05:53:58
Message-ID: X/6K9lAuRdfJHVLQ@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Tue, Jan 12, 2021 at 12:08:04PM -0300, Alvaro Herrera wrote:
> 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.

I have not found a thread discussing that around the date of this
commit, but I'll take your word on that.

I just have one small comment.

+ if (!create_storage && reltablespace != InvalidOid)
+ recordDependencyOnTablespace(RelationRelationId, relid,
+ reltablespace);
For now we assume that this code path is taken only for partitioned
tables or indexes per the logic in heap_create(). Perhaps it would be
better to add to this code path, or to recordDependencyOnTablespace()
an assertion to check that only the supported relkinds register this
dependency? If a new relkind is added, it would be easy to miss that
this shared dependency may need to be supported.
--
Michael

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2021-01-13 07:43:43 BUG #16820: PG will have a deadlock when multiple rows are updated concurrently
Previous Message Amit Kapila 2021-01-13 05:40:26 Re: SnapBuildSerialize function forgot pfree variable ondisk_c