| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: WAL recycled despite logical replication slot |
| Date: | 2019-09-22 23:37:39 |
| Message-ID: | 20190922233739.ayo7egos7losgatn@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2019-09-22 11:45:05 -0400, Jeff Janes wrote:
> On Fri, Sep 20, 2019 at 6:25 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > Hi,
> > >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.
> >
> > It indeed should. What's the content of
> > pg_replication_slot for that slot?
> >
>
> Unfortunately I don't think I have that preserved. If I can reproduce the
> issue, would preserving data/pg_replslot/sub/state help as well?
Can't hurt. Best together with other slots, if they exists.
Could you describe the system a bit?
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2019-09-22 23:57:28 | Re: strong memory leak in plpgsql from handled rollback and lazy cast |
| Previous Message | Alexander Korotkov | 2019-09-22 23:03:14 | Re: JSONPATH documentation |