Qingqing Zhou zhouqq.postg...@gmail.com writes:
Not sure if I understand correctly: in uniqueness check, we see all
possible tuples with a dirty snapshot. For a tuple version inserted
and updated by myself, it is surely dead no matter how the transaction
ends. So I interpret that we can
My understanding is that all subtransactions get their own unique XID
(assuming they need one), and that CommandId can't move backwards within
a transaction. If that's correct, then shouldn't we be able to prune
tuples where XMIN and XMAX match our *exact* XID (not all the extra
stuff that
On Tue, Apr 7, 2015 at 6:11 PM, Peter Geoghegan p...@heroku.com wrote:
No. For one thing, unique index enforcement still requires the tuples
to be treated as a conflict while the other transaction is running
IMV.
Not sure if I understand correctly: in uniqueness check, we see all
possible
On 4/7/15 8:11 PM, Peter Geoghegan wrote:
You're not the first to consider trying something like this in
specific scenarios, but my work on UPSERT leads me to believe it isn't
workable.
Yeah, every time I get into the really nitty-gritty details of this
stuff it gets scary. That's why I
On Tue, Apr 7, 2015 at 5:59 PM, Jim Nasby jim.na...@bluetreble.com wrote:
My understanding is that all subtransactions get their own unique XID
(assuming they need one), and that CommandId can't move backwards within a
transaction. If that's correct, then shouldn't we be able to prune tuples
On Tue, Apr 7, 2015 at 7:16 PM, Qingqing Zhou zhouqq.postg...@gmail.com wrote:
If another transaction T2 coming later than T1, and if we prune early,
then T1 can suddenly hang on insertion waiting for T2 to complete. But
does this violate any isolation rule?
Well, it means that you don't lock
