Re: BUG #5798: Some weird error with pl/pgsql procedure - Mailing list pgsql-bugs

Today I perfomed some more digging with code and gdb.

I not sure, but may be I have an idea what happens here:

RETURNING ctid fails when code implementing returning happened to get a
"Virtual" tuple as input.
And that ofcourse fail because "virtual tuple does not have any "system
columns" (such as tid).
(seems no one got such error before because no one tried to use system
columns in RETURNING list).

I tracked virtual tuple from heaptuple.c::slot_getattr down to
execMain.c::ExecUpdate and I think somewhere in this way virtual tuple
should be need to be "materialized" into physical tuple.

I have zero expirience with reporting such results so I will try my best:
path of that virtual tuple in problem case looks like:

*(slot_getattr::slot)
*(ExecEvalVar::econtext->ecxt_scantuple)
*(ExecTargetList::econtext->ecxt_scantuple)
*(ExecProject::econtext->ecxt_scantuple)
*(ExecProject::projInfo->pi_exprContext->ecxt_scantuple)
*(ExecProcessReturning::projectReturning->pi_exprContext->ecxt_scantuple)
*(ExecUpdate::resultRelInfo->ri_projectReturning->pi_exprContext->ecxt_scan=
tuple)

All these variable contained the same TupleTableSlot structure:

(gdb) print
*(ExecUpdate::resultRelInfo->ri_projectReturning->pi_exprContext->ecxt_scan=
tuple)
$29 =3D {
  type =3D T_TupleTableSlot,
  tts_isempty =3D 0 '\000',
  tts_shouldFree =3D 0 '\000',
  tts_shouldFreeMin =3D 0 '\000',
  tts_slow =3D 0 '\000',
  tts_tuple =3D 0x0,
  tts_tupleDescriptor =3D 0xdd09d1030,
  tts_mcxt =3D 0xdd08da2e0,
  tts_buffer =3D 0,
  tts_nvalid =3D 11,
  tts_values =3D 0xdd09d1840,
  tts_isnull =3D 0xdd09d18d0 "",
  tts_mintuple =3D 0x0,
  tts_minhdr =3D {
    t_len =3D 0,
    t_self =3D {
      ip_blkid =3D {
        bi_hi =3D 0,
        bi_lo =3D 0
      },
      ip_posid =3D 44192
    },
    t_tableOid =3D 13,
    t_data =3D 0x10
  },
  tts_off =3D 59333634048
}

Again I not sure but ExecProcessReturning function seems good candidate to
perform tuple materialization.

PS: May be it seems just a lot handwaving but I just started study gdb and
postgresql source code.

PPS: I must say thanks to authors of http://doxygen.postgresql.org . It is
great tool and saved me lot time today.

On Sun, Feb 20, 2011 at 12:01 PM, Maxim Boguk <maxim.boguk@gmail.com> wrote:

>
>
> On Sun, Feb 20, 2011 at 5:08 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>> Maxim Boguk <maxim.boguk@gmail.com> writes:
>> > I finally managed create working slave server with non-stripped
>> Postgresql
>> > 8.4.7 and working gdb.
>> > (sorry for such long delay).
>> > And i can reproduce situation quite easy now, so i managed get stack
>> > backtrace with that error.
>> > What i need to do now? I have some expirience with gbd now but i have =
no
>> > idea where to look next.
>>
>> Now that you know what query is causing the problem:
>>
>> > #9  0x0000000000673d43 in ProcessQuery (plan=3D0xdd0998890,
>> >     sourceText=3D0xdd09c5830 "UPDATE ONLY bill.ctrl_servers SET opt =
=3D opt
>> > WHERE ctid=3DANY($1) RETURNING ctid", params=3D0xdd09c58c0,
>> >     dest=3D0xdd09de5c8, completionTag=3D0x7fffffffd4e0 "") at pquery.c=
:196
>>
>> it shouldn't be too hard to prepare a self-contained test case so that
>> others can look at this.
>>
>>                        regards, tom lane
>>
>
>
> Sorry, but it's very unlikely I can create self-contained test case.
> That error doesn't happen on stand alone idle server.
> It's only happen at random time on table with very high update rate in
> production environment, and happen over 1-30 minutes calling my storable
> procedure in endless loop (e.g. once per 1000+ calls).
> I was long ago sure about exact place where that error happens  (becuase =
my
> storable procedure contains only one real sql query), but because I can't
> create self contained test case I was asked use gdb and try to get backtr=
ace
> at point of error.
>
> So now I can examine and provide variable values at that point to give a
> clue about what happens here.
>
>
> --
> Maxim Boguk
> Senior Postgresql DBA.
>
> Skype: maxim.boguk
> Jabber: maxim.boguk@gmail.com
>
> LinkedIn profile: http://nz.linkedin.com/in/maximboguk
> If they can send one man to the moon... why can't they send them all?
>
> =D0=9C=D0=BE=D0=B9=D0=9A=D1=80=D1=83=D0=B3: http://mboguk.moikrug.ru/
> =D0=A1=D0=B8=D0=BB=D0=B0 =D1=81=D0=BE=D0=BB=D0=BE=D0=BC=D1=83 =D0=BB=D0=
=BE=D0=BC=D0=B8=D1=82, =D0=BD=D0=BE =D0=BD=D0=B5 =D0=B2=D1=81=D0=B5 =D0=B2 =
=D0=BD=D0=B0=D1=88=D0=B5=D0=B9 =D0=B6=D0=B8=D0=B7=D0=BD=D0=B8 - =D1=81=D0=
=BE=D0=BB=D0=BE=D0=BC=D0=B0, =D0=B4=D0=B0 =D0=B8 =D1=81=D0=B8=D0=BB=D0=B0 =
=D0=B4=D0=B0=D0=BB=D0=B5=D0=BA=D0=BE =D0=BD=D0=B5
> =D0=B2=D1=81=D0=B5.
>



--=20
Maxim Boguk
Senior Postgresql DBA.

Skype: maxim.boguk
Jabber: maxim.boguk@gmail.com

LinkedIn profile: http://nz.linkedin.com/in/maximboguk
If they can send one man to the moon... why can't they send them all?

=D0=9C=D0=BE=D0=B9=D0=9A=D1=80=D1=83=D0=B3: http://mboguk.moikrug.ru/
=D0=A1=D0=B8=D0=BB=D0=B0 =D1=81=D0=BE=D0=BB=D0=BE=D0=BC=D1=83 =D0=BB=D0=BE=
=D0=BC=D0=B8=D1=82, =D0=BD=D0=BE =D0=BD=D0=B5 =D0=B2=D1=81=D0=B5 =D0=B2 =D0=
=BD=D0=B0=D1=88=D0=B5=D0=B9 =D0=B6=D0=B8=D0=B7=D0=BD=D0=B8 - =D1=81=D0=BE=
=D0=BB=D0=BE=D0=BC=D0=B0, =D0=B4=D0=B0 =D0=B8 =D1=81=D0=B8=D0=BB=D0=B0 =D0=
=B4=D0=B0=D0=BB=D0=B5=D0=BA=D0=BE =D0=BD=D0=B5
=D0=B2=D1=81=D0=B5.