pg.ddx.io pgsql-committers@postgresql.org mailing list archive
help / color / mirror / Atom feedpgsql: GIN's ItemPointerIsMin, ItemPointerIsMax, and
4+ messages / 2 participants
[nested] [flat]
* pgsql: GIN's ItemPointerIsMin, ItemPointerIsMax, and
@ 2009-06-05 18:50 Tom Lane <tgl@postgresql.org>
0 siblings, 0 replies; 4+ messages in thread
From: tgl@postgresql.org @ 2009-06-05 18:50 UTC (permalink / raw)
To: pgsql-committers
Log Message:
-----------
GIN's ItemPointerIsMin, ItemPointerIsMax, and ItemPointerIsLossyPage macros
should use GinItemPointerGetBlockNumber/GinItemPointerGetOffsetNumber,
not ItemPointerGetBlockNumber/ItemPointerGetOffsetNumber, because the latter
will Assert() on ip_posid == 0, ie a "Min" pointer. (Thus, ItemPointerIsMin
has never worked at all, but it seems unused at present.) I'm not certain
that the case can occur in normal functioning, but it's blowing up on me
while investigating Tatsuo-san's data corruption problem. In any case it
seems like a problem waiting to bite someone.
Back-patch just in case this really is a problem for somebody in the field.
Modified Files:
--------------
pgsql/src/include/access:
gin.h (r1.31 -> r1.32)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/access/gin.h?r1=1.31&r2=1.32)
^ permalink raw reply [nested|flat] 4+ messages in thread
* pgsql: GIN's ItemPointerIsMin, ItemPointerIsMax, and
@ 2009-06-05 18:50 Tom Lane <tgl@postgresql.org>
0 siblings, 0 replies; 4+ messages in thread
From: tgl@postgresql.org @ 2009-06-05 18:50 UTC (permalink / raw)
To: pgsql-committers
Log Message:
-----------
GIN's ItemPointerIsMin, ItemPointerIsMax, and ItemPointerIsLossyPage macros
should use GinItemPointerGetBlockNumber/GinItemPointerGetOffsetNumber,
not ItemPointerGetBlockNumber/ItemPointerGetOffsetNumber, because the latter
will Assert() on ip_posid == 0, ie a "Min" pointer. (Thus, ItemPointerIsMin
has never worked at all, but it seems unused at present.) I'm not certain
that the case can occur in normal functioning, but it's blowing up on me
while investigating Tatsuo-san's data corruption problem. In any case it
seems like a problem waiting to bite someone.
Back-patch just in case this really is a problem for somebody in the field.
Tags:
----
REL8_3_STABLE
Modified Files:
--------------
pgsql/src/include/access:
gin.h (r1.16.2.2 -> r1.16.2.3)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/access/gin.h?r1=1.16.2.2&r2=1.16.2.3)
^ permalink raw reply [nested|flat] 4+ messages in thread
* pgsql: GIN's ItemPointerIsMin, ItemPointerIsMax, and
@ 2009-06-05 18:50 Tom Lane <tgl@postgresql.org>
0 siblings, 0 replies; 4+ messages in thread
From: tgl@postgresql.org @ 2009-06-05 18:50 UTC (permalink / raw)
To: pgsql-committers
Log Message:
-----------
GIN's ItemPointerIsMin, ItemPointerIsMax, and ItemPointerIsLossyPage macros
should use GinItemPointerGetBlockNumber/GinItemPointerGetOffsetNumber,
not ItemPointerGetBlockNumber/ItemPointerGetOffsetNumber, because the latter
will Assert() on ip_posid == 0, ie a "Min" pointer. (Thus, ItemPointerIsMin
has never worked at all, but it seems unused at present.) I'm not certain
that the case can occur in normal functioning, but it's blowing up on me
while investigating Tatsuo-san's data corruption problem. In any case it
seems like a problem waiting to bite someone.
Back-patch just in case this really is a problem for somebody in the field.
Tags:
----
REL8_2_STABLE
Modified Files:
--------------
pgsql/src/include/access:
gin.h (r1.9.2.3 -> r1.9.2.4)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/access/gin.h?r1=1.9.2.3&r2=1.9.2.4)
^ permalink raw reply [nested|flat] 4+ messages in thread
* pgsql: Refactoring for CommitTransactionCommand()/AbortCurrentTransacti
@ 2024-04-17 21:46 Alexander Korotkov <akorotkov@postgresql.org>
0 siblings, 0 replies; 4+ messages in thread
From: Alexander Korotkov @ 2024-04-17 21:46 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Refactoring for CommitTransactionCommand()/AbortCurrentTransaction()
fefd9a3fed turned tail recursion of CommitTransactionCommand() and
AbortCurrentTransaction() into iteration. However, it splits the handling of
cases between different functions.
This commit puts the handling of all the cases into
AbortCurrentTransactionInternal() and CommitTransactionCommandInternal().
Now CommitTransactionCommand() and AbortCurrentTransaction() are just doing
the repeated calls of internal functions.
Reported-by: Andres Freund
Discussion: https://postgr.es/m/20240415224834.w6piwtefskoh32mv%40awork3.anarazel.de
Author: Andres Freund
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/40126ac68f2ff96351cd6071350eb2d5cbd50145
Modified Files
--------------
src/backend/access/transam/xact.c | 155 +++++++++++++++++---------------------
1 file changed, 71 insertions(+), 84 deletions(-)
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2024-04-17 21:46 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2009-06-05 18:50 pgsql: GIN's ItemPointerIsMin, ItemPointerIsMax, and Tom Lane <tgl@postgresql.org>
2009-06-05 18:50 pgsql: GIN's ItemPointerIsMin, ItemPointerIsMax, and Tom Lane <tgl@postgresql.org>
2009-06-05 18:50 pgsql: GIN's ItemPointerIsMin, ItemPointerIsMax, and Tom Lane <tgl@postgresql.org>
2024-04-17 21:46 pgsql: Refactoring for CommitTransactionCommand()/AbortCurrentTransacti 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