Re: pgsql: Fix "base" snapshot handling in logical decoding - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: pgsql: Fix "base" snapshot handling in logical decoding
Date
Msg-id 20180705182232.3n7ih4kyhtwhmvod@alvherre.pgsql
Whole thread Raw
In response to Re: pgsql: Fix "base" snapshot handling in logical decoding  (Arseny Sher <a.sher@postgrespro.ru>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: Global shared meta cache
Next
From: Sergei Kornilov
Date:
Subject: Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query