On Fri, Jan 20, 2017 at 4:44 AM, Tom DalPozzo <t.dalpo...@gmail.com> wrote:
> I've two threads countinuously updataing rows in the same table. > Each one does: BEGIN, UPDATE,UPDATE,,,,COMMIT > There can't be two active transactions updating the same row (my > bug apart but I don't think so). > I'm using default_transaction_isolation = 'serializable' > I get "could not serialize access due to read/write dependencies > among transactions" > I din't expect to see it, hence there must be something in > postgresql theory that I haven't understood well and I'd like a > clarification. Most likely one or both transactions have have updated 3 or more tuples on a single page, causing the tuple locks for the transaction on that page to be combined into a single page lock for that transaction. This is intended to prevent the memory required for tracking predicate locks from growing too large. This threshold of 3 per page was entirely arbitrary and always seen as something which could and should be improved someday. That might happen for version 10 (expected to be released next year), since a patch has been submitted to make that configurable. https://www.postgresql.org/message-id/flat/d8joa0eh9yw....@dalvik.ping.uio.no#d8joa0eh9yw....@dalvik.ping.uio.no If you are able to build from source, you might want to test the efficacy of the patch for your situation. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
