WAL recycled despite logical replication slot - Mailing list pgsql-hackers

From Jeff Janes
Subject WAL recycled despite logical replication slot
Date
Msg-id CAMkU=1yR2V_2F2is+XTPqe6oLruXKgPmYkGS7m1dUunMKnrFRg@mail.gmail.com
Whole thread Raw
Responses Re: WAL recycled despite logical replication slot
Re: WAL recycled despite logical replication slot
List pgsql-hackers

While testing something else (whether "terminating walsender process due to replication timeout" was happening spuriously), I had logical replication set up streaming a default pgbench transaction load, with the publisher being 13devel-e1c8743 and subscriber being 12BETA4.  Eventually I started getting errors about requested wal segments being already removed:

10863 sub idle 00000 2019-09-19 17:14:58.140 EDT LOG:  starting logical decoding for slot "sub"
10863 sub idle 00000 2019-09-19 17:14:58.140 EDT DETAIL:  Streaming transactions committing after 79/EB0B17A0, reading WAL from 79/E70736A0.
10863 sub idle 58P01 2019-09-19 17:14:58.140 EDT ERROR:  requested WAL segment 0000000100000079000000E7 has already been removed
10863 sub idle 00000 2019-09-19 17:14:58.144 EDT LOG:  disconnection: session time: 0:00:00.030 user=jjanes database=jjanes host=10.0.2.2 port=40830

It had been streaming for about 50 minutes before the error showed up, and it showed right when streaming was restarting after one of the replication timeouts.

Is there an innocent explanation for this?  I thought logical replication slots provided an iron-clad guarantee that WAL would be retained until it was no longer needed.  I am just using pub/sub, none of the lower level stuff.

Cheers,

Jeff

pgsql-hackers by date:

Previous
From: Asim R P
Date:
Subject: Re: standby recovery fails (tablespace related) (tentative patch and discussion)
Next
From: Robert Haas
Date:
Subject: Re: backup manifests