From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Julien Rouhaud <julien(dot)rouhaud(at)dalibo(dot)com> |
Cc: | Peter Geoghegan <pg(at)heroku(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: Minor bug affecting ON CONFLICT lock wait log messages |
Date: | 2016-03-15 13:18:30 |
Message-ID: | 20160315131830.GA3127@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Julien Rouhaud (julien(dot)rouhaud(at)dalibo(dot)com) wrote:
> On 15/03/2016 03:30, Peter Geoghegan wrote:
> > On Mon, Mar 7, 2016 at 1:46 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> >> Attached patch fixes a bug reported privately by Stephen this morning.
> >
> > Bump.
> >
> > I would like to see this in the next point release. It shouldn't be
> > hard to review.
> >
>
> + reason_wait = indexInfo->ii_ExclusionOps ?
> + XLTW_RecheckExclusionConstr : XLTW_InsertIndex;
>
> Shouldn't it be set to XLTW_InsertIndexUnique instead?
Actually, no, though I had the same question for Peter when I was first
reviewing this.
XLTW_InsertIndexUnique is used when building a unique index, but this is
just a check, and more to the point, it's actually a re-check of what
we're doing in nbinsert.c where we're already using XLTW_InsertIndex.
We wouldn't want to end up returning different error messages for the
same command under the same conditions just based, which is what we'd
potentially end up doing if we used XLTW_InsertIndexUnique here.
> Otherwise the patch seems ok to me.
Agreed. I'm going to play with it a bit more but barring objections,
I'll commit and back-patch Peter's patch.
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2016-03-15 13:40:15 | Re: Parallel Aggregate |
Previous Message | Thomas Reiss | 2016-03-15 13:17:10 | Re: RFC: replace pg_stat_activity.waiting with something more descriptive |