From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Melvin Davidson <melvin6925(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Clarify "allow_system_table_mods" |
Date: | 2016-04-26 00:03:55 |
Message-ID: | 861.1461629035@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Monday, April 25, 2016, Melvin Davidson <melvin6925(at)gmail(dot)com> wrote:
>> I need clarification on allow_system_table_mods parameter
> If it's going to prevent the action it should be able to do so without
> crashing the server..and I doubt it's intended to be opinionated aside from
> covering all DDL. What little there is on Google seems to support this.
You've got that backwards. Turning allow_system_table_mods on simply
disables a bunch of safety/permissions checks, allowing incautious
superusers to break their databases by changing system catalog structure.
It does not promise to make things work that are incapable of being
supported by the underlying C code. For the most part, no change in the
rowtype of any system catalog is going to work; the C code has compiled-in
notions about the numbers and types of the columns in each catalog.
allow_system_table_mods only exists so that initdb can do some setup steps
that would otherwise be inconvenient to manage. It's not intended to be
used by average mortals; and that's the reason for the lack of
documentation, as well as the lack of concern about whether you can crash
the system with it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2016-04-26 00:05:51 | Re: Clarify "allow_system_table_mods" |
Previous Message | Melvin Davidson | 2016-04-26 00:01:36 | Re: Clarify "allow_system_table_mods" |