Re: Timeline following for logical slots
| От | Craig Ringer |
|---|---|
| Тема | Re: Timeline following for logical slots |
| Дата | |
| Msg-id | CAMsr+YHJiXp1r7WHFXjFPPzfNZZo89KWeiwNdnUcU087ubo1CQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Timeline following for logical slots (Andres Freund <andres@anarazel.de>) |
| Список | pgsql-hackers |
On 4 April 2016 at 14:43, Andres Freund <andres@anarazel.de> wrote:
Not really no. The important point isn't invalidation or anything. It's> OK, makes sense. And still resume decoding from restart_lsn, despite having
> that visibility information stashed, because we also have to rebuild the
> information on invalidations for running xacts, which is not stored
> persistently anywhere as decoding progresses. So for now at least it's an
> optimisation to store the visibility info, since we still have go go back
> and decode for invalidations anyway. Right?
that we don't have the content & metadata of the transactions
themselves. Yes, we also do re-read invalidations, but that's just a
side effect.
I've been looking too hard for the details and somehow managed to completely miss the blindingly obvious right in front of me. I knew that the confirmed lsn was the threshold of confirmed commit LSNs, I knew about the reorder buffer needing to accumulate changes, I knew it wasn't persistent, etc. Yet I can't pretend I didn't overlook that when looking over the xlogreader vs decoding startup, per those comments.
I don't think a succinct comment there will be useful given that it'd really just do a better job of explaining what restart_lsn is and why we start decoding there. So I guess a more detailed comment on the slot struct (not on the field, at the start) would be good. Or that README.
Thanks for your patience.
--
В списке pgsql-hackers по дате отправления: