Re: BUG #16036: Segmentation fault while doing an update

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #16036: Segmentation fault while doing an update
Date: 2019-10-04 22:40:57
Message-ID: CAH2-Wz=7a7NfrHDYofvrYvNdDFs=1GAzr+_ANRzpc-fLmi=hDg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Fri, Oct 4, 2019 at 3:24 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> I was under the assumption that it'd be deterministic who gets to
> continue with a speculative insertion, but that ain't so.

There is no heap_lock_tuple() style lock arbitration built in to
speculative insertions:

https://wiki.postgresql.org/wiki/UPSERT#Theoretical_lock_starvation_hazards

I do not consider this to be a problem.

> Peter, do you see an easy way around that? Do you consider that a
> problem? ISTM we ought to make this fair, but that doing so would
> require a bit bigger changes that we'd want to make in the backbranches?

It would also require formally defining "fair", which doesn't seem
straightforward to me. The MVCC snapshot is barely involved at all.

--
Peter Geoghegan

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2019-10-04 22:43:03 BUG #16041: Error shows up both in pgAdmin and in Ruby (pg gem) - Segmentation fault
Previous Message Andres Freund 2019-10-04 22:24:37 Re: BUG #16036: Segmentation fault while doing an update