Re: Nested transactions and tuple header info
| От | Bruce Momjian |
|---|---|
| Тема | Re: Nested transactions and tuple header info |
| Дата | |
| Msg-id | 200406021457.i52Ev5j13915@candle.pha.pa.us обсуждение исходный текст |
| Ответ на | Re: Nested transactions and tuple header info (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Nested transactions and tuple header info
Re: Nested transactions and tuple header info |
| Список | pgsql-hackers |
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Tom Lane wrote: > >> I've been trying to think of ways to solve these problems by having a > >> main xact and all its subxacts share a common CID sequence (ie, a > >> subxact would have its own xid but would not start CID over at one). > >> If you assume that, then Bruce's idea may indeed work, since you would > >> never replace xmin in a way that would shift the interpretation of cmin > >> into a different CID sequence. But I suspect there is a simpler way to > >> solve it given that constraint. > > > I thought about using a global command counter. The problem there is > > that there is no way to control the visibility of tuples by other > > transactions on commit except going back end fixing up tuples, which is > > unacceptable. > > No, I said own xid --- so the "phantom xid" part is still there. But > your idea definitely does *not* work unless you use a single CID > sequence for the whole main xact; and I'm still wondering if there's > not a simpler implementation possible given that assumption. I don't understand why a single counter is needed for phantom xids. We keep the cmin/cmax on the tuple already, and our own backend can look up the xmin/xmax that goes with the phantom. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: