From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | heikki(dot)linnakangas(at)enterprisedb(dot)com, drkp(at)csail(dot)mit(dot)edu, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Serializable Snapshot Isolation |
Date: | 2010-09-17 14:08:27 |
Message-ID: | 10159.1284732507@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Heikki Linnakangas wrote:
>> That sounds like it can eat through your shared memory very quickly
>> if you have a lot of subtransactions.
> Hmmm.... I've never explicitly used subtransactions, so I don't tend
> to think of them routinely going too deep. And the struct is pretty
> small.
That assumption is absolutely, totally not going to fly.
>> Why not use SubTransGetTopmostTransaction() ?
> This needs to work when the xid of a transaction is found in the MVCC
> data of a tuple for any overlapping serializable transaction -- even
> if that transaction has completed and its connection has been
> closed. It didn't look to me like SubTransGetTopmostTransaction()
> would work after the transaction was gone.
Yes, it should work. If it doesn't, you are failing to manage the
TransactionXmin horizon correctly.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2010-09-17 14:21:46 | Re: Serializable Snapshot Isolation |
Previous Message | Aidan Van Dyk | 2010-09-17 13:59:43 | Re: Configuring synchronous replication |