pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix access-to-already-freed-memory issue in plpython's error han 10+ messages / 2 participants [nested] [flat]
* pgsql: Fix access-to-already-freed-memory issue in plpython's error han @ 2016-04-11 03:16 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 10+ messages in thread From: Tom Lane @ 2016-04-11 03:16 UTC (permalink / raw) To: pgsql-committers Fix access-to-already-freed-memory issue in plpython's error handling. PLy_elog() could attempt to access strings that Python had already freed, because the strings that PLy_get_spi_error_data() returns are simply pointers into storage associated with the error "val" PyObject. That's fine at the instant PLy_get_spi_error_data() returns them, but just after that PLy_traceback() intentionally releases the only refcount on that object, allowing it to be freed --- so that the strings we pass to ereport() are dangling pointers. In principle this could result in garbage output or a coredump. In practice, I think the risk is pretty low, because there are no Python operations between where we decrement that refcount and where we use the strings (and copy them into PG storage), and thus no reason for Python to recycle the storage. Still, it's clearly hazardous, and it leads to Valgrind complaints when running under a Valgrind that hasn't been lobotomized to ignore Python memory allocations. The code was a mess anyway: we fetched the error data out of Python (clearing Python's error indicator) with PyErr_Fetch, examined it, pushed it back into Python with PyErr_Restore (re-setting the error indicator), then immediately pulled it back out with another PyErr_Fetch. Just to confuse matters even more, there were some gratuitous-and-yet-hazardous PyErr_Clear calls in the "examine" step, and we didn't get around to doing PyErr_NormalizeException until after the second PyErr_Fetch, making it even less clear which object was being manipulated where and whether we still had a refcount on it. (If PyErr_NormalizeException did substitute a different "val" object, it's possible that the problem could manifest for real, because then we'd be doing assorted Python stuff with no refcount on the object we have string pointers into.) So, rearrange all that into some semblance of sanity, and don't decrement the refcount on the Python error objects until the end of PLy_elog(). In HEAD, I failed to resist the temptation to reformat some messy bits from 5c3c3cd0a3046339 along the way. Back-patch as far as 9.2, because the code is substantially the same that far back. I believe that 9.1 has the bug as well; but the code around it is rather different and I don't want to take a chance on breaking something for what seems a low-probability problem. Branch ------ master Details ------- http://git.postgresql.org/pg/commitdiff/7e3bb080387f4143cdc908bf97daf9a8abdc445f Modified Files -------------- src/pl/plpython/plpy_elog.c | 91 ++++++++++++++++++++++++--------------------- 1 file changed, 48 insertions(+), 43 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers ^ permalink raw reply [nested|flat] 10+ messages in thread
* pgsql: Fix access-to-already-freed-memory issue in plpython's error han @ 2016-04-11 03:16 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 10+ messages in thread From: Tom Lane @ 2016-04-11 03:16 UTC (permalink / raw) To: pgsql-committers Fix access-to-already-freed-memory issue in plpython's error handling. PLy_elog() could attempt to access strings that Python had already freed, because the strings that PLy_get_spi_error_data() returns are simply pointers into storage associated with the error "val" PyObject. That's fine at the instant PLy_get_spi_error_data() returns them, but just after that PLy_traceback() intentionally releases the only refcount on that object, allowing it to be freed --- so that the strings we pass to ereport() are dangling pointers. In principle this could result in garbage output or a coredump. In practice, I think the risk is pretty low, because there are no Python operations between where we decrement that refcount and where we use the strings (and copy them into PG storage), and thus no reason for Python to recycle the storage. Still, it's clearly hazardous, and it leads to Valgrind complaints when running under a Valgrind that hasn't been lobotomized to ignore Python memory allocations. The code was a mess anyway: we fetched the error data out of Python (clearing Python's error indicator) with PyErr_Fetch, examined it, pushed it back into Python with PyErr_Restore (re-setting the error indicator), then immediately pulled it back out with another PyErr_Fetch. Just to confuse matters even more, there were some gratuitous-and-yet-hazardous PyErr_Clear calls in the "examine" step, and we didn't get around to doing PyErr_NormalizeException until after the second PyErr_Fetch, making it even less clear which object was being manipulated where and whether we still had a refcount on it. (If PyErr_NormalizeException did substitute a different "val" object, it's possible that the problem could manifest for real, because then we'd be doing assorted Python stuff with no refcount on the object we have string pointers into.) So, rearrange all that into some semblance of sanity, and don't decrement the refcount on the Python error objects until the end of PLy_elog(). In HEAD, I failed to resist the temptation to reformat some messy bits from 5c3c3cd0a3046339 along the way. Back-patch as far as 9.2, because the code is substantially the same that far back. I believe that 9.1 has the bug as well; but the code around it is rather different and I don't want to take a chance on breaking something for what seems a low-probability problem. Branch ------ REL9_5_STABLE Details ------- http://git.postgresql.org/pg/commitdiff/ec91ee8f00af9c3960cdc3dd1ecb9e3bb7cfee86 Modified Files -------------- src/pl/plpython/plpy_elog.c | 42 +++++++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 21 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers ^ permalink raw reply [nested|flat] 10+ messages in thread
* pgsql: Fix access-to-already-freed-memory issue in plpython's error han @ 2016-04-11 03:16 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 10+ messages in thread From: Tom Lane @ 2016-04-11 03:16 UTC (permalink / raw) To: pgsql-committers Fix access-to-already-freed-memory issue in plpython's error handling. PLy_elog() could attempt to access strings that Python had already freed, because the strings that PLy_get_spi_error_data() returns are simply pointers into storage associated with the error "val" PyObject. That's fine at the instant PLy_get_spi_error_data() returns them, but just after that PLy_traceback() intentionally releases the only refcount on that object, allowing it to be freed --- so that the strings we pass to ereport() are dangling pointers. In principle this could result in garbage output or a coredump. In practice, I think the risk is pretty low, because there are no Python operations between where we decrement that refcount and where we use the strings (and copy them into PG storage), and thus no reason for Python to recycle the storage. Still, it's clearly hazardous, and it leads to Valgrind complaints when running under a Valgrind that hasn't been lobotomized to ignore Python memory allocations. The code was a mess anyway: we fetched the error data out of Python (clearing Python's error indicator) with PyErr_Fetch, examined it, pushed it back into Python with PyErr_Restore (re-setting the error indicator), then immediately pulled it back out with another PyErr_Fetch. Just to confuse matters even more, there were some gratuitous-and-yet-hazardous PyErr_Clear calls in the "examine" step, and we didn't get around to doing PyErr_NormalizeException until after the second PyErr_Fetch, making it even less clear which object was being manipulated where and whether we still had a refcount on it. (If PyErr_NormalizeException did substitute a different "val" object, it's possible that the problem could manifest for real, because then we'd be doing assorted Python stuff with no refcount on the object we have string pointers into.) So, rearrange all that into some semblance of sanity, and don't decrement the refcount on the Python error objects until the end of PLy_elog(). In HEAD, I failed to resist the temptation to reformat some messy bits from 5c3c3cd0a3046339 along the way. Back-patch as far as 9.2, because the code is substantially the same that far back. I believe that 9.1 has the bug as well; but the code around it is rather different and I don't want to take a chance on breaking something for what seems a low-probability problem. Branch ------ REL9_4_STABLE Details ------- http://git.postgresql.org/pg/commitdiff/d54de3962a12e6075eae80fe75afc3ab59eea0d5 Modified Files -------------- src/pl/plpython/plpy_elog.c | 42 +++++++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 21 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers ^ permalink raw reply [nested|flat] 10+ messages in thread
* pgsql: Fix access-to-already-freed-memory issue in plpython's error han @ 2016-04-11 03:16 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 10+ messages in thread From: Tom Lane @ 2016-04-11 03:16 UTC (permalink / raw) To: pgsql-committers Fix access-to-already-freed-memory issue in plpython's error handling. PLy_elog() could attempt to access strings that Python had already freed, because the strings that PLy_get_spi_error_data() returns are simply pointers into storage associated with the error "val" PyObject. That's fine at the instant PLy_get_spi_error_data() returns them, but just after that PLy_traceback() intentionally releases the only refcount on that object, allowing it to be freed --- so that the strings we pass to ereport() are dangling pointers. In principle this could result in garbage output or a coredump. In practice, I think the risk is pretty low, because there are no Python operations between where we decrement that refcount and where we use the strings (and copy them into PG storage), and thus no reason for Python to recycle the storage. Still, it's clearly hazardous, and it leads to Valgrind complaints when running under a Valgrind that hasn't been lobotomized to ignore Python memory allocations. The code was a mess anyway: we fetched the error data out of Python (clearing Python's error indicator) with PyErr_Fetch, examined it, pushed it back into Python with PyErr_Restore (re-setting the error indicator), then immediately pulled it back out with another PyErr_Fetch. Just to confuse matters even more, there were some gratuitous-and-yet-hazardous PyErr_Clear calls in the "examine" step, and we didn't get around to doing PyErr_NormalizeException until after the second PyErr_Fetch, making it even less clear which object was being manipulated where and whether we still had a refcount on it. (If PyErr_NormalizeException did substitute a different "val" object, it's possible that the problem could manifest for real, because then we'd be doing assorted Python stuff with no refcount on the object we have string pointers into.) So, rearrange all that into some semblance of sanity, and don't decrement the refcount on the Python error objects until the end of PLy_elog(). In HEAD, I failed to resist the temptation to reformat some messy bits from 5c3c3cd0a3046339 along the way. Back-patch as far as 9.2, because the code is substantially the same that far back. I believe that 9.1 has the bug as well; but the code around it is rather different and I don't want to take a chance on breaking something for what seems a low-probability problem. Branch ------ REL9_3_STABLE Details ------- http://git.postgresql.org/pg/commitdiff/8d82e6e28e22edf8082810dbba137c7f400af7b8 Modified Files -------------- src/pl/plpython/plpy_elog.c | 42 +++++++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 21 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers ^ permalink raw reply [nested|flat] 10+ messages in thread
* pgsql: Fix access-to-already-freed-memory issue in plpython's error han @ 2016-04-11 03:16 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 10+ messages in thread From: Tom Lane @ 2016-04-11 03:16 UTC (permalink / raw) To: pgsql-committers Fix access-to-already-freed-memory issue in plpython's error handling. PLy_elog() could attempt to access strings that Python had already freed, because the strings that PLy_get_spi_error_data() returns are simply pointers into storage associated with the error "val" PyObject. That's fine at the instant PLy_get_spi_error_data() returns them, but just after that PLy_traceback() intentionally releases the only refcount on that object, allowing it to be freed --- so that the strings we pass to ereport() are dangling pointers. In principle this could result in garbage output or a coredump. In practice, I think the risk is pretty low, because there are no Python operations between where we decrement that refcount and where we use the strings (and copy them into PG storage), and thus no reason for Python to recycle the storage. Still, it's clearly hazardous, and it leads to Valgrind complaints when running under a Valgrind that hasn't been lobotomized to ignore Python memory allocations. The code was a mess anyway: we fetched the error data out of Python (clearing Python's error indicator) with PyErr_Fetch, examined it, pushed it back into Python with PyErr_Restore (re-setting the error indicator), then immediately pulled it back out with another PyErr_Fetch. Just to confuse matters even more, there were some gratuitous-and-yet-hazardous PyErr_Clear calls in the "examine" step, and we didn't get around to doing PyErr_NormalizeException until after the second PyErr_Fetch, making it even less clear which object was being manipulated where and whether we still had a refcount on it. (If PyErr_NormalizeException did substitute a different "val" object, it's possible that the problem could manifest for real, because then we'd be doing assorted Python stuff with no refcount on the object we have string pointers into.) So, rearrange all that into some semblance of sanity, and don't decrement the refcount on the Python error objects until the end of PLy_elog(). In HEAD, I failed to resist the temptation to reformat some messy bits from 5c3c3cd0a3046339 along the way. Back-patch as far as 9.2, because the code is substantially the same that far back. I believe that 9.1 has the bug as well; but the code around it is rather different and I don't want to take a chance on breaking something for what seems a low-probability problem. Branch ------ REL9_2_STABLE Details ------- http://git.postgresql.org/pg/commitdiff/e1f08ba1cc8ce31be75ec694e229daaa002adc6a Modified Files -------------- src/pl/plpython/plpy_elog.c | 42 +++++++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 21 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers ^ permalink raw reply [nested|flat] 10+ messages in thread
* pgsql: Fix access-to-already-freed-memory issue in pgoutput. @ 2025-10-09 18:00 Masahiko Sawada <msawada@postgresql.org> 0 siblings, 0 replies; 10+ messages in thread From: Masahiko Sawada @ 2025-10-09 18:00 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix access-to-already-freed-memory issue in pgoutput. While pgoutput caches relation synchronization information in RelationSyncCache that resides in CacheMemoryContext, each entry's information (such as row filter expressions and column lists) is stored in the entry's private memory context (entry_cxt in RelationSyncEntry), which is a descendant memory context of the decoding context. If a logical decoding invoked via SQL functions like pg_logical_slot_get_binary_changes fails with an error, subsequent logical decoding executions could access already-freed memory of the entry's cache, resulting in a crash. With this change, it's ensured that RelationSyncCache is cleaned up even in error cases by using a memory context reset callback function. Backpatch to 15, where entry_cxt was introduced for column filtering and row filtering. While the backbranches v13 and v14 have a similar issue where RelationSyncCache persists even after an error when pgoutput is used via SQL API, we decided not to backport this fix. This decision was made because v13 is approaching its final minor release, and we won't have an chance to fix any new issues that might arise. Additionally, since using pgoutput via SQL API is not a common use case, the risk outwights the benefit. If we receive bug reports, we can consider backporting the fixes then. Author: vignesh C <vignesh21@gmail.com> Co-authored-by: Masahiko Sawada <sawada.mshk@gmail.com> Reviewed-by: Zhijie Hou <houzj.fnst@fujitsu.com> Reviewed-by: Euler Taveira <euler@eulerto.com> Discussion: https://postgr.es/m/CALDaNm0x-aCehgt8Bevs2cm=uhmwS28MvbYq1=s2Ekf0aDPkOA@mail.gmail.com Backpatch-through: 15 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/b46efe90482bc1105a17955fce02cb3708230f0e Modified Files -------------- src/backend/replication/pgoutput/pgoutput.c | 29 ++++++++++++++++++++++++----- 1 file changed, 24 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 10+ messages in thread
* pgsql: Fix access-to-already-freed-memory issue in pgoutput. @ 2025-10-09 18:00 Masahiko Sawada <msawada@postgresql.org> 0 siblings, 0 replies; 10+ messages in thread From: Masahiko Sawada @ 2025-10-09 18:00 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix access-to-already-freed-memory issue in pgoutput. While pgoutput caches relation synchronization information in RelationSyncCache that resides in CacheMemoryContext, each entry's information (such as row filter expressions and column lists) is stored in the entry's private memory context (entry_cxt in RelationSyncEntry), which is a descendant memory context of the decoding context. If a logical decoding invoked via SQL functions like pg_logical_slot_get_binary_changes fails with an error, subsequent logical decoding executions could access already-freed memory of the entry's cache, resulting in a crash. With this change, it's ensured that RelationSyncCache is cleaned up even in error cases by using a memory context reset callback function. Backpatch to 15, where entry_cxt was introduced for column filtering and row filtering. While the backbranches v13 and v14 have a similar issue where RelationSyncCache persists even after an error when pgoutput is used via SQL API, we decided not to backport this fix. This decision was made because v13 is approaching its final minor release, and we won't have an chance to fix any new issues that might arise. Additionally, since using pgoutput via SQL API is not a common use case, the risk outwights the benefit. If we receive bug reports, we can consider backporting the fixes then. Author: vignesh C <vignesh21@gmail.com> Co-authored-by: Masahiko Sawada <sawada.mshk@gmail.com> Reviewed-by: Zhijie Hou <houzj.fnst@fujitsu.com> Reviewed-by: Euler Taveira <euler@eulerto.com> Discussion: https://postgr.es/m/CALDaNm0x-aCehgt8Bevs2cm=uhmwS28MvbYq1=s2Ekf0aDPkOA@mail.gmail.com Backpatch-through: 15 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/32b95fc71b5825ad1722b821ae2508657970ce79 Modified Files -------------- src/backend/replication/pgoutput/pgoutput.c | 29 ++++++++++++++++++++++++----- 1 file changed, 24 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 10+ messages in thread
* pgsql: Fix access-to-already-freed-memory issue in pgoutput. @ 2025-10-09 18:00 Masahiko Sawada <msawada@postgresql.org> 0 siblings, 0 replies; 10+ messages in thread From: Masahiko Sawada @ 2025-10-09 18:00 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix access-to-already-freed-memory issue in pgoutput. While pgoutput caches relation synchronization information in RelationSyncCache that resides in CacheMemoryContext, each entry's information (such as row filter expressions and column lists) is stored in the entry's private memory context (entry_cxt in RelationSyncEntry), which is a descendant memory context of the decoding context. If a logical decoding invoked via SQL functions like pg_logical_slot_get_binary_changes fails with an error, subsequent logical decoding executions could access already-freed memory of the entry's cache, resulting in a crash. With this change, it's ensured that RelationSyncCache is cleaned up even in error cases by using a memory context reset callback function. Backpatch to 15, where entry_cxt was introduced for column filtering and row filtering. While the backbranches v13 and v14 have a similar issue where RelationSyncCache persists even after an error when pgoutput is used via SQL API, we decided not to backport this fix. This decision was made because v13 is approaching its final minor release, and we won't have an chance to fix any new issues that might arise. Additionally, since using pgoutput via SQL API is not a common use case, the risk outwights the benefit. If we receive bug reports, we can consider backporting the fixes then. Author: vignesh C <vignesh21@gmail.com> Co-authored-by: Masahiko Sawada <sawada.mshk@gmail.com> Reviewed-by: Zhijie Hou <houzj.fnst@fujitsu.com> Reviewed-by: Euler Taveira <euler@eulerto.com> Discussion: https://postgr.es/m/CALDaNm0x-aCehgt8Bevs2cm=uhmwS28MvbYq1=s2Ekf0aDPkOA@mail.gmail.com Backpatch-through: 15 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/a61592253e57b7e7034e9a6158f709343280bb43 Modified Files -------------- src/backend/replication/pgoutput/pgoutput.c | 27 ++++++++++++++++----------- 1 file changed, 16 insertions(+), 11 deletions(-) ^ permalink raw reply [nested|flat] 10+ messages in thread
* pgsql: Fix access-to-already-freed-memory issue in pgoutput. @ 2025-10-09 18:00 Masahiko Sawada <msawada@postgresql.org> 0 siblings, 0 replies; 10+ messages in thread From: Masahiko Sawada @ 2025-10-09 18:00 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix access-to-already-freed-memory issue in pgoutput. While pgoutput caches relation synchronization information in RelationSyncCache that resides in CacheMemoryContext, each entry's information (such as row filter expressions and column lists) is stored in the entry's private memory context (entry_cxt in RelationSyncEntry), which is a descendant memory context of the decoding context. If a logical decoding invoked via SQL functions like pg_logical_slot_get_binary_changes fails with an error, subsequent logical decoding executions could access already-freed memory of the entry's cache, resulting in a crash. With this change, it's ensured that RelationSyncCache is cleaned up even in error cases by using a memory context reset callback function. Backpatch to 15, where entry_cxt was introduced for column filtering and row filtering. While the backbranches v13 and v14 have a similar issue where RelationSyncCache persists even after an error when pgoutput is used via SQL API, we decided not to backport this fix. This decision was made because v13 is approaching its final minor release, and we won't have an chance to fix any new issues that might arise. Additionally, since using pgoutput via SQL API is not a common use case, the risk outwights the benefit. If we receive bug reports, we can consider backporting the fixes then. Author: vignesh C <vignesh21@gmail.com> Co-authored-by: Masahiko Sawada <sawada.mshk@gmail.com> Reviewed-by: Zhijie Hou <houzj.fnst@fujitsu.com> Reviewed-by: Euler Taveira <euler@eulerto.com> Discussion: https://postgr.es/m/CALDaNm0x-aCehgt8Bevs2cm=uhmwS28MvbYq1=s2Ekf0aDPkOA@mail.gmail.com Backpatch-through: 15 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/b07682bce301d2236667ad45aeba61c671f81aae Modified Files -------------- src/backend/replication/pgoutput/pgoutput.c | 27 ++++++++++++++++----------- 1 file changed, 16 insertions(+), 11 deletions(-) ^ permalink raw reply [nested|flat] 10+ messages in thread
* pgsql: Fix access-to-already-freed-memory issue in pgoutput. @ 2025-10-09 18:00 Masahiko Sawada <msawada@postgresql.org> 0 siblings, 0 replies; 10+ messages in thread From: Masahiko Sawada @ 2025-10-09 18:00 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix access-to-already-freed-memory issue in pgoutput. While pgoutput caches relation synchronization information in RelationSyncCache that resides in CacheMemoryContext, each entry's information (such as row filter expressions and column lists) is stored in the entry's private memory context (entry_cxt in RelationSyncEntry), which is a descendant memory context of the decoding context. If a logical decoding invoked via SQL functions like pg_logical_slot_get_binary_changes fails with an error, subsequent logical decoding executions could access already-freed memory of the entry's cache, resulting in a crash. With this change, it's ensured that RelationSyncCache is cleaned up even in error cases by using a memory context reset callback function. Backpatch to 15, where entry_cxt was introduced for column filtering and row filtering. While the backbranches v13 and v14 have a similar issue where RelationSyncCache persists even after an error when pgoutput is used via SQL API, we decided not to backport this fix. This decision was made because v13 is approaching its final minor release, and we won't have an chance to fix any new issues that might arise. Additionally, since using pgoutput via SQL API is not a common use case, the risk outwights the benefit. If we receive bug reports, we can consider backporting the fixes then. Author: vignesh C <vignesh21@gmail.com> Co-authored-by: Masahiko Sawada <sawada.mshk@gmail.com> Reviewed-by: Zhijie Hou <houzj.fnst@fujitsu.com> Reviewed-by: Euler Taveira <euler@eulerto.com> Discussion: https://postgr.es/m/CALDaNm0x-aCehgt8Bevs2cm=uhmwS28MvbYq1=s2Ekf0aDPkOA@mail.gmail.com Backpatch-through: 15 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/c40761759fe48d146717694b0e21d2c231addc31 Modified Files -------------- src/backend/replication/pgoutput/pgoutput.c | 27 ++++++++++++++++----------- 1 file changed, 16 insertions(+), 11 deletions(-) ^ permalink raw reply [nested|flat] 10+ messages in thread
end of thread, other threads:[~2025-10-09 18:00 UTC | newest] Thread overview: 10+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2016-04-11 03:16 pgsql: Fix access-to-already-freed-memory issue in plpython's error han Tom Lane <tgl@sss.pgh.pa.us> 2016-04-11 03:16 pgsql: Fix access-to-already-freed-memory issue in plpython's error han Tom Lane <tgl@sss.pgh.pa.us> 2016-04-11 03:16 pgsql: Fix access-to-already-freed-memory issue in plpython's error han Tom Lane <tgl@sss.pgh.pa.us> 2016-04-11 03:16 pgsql: Fix access-to-already-freed-memory issue in plpython's error han Tom Lane <tgl@sss.pgh.pa.us> 2016-04-11 03:16 pgsql: Fix access-to-already-freed-memory issue in plpython's error han Tom Lane <tgl@sss.pgh.pa.us> 2025-10-09 18:00 pgsql: Fix access-to-already-freed-memory issue in pgoutput. Masahiko Sawada <msawada@postgresql.org> 2025-10-09 18:00 pgsql: Fix access-to-already-freed-memory issue in pgoutput. Masahiko Sawada <msawada@postgresql.org> 2025-10-09 18:00 pgsql: Fix access-to-already-freed-memory issue in pgoutput. Masahiko Sawada <msawada@postgresql.org> 2025-10-09 18:00 pgsql: Fix access-to-already-freed-memory issue in pgoutput. Masahiko Sawada <msawada@postgresql.org> 2025-10-09 18:00 pgsql: Fix access-to-already-freed-memory issue in pgoutput. Masahiko Sawada <msawada@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