> prion is complaining here:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion&dt=2025-09-05%2023%3A03%3A05
>
> I did not look into the details, but this usually points to a
> use-after-free problem.
Regression diff shows:
diff -U3
/home/ec2-user/bf/root/HEAD/pgsql/src/test/regres
On Fri, Sep 05, 2025 at 10:52:55PM +, Tatsuo Ishii wrote:
> Allow to log raw parse tree.
>
> This commit allows to log the raw parse tree in the same way we
> currently log the parse tree, rewritten tree, and plan tree.
>
> To avoid unnecessary log noise for users not interested in this
> det
Fix replica identity check for MERGE.
When executing a MERGE, check that the target relation supports all
actions mentioned in the MERGE command. Specifically, check that it
has a REPLICA IDENTITY if it publishes updates or deletes and the
MERGE command contains update or delete actions. Failing t
bufmgr: Use consistent naming of the clock-sweep algorithm
Minor edits to comments only.
Author: Greg Burd
Reviewed-by: Tomas Vondra
Reviewed-by: Andres Freund
Discussion:
https://postgr.es/m/70c6a5b5-2a20-4d0b-bc73-eb09dd62d...@getmailspring.com
Branch
--
master
Details
---
https:/
Allow to log raw parse tree.
This commit allows to log the raw parse tree in the same way we
currently log the parse tree, rewritten tree, and plan tree.
To avoid unnecessary log noise for users not interested in this
detail, a new GUC option, "debug_print_raw_parse", has been added.
When starti
bufmgr: Remove freelist, always use clock-sweep
This set of changes removes the list of available buffers and instead simply
uses the clock-sweep algorithm to find and return an available buffer. This
also removes the have_free_buffer() function and simply caps the
pg_autoprewarm process to at mo
Add assert and log message to visibilitymap_set
Add an assert to visibilitymap_set() that the provided heap buffer is
exclusively locked, which is expected.
Also, enhance the debug logging message to specify which VM flags were
set.
Based on a related suggestion by Kirill Reshke on an in-progres
Fix concurrent update issue with MERGE.
When executing a MERGE UPDATE action, if there is more than one
concurrent update of the target row, the lock-and-retry code would
sometimes incorrectly identify the latest version of the target tuple,
leading to incorrect results.
This was caused by using
Fix concurrent update issue with MERGE.
When executing a MERGE UPDATE action, if there is more than one
concurrent update of the target row, the lock-and-retry code would
sometimes incorrectly identify the latest version of the target tuple,
leading to incorrect results.
This was caused by using
Fix concurrent update issue with MERGE.
When executing a MERGE UPDATE action, if there is more than one
concurrent update of the target row, the lock-and-retry code would
sometimes incorrectly identify the latest version of the target tuple,
leading to incorrect results.
This was caused by using
Fix concurrent update issue with MERGE.
When executing a MERGE UPDATE action, if there is more than one
concurrent update of the target row, the lock-and-retry code would
sometimes incorrectly identify the latest version of the target tuple,
leading to incorrect results.
This was caused by using
Fix concurrent update issue with MERGE.
When executing a MERGE UPDATE action, if there is more than one
concurrent update of the target row, the lock-and-retry code would
sometimes incorrectly identify the latest version of the target tuple,
leading to incorrect results.
This was caused by using
12 matches
Mail list logo
