Small Bug in GetConflictingVirtualXIDs

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Small Bug in GetConflictingVirtualXIDs
Date: 2009-12-21 03:02:37
Message-ID: 200912210402.37850.andres@anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-12-21 03:17:17 Possible patch for better index name choosing
Previous Message Robert Haas 2009-12-21 03:01:55 Re: using separate parameters in psql query execution