Re: [PATCHES] Lazy xid assignment V4
От | Tom Lane |
---|---|
Тема | Re: [PATCHES] Lazy xid assignment V4 |
Дата | |
Msg-id | 7719.1189032026@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCHES] Lazy xid assignment V4 (Robert Treat <xzilla@users.sourceforge.net>) |
Ответы |
Re: [PATCHES] Lazy xid assignment V4
|
Список | pgsql-hackers |
Robert Treat <xzilla@users.sourceforge.net> writes: > I'm trying to decide how reasonable the use case is. We have transactions that > run several hours long, often touching a number of tables, and I've used the > transaction to get a list of all of the relations a given transaction is > touching. This makes the above solution more annoying by far, but I don't do > it often, and I think I generally use the pid to get that information anyway; > if I used prepared transactions I'm sure I'd feel stronger about this. I don't see why you wouldn't start using the VXID for this purpose? >> Also, I still agree with Florian's earlier argument that we should >> deliberately break any code that's depending on the transaction column. >> Any such code is unlikely to be prepared for the column containing nulls. > I don't buy this argument really only so far as the column can already be > null, so apps already need a way to deal with that. No, it was not possible for the XID column to be null before. Up to now, if you didn't have an XID you weren't holding a lock. regards, tom lane
В списке pgsql-hackers по дате отправления: