pg.ddx.io pgsql-committers@postgresql.org mailing list archive
help / color / mirror / Atom feedpgsql: Marginal improvement of description of recovery_end_command.
4+ messages / 2 participants
[nested] [flat]
* pgsql: Marginal improvement of description of recovery_end_command.
@ 2009-06-26 22:06 Tom Lane <tgl@postgresql.org>
0 siblings, 0 replies; 4+ messages in thread
From: tgl@postgresql.org @ 2009-06-26 22:06 UTC (permalink / raw)
To: pgsql-committers
Log Message:
-----------
Marginal improvement of description of recovery_end_command.
Modified Files:
--------------
pgsql/doc/src/sgml:
backup.sgml (r2.128 -> r2.129)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/backup.sgml?r1=2.128&r2=2.129)
^ permalink raw reply [nested|flat] 4+ messages in thread
* pgsql: Fix handling of self-modified tuples in MERGE.
@ 2024-03-07 09:59 Dean Rasheed <dean.a.rasheed@gmail.com>
0 siblings, 0 replies; 4+ messages in thread
From: Dean Rasheed @ 2024-03-07 09:59 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix handling of self-modified tuples in MERGE.
When an UPDATE or DELETE action in MERGE returns TM_SelfModified,
there are 2 possible causes:
1). The target tuple was already updated or deleted by the current
command. This can happen if the target row joins to more than one
source row, and the SQL standard explicitly says that this must be
an error.
2). The target tuple was already updated or deleted by a later command
in the current transaction. This can happen if the tuple is
modified by a BEFORE trigger or a volatile function used in the
query, and should be an error for the same reason that it is in a
plain UPDATE or DELETE command.
In MERGE's primary error handling block, it failed to check for (2),
causing it to return a misleading error message in such cases.
In the secondary error handling block, following a concurrent update
from another session, it failed to check for (1), causing it to
silently ignore target rows joined to more than one source row,
instead of reporting an error.
Fix this, and add tests for both of these cases.
Per report from Wenjiang Zhang. Back-patch to v15, where MERGE was
introduced.
Discussion: https://postgr.es/m/tencent_41DE0FF443FE14B94A5898D373792109E408%40qq.com
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/29ef1dd19b4f3eb54569b2eece4a8a65034a2216
Modified Files
--------------
src/backend/executor/nodeModifyTable.c | 46 +++++++++++++++++++++++-----
src/test/isolation/expected/merge-update.out | 43 ++++++++++++++++++++++++++
src/test/isolation/specs/merge-update.spec | 13 ++++++++
src/test/regress/expected/triggers.out | 8 +++++
src/test/regress/sql/triggers.sql | 4 +++
5 files changed, 106 insertions(+), 8 deletions(-)
^ permalink raw reply [nested|flat] 4+ messages in thread
* pgsql: Fix handling of self-modified tuples in MERGE.
@ 2024-03-07 09:59 Dean Rasheed <dean.a.rasheed@gmail.com>
0 siblings, 0 replies; 4+ messages in thread
From: Dean Rasheed @ 2024-03-07 09:59 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix handling of self-modified tuples in MERGE.
When an UPDATE or DELETE action in MERGE returns TM_SelfModified,
there are 2 possible causes:
1). The target tuple was already updated or deleted by the current
command. This can happen if the target row joins to more than one
source row, and the SQL standard explicitly says that this must be
an error.
2). The target tuple was already updated or deleted by a later command
in the current transaction. This can happen if the tuple is
modified by a BEFORE trigger or a volatile function used in the
query, and should be an error for the same reason that it is in a
plain UPDATE or DELETE command.
In MERGE's primary error handling block, it failed to check for (2),
causing it to return a misleading error message in such cases.
In the secondary error handling block, following a concurrent update
from another session, it failed to check for (1), causing it to
silently ignore target rows joined to more than one source row,
instead of reporting an error.
Fix this, and add tests for both of these cases.
Per report from Wenjiang Zhang. Back-patch to v15, where MERGE was
introduced.
Discussion: https://postgr.es/m/tencent_41DE0FF443FE14B94A5898D373792109E408%40qq.com
Branch
------
REL_16_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/dd73d10adf0048d2d8dc4e94cd64ce5e5ff45a4b
Modified Files
--------------
src/backend/executor/nodeModifyTable.c | 46 +++++++++++++++++++++++-----
src/test/isolation/expected/merge-update.out | 43 ++++++++++++++++++++++++++
src/test/isolation/specs/merge-update.spec | 13 ++++++++
src/test/regress/expected/triggers.out | 8 +++++
src/test/regress/sql/triggers.sql | 4 +++
5 files changed, 106 insertions(+), 8 deletions(-)
^ permalink raw reply [nested|flat] 4+ messages in thread
* pgsql: Fix handling of self-modified tuples in MERGE.
@ 2024-03-07 09:59 Dean Rasheed <dean.a.rasheed@gmail.com>
0 siblings, 0 replies; 4+ messages in thread
From: Dean Rasheed @ 2024-03-07 09:59 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix handling of self-modified tuples in MERGE.
When an UPDATE or DELETE action in MERGE returns TM_SelfModified,
there are 2 possible causes:
1). The target tuple was already updated or deleted by the current
command. This can happen if the target row joins to more than one
source row, and the SQL standard explicitly says that this must be
an error.
2). The target tuple was already updated or deleted by a later command
in the current transaction. This can happen if the tuple is
modified by a BEFORE trigger or a volatile function used in the
query, and should be an error for the same reason that it is in a
plain UPDATE or DELETE command.
In MERGE's primary error handling block, it failed to check for (2),
causing it to return a misleading error message in such cases.
In the secondary error handling block, following a concurrent update
from another session, it failed to check for (1), causing it to
silently ignore target rows joined to more than one source row,
instead of reporting an error.
Fix this, and add tests for both of these cases.
Per report from Wenjiang Zhang. Back-patch to v15, where MERGE was
introduced.
Discussion: https://postgr.es/m/tencent_41DE0FF443FE14B94A5898D373792109E408%40qq.com
Branch
------
REL_15_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/b5c645d2a2652070ac128a42cf0d7b34403a6cfe
Modified Files
--------------
src/backend/executor/nodeModifyTable.c | 46 +++++++++++++++++++++++-----
src/test/isolation/expected/merge-update.out | 43 ++++++++++++++++++++++++++
src/test/isolation/specs/merge-update.spec | 13 ++++++++
src/test/regress/expected/triggers.out | 8 +++++
src/test/regress/sql/triggers.sql | 4 +++
5 files changed, 106 insertions(+), 8 deletions(-)
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2024-03-07 09:59 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2009-06-26 22:06 pgsql: Marginal improvement of description of recovery_end_command. Tom Lane <tgl@postgresql.org>
2024-03-07 09:59 pgsql: Fix handling of self-modified tuples in MERGE. Dean Rasheed <dean.a.rasheed@gmail.com>
2024-03-07 09:59 pgsql: Fix handling of self-modified tuples in MERGE. Dean Rasheed <dean.a.rasheed@gmail.com>
2024-03-07 09:59 pgsql: Fix handling of self-modified tuples in MERGE. Dean Rasheed <dean.a.rasheed@gmail.com>
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