Re: Make tuple deformation faster

From: Alexander Lakhin <exclusion(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>
Cc: Victor Yegorov <vyegorov(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Make tuple deformation faster
Date: 2024-12-23 13:00:00
Message-ID: ca3a256a-5d12-42db-aabe-a75a030d9fb9@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello David,

20.12.2024 12:31, David Rowley wrote:
> The attcacheoff removal is now pushed. I've attached the two remaining patches.

Please look at the following query, which triggers (sometimes not on a
first run) an assert added with 5983a4cff:
regression=# SELECT COUNT(*) FROM
(SELECT (aclexplode(proacl)).* FROM pg_proc) a,
(SELECT oid FROM pg_proc UNION ALL SELECT oid FROM pg_proc) b;
 count
--------
 520366
(1 row)

regression=# SELECT COUNT(*) FROM
(SELECT (aclexplode(proacl)).* FROM pg_proc) a,
(SELECT oid FROM pg_proc UNION ALL SELECT oid FROM pg_proc) b;
WARNING:  terminating connection because of crash of another server process
...
TRAP: failed Assert("memcmp(&snapshot, cattr, sizeof(CompactAttribute)) == 0"), File:
"../../../../src/include/access/tupdesc.h", Line: 191, PID: 1302048
ExceptionalCondition at assert.c:52:13
TupleDescCompactAttr at tupdesc.h:195:1
nocachegetattr at heaptuple.c:668:8
fastgetattr at htup_details.h:768:11
heap_getattr at htup_details.h:804:11
ExecEvalFieldSelect at execExprInterp.c:3623:17
ExecInterpExpr at execExprInterp.c:1542:4
MemoryContextSwitchTo at palloc.h:128:23
 (inlined by) ExecEvalExprSwitchContext at executor.h:370:2
ExecProject at executor.h:409:18
ExecResult at nodeResult.c:139:1
ExecProcNode at executor.h:273:1
SubqueryNext at nodeSubqueryscan.c:61:1
ExecScanFetch at execScan.c:131:10
ExecScan at execScan.c:197:10
ExecSubqueryScan at nodeSubqueryscan.c:90:1
ExecProcNode at executor.h:273:1
ExecMaterial at nodeMaterial.c:134:15
ExecProcNode at executor.h:273:1
ExecNestLoop at nodeNestloop.c:160:29
ExecProcNode at executor.h:273:1
fetch_input_tuple at nodeAgg.c:561:10
agg_retrieve_direct at nodeAgg.c:2459:18
...
LaunchMissingBackgroundProcesses at postmaster.c:3220:1

(I've discovered this with SQLsmith.)

Best regards,
Alexander

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message RECHTÉ Marc 2024-12-23 13:56:51 Re: Logical replication timeout
Previous Message Hayato Kuroda (Fujitsu) 2024-12-23 12:29:28 RE: Logical replication timeout