Re: Pluggable Storage - Andres's take - Mailing list pgsql-hackers

From Haribabu Kommi
Subject Re: Pluggable Storage - Andres's take
Date
Msg-id CAJrrPGfHrQeGzqZwd=Bj96P9aubDH67kO8gf5mvynvRxXucq2g@mail.gmail.com
Whole thread Raw
In response to Re: Pluggable Storage - Andres's take  (Dmitry Dolgov <9erthalion6@gmail.com>)
Responses Re: Pluggable Storage - Andres's take  (Dmitry Dolgov <9erthalion6@gmail.com>)
List pgsql-hackers
On Mon, Oct 29, 2018 at 7:40 AM Dmitry Dolgov <9erthalion6@gmail.com> wrote:
> On Fri, 26 Oct 2018 at 13:25, Haribabu Kommi <kommi.haribabu@gmail.com> wrote:
>
> Here I attached the cumulative patch with all fixes that are shared in earlier mails by me.
> Except fast_default test, rest of test failures are fixed.

Hi,

If I understand correctly, these patches are for the branch "pluggable-storage"
in [1] (at least I couldn't apply them cleanly to "pluggable-zheap" branch),
right?

Yes, the patches attached are for pluggable-storage branch.
 
I've tried to experiment a bit with the current status of the patch, and
accidentally stumbled upon what seems to be an issue - when I run pgbench
agains it with some significant number of clients and script [2]:

    $ pgbench -T 60 -c 128 -j 64 -f zipfian.sql

Thanks for testing the patches.
 
I've got for some client an error:

    client 117 aborted in command 5 (SQL) of script 0; ERROR:
unrecognized heap_update status: 1

This error is for the tuple state of HeapTupleInvisible, As per the comments
in heap_lock_tuple, this is possible in ON CONFLICT UPDATE, but because
of reorganizing of the table_lock_tuple out of EvalPlanQual(), the invisible
error is returned in other cases also. This case is missed in the new code.
 
This problem couldn't be reproduced on the master branch, so I've tried to
investigate it. It comes from nodeModifyTable.c:1267, when we've got
HeapTupleInvisible as a result, and this value in turn comes from
table_lock_tuple. Everything points to the new way of handling HeapTupleUpdated
result from heap_update, when table_lock_tuple call was introduced. Since I
don't see anything similar in the master branch, can anyone clarify why is this
lock necessary here?

In the master branch code also, there is a tuple lock that is happening in
EvalPlanQual() function, but pluggable-storage code, the lock is kept outside
and also function call rearrangements, to make it easier for the table access
methods to provide their own MVCC implementation.
 
Out of curiosity I've rearranged the code, that handles
HeapTupleUpdated, back to switch and removed table_lock_tuple (see the attached
patch, it can be applied on top of the lastest two patches posted by Haribabu)
and it seems to solve the issue.

Thanks for the patch. I didn't reproduce the problem, based on the error from
your mail, the attached draft patch of handling of invisible tuples in update and
delete cases should also fix it.

Regards,
Haribabu Kommi
Fujitsu Australia
Attachment

pgsql-hackers by date:

Previous
From: "myungkyu.lim"
Date:
Subject: RE: COPY FROM WHEN condition
Next
From: Andrey Borodin
Date:
Subject: Re: [Patch] pg_rewind: options to use restore_command fromrecovery.conf or command line