Re: Problems with approach #2 to value locking (INSERT ... ON CONFLICT UPDATE/IGNORE patch)

On Mon, Jan 5, 2015 at 5:53 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> It's not all that easy to recreate, even with my custom
> instrumentation. With fsync=off, it occurs somewhat infrequently with
> a custom instrumentation Postgres build:
>
> pg(at)hamster:~/jjanes_upsert$ perl count_upsert.pl 8 100000
> [Mon Jan 5 17:31:57 2015] init done at count_upsert.pl line 101.
> [Mon Jan 5 17:32:17 2015] child abnormal exit [Mon Jan 5 17:32:17
> 2015] DBD::Pg::db selectall_arrayref failed: ERROR: mismatch in xmin
> for (322,264). Initially 4324145, then 4324429 at count_upsert.pl line
> 210.\n at count_upsert.pl line 227.
> [Mon Jan 5 17:32:49 2015] sum is -800
> [Mon Jan 5 17:32:49 2015] count is 9515
> [Mon Jan 5 17:32:49 2015] normal exit at 1420507969 after 733912
> items processed at count_upsert.pl line 182.
>
> I think that "super deleting" broken promise tuples undermines how
> vacuum interlocking is supposed to work [1].

Hmm. On second thought, I think that the instrumentation I added here
can be confused by redirecting line pointers, and that may account for
this apparent problem. Still, I would like for us to figure out how it
was previously possible for the implementation to update a
"super-deleted" tuple (resulting in unusual all-NULLs tuples) since I
though that in order for that to happen, other xacts would have to see
what was only ever a promise tuple as a fully-fledged tuple -- in
order for the logic that pre-checks for conflicts to find a conflict,
it would have to find the tuple already committed (so it certainly
couldn't be an unresolved promise tuple). My superficial fix [1] was
written without fully understanding what the problem was.

In any case, I doubt the changes that I made to tqual.c in that fix
will be accepted as-is.

[1] http://www.postgresql.org/message-id/CAM3SWZTfTt_fehet3tU3YKCpCYPYnNaUqUZ3Q+NAASnH-60teA@mail.gmail.com
--
Peter Geoghegan