Re: BUG #15653: pg_detoast_datum_packed problem

The following bug has been logged on the website:

Bug reference: 15653
Logged by: Vladimir Kokovic
Email address: vladimir(dot)kokovic(at)gmail(dot)com
PostgreSQL version: Unsupported/Unknown
Operating system: linux manjaro
Description:

This bug I have to report only for sentimental reasons because vkBytea
system exists since the version of PostgreSQL 7.4!
vkBytea system serves to restore all elemental PostgreSQL types in bytea
form.
It survived all versions in the meantime so that current GIT HEAD would
report SIGSEGV to the pg_bvarchar method.
My impression is that the problem is in the method pg_detoast_datum_packed
but i do not understand the reason why. select * return all rows OK.

The complete primer and source in tar.gz will be sent later.

Hi,

GDB BACKTRACE
-------------
GNU gdb (GDB) 8.2.1
Copyright (C) 2018 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-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://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"...
vk qt5printers
vk wx5printers
vk libpython
sys.version_info(major=3, minor=7, micro=2, releaselevel='final', serial=0)
Reading symbols from
/mnt/sdd1/home/src/postgresql-devel/20190222/bin/postgres...done.
[New LWP 4815]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `postgres: vlada ispp-pionir-test ::1(33336)
SELECT                            '.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f8888d24f10 in __memcpy_ssse3 () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007f8888d24f10 in __memcpy_ssse3 () from /usr/lib/libc.so.6
#1  0x00007f8889e615ce in pg_bvarchar (fcinfo=0x560c6689fa40) at
vkBytea.c:137
#2  0x0000560c6503478c in ExecInterpExpr (state=0x560c6689f488,
econtext=0x560c6689e910, isnull=0x7ffe0538847f)
    at
/mnt/sdd1/home/src/postgresql-devel/postgresql-git/postgresql/src/backend/executor/execExprInterp.c:649
#3  0x0000560c6503672b in ExecInterpExprStillValid
(state=0x560c6689f488, econtext=0x560c6689e910, isNull=0x7ffe0538847f)
    at
/mnt/sdd1/home/src/postgresql-devel/postgresql-git/postgresql/src/backend/executor/execExprInterp.c:1769
#4  0x0000560c6504ccad in ExecEvalExprSwitchContext
(state=0x560c6689f488, econtext=0x560c6689e910, isNull=0x7ffe0538847f)
    at
/mnt/sdd1/home/src/postgresql-devel/postgresql-git/postgresql/src/include/executor/executor.h:308
#5  0x0000560c6504cddd in ExecQual (state=0x560c6689f488,
econtext=0x560c6689e910)
    at
/mnt/sdd1/home/src/postgresql-devel/postgresql-git/postgresql/src/include/executor/executor.h:377
#6  0x0000560c6504d0d2 in ExecScan (node=0x560c6689e7f8,
accessMtd=0x560c65080e57 <SeqNext>, recheckMtd=0x560c65080f20 <SeqRecheck>)
    at
/mnt/sdd1/home/src/postgresql-devel/postgresql-git/postgresql/src/backend/executor/execScan.c:190
#7  0x0000560c65080f6e in ExecSeqScan (pstate=0x560c6689e7f8)
    at
/mnt/sdd1/home/src/postgresql-devel/postgresql-git/postgresql/src/backend/executor/nodeSeqscan.c:129
#8  0x0000560c6504ad76 in ExecProcNodeFirst (node=0x560c6689e7f8)
    at
/mnt/sdd1/home/src/postgresql-devel/postgresql-git/postgresql/src/backend/executor/execProcnode.c:445
#9  0x0000560c65082510 in ExecProcNode (node=0x560c6689e7f8)
    at
/mnt/sdd1/home/src/postgresql-devel/postgresql-git/postgresql/src/include/executor/executor.h:241
#10 0x0000560c65082656 in ExecSort (pstate=0x560c6689e5e0)
    at
/mnt/sdd1/home/src/postgresql-devel/postgresql-git/postgresql/src/backend/executor/nodeSort.c:107
#11 0x0000560c6504ad76 in ExecProcNodeFirst (node=0x560c6689e5e0)
    at
/mnt/sdd1/home/src/postgresql-devel/postgresql-git/postgresql/src/backend/executor/execProcnode.c:445
#12 0x0000560c6503f1f9 in ExecProcNode (node=0x560c6689e5e0)
    at
/mnt/sdd1/home/src/postgresql-devel/postgresql-git/postgresql/src/include/executor/executor.h:241
#13 0x0000560c65041be1 in ExecutePlan (estate=0x560c6689e388,
planstate=0x560c6689e5e0, use_parallel_mode=false, operation=CMD_SELECT,
sendTuples=true,
    numberTuples=0, direction=ForwardScanDirection,
dest=0x560c668ef3c8, execute_once=true)
    at
/mnt/sdd1/home/src/postgresql-devel/postgresql-git/postgresql/src/backend/executor/execMain.c:1644
#14 0x0000560c6503f871 in standard_ExecutorRun
(queryDesc=0x560c6693aab8, direction=ForwardScanDirection, count=0,
execute_once=true)
    at
/mnt/sdd1/home/src/postgresql-devel/postgresql-git/postgresql/src/backend/executor/execMain.c:362
#15 0x0000560c6503f695 in ExecutorRun (queryDesc=0x560c6693aab8,
direction=ForwardScanDirection, count=0, execute_once=true)
    at
/mnt/sdd1/home/src/postgresql-devel/postgresql-git/postgresql/src/backend/executor/execMain.c:306
#16 0x0000560c65256540 in PortalRunSelect (portal=0x560c66824048,
forward=true, count=0, dest=0x560c668ef3c8)
    at
/mnt/sdd1/home/src/postgresql-devel/postgresql-git/postgresql/src/backend/tcop/pquery.c:929
--Type <RET> for more, q to quit, c to continue without paging--
#17 0x0000560c6525615f in PortalRun (portal=0x560c66824048,
count=9223372036854775807, isTopLevel=true, run_once=true,
dest=0x560c668ef3c8,
    altdest=0x560c668ef3c8, completionTag=0x7ffe05388950 "") at
/mnt/sdd1/home/src/postgresql-devel/postgresql-git/postgresql/src/backend/tcop/pquery.c:770
#18 0x0000560c6524f797 in exec_simple_query (
    query_string=0x560c667b5528 "RELEASE _EXEC_SVP_0x4f3870;SAVEPOINT
_EXEC_SVP_0x4f3870;select *,OID from ispp_wmpl where
(bvarchar(key))>=(bvarchar('W '::varchar)) and
(bvarchar(key))<=(bvarchar('W", '~' <repeats 11 times>, "'::varchar)) 
order by key")
    at
/mnt/sdd1/home/src/postgresql-devel/postgresql-git/postgresql/src/backend/tcop/postgres.c:1215
#19 0x0000560c652541a6 in PostgresMain (argc=1, argv=0x560c667ae488,
dbname=0x560c667e1e68 "ispp-pionir-test", username=0x560c667e4020 "vlada")
    at
/mnt/sdd1/home/src/postgresql-devel/postgresql-git/postgresql/src/backend/tcop/postgres.c:4256
#20 0x0000560c651a4be9 in BackendRun (port=0x560c667db6f0)
    at
/mnt/sdd1/home/src/postgresql-devel/postgresql-git/postgresql/src/backend/postmaster/postmaster.c:4382
#21 0x0000560c651a42d1 in BackendStartup (port=0x560c667db6f0)
    at
/mnt/sdd1/home/src/postgresql-devel/postgresql-git/postgresql/src/backend/postmaster/postmaster.c:4073
#22 0x0000560c651a020d in ServerLoop () at
/mnt/sdd1/home/src/postgresql-devel/postgresql-git/postgresql/src/backend/postmaster/postmaster.c:1703
#23 0x0000560c6519f999 in PostmasterMain (argc=3, argv=0x560c667ac3c0)
    at
/mnt/sdd1/home/src/postgresql-devel/postgresql-git/postgresql/src/backend/postmaster/postmaster.c:1376
#24 0x0000560c650b941c in main (argc=3, argv=0x560c667ac3c0) at
/mnt/sdd1/home/src/postgresql-devel/postgresql-git/postgresql/src/backend/main/main.c:228
(gdb)

Vladimir Koković, DP senior(69)
Belgrade, Mar. 1 2019

On 25.2.19. 17:37, gmail Vladimir Koković wrote:
> The complete primer and source in tar.gz
>
> On 23.2.19. 21:43, PG Bug reporting form wrote:
>> The following bug has been logged on the website:
>>
>> Bug reference:      15653
>> Logged by:          Vladimir Kokovic
>> Email address:      vladimir(dot)kokovic(at)gmail(dot)com
>> PostgreSQL version: Unsupported/Unknown
>> Operating system:   linux manjaro
>> Description:
>>
>> This bug I have to report only for sentimental reasons because vkBytea
>> system exists since the version of PostgreSQL 7.4!
>> vkBytea system serves to restore all elemental PostgreSQL types in bytea
>> form.
>> It survived all versions in the meantime so that current GIT HEAD would
>> report SIGSEGV to the pg_bvarchar method.
>> My impression is that the problem is in the method
>> pg_detoast_datum_packed
>> but i do not understand the reason why.  select * return all rows OK.
>>
>> The complete primer and source in tar.gz will be sent later.
>>
>
>

Hi,

/* SQL function: bvarchar(varchar) returns bytea */

PG_FUNCTION_INFO_V1(pg_bvarchar);
Datum pg_bvarchar(PG_FUNCTION_ARGS) {
  VarChar *arg = PG_GETARG_VARCHAR_PP(0);
    unsigned    len;
    bytea       *res;
    len = VARSIZE( arg ) - VARHDRSZ;
    res = (text *)palloc( len + VARHDRSZ );
    SET_VARSIZE( res, len + VARHDRSZ );
    memcpy( VARDATA( res ), VARDATA( arg ), len);
    PG_RETURN_BYTEA_P(res);
}

Vladimir Koković, DP senior(69)
Belgrade, Mar. 1 2019

>>>>> "gmail" == gmail Vladimir Koković <vladimir(dot)kokovic(at)gmail(dot)com> writes:

gmail>   VarChar *arg = PG_GETARG_VARCHAR_PP(0);

The _PP there means that this is allowed to return either a packed
(short) varlena or a normal one...

gmail>     len = VARSIZE( arg ) - VARHDRSZ;

...but VARSIZE is only allowed on unpacked varlenas, you need to use
VARSIZE_ANY_EXHDR instead (and VARDATA_ANY rather than VARDATA).

--
Andrew (irc:RhodiumToad)

Hi Andrew.

I changed VARSIZE to VARSIZE_ANY_EXHDR and VARDATA in VARDATA_ANY as you
said, but there is still a problem I can not understand ! 124 Datum
pg_bvarchar(PG_FUNCTION_ARGS) { 125 VarChar *arg =
PG_GETARG_VARCHAR_PP(0); 0x7f5b4adb1380 <pg_bvarchar>: push r13 -
0x7f5b4adb1382 <pg_bvarchar+2>: push r12 - 0x7f5b4adb1384
<pg_bvarchar+4>: push rbp - 0x7f5b4adb1385 <pg_bvarchar+5>: push rbx -
0x7f5b4adb1386 <pg_bvarchar+6>: sub rsp,0x8 - 0x7f5b4adb138a
<pg_bvarchar+10>: mov rdi,QWORD PTR [rdi+0x20] - 0x7f5b4adb138e
<pg_bvarchar+14>: call 0x7f5b4adb1030 <pg_detoast_datum_packed(at)plt> -
0x7f5b4adb1393 <pg_bvarchar+19>: mov rbx,rax 126 unsigned len; 127 bytea
*res; 128 129 len = VARSIZE_ANY_EXHDR(arg) - VARHDRSZ; - 0x7f5b4adb1396
<pg_bvarchar+22>: movzx eax,BYTE PTR [rax] - 0x7f5b4adb1399
<pg_bvarchar+25>: cmp al,0x1 - 0x7f5b4adb139b <pg_bvarchar+27>: je
0x7f5b4adb1408 <pg_bvarchar+136> - 0x7f5b4adb139d <pg_bvarchar+29>: test
al,0x1 - 0x7f5b4adb139f <pg_bvarchar+31>: jne 0x7f5b4adb13f0
<pg_bvarchar+112> - 0x7f5b4adb13a1 <pg_bvarchar+33>: mov eax,DWORD PTR
[rbx] - 0x7f5b4adb13a3 <pg_bvarchar+35>: shr eax,0x2 - 0x7f5b4adb13a6
<pg_bvarchar+38>: lea edi,[rax-0x4] - 0x7f5b4adb13a9 <pg_bvarchar+41>:
lea r13d,[rax-0x8] - 0x7f5b4adb13ad <pg_bvarchar+45>: mov r12,rdi -
0x7f5b4adb13b0 <pg_bvarchar+48>: shl r12d,0x2 130 res = (text *)
palloc(len + VARHDRSZ); - 0x7f5b4adb13b4 <pg_bvarchar+52>: call
0x7f5b4adb1050 <palloc(at)plt> - 0x7f5b4adb13b9 <pg_bvarchar+57>: lea
rsi,[rbx+0x4] - 0x7f5b4adb13bd <pg_bvarchar+61>: mov rdx,r13 -
0x7f5b4adb13c0 <pg_bvarchar+64>: mov rbp,rax 131 SET_VARSIZE(res, len +
VARHDRSZ); - 0x7f5b4adb13c3 <pg_bvarchar+67>: mov DWORD PTR [rax],r12d
132 memcpy(VARDATA(res), VARDATA_ANY(arg), len); - 0x7f5b4adb13c6
<pg_bvarchar+70>: lea rax,[rbx+0x1] - 0x7f5b4adb13ca <pg_bvarchar+74>:
test BYTE PTR [rbx],0x1 - 0x7f5b4adb13cd <pg_bvarchar+77>: cmovne
rsi,rax - 0x7f5b4adb13d1 <pg_bvarchar+81>: lea rdi,[rbp+0x4] -
0x7f5b4adb13d5 <pg_bvarchar+85>: call 0x7f5b4adb1040 <memcpy(at)plt>
Program terminated with signal SIGSEGV, Segmentation fault. 133
PG_RETURN_BYTEA_P(res); - 0x7f5b4adb13da <pg_bvarchar+90>: add rsp,0x8 -
0x7f5b4adb13de <pg_bvarchar+94>: mov rax,rbp - 0x7f5b4adb13e1
<pg_bvarchar+97>: pop rbx - 0x7f5b4adb13e2 <pg_bvarchar+98>: pop rbp -
0x7f5b4adb13e3 <pg_bvarchar+99>: pop r12 - 0x7f5b4adb13e5
<pg_bvarchar+101>: pop r13 - 0x7f5b4adb13e7 <pg_bvarchar+103>: ret -
0x7f5b4adb13e8 <pg_bvarchar+104>: nop DWORD PTR [rax+rax*1+0x0] -
0x7f5b4adb13f0 <pg_bvarchar+112>: shr al,1 - 0x7f5b4adb13f2
<pg_bvarchar+114>: movzx eax,al - 0x7f5b4adb13f5 <pg_bvarchar+117>: lea
edi,[rax-0x1] - 0x7f5b4adb13f8 <pg_bvarchar+120>: lea r13d,[rax-0x5] -
0x7f5b4adb13fc <pg_bvarchar+124>: mov r12,rdi - 0x7f5b4adb13ff
<pg_bvarchar+127>: shl r12d,0x2 - 0x7f5b4adb1403 <pg_bvarchar+131>: jmp
0x7f5b4adb13b4 <pg_bvarchar+52> - 0x7f5b4adb1405 <pg_bvarchar+133>: nop
DWORD PTR [rax] - 0x7f5b4adb1408 <pg_bvarchar+136>: movzx eax,BYTE PTR
[rbx+0x1] - 0x7f5b4adb140c <pg_bvarchar+140>: cmp al,0x1 -
0x7f5b4adb140e <pg_bvarchar+142>: je 0x7f5b4adb1438 <pg_bvarchar+184> -
0x7f5b4adb1410 <pg_bvarchar+144>: mov edx,eax - 0x7f5b4adb1412
<pg_bvarchar+146>: and edx,0xfe - 0x7f5b4adb1418 <pg_bvarchar+152>: cmp
edx,0x2 - 0x7f5b4adb141b <pg_bvarchar+155>: je 0x7f5b4adb1438
<pg_bvarchar+184> - 0x7f5b4adb141d <pg_bvarchar+157>: cmp al,0x12 -
0x7f5b4adb141f <pg_bvarchar+159>: jne 0x7f5b4adb144e <pg_bvarchar+206> -
0x7f5b4adb1421 <pg_bvarchar+161>: mov r13d,0xc - 0x7f5b4adb1427
<pg_bvarchar+167>: mov r12d,0x40 - 0x7f5b4adb142d <pg_bvarchar+173>: mov
edi,0x10 - 0x7f5b4adb1432 <pg_bvarchar+178>: jmp 0x7f5b4adb13b4
<pg_bvarchar+52> - 0x7f5b4adb1434 <pg_bvarchar+180>: nop DWORD PTR
[rax+0x0] - 0x7f5b4adb1438 <pg_bvarchar+184>: mov r13d,0x4 -
0x7f5b4adb143e <pg_bvarchar+190>: mov r12d,0x20 - 0x7f5b4adb1444
<pg_bvarchar+196>: mov edi,0x8 - 0x7f5b4adb1449 <pg_bvarchar+201>: jmp
0x7f5b4adb13b4 <pg_bvarchar+52> - 0x7f5b4adb144e <pg_bvarchar+206>: mov
ecx,0x81 - 0x7f5b4adb1453 <pg_bvarchar+211>: lea rdx,[rip+0xba6] #
0x7f5b4adb2000 - 0x7f5b4adb145a <pg_bvarchar+218>: lea rsi,[rip+0xba9] #
0x7f5b4adb200a - 0x7f5b4adb1461 <pg_bvarchar+225>: lea rdi,[rip+0xbbc] #
0x7f5b4adb2024 - 0x7f5b4adb1468 <pg_bvarchar+232>: call 0x7f5b4adb1060
<ExceptionalCondition(at)plt> - 0x7f5b4adb146d: nop DWORD PTR [rax]

On 8.3.19. 20:15, Andrew Gierth wrote:
>>>>>> "gmail" == gmail Vladimir Koković <vladimir(dot)kokovic(at)gmail(dot)com> writes:
> gmail>   VarChar *arg = PG_GETARG_VARCHAR_PP(0);
>
> The _PP there means that this is allowed to return either a packed
> (short) varlena or a normal one...
>
> gmail>     len = VARSIZE( arg ) - VARHDRSZ;
>
> ...but VARSIZE is only allowed on unpacked varlenas, you need to use
> VARSIZE_ANY_EXHDR instead (and VARDATA_ANY rather than VARDATA).
>

>>>>> "gmail" == gmail Vladimir Koković <vladimir(dot)kokovic(at)gmail(dot)com> writes:

gmail> Hi Andrew.
gmail> I changed VARSIZE to VARSIZE_ANY_EXHDR and VARDATA in
gmail> VARDATA_ANY as you said, but there is still a problem I can not
gmail> understand !

Your message formatting was all messed up, but I can see that you are
still subtracting VARHDRSZ - don't do that: VARSIZE_ANY_EXHDR already
has the header size subtracted (hence "EXHDR"), it returns only the data
size. (The header size is variable, 1 or 4 bytes, so it wouldn't make
sense to include it.)

--
Andrew (irc:RhodiumToad)

Hi Andrew,

You are absolutely right and "select ", OID from ispp_wmpl where
(bvarchar (key))> = (bvarchar ('W' :: varchar)) and (bvarchar (key)) <=
(bvarchar ~~~~~~~~ ':: varchar)) order by key" has passed! However, pg
log file now has hundreds of warning message: 2019-03-09 10:53:29 CET
ispp-pionir-test :: 1 (53858) 14721 0 01000 WARNING: problem in
allocation set ExprContext: detected write past chunk end block
0x55ccb0b36468, chunk 0x55ccb0b36490 2019-03-09 10:53:29 CET
ispp-pionir-test :: 1 (53858) 14721 0 01000 WARNING: problem in
allocation set ExprContext: detected write past chunk end in block
0x55ccb0b36468, chunk 0x55ccb0b36490 2019-03-09 10:53:29 CET
ispp-pionir-test :: 1 (53858) 14721 0 01000 WARNING: problem in
allocation set ExprContext: detected write past chunk end in block
0x55ccb0b36468, chunk 0x55ccb0b36490 ... Andrew, I have to thank you for
this help because without this, my 'select' would never have passed. Vladimir Koković, DP senior(69)
Belgrade, Mar. 9 2019

On 9.3.19. 10:48, Andrew Gierth wrote:
>>>>>> "gmail" == gmail Vladimir Koković <vladimir(dot)kokovic(at)gmail(dot)com> writes:
> gmail> Hi Andrew.
> gmail> I changed VARSIZE to VARSIZE_ANY_EXHDR and VARDATA in
> gmail> VARDATA_ANY as you said, but there is still a problem I can not
> gmail> understand !
>
> Your message formatting was all messed up, but I can see that you are
> still subtracting VARHDRSZ - don't do that: VARSIZE_ANY_EXHDR already
> has the header size subtracted (hence "EXHDR"), it returns only the data
> size. (The header size is variable, 1 or 4 bytes, so it wouldn't make
> sense to include it.)
>

Hi Andrew,

I forgot to show the final version of pg_bvarchar.

/* SQL function: bvarchar(varchar) returns bytea */

PG_FUNCTION_INFO_V1(pg_bvarchar);
Datum pg_bvarchar(PG_FUNCTION_ARGS) {
  VarChar *arg = PG_GETARG_VARCHAR_PP(0);
  unsigned len;
  bytea *res;

  len = VARSIZE_ANY_EXHDR(arg);
  res = (text *) palloc(len);
  SET_VARSIZE(res, len + VARHDRSZ);
  memcpy(VARDATA(res), VARDATA_ANY(arg), len);
  PG_RETURN_BYTEA_P(res);
}

On 9.3.19. 11:08, gmail Vladimir Koković wrote:

> Hi Andrew,
>
> You are absolutely right and "select ", OID from ispp_wmpl where
> (bvarchar (key))> = (bvarchar ('W' :: varchar)) and (bvarchar (key))
> <= (bvarchar ~~~~~~~~ ':: varchar)) order by key" has passed! However,
> pg log file now has hundreds of warning message: 2019-03-09 10:53:29
> CET ispp-pionir-test :: 1 (53858) 14721 0 01000 WARNING: problem in
> allocation set ExprContext: detected write past chunk end block
> 0x55ccb0b36468, chunk 0x55ccb0b36490 2019-03-09 10:53:29 CET
> ispp-pionir-test :: 1 (53858) 14721 0 01000 WARNING: problem in
> allocation set ExprContext: detected write past chunk end in block
> 0x55ccb0b36468, chunk 0x55ccb0b36490 2019-03-09 10:53:29 CET
> ispp-pionir-test :: 1 (53858) 14721 0 01000 WARNING: problem in
> allocation set ExprContext: detected write past chunk end in block
> 0x55ccb0b36468, chunk 0x55ccb0b36490 ... Andrew, I have to thank you
> for this help because without this, my 'select' would never have passed. Vladimir Koković, DP senior(69)
> Belgrade, Mar. 9 2019
>
> On 9.3.19. 10:48, Andrew Gierth wrote:

> "gmail" == gmail Vladimir Koković<vladimir(dot)kokovic(at)gmail(dot)com> writes:
>> gmail> Hi Andrew.
>> gmail> I changed VARSIZE to VARSIZE_ANY_EXHDR and VARDATA in
>> gmail> VARDATA_ANY as you said, but there is still a problem I can not
>> gmail> understand !
>>
>> Your message formatting was all messed up, but I can see that you are
>> still subtracting VARHDRSZ - don't do that: VARSIZE_ANY_EXHDR already
>> has the header size subtracted (hence "EXHDR"), it returns only the data
>> size. (The header size is variable, 1 or 4 bytes, so it wouldn't make
>> sense to include it.)
>>

Hi Andrew,

Definitely the problem is solved with the following version pg_bvarchar!

/* SQL function: bvarchar(varchar) returns bytea */

PG_FUNCTION_INFO_V1(pg_bvarchar);
Datum pg_bvarchar(PG_FUNCTION_ARGS) {
  VarChar *arg = PG_GETARG_VARCHAR_PP(0);
  unsigned len;
  bytea *res;

  len = VARSIZE_ANY_EXHDR(arg);
  res = (text *) palloc(len + VARHDRSZ);
  SET_VARSIZE(res, len + VARHDRSZ);
  memcpy(VARDATA(res), VARDATA_ANY(arg), len);
  PG_RETURN_BYTEA_P(res);
}

'select' has passed and no more warnigs.

Thanks again.

Vladimir Koković, DP senior(69)
Belgrade, Mar. 9 2019

On 9.3.19. 11:54, gmail Vladimir Koković wrote:
>
> Hi Andrew,
>
> I forgot to show the final version of pg_bvarchar.
>
> /* SQL function: bvarchar(varchar) returns bytea */
>
> PG_FUNCTION_INFO_V1(pg_bvarchar);
> Datum pg_bvarchar(PG_FUNCTION_ARGS) {
>   VarChar *arg = PG_GETARG_VARCHAR_PP(0);
>   unsigned len;
>   bytea *res;
>
>   len = VARSIZE_ANY_EXHDR(arg);
>   res = (text *) palloc(len);
>   SET_VARSIZE(res, len + VARHDRSZ);
>   memcpy(VARDATA(res), VARDATA_ANY(arg), len);
>   PG_RETURN_BYTEA_P(res);
> }
>
> On 9.3.19. 11:08, gmail Vladimir Koković wrote:
>>
>> Hi Andrew,
>>
>> You are absolutely right and "select ", OID from ispp_wmpl where
>> (bvarchar (key))> = (bvarchar ('W' :: varchar)) and (bvarchar (key))
>> <= (bvarchar ~~~~~~~~ ':: varchar)) order by key" has passed!
>> However, pg log file now has hundreds of warning message: 2019-03-09
>> 10:53:29 CET ispp-pionir-test :: 1 (53858) 14721 0 01000 WARNING:
>> problem in allocation set ExprContext: detected write past chunk end
>> block 0x55ccb0b36468, chunk 0x55ccb0b36490 2019-03-09 10:53:29 CET
>> ispp-pionir-test :: 1 (53858) 14721 0 01000 WARNING: problem in
>> allocation set ExprContext: detected write past chunk end in block
>> 0x55ccb0b36468, chunk 0x55ccb0b36490 2019-03-09 10:53:29 CET
>> ispp-pionir-test :: 1 (53858) 14721 0 01000 WARNING: problem in
>> allocation set ExprContext: detected write past chunk end in block
>> 0x55ccb0b36468, chunk 0x55ccb0b36490 ... Andrew, I have to thank you
>> for this help because without this, my 'select' would never have passed. Vladimir Koković, DP senior(69)
>> Belgrade, Mar. 9 2019
>>
>> On 9.3.19. 10:48, Andrew Gierth wrote:
>
>> "gmail" == gmail Vladimir Koković<vladimir(dot)kokovic(at)gmail(dot)com> writes:
>>> gmail> Hi Andrew.
>>> gmail> I changed VARSIZE to VARSIZE_ANY_EXHDR and VARDATA in
>>> gmail> VARDATA_ANY as you said, but there is still a problem I can not
>>> gmail> understand !
>>>
>>> Your message formatting was all messed up, but I can see that you are
>>> still subtracting VARHDRSZ - don't do that: VARSIZE_ANY_EXHDR already
>>> has the header size subtracted (hence "EXHDR"), it returns only the data
>>> size. (The header size is variable, 1 or 4 bytes, so it wouldn't make
>>> sense to include it.)
>>>