Hi Robert, Andres, Tom, Thank you for sharing your thoughts.
On Tue, Jun 18, 2024 at 8:02 PM Andres Freund <and...@anarazel.de> wrote: > > Hi, > > On 2024-06-18 19:58:26 +0530, Ashutosh Sharma wrote: > > On Tue, Jun 18, 2024 at 7:50 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > > > > > Robert Haas <robertmh...@gmail.com> writes: > > > > On Tue, Jun 18, 2024 at 8:10 AM Ashutosh Sharma <ashu.coe...@gmail.com> > > > > wrote: > > > >> Executing below commands: > > > >> -- set allow_system_table_mods TO on; > > > >> -- truncate table pg_type; > > > > > > > If the operation isn't allowed without turning on > > > > allow_system_table_mods, that means that doing it is probably a bad > > > > idea and will probably break stuff, as happened here. > > > > > > Nothing good can come of truncating *any* core system catalog --- what > > > do you think you'll still be able to do afterwards? > > > > > > 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? > > What's the point? There are occasional cases where doing something dangerous > is useful, for debugging or corruption recovery. If we flat out prohibit this > we'll just need a allow_system_table_mods_but_for_real option. > This is specifically about truncation of system catalogs, and does not refer to any other DML operations on system catalogs, which I see are necessary for many extensions that directly update catalogs like pg_proc and others. Additionally, according to the comments in truncate_check_rel(), we permit truncation of the pg_largeobject catalog specifically during pg_upgrade. So, afaiu truncation of any catalogs other than this can be restricted. -- With Regards, Ashutosh Sharma.
