From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: Peter Geoghegan <pg@heroku.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Jeff Janes <jeff.janes@gmail.com>
Cc: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0
Date: Fri, 08 May 2015 15:22:09 -0400
Message-ID: <19213.1431112929@sss.pgh.pa.us> (raw)
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: tgl@sss.pgh.pa.us, sfrost@snowman.net, pg@heroku.com, andres@anarazel.de, hlinnaka@iki.fi, jeff.janes@gmail.com, dean.a.rasheed@gmail.com, bruce@momjian.us, pgsql-hackers@postgresql.org
Subject: Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0
In-Reply-To: <19213.1431112929@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox