Thread: BUG #15653: pg_detoast_datum_packed problem

BUG #15653: pg_detoast_datum_packed problem

From
PG Bug reporting form
Date:
The following bug has been logged on the website:

Bug reference:      15653
Logged by:          Vladimir Kokovic
Email address:      vladimir.kokovic@gmail.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.


Re: BUG #15653: pg_detoast_datum_packed problem

From
gmail Vladimir Koković
Date:
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.kokovic@gmail.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.
>>
>
>


Re: BUG #15653: pg_detoast_datum_packed problem

From
gmail Vladimir Koković
Date:
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



Re: BUG #15653: pg_detoast_datum_packed problem

From
Andrew Gierth
Date:
>>>>> "gmail" == gmail Vladimir Koković <vladimir.kokovic@gmail.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)


Re: BUG #15653: pg_detoast_datum_packed problem

From
gmail Vladimir Koković
Date:

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@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@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@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@plt>
-	0x7f5b4adb146d:		nop    DWORD PTR [rax]

































On 8.3.19. 20:15, Andrew Gierth wrote:
"gmail" == gmail Vladimir Koković <vladimir.kokovic@gmail.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).

Re: BUG #15653: pg_detoast_datum_packed problem

From
Andrew Gierth
Date:
>>>>> "gmail" == gmail Vladimir Koković <vladimir.kokovic@gmail.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)


Re: BUG #15653: pg_detoast_datum_packed problem

From
gmail Vladimir Koković
Date:

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.kokovic@gmail.com> writes:
gmail> Hi Andrew.gmail> I changed VARSIZE to VARSIZE_ANY_EXHDR and VARDATA ingmail> VARDATA_ANY as you said, but there is still a problem I can notgmail> 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.)

Re: BUG #15653: pg_detoast_datum_packed problem

From
gmail Vladimir Koković
Date:

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.kokovic@gmail.com> writes:
 gmail> Hi Andrew.gmail> I changed VARSIZE to VARSIZE_ANY_EXHDR and VARDATA ingmail> VARDATA_ANY as you said, but there is still a problem I can notgmail> 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.)

Re: BUG #15653: pg_detoast_datum_packed problem

From
gmail Vladimir Koković
Date:

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.kokovic@gmail.com> writes:
 gmail> Hi Andrew.gmail> I changed VARSIZE to VARSIZE_ANY_EXHDR and VARDATA ingmail> VARDATA_ANY as you said, but there is still a problem I can notgmail> 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.)