On 01/20/2017 10:05 AM, Kevin Grittner wrote:
> 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.
>
> https://www.postgresql.org/message-id/flat/d8joa0eh9yw(dot)fsf(at)dalvik(dot)ping(dot)uio(dot)no#d8joa0eh9yw(dot)fsf@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
>
>
Configurable or dynamic? Wouldn't something related to tuples per page
(and maybe fillfactor) do the trick?