Обсуждение: 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.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.
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. >> > >
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.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)
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).
>>>>> "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)
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.)
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.)
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.)