Re: Tuple insert missing query in ongoing transaction - Mailing list pgsql-sql

Dear DAQ,

Thanks for the native answer ;) For those who have concerns reading 
Hungarian, here is an excerpt including my answer.

You adviced me to issue an ACCESS EXCLUSIVE lock on table "shift" in 
transaction B, before issuing the actual insert, so that the insert will 
wait till the end of transaction S.

Actually, you pointed me to the right way of the PostgreSQL doc and gave me 
the inspiration to actually read about lock modes :) As far as I understood 
things:

1. Shouldn't it be enough to lock in EXCLUSIVE mode, thus allowing others to 
access (select only) table "shift"? What's more, since any ins/upd/del on a 
table aquires ROW EXCLUSIVE mode, shouldn't it be enough to just acquire 
SHARE mode? It wouldn't even conflict with concurrent SHARE locks of other 
clients inserting into table B.

2. Am I reading right that acquiring a lock in a BEFORE trigger is too late? 
(not mentioning that trigger firing order is undefined) If so, is there 
another way to provide a server-side automatic lock before the insert, say, 
writing an ON INSERT rule on table "barcode"?

3. I can't see why shouldn't this work with updates and deletes (on any of 
the two tables), but since I'm new to this topic, it's better to ask: should 
I have any further concerns?

TIA,

--
G.


On 2005.08.23. 18:26, daq wrote:
> SG> Dear Gurus,
> 
> SG> I know this is the typical case of transaction use, I just seem to lack the 
> SG> appropriate education of what exactly happens and whether I may be able to 
> SG> detect it.
> 
> SG> I have two queries, one affecting the other.
> 
> SG> 1. INSERT INTO barcode.
> SG> A BEFORE INSERT/UPDATE trigger checks if there's an appropriate tuple in 
> SG> table "shift" for this tuple (matching day, shift-of-the-day and workplace) 
> SG> and denormalizes fields.
> 
> SG> 2. INSERT INTO shift.
> SG> An AFTER INSERT/UPDATE/DELETE trigger updates rows in table barcode, forcing 
> SG> the abovementioned check for shift.
> 
> SG> The second one is a long process, taking about 20 sec to finish. Imagine the 
> SG> following scenario:
> 
> SG> x:xx:00 INSERT INTO shift.
> SG>         Transaction "S" begins.
> SG>         It updates several rows, but not the not-yet-inserted row.
> SG> x:xx:10 INSERT INTO barcode (... appropriate for above-inserted shift ...)
> SG>         Transaction "B" begins.
> SG>         It checks but does not find the corresponding shift.
> SG> x:xx:11 Transaction "B" ends.
> SG> x:xx:20 Transaction "S" ends.
> 
> SG> In such scenarios, sometimes we get "Deadlock detected." That's OK since the 
> SG> transactions actually cross each other's way.
> 
> SG> But not always. In about 100 inserts, now we have the first case that did 
> SG> not show any trace of that something went wrong.
> 
> SG> 1. Is there a way to detect such "crossing" transactions?
> SG> 2. Is there a thorough article on deadlocks, how and when do they happen?
> SG> 3. Maybe a section of the postgresql doc clarifying when do tuples get locked?
> 
> A helyzet elkerulesere talan tudok egy modszert. A barcode tablaba
> insertalast szervezd tranzakcioba, es access exclusive moddal lockold
> az elejen(mindenkeppen meg az insert elott) a shift tablat. Igy mig "S" tranzakcio folyamatban van,
> addig a "B" nem indulhat el az exclusiv lock igenye miatt, es mig a
> "B" var a sorara, addig ujabb "S"-t sem enged elindulni. Igy
> elkerulheted az egymast keresztbe vero tranzakciokat, ami a
> deadlockhoz szokott vezetni.
> 
> DAQ
> 
>