From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Langote <amitlangote09@gmail.com>
Cc: David Steele <david@pgmasters.net>
Cc: Pavel Biryukov <79166341370@yandex.ru>
Cc: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: posgres 12 bug (partitioned table)
Date: Thu, 22 Apr 2021 14:21:05 -0400
Message-ID: <1102101.1619115665@sss.pgh.pa.us> (raw)
In-Reply-To: <CA+HiwqGASb2n+fOKVgDUddzV-_vc6ZxRj9i5oWMWOw1VK0_c7g@mail.gmail.com>
References: <141051591267657@mail.yandex.ru>
<1251598.1591289850@sss.pgh.pa.us>
<20200811180231.fcssvhelqpnydnx7@alap3.anarazel.de>
<CA+HiwqH7bA+orwhcA5dofKR_UNzk-S8GPK23g1vCrWxAjnK=Og@mail.gmail.com>
<81885.1597205290@sss.pgh.pa.us>
<CA+HiwqFx8oBGTDmwVQNHQrSGw4we84E4z5J+q2zFRJeAt5BaCA@mail.gmail.com>
<20200812162718.ycxrktzoe6rpdy5k@alap3.anarazel.de>
<CA+HiwqEGgy8x5M2dotzH7HSd0v+byyJXGU8S+d5NFnrOBiTZDA@mail.gmail.com>
<407111603806900@mail.yandex.ru>
<CA+HiwqFjEim_RMCiaFxA4nUx00o3auXKPy-OsOcog+chg5K-zA@mail.gmail.com>
<cd492dbd-a0ba-4790-bcf7-c4af2d2dc8d1@pgmasters.net>
<CA+HiwqG7qhKJnFpZOqyrFngqcMzja+p=gssMK=73b+-BZffxqw@mail.gmail.com>
<CA+HiwqHqnC=A9a+=F-k8J=JV-EKKt3vTgxq01=9af-0HE045NQ@mail.gmail.com>
<793243.1619032209@sss.pgh.pa.us>
<CA+HiwqGASb2n+fOKVgDUddzV-_vc6ZxRj9i5oWMWOw1VK0_c7g@mail.gmail.com>
Amit Langote <amitlangote09@gmail.com> writes:
> On Thu, Apr 22, 2021 at 4:10 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> In the meantime, if the back branches fail with something like
>> "virtual tuple table slot does not have system attributes" when
>> trying to do this, that's not great but I'm not sure we should
>> be putting effort into improving it.
> Got it. That sounds like an acceptable compromise.
Hm, we're not done with this. Whatever you think of the merits of
throwing an implementation-level error, what's actually happening
in v12 and v13 in the wake of a71cfc56b is that an attempt to do
"RETURNING xmin" works in a non-cross-partition UPDATE, but in
a cross-partition UPDATE it dumps core. What I'm seeing is that
the result of the execute_attr_map_slot() call looks like
(gdb) p *(BufferHeapTupleTableSlot*) scanslot
$3 = {base = {base = {type = T_TupleTableSlot, tts_flags = 8, tts_nvalid = 3,
tts_ops = 0xa305c0 <TTSOpsBufferHeapTuple>,
tts_tupleDescriptor = 0x7f1c7798f920, tts_values = 0x2077100,
tts_isnull = 0x2075fb0, tts_mcxt = 0x2015ea0, tts_tid = {ip_blkid = {
bi_hi = 0, bi_lo = 0}, ip_posid = 3}, tts_tableOid = 37812},
tuple = 0x0, off = 0, tupdata = {t_len = 0, t_self = {ip_blkid = {
bi_hi = 0, bi_lo = 0}, ip_posid = 0}, t_tableOid = 0,
t_data = 0x0}}, buffer = 0}
and since base.tuple is NULL, heap_getsysattr dies on either
"Assert(tup)" or a null-pointer dereference.
So
(1) It seems like this is exposing a shortcoming in the
multiple-slot-types logic. It's not hard to understand why the slot would
look like this after execute_attr_map_slot does ExecStoreVirtualTuple,
but if this is not a legal state for a BufferHeapTuple slot, why didn't
ExecStoreVirtualTuple raise a complaint?
(2) It also seems like we can't use the srcSlot if we want to have
the fail-because-its-a-virtual-tuple behavior. I experimented with
doing ExecMaterializeSlot on the result of execute_attr_map_slot,
and that stops the crash, but then we're returning garbage values
of xmin etc, which does not seem good.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, amitlangote09@gmail.com, david@pgmasters.net, 79166341370@yandex.ru, andres@anarazel.de, pgsql-bugs@lists.postgresql.org
Subject: Re: posgres 12 bug (partitioned table)
In-Reply-To: <1102101.1619115665@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox