agora inbox for pgsql-committers@postgresql.org  
help / color / mirror / Atom feed
pgsql: Tighten up TS dictionary cache entry creation.
7+ messages / 1 participants
[nested] [flat]

* pgsql: Tighten up TS dictionary cache entry creation.
@ 2026-08-02 20:49 Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 7+ messages in thread

From: Tom Lane @ 2026-08-02 20:49 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Tighten up TS dictionary cache entry creation.

In the not-too-likely scenario where we successfully created a hash
table entry for a TS dictionary, but then failed to make a small
memory context for it, we left the hash entry in existence but with
a garbage value for dictCtx.  This confused the code the next time
through, leading to a crash.  Rearrange things so that we leave
the hash entry in a well-defined state with dictCtx == NULL, and
then the next try knows it still needs to make a memory context.

Reported-by: Alexander Lakhin <exclusion@gmail.com>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/0f3ddeb5-0dbd-479c-9d0e-ae254758e624@gmail.com
Backpatch-through: 14

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/4e68b7e291d39bc778f867e08f2741e63417fc2e

Modified Files
--------------
src/backend/utils/cache/ts_cache.c | 29 +++++++++++++++++++++--------
1 file changed, 21 insertions(+), 8 deletions(-)



^ permalink  raw  reply  [nested|flat] 7+ messages in thread

* pgsql: Tighten up TS dictionary cache entry creation.
@ 2026-08-02 20:49 Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 7+ messages in thread

From: Tom Lane @ 2026-08-02 20:49 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Tighten up TS dictionary cache entry creation.

In the not-too-likely scenario where we successfully created a hash
table entry for a TS dictionary, but then failed to make a small
memory context for it, we left the hash entry in existence but with
a garbage value for dictCtx.  This confused the code the next time
through, leading to a crash.  Rearrange things so that we leave
the hash entry in a well-defined state with dictCtx == NULL, and
then the next try knows it still needs to make a memory context.

Reported-by: Alexander Lakhin <exclusion@gmail.com>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/0f3ddeb5-0dbd-479c-9d0e-ae254758e624@gmail.com
Backpatch-through: 14

Branch
------
REL_19_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/df8407d7dc7dc77165f56e5bdfed13ac72048696

Modified Files
--------------
src/backend/utils/cache/ts_cache.c | 29 +++++++++++++++++++++--------
1 file changed, 21 insertions(+), 8 deletions(-)



^ permalink  raw  reply  [nested|flat] 7+ messages in thread

* pgsql: Tighten up TS dictionary cache entry creation.
@ 2026-08-02 20:49 Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 7+ messages in thread

From: Tom Lane @ 2026-08-02 20:49 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Tighten up TS dictionary cache entry creation.

In the not-too-likely scenario where we successfully created a hash
table entry for a TS dictionary, but then failed to make a small
memory context for it, we left the hash entry in existence but with
a garbage value for dictCtx.  This confused the code the next time
through, leading to a crash.  Rearrange things so that we leave
the hash entry in a well-defined state with dictCtx == NULL, and
then the next try knows it still needs to make a memory context.

Reported-by: Alexander Lakhin <exclusion@gmail.com>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/0f3ddeb5-0dbd-479c-9d0e-ae254758e624@gmail.com
Backpatch-through: 14

Branch
------
REL_18_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/81b1e79166a524b95628f8d459571f1b029fe19e

Modified Files
--------------
src/backend/utils/cache/ts_cache.c | 29 +++++++++++++++++++++--------
1 file changed, 21 insertions(+), 8 deletions(-)



^ permalink  raw  reply  [nested|flat] 7+ messages in thread

* pgsql: Tighten up TS dictionary cache entry creation.
@ 2026-08-02 20:49 Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 7+ messages in thread

From: Tom Lane @ 2026-08-02 20:49 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Tighten up TS dictionary cache entry creation.

In the not-too-likely scenario where we successfully created a hash
table entry for a TS dictionary, but then failed to make a small
memory context for it, we left the hash entry in existence but with
a garbage value for dictCtx.  This confused the code the next time
through, leading to a crash.  Rearrange things so that we leave
the hash entry in a well-defined state with dictCtx == NULL, and
then the next try knows it still needs to make a memory context.

Reported-by: Alexander Lakhin <exclusion@gmail.com>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/0f3ddeb5-0dbd-479c-9d0e-ae254758e624@gmail.com
Backpatch-through: 14

Branch
------
REL_17_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/634a8dcb8f64bed1a74a465c707ee25cb6178fea

Modified Files
--------------
src/backend/utils/cache/ts_cache.c | 29 +++++++++++++++++++++--------
1 file changed, 21 insertions(+), 8 deletions(-)



^ permalink  raw  reply  [nested|flat] 7+ messages in thread

* pgsql: Tighten up TS dictionary cache entry creation.
@ 2026-08-02 20:49 Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 7+ messages in thread

From: Tom Lane @ 2026-08-02 20:49 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Tighten up TS dictionary cache entry creation.

In the not-too-likely scenario where we successfully created a hash
table entry for a TS dictionary, but then failed to make a small
memory context for it, we left the hash entry in existence but with
a garbage value for dictCtx.  This confused the code the next time
through, leading to a crash.  Rearrange things so that we leave
the hash entry in a well-defined state with dictCtx == NULL, and
then the next try knows it still needs to make a memory context.

Reported-by: Alexander Lakhin <exclusion@gmail.com>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/0f3ddeb5-0dbd-479c-9d0e-ae254758e624@gmail.com
Backpatch-through: 14

Branch
------
REL_16_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/83336e3ed30b0d0b021900429e5bfde8367e2729

Modified Files
--------------
src/backend/utils/cache/ts_cache.c | 29 +++++++++++++++++++++--------
1 file changed, 21 insertions(+), 8 deletions(-)



^ permalink  raw  reply  [nested|flat] 7+ messages in thread

* pgsql: Tighten up TS dictionary cache entry creation.
@ 2026-08-02 20:49 Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 7+ messages in thread

From: Tom Lane @ 2026-08-02 20:49 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Tighten up TS dictionary cache entry creation.

In the not-too-likely scenario where we successfully created a hash
table entry for a TS dictionary, but then failed to make a small
memory context for it, we left the hash entry in existence but with
a garbage value for dictCtx.  This confused the code the next time
through, leading to a crash.  Rearrange things so that we leave
the hash entry in a well-defined state with dictCtx == NULL, and
then the next try knows it still needs to make a memory context.

Reported-by: Alexander Lakhin <exclusion@gmail.com>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/0f3ddeb5-0dbd-479c-9d0e-ae254758e624@gmail.com
Backpatch-through: 14

Branch
------
REL_15_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/0252281049a6e06f6afb5b827f1ac6a45a7637c8

Modified Files
--------------
src/backend/utils/cache/ts_cache.c | 29 +++++++++++++++++++++--------
1 file changed, 21 insertions(+), 8 deletions(-)



^ permalink  raw  reply  [nested|flat] 7+ messages in thread

* pgsql: Tighten up TS dictionary cache entry creation.
@ 2026-08-02 20:49 Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 7+ messages in thread

From: Tom Lane @ 2026-08-02 20:49 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Tighten up TS dictionary cache entry creation.

In the not-too-likely scenario where we successfully created a hash
table entry for a TS dictionary, but then failed to make a small
memory context for it, we left the hash entry in existence but with
a garbage value for dictCtx.  This confused the code the next time
through, leading to a crash.  Rearrange things so that we leave
the hash entry in a well-defined state with dictCtx == NULL, and
then the next try knows it still needs to make a memory context.

Reported-by: Alexander Lakhin <exclusion@gmail.com>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/0f3ddeb5-0dbd-479c-9d0e-ae254758e624@gmail.com
Backpatch-through: 14

Branch
------
REL_14_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/dda622edcdba673e90d7b2cafe747ab78249368b

Modified Files
--------------
src/backend/utils/cache/ts_cache.c | 29 +++++++++++++++++++++--------
1 file changed, 21 insertions(+), 8 deletions(-)



^ permalink  raw  reply  [nested|flat] 7+ messages in thread


end of thread, other threads:[~2026-08-02 20:49 UTC | newest]

Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-08-02 20:49 pgsql: Tighten up TS dictionary cache entry creation. Tom Lane <tgl@sss.pgh.pa.us>
2026-08-02 20:49 pgsql: Tighten up TS dictionary cache entry creation. Tom Lane <tgl@sss.pgh.pa.us>
2026-08-02 20:49 pgsql: Tighten up TS dictionary cache entry creation. Tom Lane <tgl@sss.pgh.pa.us>
2026-08-02 20:49 pgsql: Tighten up TS dictionary cache entry creation. Tom Lane <tgl@sss.pgh.pa.us>
2026-08-02 20:49 pgsql: Tighten up TS dictionary cache entry creation. Tom Lane <tgl@sss.pgh.pa.us>
2026-08-02 20:49 pgsql: Tighten up TS dictionary cache entry creation. Tom Lane <tgl@sss.pgh.pa.us>
2026-08-02 20:49 pgsql: Tighten up TS dictionary cache entry creation. Tom Lane <tgl@sss.pgh.pa.us>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox