Stephen Frost wrote:
> I don't think either message really fits here, unfortunately. We're not
> actually checking the uniqueness of someone else's tuple here either,
> after all, we're waiting to see what happens with their tuple because
> ours won't be unique if it goes in with that other tuple
On Mon, Mar 21, 2016 at 3:38 PM, Stephen Frost wrote:
>> Basically, unlike with the similar nbtinsert.c code, we're checking
>> someone else's tuple in the speculative insertion
>> check_exclusion_or_unique_constraint() case that was changed (or it's
>> an exclusion constraint, where even the chec
Peter,
* Peter Geoghegan (p...@heroku.com) wrote:
> Thinking about this again, I think we should use
> XLTW_InsertIndexUnique after all. The resemblance of the
> check_exclusion_or_unique_constraint() code to the nbtinsert.c code
> seems only superficial on second thought. So, I propose fixing the
On Tue, Mar 15, 2016 at 8:31 AM, Stephen Frost wrote:
>> > 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.
>>
>> Perhaps we need a
On Tue, Mar 15, 2016 at 6:18 AM, Stephen Frost wrote:
> Agreed. I'm going to play with it a bit more but barring objections,
> I'll commit and back-patch Peter's patch.
Thanks for taking care of this, Stephen.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Julien Rouhaud (julien.rouh...@dalibo.com) wrote:
>
> > 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
Stephen Frost wrote:
> * Julien Rouhaud (julien.rouh...@dalibo.com) wrote:
> 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.
>
>
On 15/03/2016 14:18, Stephen Frost wrote:
> * Julien Rouhaud (julien.rouh...@dalibo.com) wrote:
>> On 15/03/2016 03:30, Peter Geoghegan wrote:
>>> On Mon, Mar 7, 2016 at 1:46 PM, Peter Geoghegan wrote:
Attached patch fixes a bug reported privately by Stephen this morning.
>>>
>>> Bump.
>>>
>>
* Julien Rouhaud (julien.rouh...@dalibo.com) wrote:
> On 15/03/2016 03:30, Peter Geoghegan wrote:
> > On Mon, Mar 7, 2016 at 1:46 PM, Peter Geoghegan wrote:
> >> Attached patch fixes a bug reported privately by Stephen this morning.
> >
> > Bump.
> >
> > I would like to see this in the next poin
On 15/03/2016 03:30, Peter Geoghegan wrote:
> On Mon, Mar 7, 2016 at 1:46 PM, Peter Geoghegan 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.
>
+
On Mon, Mar 7, 2016 at 1:46 PM, Peter Geoghegan 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.
Thanks
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-h
Attached patch fixes a bug reported privately by Stephen this morning.
He complained about deadlocking ON CONFLICT DO NOTHING statements.
There were no exclusion constraints involved, and yet they were
incorrectly indicated as being involved in log messages that related
to these deadlocks.
--
Pet
12 matches
Mail list logo
