From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Huxton <dev@archonet.com>
Cc: Tony Cebzanov <tonyceb@andrew.cmu.edu>
Cc: pgsql-sql@postgresql.org
Subject: Re: Avoiding cycles in a directed graph
Date: Tue, 16 Mar 2010 18:22:12 -0400
Message-ID: <15827.1268778132@sss.pgh.pa.us> (raw)
In-Reply-To: <4BA002DC.1050700@archonet.com>
References: <4B9FDFDE.5030005@andrew.cmu.edu>
<4B9FE752.4080709@archonet.com>
<14113.1268771643@sss.pgh.pa.us>
<4B9FEEE8.1060404@andrew.cmu.edu>
<14550.1268773752@sss.pgh.pa.us>
<4BA002DC.1050700@archonet.com>
Richard Huxton <dev@archonet.com> writes:
> On 16/03/10 21:09, Tom Lane wrote:
>> If you don't expect this to be common, maybe you could fix the
>> concurrency issue by taking a table-wide lock that locks out
>> other writers.
> Surely SELECT FOR UPDATE on the parents would be sufficient? If there's
> no overlap between (currently non-cyclic) graphs being altered then
> there can't be any conflict.
Um, what if the cycle is being formed from whole cloth? For instance
T1 inserts an edge A->B while T2 is inserting B->A. There are no
pre-existing rows to lock, but there will still be a cycle after they
both commit.
Also it seems pretty deadlock-prone if there are multiple existing rows
to try to lock. Perhaps you could work around the risk by locking those
rows one at a time in an application-defined ordering ... but I'm afraid
the performance would be poor, unless the connected graphs are always
very small.
On the whole I think Tony's better off with a KISS approach, ie just
lock the whole table against other writers.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: tgl@sss.pgh.pa.us, dev@archonet.com, tonyceb@andrew.cmu.edu
Subject: Re: Avoiding cycles in a directed graph
In-Reply-To: <15827.1268778132@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox