Re: our checks for read-only queries are not great
От | Bruce Momjian |
---|---|
Тема | Re: our checks for read-only queries are not great |
Дата | |
Msg-id | 20200119014759.GA27638@momjian.us обсуждение исходный текст |
Ответ на | Re: our checks for read-only queries are not great (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: our checks for read-only queries are not great
|
Список | pgsql-hackers |
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. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
В списке pgsql-hackers по дате отправления: