WAL recycled despite logical replication slot

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: WAL recycled despite logical replication slot
Date: 2019-09-20 12:45:34
Message-ID: CAMkU=1yR2V_2F2is+XTPqe6oLruXKgPmYkGS7m1dUunMKnrFRg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-09-20 12:58:40 Re: backup manifests
Previous Message Asim R P 2019-09-20 12:23:56 Re: standby recovery fails (tablespace related) (tentative patch and discussion)