| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Function to move the position of a replication slot |
| Date: | 2017-09-02 22:36:59 |
| Message-ID: | 20170902223659.x4vxt4fxnhwaw3vx@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2017-09-02 18:31:10 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > I don't quite see how you'd get corruption from a physical slot being
> > forwarded? I mean you surely can get into the situation that there's
> > missing WAL from wherever a standby is receiving its WAL, but that'll
> > "just" break replication.
>
> Um, doesn't advancing a slot correspond exactly to skipping some amount
> of WAL?
Not for physical ones, no. The slot is just a marker on the *upstream*
(or a potential upstream) that remembers a standby's current WAL replay
position and, if enabled, it's current xmin. The prevents the upstream
to remove the WAL that the standby still need and if applicable vacuum
from removing rows the standby needs. If the slot is at the wrong
position exactly the same things that can happen if no slot were in use
can also happen, i.e. "ERROR: requested WAL segment %s has already been removed".
For logical replication such a forward operation would have to be *more*
complicated than for physical rep, because the state that's kept is more
complicated...
- Andres
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2017-09-02 23:59:55 | Re: JIT & function naming |
| Previous Message | Tom Lane | 2017-09-02 22:31:10 | Re: Function to move the position of a replication slot |