pgsql: Take a little more care in set_backtrace().

2025-08-03 Thread Tom Lane
Take a little more care in set_backtrace().

Coverity complained that the "errtrace" string is leaked if we return
early because backtrace_symbols fails.  Another criticism that could
be leveled at this is that not providing any hint of what happened is
user-unfriendly.  Fix that.

The odds of a leak here are small, and typically it wouldn't matter
anyway since the leak will be in ErrorContext which will soon get
reset.  So I'm not feeling a need to back-patch.

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/5c8eda1f72a2b0a8c48ada9b872eb5ef581f7c81

Modified Files
--
src/backend/utils/error/elog.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)



pgsql: Detect and report update_deleted conflicts.

2025-08-03 Thread Amit Kapila
Detect and report update_deleted conflicts.

This enhancement builds upon the infrastructure introduced in commit
228c370868, which enables the preservation of deleted tuples and their
origin information on the subscriber. This capability is crucial for
handling concurrent transactions replicated from remote nodes.

The update introduces support for detecting update_deleted conflicts
during the application of update operations on the subscriber. When an
update operation fails to locate the target row-typically because it has
been concurrently deleted-we perform an additional table scan. This scan
uses the SnapshotAny mechanism and we do this additional scan only when
the retain_dead_tuples option is enabled for the relevant subscription.

The goal of this scan is to locate the most recently deleted tuple-matching
the old column values from the remote update-that has not yet been removed
by VACUUM and is still visible according to our slot (i.e., its deletion
is not older than conflict-detection-slot's xmin). If such a tuple is
found, the system reports an update_deleted conflict, including the origin
and transaction details responsible for the deletion.

This provides a groundwork for more robust and accurate conflict
resolution process, preventing unexpected behavior by correctly
identifying cases where a remote update clashes with a deletion from
another origin.

Author: Zhijie Hou 
Reviewed-by: shveta malik 
Reviewed-by: Nisha Moond 
Reviewed-by: Dilip Kumar 
Reviewed-by: Hayato Kuroda 
Reviewed-by: Amit Kapila 
Discussion: 
https://postgr.es/m/os0pr01mb5716be80daeb0ee2a6a5d1f594...@os0pr01mb5716.jpnprd01.prod.outlook.com

Branch
--
master

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

Modified Files
--
doc/src/sgml/catalogs.sgml |   3 +-
doc/src/sgml/logical-replication.sgml  |  16 ++
doc/src/sgml/monitoring.sgml   |  11 ++
doc/src/sgml/ref/create_subscription.sgml  |   9 +-
src/backend/catalog/system_views.sql   |   1 +
src/backend/executor/execReplication.c | 251 -
src/backend/replication/logical/conflict.c |  22 +++
src/backend/replication/logical/worker.c   | 186 ++---
src/backend/utils/adt/pgstatfuncs.c|  14 +-
src/include/catalog/catversion.h   |   2 +-
src/include/catalog/pg_proc.dat|   6 +-
src/include/executor/executor.h|  14 +-
src/include/replication/conflict.h |   3 +
src/include/replication/worker_internal.h  |   5 +-
src/test/regress/expected/rules.out|   3 +-
src/test/subscription/t/035_conflicts.pl   |  66 +++-
16 files changed, 566 insertions(+), 46 deletions(-)



pgsql: Fix incorrect comment regarding mod_since_analyze

2025-08-03 Thread David Rowley
Fix incorrect comment regarding mod_since_analyze

Author: Yugo Nagata 
Discussion: 
https://postgr.es/m/20250804140120.280c2d6a9d2ea687cd167...@sraoss.co.jp

Branch
--
master

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

Modified Files
--
src/backend/commands/analyze.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)