On 13 February 2017 at 12:01, Amit Khandekar <amitdkhan...@gmail.com> wrote: > There are a few things that can be discussed about :
If you do a normal update the new tuple is linked to the old one using the ctid forming a chain of tuple versions. This tuple movement breaks that chain. So the question I had reading this proposal is what behaviour depends on ctid and how is it affected by the ctid chain being broken. I think the concurrent update case is just a symptom of this. If you try to update a row that's locked for a concurrent update you normally wait until the concurrent update finishes, then follow the ctid chain and recheck the where clause on the target of the link and if it still matches you perform the update there. At least you do that if you have isolation_level set to repeatable_read. If you have isolation level set to serializable then you just fail with a serialization failure. I think that's what you should do if you come across a row that's been updated with a broken ctid chain even in repeatable read mode. Just fail with a serialization failure and document that in partitioned tables if you perform updates that move tuples between partitions then you need to be ensure your updates are prepared for serialization failures. I think this would require another bit in the tuple info mask indicating that this is tuple is the last version before a broken ctid chain -- i.e. that it was updated by moving it to another partition. Maybe there's some combination of bits you could use though since this is only needed in a particular situation. Offhand I don't know what other behaviours are dependent on the ctid chain. I think you need to go search the docs -- and probably the code just to be sure -- for any references to ctid to ensure you catch every impact of breaking the ctid chain. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers