From: Andres Freund <andres@anarazel.de>
To: pgsql-hackers@postgresql.org, Simon Riggs <simon@2ndquadrant.com>
Subject: Small Bug in GetConflictingVirtualXIDs
Date: Mon, 21 Dec 2009 04:02:37 +0100
Message-ID: <200912210402.37850.andres@anarazel.de> (raw)
Hi Simon, Hi all,
HS currently does the following in GetConflictingVirtualXIDs
TransactionId pxmin = proc->xmin;
/*
* We ignore an invalid pxmin because this means that backend
* has no snapshot and cannot get another one while we hold exclusive lock.
*/
if (TransactionIdIsValid(pxmin) && !TransactionIdFollows(pxmin, limitXmin))
{
VirtualTransactionId vxid;
GET_VXID_FROM_PGPROC(vxid, *proc);
if (VirtualTransactionIdIsValid(vxid))
vxids[count++] = vxid;
}
The logic behind this seems fine except in the case of dropping a database.
There you very well might have a open connection without an open snapshot.
This leads to nice errors when youre connected to a database on the slave
without having a in progress transaction while dropping the database on the
primary:
CET FATAL: terminating connection due to administrator command
CET LOG: shutting down
CET LOG: restartpoint starting: shutdown immediate
CET FATAL: could not open file "base/16604/1259": No such file or directory
CET CONTEXT: writing block 5 of relation base/16604/1259
CET WARNING: could not write block 5 of base/16604/1259
CET DETAIL: Multiple failures --- write error might be permanent.
CET CONTEXT: writing block 5 of relation base/16604/1259
Should easily be solvable through an extra parameter for
GetConflictingVirtualXIDs. Want me to prepare a patch?
Andres
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: andres@anarazel.de, simon@2ndquadrant.com
Subject: Re: Small Bug in GetConflictingVirtualXIDs
In-Reply-To: <200912210402.37850.andres@anarazel.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
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