Re: BUG #18979: pg_upgrade to PG17 fails if max_slot_wal_keep_size is not set to -1
От | Tom Lane |
---|---|
Тема | Re: BUG #18979: pg_upgrade to PG17 fails if max_slot_wal_keep_size is not set to -1 |
Дата | |
Msg-id | 200807.1751815611@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: BUG #18979: pg_upgrade to PG17 fails if max_slot_wal_keep_size is not set to -1
|
Список | pgsql-bugs |
PG Bug reporting form <noreply@postgresql.org> writes: > Steps to Reproduce: > 1. On a PostgreSQL 16 cluster, set max_slot_wal_keep_size = 500 (or any > non-default value). > 2. Initdb a new PostgreSQL 17 cluster. > 3. Copy the postgresql.conf from 16 to 17. > 4. Attempt to perform a binary upgrade to PostgreSQL 17 using pg_upgrade > --check. > Expected Behavior: > pg_upgrade should automatically override max_slot_wal_keep_size to -1 as > required for upgrade mode. I do not think it is within pg_upgrade's charter to modify your postgresql.conf file. However, maybe instead of having check_max_slot_wal_keep_size throw an error about this, we could make it just silently keep the value as -1. There's a nearby thread about silently ignoring inappropriate GUC settings during initdb [1], and this seems like it'd be in the same spirit. Or we could just drop the server-side check altogether, figuring that it's pg_upgrade's job to see to that. BTW, your step 3 above is not very good practice. It will lose the entries for any new GUCs added in the new PG version. While that's not a functional problem, it does mean that the .conf file's usefulness as documentation gets worse and worse over time. regards, tom lane [1] https://www.postgresql.org/message-id/flat/87plejmnpy.fsf%40163.com
В списке pgsql-bugs по дате отправления: