From: | Tony Cebzanov <tonyceb(at)andrew(dot)cmu(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Richard Huxton <dev(at)archonet(dot)com>, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Avoiding cycles in a directed graph |
Date: | 2010-03-17 18:36:12 |
Message-ID: | 4BA1211C.20800@andrew.cmu.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
On 3/16/10 6:22 PM, Tom Lane wrote:
> Richard Huxton <dev(at)archonet(dot)com> writes:
>
>
> 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.
For what it's worth, when I did give the "FOR UPDATE" strategy a try,
but with the recursive query rather than the simpler approach Richard
suggested, I got the following error (v8.4.2):
ERROR: FOR UPDATE/SHARE in a recursive query is not implemented
I'm sticking with the recursive query, because it seems to me the only
way to ensure there are no cycles is to check the whole graph for
cycles, and the only way I know how to do that is the recursive
approach. Since "FOR UPDATE" isn't implemented for recursive queries,
I'll just lock the entire table for now.
Thanks, all!
-Tony
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Gould | 2010-03-17 19:18:23 | Re: strange issue with UUID data types |
Previous Message | Rob Sargent | 2010-03-17 16:42:47 | Re: strange issue with UUID data types |