From: | Kevin Grittner <kgrittn(at)gmail(dot)com> |
---|---|
To: | Tom DalPozzo <t(dot)dalpozzo(at)gmail(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: update error with serializable |
Date: | 2017-01-20 17:05:51 |
Message-ID: | CACjxUsNj7RmBAL6rKtuGdsp_yjEDrKX2y0swAu8OckDe9SR_wg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, Jan 20, 2017 at 4:44 AM, Tom DalPozzo <t(dot)dalpozzo(at)gmail(dot)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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Rob Sargent | 2017-01-20 17:27:18 | Re: update error with serializable |
Previous Message | Rader, David | 2017-01-20 16:41:41 | Re: migrate Sql Server database to PostgreSql |