Re: BUG #16577: Segfault on altering a table located in a dropped tablespace
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Michael Paquier <michael@paquier.xyz>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2020-10-28T13:40:45Z
Lists: pgsql-bugs
On 2020-Oct-28, Michael Paquier wrote: > On Thu, Oct 15, 2020 at 12:19:59PM -0300, Alvaro Herrera wrote: > > It just dawned on me that a way to fix this is to use a pg_shdepend > > entry to protect the tablespace from being dropped. > > Haven't thought of that approach, good idea! That would not be > backpatchable but that would be a solution that does not require > creating files where we don't need them. Did you begin to look at > that? I haven't started on this one yet, but I intend to do so shortly. Strictly speaking, we can still introduce a new category of pg_shdepend entries in back branches; it won't break anything that works today. And while it won't fix the problem on existing partitioned tables, it is possible to have users run a query on each database to create any rows needed. The only *actual* incompatibility is that once you upgrade and create the rows, an older server of the same major may misbehave when does rows are present. But do we ever see users going back to previous minors? I think this isn't really a terrible problem in practice. And even if it is, users can work around it by deleting the offending rows. What do you think?
Commits
-
Prevent drop of tablespaces used by partitioned relations
- ebfe2dbd6b62 14.0 landed
- c9b702552acc 12.6 landed
- c442b32c2e6d 11.11 landed
- 5b01a6f13ff7 13.2 landed
-
Don't create relfilenode for relations without storage
- 807ae415c546 12.0 cited