pg.ddx.io pgsql-committers@postgresql.org mailing list archive
help / color / mirror / Atom feedpgbouncer - pgbouncer: Fix broken alignment in src/slab.c Alignment
3+ messages / 2 participants
[nested] [flat]
* pgbouncer - pgbouncer: Fix broken alignment in src/slab.c Alignment
@ 2009-04-07 09:31 User Mkz <mkz@pgfoundry.org>
0 siblings, 0 replies; 3+ messages in thread
From: mkz@pgfoundry.org @ 2009-04-07 09:31 UTC (permalink / raw)
To: pgsql-committers
Log Message:
-----------
Fix broken alignment in src/slab.c
Alignment macro was buggy, thus resulting in bad alignment.
This means speed hit on x86, but may result in crashes
on arches which are strict on alignment, unless the macro
is pre-defined in OS headers.
No problems from the field have been reported, thus maybe
even the bad alignment happened to be aligned?
Modified Files:
--------------
pgbouncer/src:
slab.c (r1.9 -> r1.10)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/src/slab.c.diff?r1=1.9&r2=1.10)
^ permalink raw reply [nested|flat] 3+ messages in thread
* pgsql: Allow locking updated tuples in tuple_update() and tuple_delete(
@ 2023-03-22 21:27 Alexander Korotkov <akorotkov@postgresql.org>
0 siblings, 0 replies; 3+ messages in thread
From: Alexander Korotkov @ 2023-03-22 21:27 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Allow locking updated tuples in tuple_update() and tuple_delete()
Currently, in read committed transaction isolation mode (default), we have the
following sequence of actions when tuple_update()/tuple_delete() finds
the tuple updated by concurrent transaction.
1. Attempt to update/delete tuple with tuple_update()/tuple_delete(), which
returns TM_Updated.
2. Lock tuple with tuple_lock().
3. Re-evaluate plan qual (recheck if we still need to update/delete and
calculate the new tuple for update).
4. Second attempt to update/delete tuple with tuple_update()/tuple_delete().
This attempt should be successful, since the tuple was previously locked.
This patch eliminates step 2 by taking the lock during first
tuple_update()/tuple_delete() call. Heap table access method saves some
efforts by checking the updated tuple once instead of twice. Future
undo-based table access methods, which will start from the latest row version,
can immediately place a lock there.
The code in nodeModifyTable.c is simplified by removing the nested switch/case.
Discussion: https://postgr.es/m/CAPpHfdua-YFw3XTprfutzGp28xXLigFtzNbuFY8yPhqeq6X5kg%40mail.gmail.com
Reviewed-by: Aleksander Alekseev, Pavel Borisov, Vignesh C, Mason Sharp
Reviewed-by: Andres Freund, Chris Travers
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/11470f544e3729c60fab890145b2e839cbc8905e
Modified Files
--------------
src/backend/access/heap/heapam_handler.c | 109 +++++++++++-
src/backend/access/table/tableam.c | 6 +-
src/backend/executor/nodeModifyTable.c | 288 +++++++++++++------------------
src/include/access/tableam.h | 28 ++-
src/include/executor/tuptable.h | 38 ++++
src/tools/pgindent/typedefs.list | 2 +
6 files changed, 285 insertions(+), 186 deletions(-)
^ permalink raw reply [nested|flat] 3+ messages in thread
* pgsql: Allow locking updated tuples in tuple_update() and tuple_delete(
@ 2024-03-25 23:30 Alexander Korotkov <akorotkov@postgresql.org>
0 siblings, 0 replies; 3+ messages in thread
From: Alexander Korotkov @ 2024-03-25 23:30 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Allow locking updated tuples in tuple_update() and tuple_delete()
Currently, in read committed transaction isolation mode (default), we have the
following sequence of actions when tuple_update()/tuple_delete() finds
the tuple updated by the concurrent transaction.
1. Attempt to update/delete tuple with tuple_update()/tuple_delete(), which
returns TM_Updated.
2. Lock tuple with tuple_lock().
3. Re-evaluate plan qual (recheck if we still need to update/delete and
calculate the new tuple for update).
4. Second attempt to update/delete tuple with tuple_update()/tuple_delete().
This attempt should be successful, since the tuple was previously locked.
This commit eliminates step 2 by taking the lock during the first
tuple_update()/tuple_delete() call. The heap table access method saves some
effort by checking the updated tuple once instead of twice. Future
undo-based table access methods, which will start from the latest row version,
can immediately place a lock there.
Also, this commit makes tuple_update()/tuple_delete() optionally save the old
tuple into the dedicated slot. That saves efforts on re-fetching tuples in
certain cases.
The code in nodeModifyTable.c is simplified by removing the nested switch/case.
Discussion: https://postgr.es/m/CAPpHfdua-YFw3XTprfutzGp28xXLigFtzNbuFY8yPhqeq6X5kg%40mail.gmail.com
Reviewed-by: Aleksander Alekseev, Pavel Borisov, Vignesh C, Mason Sharp
Reviewed-by: Andres Freund, Chris Travers
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/87985cc9252296f11db3cacc155e8d710d2e9b9c
Modified Files
--------------
src/backend/access/heap/heapam.c | 205 +++++++++++++-----
src/backend/access/heap/heapam_handler.c | 94 ++++++--
src/backend/access/table/tableam.c | 26 ++-
src/backend/commands/trigger.c | 55 ++---
src/backend/executor/execReplication.c | 19 +-
src/backend/executor/nodeModifyTable.c | 353 ++++++++++++++-----------------
src/include/access/heapam.h | 19 +-
src/include/access/tableam.h | 73 +++++--
src/include/commands/trigger.h | 4 +-
9 files changed, 502 insertions(+), 346 deletions(-)
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2024-03-25 23:30 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2009-04-07 09:31 pgbouncer - pgbouncer: Fix broken alignment in src/slab.c Alignment User Mkz <mkz@pgfoundry.org>
2023-03-22 21:27 pgsql: Allow locking updated tuples in tuple_update() and tuple_delete( Alexander Korotkov <akorotkov@postgresql.org>
2024-03-25 23:30 pgsql: Allow locking updated tuples in tuple_update() and tuple_delete( Alexander Korotkov <akorotkov@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