Re: Truncation of mapped catalogs (whether local or shared) leads to server crash

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Truncation of mapped catalogs (whether local or shared) leads to server crash
Date: 2024-06-18 14:55:16
Message-ID: 3601887.1718722516@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> writes:
> On Tue, Jun 18, 2024 at 7:50 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I think the assertion you noticed is there because the code path gets
>> traversed during REINDEX, which is an operation we do support on
>> system catalogs. I have zero interest in making truncate work
>> on them.

> I agree with you on that point. How about considering a complete
> restriction instead?

You already broke the safety seal by enabling allow_system_table_mods.
Perhaps the documentation of that is not scary enough?

Allows modification of the structure of system tables as well as
certain other risky actions on system tables. This is otherwise not
allowed even for superusers. Ill-advised use of this setting can
cause irretrievable data loss or seriously corrupt the database
system.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2024-06-18 15:02:38 Re: consider -Wmissing-variable-declarations
Previous Message Dave Page 2024-06-18 14:54:27 Re: Meson far from ready on Windows