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

From Andres Freund
Subject Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0
Date
Msg-id 20150508165246.GO12950@alap3.anarazel.de
Whole thread Raw
In response to Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2015-05-08 12:32:10 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > So I've committed the patch yesterday evening. I'm pretty sure there'll
> > be some more minor things to change. But overall I feel good about the
> > current state.
> 
> Looks like there's a CLOBBER_CACHE_ALWAYS issue ...
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguarundi&dt=2015-05-08%2011%3A52%3A00

Hm. I can't immediately think of anything CCA relevant in the patch. I
do wonder if it's possible that this is a consequence of
indcheckxmin. The unique index is created just before the failing
statement, after the table has had a couple updates. And the following
statement succeeds.

Currently index inferrence ignores indexes that aren't yet valid
according to checkxmin. I'm tempted to think that is a mistake. I think
we should throw an error instead; possbily at execution rather than plan
time. It'll be rather confusing for users if a INSERT ... ON CONFLICT
fails shortly after an index creation, but not later.  Not that an error
message will make them happy, but it'll be much less confusing.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0
Next
From: Kevin Grittner
Date:
Subject: Re: [COMMITTERS] pgsql: Teach autovacuum about multixact member wraparound.