Skip to content

Commit a32c3ec

Browse files
committed
Promote the assertion that XLogBeginInsert() is not called twice into ERROR.
Seems like cheap insurance for WAL bugs. A spurious call to XLogBeginInsert() in itself would be fairly harmless, but if there is any data registered and the insertion is not completed/cancelled properly, there is a risk that the data ends up in a wrong WAL record. Per Jeff Janes's suggestion.
1 parent a45c70a commit a32c3ec

File tree

1 file changed

+3
-1
lines changed

1 file changed

+3
-1
lines changed

src/backend/access/transam/xloginsert.c

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -122,12 +122,14 @@ XLogBeginInsert(void)
122122
Assert(max_registered_block_id == 0);
123123
Assert(mainrdata_last == (XLogRecData *) &mainrdata_head);
124124
Assert(mainrdata_len == 0);
125-
Assert(!begininsert_called);
126125

127126
/* cross-check on whether we should be here or not */
128127
if (!XLogInsertAllowed())
129128
elog(ERROR, "cannot make new WAL entries during recovery");
130129

130+
if (begininsert_called)
131+
elog(ERROR, "XLogBeginInsert was already called");
132+
131133
begininsert_called = true;
132134
}
133135

0 commit comments

Comments
 (0)
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy