Thanks. You saved me work by pointing me to the FOR UPDATE detail, and
the aggregate non-locking restriction. Can anyone comment on why this is
so? Reposting in HACKERS was a good idea :)
Side note: GeneXus (http://www.genexus.com) support, will be formally
announced in 10 days in an important in
I believe LOCK TABLE IN EXCLUSIVE MODE should block everything but
selects, but it locks for the entire transaction I think. Maybe in tcl you
could create your own locking using global variables. If the spin lock code
is available to user functions you might be able to use that.
Alternativley, in
I had a similar issue.
I needed to make sure I had a unique row- insert if not there, update if
there.
So I resorted to locking the whole table, then select, then insert/update.
What Tom told me to do was to use lock table tablename in exclusive mode
for my case.
This blocks select for update
"Matthew T. O'Connor" wrote:
>
> > A solution, could be to query for the existance of the PK, just before the
> > insertion. But there is a little span between the test and the
> > insertion, where another insertion from another transaction could void
> > the existance test. Any clever ideas on
> A solution, could be to query for the existance of the PK, just before the
> insertion. But there is a little span between the test and the
> insertion, where another insertion from another transaction could void
> the existance test. Any clever ideas on how to solve this? Using
> triggers mayb
Hi dear people,
Now I'm reposting this on hackers from general, sorry if no fully
suitable.
We are building a RAD tool (GeneXus) support, for PostgreSQL, as I have
mentioned before a number of times.
A problem which arose, is that within a transaction, if one inserts on a
table and the PK restr
