Re: snapbuild woes

From: Andres Freund <andres(at)anarazel(dot)de>
To: Antonin Houska <ah(at)cybertec(dot)at>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: snapbuild woes
Date: 2017-08-06 21:37:31
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2017-06-09 09:25:34 +0200, Antonin Houska wrote:
> Andres Freund <andres(at)anarazel(dot)de> wrote:
> > Looking at 0001:
> > - GetOldestSafeDecodingTransactionId() only guarantees to return an xid
> > safe for decoding (note how procArray->replication_slot_catalog_xmin
> > is checked), not one for the initial snapshot - so afaics this whole
> > exercise doesn't guarantee much so far.
> I happen to use CreateInitDecodingContext() in an extension, so I had to think
> what the new argumen exactly means (as for the incompatibility between PG
> 9.6.2 and 9.6.3, I suppose preprocessor directives can handle it).
> One thing I'm failing to understand is: if TRUE is passed for
> need_full_snapshot, then slot->effective_xmin receives the result of
> GetOldestSafeDecodingTransactionId(need_full_snapshot)
> but this does include "catalog xmin".
> If the value returned is determined by an existing slot which has valid
> effective_catalog_xmin and invalid effective_xmin (i.e. that slot only
> protects catalog tables from VACUUM but not the regular ones), then the new
> slot will think it (i.e. the new slot) protects even non-catalog tables, but
> that's no true.
> Shouldn't the xmin_horizon be computed by this call instead?
> GetOldestSafeDecodingTransactionId(!need_full_snapshot);
> (If so, I think "considerCatalog" argument name would be clearer than
> "catalogOnly".)

Good catch. Pushing a fix. Afaict it's luckily inconsequential atm
because fo the way we wait for concurrent snapshots when creating a
slot. But it obviously nevertheless needs tobe fixed.


Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2017-08-06 21:55:21 Re: Replication to Postgres 10 on Windows is broken
Previous Message Peter Geoghegan 2017-08-06 21:17:41 Re: Crash report for some ICU-52 (debian8) COLLATE and work_mem values