Subject: Re: format_datum debugging function

From: Peter Eisentraut <[email-masked]>
Date: Wed, 14 Aug 2024 11:16:01 +0200

On 12.08.24 23:15, Paul Jungwirth wrote:
> On 8/12/24 04:32, Aleksander Alekseev wrote:
>>> [...] This function takes a Datum and the appropriate out function, 
>>> and returns a char *. So you
>>> can do this:
>>>
>>> (gdb) call format_datum(range_out, $1)
>>> $2 = 0x59162692d938 "[1,4)"
>>>
>>> I assume a patch like this doesn't need documentation. Does it need a 
>>> test? Anything else?
>>
>> I think you forgot to attach the patch. Or is it just a proposal?
> 
> Sorry, patch attached here.

I don't think it's safe to call output functions at arbitrary points 
from a debugger.  But if you're okay with that during development, say, 
then I think you could just call OidOutputFunctionCall(F_RANGE_OUT, $1)?

---

From: Paul Jungwirth <[email-masked]>
Date: Wed, 14 Aug 2024 08:46:44 -0700

On 8/14/24 02:16, Peter Eisentraut wrote:
>>>> [...] This function takes a Datum and the appropriate out function, and returns a char *. So you
>>>> can do this:
>>>>
>>>> I assume a patch like this doesn't need documentation. Does it need a test? Anything else?
>>>
> I don't think it's safe to call output functions at arbitrary points from a debugger.  But if you're 
> okay with that during development, say, then I think you could just call 
> OidOutputFunctionCall(F_RANGE_OUT, $1)?

I assumed it wasn't safe everywhere (e.g. there is potentially a TOAST lookup), but for debugging a 
patch that's okay with me.

Are you doing something to get macro expansion? I've never gotten my gdb to see #defines, although 
in theory this configure line should do it, right?:

./configure 'CFLAGS=-ggdb -Og -g3 -fno-omit-frame-pointer' --enable-tap-tests --enable-cassert 
--enable-debug --prefix=${HOME}/local

I also tried -gdwarf and -gdwarf-4 and -gdwarf-5 (all still with -Og -g3).

If it makes a difference, I'm attaching to a process:

paul@tal:~/src/postgresql$ gdb -p 1175735
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04.2) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
     <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 1175735
Reading symbols from /home/paul/local/bin/postgres...
Reading symbols from /lib/x86_64-linux-gnu/libz.so.1...
(No debugging symbols found in /lib/x86_64-linux-gnu/libz.so.1)
Reading symbols from /lib/x86_64-linux-gnu/libm.so.6...
Reading symbols from /usr/lib/debug/.build-id/a5/08ec5d8bf12fb7fd08204e0f87518e5cd0b102.debug...
Reading symbols from /lib/x86_64-linux-gnu/libicui18n.so.70...
(No debugging symbols found in /lib/x86_64-linux-gnu/libicui18n.so.70)
Reading symbols from /lib/x86_64-linux-gnu/libicuuc.so.70...
(No debugging symbols found in /lib/x86_64-linux-gnu/libicuuc.so.70)
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
Reading symbols from /usr/lib/debug/.build-id/49/0fef8403240c91833978d494d39e537409b92e.debug...
Reading symbols from /lib64/ld-linux-x86-64.so.2...
Reading symbols from /usr/lib/debug/.build-id/41/86944c50f8a32b47d74931e3f512b811813b64.debug...
Reading symbols from /lib/x86_64-linux-gnu/libstdc++.so.6...
(No debugging symbols found in /lib/x86_64-linux-gnu/libstdc++.so.6)
Reading symbols from /lib/x86_64-linux-gnu/libgcc_s.so.1...
(No debugging symbols found in /lib/x86_64-linux-gnu/libgcc_s.so.1)
Reading symbols from /lib/x86_64-linux-gnu/libicudata.so.70...
(No debugging symbols found in /lib/x86_64-linux-gnu/libicudata.so.70)
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x000079878e325dea in epoll_wait (epfd=7, events=0x573f0e475820, maxevents=1, timeout=-1) at 
../sysdeps/unix/sysv/linux/epoll_wait.c:30
30      ../sysdeps/unix/sysv/linux/epoll_wait.c: No such file or directory.
(gdb) b range_in
Breakpoint 1 at 0x573f0d9b5042: file rangetypes.c, line 91.
(gdb) c
Continuing.

Breakpoint 1, range_in (fcinfo=0x7fff6d8fea90) at rangetypes.c:91
91      {
(gdb) fin
Run till exit from #0  range_in (fcinfo=0x7fff6d8fea90) at rangetypes.c:91
0x0000573f0da8c87e in InputFunctionCall (flinfo=0x7fff6d8feb20, str=0x573f0e47a258 "[3,5)", 
typioparam=3904, typmod=-1) at fmgr.c:1547
1547            result = FunctionCallInvoke(fcinfo);
Value returned is $1 = 95928334988456
(gdb) call OidOutputFunctionCall(F_RANGE_OUT, $1)
No symbol "F_RANGE_OUT" in current context.

If I know the oid, then this works:

(gdb) call OidOutputFunctionCall(3835, $1)
$2 = 0x5f9be16ca4d8 "[3,5)"

That is a big improvement, but still a little annoying.

Thanks,

-- 
Paul              ~{:-)
[email-masked]

---

From: Peter Eisentraut <[email-masked]>
Date: Thu, 15 Aug 2024 09:50:15 +0200

On 14.08.24 17:46, Paul Jungwirth wrote:
>> from a debugger.  But if you're okay with that during development, 
>> say, then I think you could just call 
> I assumed it wasn't safe everywhere (e.g. there is potentially a TOAST 
> lookup), but for debugging a patch that's okay with me.
> 
> Are you doing something to get macro expansion? I've never gotten my gdb 
> to see #defines, although in theory this configure line should do it, 
> right?:

Oh I see, you don't have the F_* constants available then.  Maybe just 
put in the OID manually then?

---

From: Tom Lane <[email-masked]>
Date: Thu, 15 Aug 2024 10:05:07 -0400

> put in the OID manually then?

That's pretty illegible and error-prone.  I agree that writing the
output function's C name is noticeably better.  However, I would
call the result DirectOutputFunctionCall and put it near
OidOutputFunctionCall in fmgr.c.  It's not like we don't already
have a naming convention and many instances of this.

(Also, now that I look at the code, I wonder why it looks so
little like any of the existing DirectFunctionCall functions.)

			regards, tom lane