Small Bug in GetConflictingVirtualXIDs
От | Andres Freund |
---|---|
Тема | Small Bug in GetConflictingVirtualXIDs |
Дата | |
Msg-id | 200912210402.37850.andres@anarazel.de обсуждение исходный текст |
Ответы |
Re: Small Bug in GetConflictingVirtualXIDs
Re: Small Bug in GetConflictingVirtualXIDs |
Список | 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 по дате отправления: