Re: pgsql: Fix "base" snapshot handling in logical decoding

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Arseny Sher <a(dot)sher(at)postgrespro(dot)ru>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: Fix "base" snapshot handling in logical decoding
Date: 2018-07-05 18:22:32
Message-ID: 20180705182232.3n7ih4kyhtwhmvod@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers 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

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Alvaro Herrera 2018-07-05 20:46:28 pgsql: Reduce cost of test_decoding's new oldest_xmin test
Previous Message Peter Eisentraut 2018-07-05 06:38:29 pgsql: Fix typo

Browse pgsql-hackers by date

  From Date Subject
Next Message Sergei Kornilov 2018-07-05 18:34:31 Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query
Previous Message Andres Freund 2018-07-05 18:04:28 Re: Global shared meta cache