On 24 February 2017 at 14:57, David G. Johnston <david.g.johns...@gmail.com> wrote: > I dislike an error. I'd say that making partition "just work" here is > material for another patch. In this one an update of the partition key can > be documented as shorthand for delete-returning-insert with all the > limitations that go with that. If someone acceptably solves the ctid > following logic later it can be committed - I'm assuming there would be no > complaints to making things just work in a case where they only sorta > worked.
Personally I don't think there's any hope that there will ever be cross-table ctids links. Maybe one day there will be a major new table storage format with very different capabilities than today but in the current architecture it seems like an impossible leap. I would expect everyone to come to terms with the basic idea that partition key updates are always going to be a corner case. The user defined the partition key and the docs should carefully explain to them the impact of that definition. As long as that explanation gives them something they can work with and manage the consequences of that's going to be fine. What I'm concerned about is that silently giving "wrong" answers in regular queries -- not even ones doing the partition key updates -- is something the user can't really manage. They have no way to rewrite the query to avoid the problem if some other user or part of their system is updating partition keys. They have no way to know the problem is even occurring. Just to spell it out -- it's not just "no-op updates" where the user sees 0 records updated. If I update all records where username='stark', perhaps to set the "user banned" flag and get back "9 records updated" and later find out that I missed a record because someone changed the department_id while my query was running -- how would I even know? How could I possibly rewrite my query to avoid that? The reason I suggested throwing a serialization failure was because I thought that would be the easiest short-cut to the problem. I had imagined having a bit pattern that indicated such a move would actually be a pretty minor change actually. I would actually consider using a normal update bitmask with InvalidBlockId in the ctid to indicate the tuple was updated and the target of the chain isn't available. That may be something we'll need in the future for other cases too. Throwing an error means the user has to retry their query but that's at least something they can do. Even if they don't do it automatically the ultimate user will probably just retry whatever operation errored out anyways. But at least their database isn't logically corrupted. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
