From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
cc: Peter Geoghegan <pg@heroku.com>, Andres Freund <andres@anarazel.de>,
 Heikki Linnakangas <hlinnaka@iki.fi>, Jeff Janes <jeff.janes@gmail.com>,
 Dean Rasheed <dean.a.rasheed@gmail.com>, Bruce Momjian <bruce@momjian.us>,
 Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0
In-reply-to: <20150508191600.GA30322@tamriel.snowman.net>
References: <554CF44B.3080808@iki.fi>
 <20150508180636.GR12950@alap3.anarazel.de>
 <CAM3SWZQsh=uDmyRW4NzYqU_kv8qAsvCYpJuuYSuikfuJbLANQQ@mail.gmail.com>
 <20150508181445.GS12950@alap3.anarazel.de> <17473.1431109846@sss.pgh.pa.us>
 <20150508183504.GU12950@alap3.anarazel.de> <18313.1431111562@sss.pgh.pa.us>
 <CAM3SWZSqDaRG9c12XewsKqFLkNAak1kxie3UZ6+Wi9cC2UKT8g@mail.gmail.com>
 <18691.1431112058@sss.pgh.pa.us> <18911.1431112384@sss.pgh.pa.us>
 <20150508191600.GA30322@tamriel.snowman.net>
Comments: In-reply-to Stephen Frost <sfrost@snowman.net>
 message dated "Fri, 08 May 2015 15:16:00 -0400"
Date: Fri, 08 May 2015 15:22:09 -0400
Message-ID: <19213.1431112929@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers