pg.ddx.io pgsql-committers@postgresql.org mailing list archive
help / color / mirror / Atom feedreorg - pg_reorg: Release 1.0.6.
5+ messages / 2 participants
[nested] [flat]
* reorg - pg_reorg: Release 1.0.6.
@ 2009-07-03 05:52 User Itagaki <itagaki@pgfoundry.org>
0 siblings, 0 replies; 5+ messages in thread
From: itagaki@pgfoundry.org @ 2009-07-03 05:52 UTC (permalink / raw)
To: pgsql-committers
Log Message:
-----------
Release 1.0.6. Workaround for 8.2 and 8.3.
Modified Files:
--------------
pg_reorg/lib:
reorg.c (r1.9 -> r1.10)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/reorg/pg_reorg/lib/reorg.c?r1=1.9&r2=1.10)
pg_reorg/lib/pgut:
pgut-be.c (r1.2 -> r1.3)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/reorg/pg_reorg/lib/pgut/pgut-be.c?r1=1.2&r2=1.3)
pgut-be.h (r1.3 -> r1.4)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/reorg/pg_reorg/lib/pgut/pgut-be.h?r1=1.3&r2=1.4)
pgut-spi.c (r1.1 -> r1.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/reorg/pg_reorg/lib/pgut/pgut-spi.c?r1=1.1&r2=1.2)
pgut-spi.h (r1.1 -> r1.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/reorg/pg_reorg/lib/pgut/pgut-spi.h?r1=1.1&r2=1.2)
^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Fix incorrect accessing of pfree'd memory in Memoize
@ 2024-03-11 05:20 David Rowley <drowley@postgresql.org>
0 siblings, 0 replies; 5+ messages in thread
From: David Rowley @ 2024-03-11 05:20 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix incorrect accessing of pfree'd memory in Memoize
For pass-by-reference types, the code added in 0b053e78b, which aimed to
resolve a memory leak, was overly aggressive in resetting the per-tuple
memory context which could result in pfree'd memory being accessed
resulting in failing to find previously cached results in the hash
table.
What was happening was prepare_probe_slot() was switching to the
per-tuple memory context and calling ExecEvalExpr(). ExecEvalExpr() may
have required a memory allocation. Both MemoizeHash_hash() and
MemoizeHash_equal() were aggressively resetting the per-tuple context
and after determining the hash value, the context would have gotten reset
before MemoizeHash_equal() was called. This could have resulted in
MemoizeHash_equal() looking at pfree'd memory.
This is less likely to have caused issues on a production build as some
other allocation would have had to have reused the pfree'd memory to
overwrite it. Otherwise, the original contents would have been intact.
However, this clearly caused issues on MEMORY_CONTEXT_CHECKING builds.
Author: Tender Wang, Andrei Lepikhov
Reported-by: Tender Wang (using SQLancer)
Reviewed-by: Andrei Lepikhov, Richard Guo, David Rowley
Discussion: https://postgr.es/m/CAHewXNnT6N6UJkya0z-jLFzVxcwGfeRQSfhiwA+NyLg-x8iGew@mail.gmail.com
Backpatch-through: 14, where Memoize was added
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/e629846472255c7a636c453a522755ef05489c90
Modified Files
--------------
src/backend/executor/nodeMemoize.c | 15 +++++++++++----
src/test/regress/expected/memoize.out | 31 ++++++++++++++++++++++++++++++-
src/test/regress/sql/memoize.sql | 23 ++++++++++++++++++++++-
3 files changed, 63 insertions(+), 6 deletions(-)
^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Fix incorrect accessing of pfree'd memory in Memoize
@ 2024-03-11 05:21 David Rowley <drowley@postgresql.org>
0 siblings, 0 replies; 5+ messages in thread
From: David Rowley @ 2024-03-11 05:21 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix incorrect accessing of pfree'd memory in Memoize
For pass-by-reference types, the code added in 0b053e78b, which aimed to
resolve a memory leak, was overly aggressive in resetting the per-tuple
memory context which could result in pfree'd memory being accessed
resulting in failing to find previously cached results in the hash
table.
What was happening was prepare_probe_slot() was switching to the
per-tuple memory context and calling ExecEvalExpr(). ExecEvalExpr() may
have required a memory allocation. Both MemoizeHash_hash() and
MemoizeHash_equal() were aggressively resetting the per-tuple context
and after determining the hash value, the context would have gotten reset
before MemoizeHash_equal() was called. This could have resulted in
MemoizeHash_equal() looking at pfree'd memory.
This is less likely to have caused issues on a production build as some
other allocation would have had to have reused the pfree'd memory to
overwrite it. Otherwise, the original contents would have been intact.
However, this clearly caused issues on MEMORY_CONTEXT_CHECKING builds.
Author: Tender Wang, Andrei Lepikhov
Reported-by: Tender Wang (using SQLancer)
Reviewed-by: Andrei Lepikhov, Richard Guo, David Rowley
Discussion: https://postgr.es/m/CAHewXNnT6N6UJkya0z-jLFzVxcwGfeRQSfhiwA+NyLg-x8iGew@mail.gmail.com
Backpatch-through: 14, where Memoize was added
Branch
------
REL_16_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/348233cb128d32fd3a61f4473eda9564efdcd29c
Modified Files
--------------
src/backend/executor/nodeMemoize.c | 15 +++++++++++----
src/test/regress/expected/memoize.out | 31 ++++++++++++++++++++++++++++++-
src/test/regress/sql/memoize.sql | 23 ++++++++++++++++++++++-
3 files changed, 63 insertions(+), 6 deletions(-)
^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Fix incorrect accessing of pfree'd memory in Memoize
@ 2024-03-11 05:21 David Rowley <drowley@postgresql.org>
0 siblings, 0 replies; 5+ messages in thread
From: David Rowley @ 2024-03-11 05:21 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix incorrect accessing of pfree'd memory in Memoize
For pass-by-reference types, the code added in 0b053e78b, which aimed to
resolve a memory leak, was overly aggressive in resetting the per-tuple
memory context which could result in pfree'd memory being accessed
resulting in failing to find previously cached results in the hash
table.
What was happening was prepare_probe_slot() was switching to the
per-tuple memory context and calling ExecEvalExpr(). ExecEvalExpr() may
have required a memory allocation. Both MemoizeHash_hash() and
MemoizeHash_equal() were aggressively resetting the per-tuple context
and after determining the hash value, the context would have gotten reset
before MemoizeHash_equal() was called. This could have resulted in
MemoizeHash_equal() looking at pfree'd memory.
This is less likely to have caused issues on a production build as some
other allocation would have had to have reused the pfree'd memory to
overwrite it. Otherwise, the original contents would have been intact.
However, this clearly caused issues on MEMORY_CONTEXT_CHECKING builds.
Author: Tender Wang, Andrei Lepikhov
Reported-by: Tender Wang (using SQLancer)
Reviewed-by: Andrei Lepikhov, Richard Guo, David Rowley
Discussion: https://postgr.es/m/CAHewXNnT6N6UJkya0z-jLFzVxcwGfeRQSfhiwA+NyLg-x8iGew@mail.gmail.com
Backpatch-through: 14, where Memoize was added
Branch
------
REL_15_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/74530804fcb7a36175fa1268928cba98aa9e6cff
Modified Files
--------------
src/backend/executor/nodeMemoize.c | 15 +++++++++++----
src/test/regress/expected/memoize.out | 31 ++++++++++++++++++++++++++++++-
src/test/regress/sql/memoize.sql | 23 ++++++++++++++++++++++-
3 files changed, 63 insertions(+), 6 deletions(-)
^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Fix incorrect accessing of pfree'd memory in Memoize
@ 2024-03-11 05:22 David Rowley <drowley@postgresql.org>
0 siblings, 0 replies; 5+ messages in thread
From: David Rowley @ 2024-03-11 05:22 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix incorrect accessing of pfree'd memory in Memoize
For pass-by-reference types, the code added in 0b053e78b, which aimed to
resolve a memory leak, was overly aggressive in resetting the per-tuple
memory context which could result in pfree'd memory being accessed
resulting in failing to find previously cached results in the hash
table.
What was happening was prepare_probe_slot() was switching to the
per-tuple memory context and calling ExecEvalExpr(). ExecEvalExpr() may
have required a memory allocation. Both MemoizeHash_hash() and
MemoizeHash_equal() were aggressively resetting the per-tuple context
and after determining the hash value, the context would have gotten reset
before MemoizeHash_equal() was called. This could have resulted in
MemoizeHash_equal() looking at pfree'd memory.
This is less likely to have caused issues on a production build as some
other allocation would have had to have reused the pfree'd memory to
overwrite it. Otherwise, the original contents would have been intact.
However, this clearly caused issues on MEMORY_CONTEXT_CHECKING builds.
Author: Tender Wang, Andrei Lepikhov
Reported-by: Tender Wang (using SQLancer)
Reviewed-by: Andrei Lepikhov, Richard Guo, David Rowley
Discussion: https://postgr.es/m/CAHewXNnT6N6UJkya0z-jLFzVxcwGfeRQSfhiwA+NyLg-x8iGew@mail.gmail.com
Backpatch-through: 14, where Memoize was added
Branch
------
REL_14_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/72b8507db2cc24810a29153838a62777d32f412f
Modified Files
--------------
src/backend/executor/nodeMemoize.c | 15 +++++++++++----
src/test/regress/expected/memoize.out | 31 ++++++++++++++++++++++++++++++-
src/test/regress/sql/memoize.sql | 23 ++++++++++++++++++++++-
3 files changed, 63 insertions(+), 6 deletions(-)
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2024-03-11 05:22 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2009-07-03 05:52 reorg - pg_reorg: Release 1.0.6. User Itagaki <itagaki@pgfoundry.org>
2024-03-11 05:20 pgsql: Fix incorrect accessing of pfree'd memory in Memoize David Rowley <drowley@postgresql.org>
2024-03-11 05:21 pgsql: Fix incorrect accessing of pfree'd memory in Memoize David Rowley <drowley@postgresql.org>
2024-03-11 05:21 pgsql: Fix incorrect accessing of pfree'd memory in Memoize David Rowley <drowley@postgresql.org>
2024-03-11 05:22 pgsql: Fix incorrect accessing of pfree'd memory in Memoize David Rowley <drowley@postgresql.org>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox