Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0
Date
Msg-id 19213.1431112929@sss.pgh.pa.us
Whole thread Raw
In response to Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0  (Stephen Frost <sfrost@snowman.net>)
Responses Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> Actually, looking closer, the quoted code is simply not broken without
>> RELCACHE_FORCE_RELEASE: without that, neither heap_close nor index_close
>> will do anything that could cause a cache flush.  So while it's certainly
>> good pratice to move that lappend_oid call up, it does not explain the
>> observed symptoms.  We still need some more investigation here.

> Couldn't a cache flush request come from another backend?  Although this
> isn't being run in a parallel group, is it?  Maybe a delayed signal that
> happens to show up late at just the right time?  Dunno if we've ever
> actually seen that but the thought occured to me.

A signal could certainly have arrived in that interval, but it wouldn't be
serviced in that interval --- or if it was, we have far worse problems
than this one.  Nothing interesting should happen except at (at least) a
CHECK_FOR_INTERRUPTS() point, and there is none in this code sequence.

I'm back to suspecting that the indcheckxmin issue is the true cause of
the buildfarm failure, though we lack an explanation why Andres failed
to reproduce it ...
        regards, tom lane



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0
Next
From: Fabrízio de Royes Mello
Date:
Subject: Re: Proposal : REINDEX xxx VERBOSE