On Mon, Jan 27, 2020 at 02:26:42PM -0500, Stephen Frost wrote: > Greetings, > > * Bruce Momjian (br...@momjian.us) wrote: > > On Mon, Jan 13, 2020 at 01:56:30PM -0500, Stephen Frost wrote: > > > > I think that having ALTER SYSTEM commands in pg_dumpall output > > > > would be a problem. It would cause all kinds of problems whenever > > > > parameters change. Thinking of the transition "checkpoint_segments" > > > > -> "max_wal_size", you'd have to build some translation magic into > > > > pg_dump. > > > > Besides, such a feature would make it harder to restore a dump taken > > > > with version x into version x + n for n > 0. > > > > > > pg_dump already specifically has understanding of how to deal with old > > > options in other things when constructing a dump for a given version- > > > and we already have issues that a dump taken with pg_dump X has a good > > > chance of now being able to be restoreding into a PG X+1, that's why > > > it's recommended to use the pg_dump for the version of PG you're > > > intending to restore into, so I don't particularly agree with any of the > > > arguments presented above. > > > > One issue is that system table GUC settings (e.g., per-database, > > per-user) cannot include postgresql.conf-only settings, like > > max_wal_size, so system tables GUC settings are less likely to be > > renamed than postgresql.conf.auto settings. FYI, we are more inclined > > to allow postgresql.conf-only changes than others because there is less > > impact on applications. > > I'm a bit unclear about what's being suggested here. When you are > talking about 'applications', are you referring specifically to pg_dump > and pg_restore, or are you talking about regular user applications?
Sorry for the late reply. I meant all applications. > If you're referring to pg_dump/restore, then what I'm understanding from > your comments is that if we made pg_dump/restore aware of ALTER SYSTEM > and were made to support it that we would then be less inclined to > change the names of postgresql.conf-only settings because, if we do so, > we have to update pg_dump/restore. > > I can see some argument in that direction but my initial reaction is > that I don't feel like the bar would really be moved very far, and, if > we came up with some mapping from one to the other for those, I actually > think it'd be really helpful downstream for packagers and such who > routinely are dealing with updating from an older postgresql.conf file > to a newer one when an upgrade is done. I should have given more examples. Changing GUC variables like search_path or work_mem, which can be set in per-database, per-user, and per-session contexts, is more disruptive than changing GUCs that can only can be set in postgresql.conf, like max_wal_size. My point is that all GUC changes don't have the same level of disruption. -- Bruce Momjian <br...@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
