Re: Catalog_xmin is not advanced when a logical slot is lost
От | sirisha chamarthi |
---|---|
Тема | Re: Catalog_xmin is not advanced when a logical slot is lost |
Дата | |
Msg-id | CAKrAKeVJ48FB+dzEaVaHOe3U-ZjVRGrmv+-hFGqmC6jcB7T6jg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Catalog_xmin is not advanced when a logical slot is lost (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: Catalog_xmin is not advanced when a logical slot is lost
|
Список | pgsql-hackers |
On Mon, Nov 21, 2022 at 10:56 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
On 2022-Nov-21, sirisha chamarthi wrote:
> I have a old .partial file in the data directory to reproduce this.
I don't think the .partial file is in itself important. But I think
this whole thing is a distraction.
Yes, sorry for the confusion.
I managed to reproduce it
eventually, by messing with the slot and WAL at random, and my
conclusion is that we shouldn't mess with this at all for this bugfix.
Agreed.
Instead I'm going to do what Ashutosh mentioned at the start, which is
to verify both the restart_lsn and the invalidated_at, when deciding
whether to ignore the slot.
Sounds good to me. Thanks!
It seems to me that there is a bigger mess here, considering that we use
the effective_xmin in some places and the other xmin (the one that's
saved to disk) in others. I have no patience for trying to disentangle
that at this point, though.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Having your biases confirmed independently is how scientific progress is
made, and hence made our great society what it is today" (Mary Gardiner)
В списке pgsql-hackers по дате отправления: