Date: Fri, 8 May 2015 15:16:00 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
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
Message-ID: <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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="Le3TVr1H7tDf22//"
Content-Disposition: inline
In-Reply-To: <18911.1431112384@sss.pgh.pa.us>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


--Le3TVr1H7tDf22//
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> I wrote:
> > Peter Geoghegan <pg@heroku.com> writes:
> >> On Fri, May 8, 2015 at 11:59 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >>> Ooops.  But shouldn't that have failed 100% of the time in a CCA buil=
d?
> >>> Or is the candidates list fairly noncritical?
>=20
> >> The candidates list is absolutely critical.
>=20
> > Oh, I was confusing CCA with RELCACHE_FORCE_RELEASE, which does somethi=
ng
> > a bit different.
>=20
> 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.

	Thanks!

		Stephen

--Le3TVr1H7tDf22//
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJVTQtwAAoJEO1sijiDR2RVB5YP/0EEe9yJFexVJa3ztJodawP0
m0EbMZ45mkDr3C4E6oW6cPQVn0l9IK4e/ul4dlPBda5g5YNJOzXR9BAabVULsS76
C7Q/A4rxbIUL0yeqZaVjqQ+AWYBLvMDa8r7gn7k4R1oKJLa7Kgd2tmp651J6xb1B
NoMolQxuhs48AdbiOuHcWFabO1xGyznunlPUkTt45xAh/pwNit2gHYqX2uSqaW73
CsOxDW9+9C7SffIUHB0MdE7rQgT/X1h9AYuIIRFGxkUvDem1nFRzJWmIjLOods/m
MDty0xFYZk6xR4h0zhzsfayoWh/0vohtSYq0yTqlu15WoToOKTeJ4cji2pJ53iyg
ZhfTakePzde3H9rTZ4hLQhwGkoLjkvfRy+16HrHricWAivh357K3JNRfmzhsp9MU
04r3GSOCjDw+DM+Rzx6M6dWLXita8DXSIQh2B3+gdFJReFI3Ief2GzHRnraxAg9f
2ZqbOKKCi3oCfMclljyjkicTs3P28D3EKIGbkDrefV7sh6joCRyZwWjKbLm4L+Vh
WnQ1OQgGgbxcJKPtyvcSNKdQg+HWiQjBfIVzC9cw3sejy1eefse112bmIpRVB+uF
ehsf8O+iHGDgyQUrCwkUAUFnqelc7282GqP4V8/JtPhC7u95HqvUxoJwTzOPTxg8
Dv9YHBQihUPiVS4lAAqH
=VoBw
-----END PGP SIGNATURE-----

--Le3TVr1H7tDf22//--