Small Bug in GetConflictingVirtualXIDs

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Small Bug in GetConflictingVirtualXIDs
Дата
Msg-id 200912210402.37850.andres@anarazel.de
обсуждение исходный текст
Ответы Re: Small Bug in GetConflictingVirtualXIDs  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Small Bug in GetConflictingVirtualXIDs  (Alvaro Herrera <alvherre@commandprompt.com>)
Список 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
holdexclusive 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: using separate parameters in psql query execution
Следующее
От: Tom Lane
Дата:
Сообщение: Possible patch for better index name choosing