Re: pgsql: Fix "base" snapshot handling in logical decoding
От | Alvaro Herrera |
---|---|
Тема | Re: pgsql: Fix "base" snapshot handling in logical decoding |
Дата | |
Msg-id | 20180705182232.3n7ih4kyhtwhmvod@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: pgsql: Fix "base" snapshot handling in logical decoding (Arseny Sher <a.sher@postgrespro.ru>) |
Список | pgsql-hackers |
Hi Arseny. I'm writing a commit message to push this test change, and I can't explain this bit: On 2018-Jul-02, Arseny Sher wrote: > 3) As a side note, answer to my question 'why do we get different errors > with VACUUM and VACUUM FULL' is the following. With VACUUM FULL, not > only old pg_attribute entry is pruned, but also xmin of new entry > with attisdropped=true is reset to frozen xid. This means that > decoding session (RelationBuildTupleDesc) actually sees 3 attributes, > and the fact that one of them is dropped doesn't embarrass this > function (apparently relnatts in pg_class is never decremented) -- > we just go ahead and decode only live attributes. I just don't see it that VACUUM FULL would change the xmin of anything to FrozenXid, and in my experiments it doesn't. Did you mean VACUUM FREEZE? PS - sorry about the broken CC I added :-( -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: