Re: pg_resetwal with replication slot (17.11)

> On Sep 26, 2026, at 23:03, Rıdvan Korkmaz <serkan(dot)ridvan(dot)korkmaz(at)gmail(dot)com> wrote:
>
> Dear Experts,
> Is this mail list correct list to share my case,
> If anybody gets this message and respond (to guide me to correct list), I really appreciate.
>
>
>> On 21 Sep 2026, at 15:21, Rıdvan Korkmaz <serkan(dot)ridvan(dot)korkmaz(at)gmail(dot)com> wrote:
>>
>> Hi Dear Experts,
>> I hit a case seems odd. I wonder if I do something unexpected, or something is here I can't see.
>>
>> First, these are all on test environment. The version is PostgreSQL 17.11, uses homebrew installation on MacOS.
>>
>> I have a master - replica setup, both are on the same host.
>> master's
>> PGDATA = m
>> port = 15432
>> rs = rep slot for streaming replication used by instance "r", created on master (m instance)
>> max_wal_size = 4GB
>> min_wal_size = 2GB
>> wal_level = replica
>>
>>
>> replica's
>> PGDATA = r
>> port = 25432
>> primary_conninfo = created by pg_basebackup
>> primary_slot_name = rs
>>
>>
>> Case: I have 16MB WAL files on master instance (so on replica). I want to utilize 1GB WAL files.
>> Here are the steps I take.
>>
>> 1. setup master - replica run on same host in respective directories and on ports
>> 2. verify streaming replication works
>> 3. verify "rs" (replication slot), master ("m" instance), and replica ("r" instance) have SAME WAL lsn
>> 4. stop master, keep replica online (simulation for actual case) (pg_ctl-17 stop -D m)
>> 5. run "pg_resetwal-17 -D m --wal-segsize=1024" on master instance.
>> 6. start master instance, started, fine. Replica complains about "ERROR: requested WAL segment 000000010000000000000000 has already been removed", no worry.
>> 7. stop master again, cool, done. (last log lines: "checkpoint complete", "database system is shut down")
>> 8. start master -> bamm, could not start. (pg_ctl-17 start -D m -l m.log)
>>
>> There is no read, write between after step 3 (after verification of WAL lsns)
>>
>> Final failure log (step 8):
>> 2026-09-21 14:47:45.525 +03 [22817] LOG: starting PostgreSQL 17.11 (Homebrew) on aarch64-apple-darwin25.6.0, compiled by Apple clang version 21.0.0 (clang-2100.1.1.101), 64-bit
>> 2026-09-21 14:47:45.525 +03 [22817] LOG: listening on IPv4 address "127.0.0.1", port 15432
>> 2026-09-21 14:47:45.525 +03 [22817] LOG: listening on Unix socket "/tmp/.s.PGSQL.15432"
>> 2026-09-21 14:47:45.528 +03 [22820] LOG: database system was shut down at 2026-09-21 14:46:42 +03
>> 2026-09-21 14:47:45.528 +03 [22820] LOG: invalid checkpoint record
>> 2026-09-21 14:47:45.528 +03 [22820] PANIC: could not locate a valid checkpoint record at 0/40000110
>> 2026-09-21 14:47:45.528 +03 [22817] LOG: startup process (PID 22820) was terminated by signal 6: Abort trap: 6
>> 2026-09-21 14:47:45.528 +03 [22817] LOG: terminating any other active server processes
>> 2026-09-21 14:47:45.529 +03 [22817] LOG: shutting down due to startup process failure
>> 2026-09-21 14:47:45.529 +03 [22817] LOG: database system is shut down
>>
>>
>>
>> After pg_resetwal, first start of master successful, but a second start fails.
>> I guess this causes master to be lost.
>>
>> I'm able to spot the issue:
>> The issue is replication slot. If I would have removed replication slot before second start (do it between 6 and 7), it succeeds.
>>
>> Questions:
>> 1. Is this behavior is expected?
>> 2. Should replication slot case mentioned in PostgreSQL documents? (I checked yet could not see)
>> 3. Am I doing something out of order, unexpected?
>> 4. Once I understood the case, I dropped replication slot and able to start master. Now I want to copy m/global/pg_control to replica and m/pg_wal to replica as well and complete wal segment size change. I wonder if this way is documented or supported. I can say "it works" but does not mean "supported or documented at all".
>>
>> Thank you in advance.
>>
>> Attachments:
>> <1-master-replica-setup-info.txt><3-all-wal-lsn-same.txt>
>>

This looks like a bug. I just reproduced the failure on master, I can debug the problem and try to work out a fix tomorrow.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/