|From:||Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>|
|To:||Dmitry Dolgov <9erthalion6(at)gmail(dot)com>|
|Cc:||Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Pluggable Storage - Andres's take|
|Views:||Raw Message | Whole Thread | Download mbox|
On Mon, Oct 29, 2018 at 7:40 AM Dmitry Dolgov <9erthalion6(at)gmail(dot)com> wrote:
> > On Fri, 26 Oct 2018 at 13:25, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
> > 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.
> If I understand correctly, these patches are for the branch
> in  (at least I couldn't apply them cleanly to "pluggable-zheap"
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 :
> $ 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
> 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
> 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
and also function call rearrangements, to make it easier for the table
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
> patch, it can be applied on top of the lastest two patches posted by
> and it seems to solve the issue.
Thanks for the patch. I didn't reproduce the problem, based on the error
your mail, the attached draft patch of handling of invisible tuples in
delete cases should also fix it.
|Next Message||Andrey Borodin||2018-10-29 05:59:37||Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line|
|Previous Message||myungkyu.lim||2018-10-29 04:12:20||RE: COPY FROM WHEN condition|