Re: pg_resetwal with replication slot (17.11) - Mailing list pgsql-hackers

On 21 Sep 2026, at 15:21, Rıdvan Korkmaz <serkan.ridvan.korkmaz@gmail.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>