| From: | hubert depesz lubaczewski <depesz(at)depesz(dot)com> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
| Cc: | pgsql-bugs mailing list <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: Backend handling replication slot stuck using 100% cpu, unkillable |
| Date: | 2023-07-04 13:55:23 |
| Message-ID: | ZKQky8nApOWI8O/X@depesz.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Tue, Jul 04, 2023 at 03:04:58PM +0200, Tomas Vondra wrote:
> The backtrace has this:
> and 187650155969544 should be LSN AAAA/B4E37C08, which maps to
> select pg_walfile_name('AAAA/B4E37C08');
> pg_walfile_name
> --------------------------
> 000000010000AAAA000000B4
We're not that far. Current WAL is 0000000100001D77000000AF
There was command in there, though that referred to wal
0000000100001D6C00000092
I checked pg_waldump of this wal, and found lots of DELETE and NEW_CID
commands on 2 relations: pg_depend and pg_publication_rel
This kinda makes sense given that around that time there was drop of
replication slot, and earlier drop of all tables from it.
Best regards,
depesz
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Gustafsson | 2023-07-04 15:43:17 | Re: BUG #17695: Failed Assert in logical replication snapbuild. |
| Previous Message | Vamshikrishna T | 2023-07-04 13:48:21 | Re: BUG #18009: Postgres Recovery not happening |