Re: [GENERAL] update error with serializable
От | Rob Sargent |
---|---|
Тема | Re: [GENERAL] update error with serializable |
Дата | |
Msg-id | bdee2ef8-c1f5-9436-0e92-4e2b55d60e77@gmail.com обсуждение исходный текст |
Ответ на | Re: [GENERAL] update error with serializable (Kevin Grittner <kgrittn@gmail.com>) |
Ответы |
Re: [GENERAL] update error with serializable
|
Список | pgsql-general |
On 01/20/2017 10:05 AM, Kevin Grittner wrote: > On Fri, Jan 20, 2017 at 4:44 AM, Tom DalPozzo <t.dalpozzo@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.fsf@dalvik.ping.uio.no#d8joa0eh9yw.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?
В списке pgsql-general по дате отправления: