Hi Bruce
Thanks for the information (and the book link, straight in the bookmarks and
remembered for an Amazon search...)
Anyway, the chapter was helpful, but I'm still stuck. SERIALIZABLE looks
like it would do the job, but I don't want any queries to fail/rollback - I'd
rather they stalled on SET TRANSACTION or LOCK TABLE until the first was
complete.
Is this possible?
I am also assuming that even with SERIALIZABLE, concurrent SELECTs can
proceed unhindered?
Thanks
Shane
On Monday 18 Feb 2002 3:16 pm, Bruce Momjian wrote:
> Shane Wright wrote:
> > Hi
> >
> > I'm having trouble getting my head round postgres's locking. I've read
> > through all the docs but cant seem to find the right thingthat does what
> > I want...
> >
> >
> > Basically, there are a few tables in my system where a SELECT is done
> > prior to an INSERT to avoid duplicating certain data and so forth.
> >
> > So, I want to lock the table for the transaction that does the stuff
> > above so no more than one can run at a time (essentially making it
> > SERIALIZABLE). But, I dont want to block other readers from SELECTing
> > from the table at the same time...
> >
> > This is the classic multiple readers, single writer problem yes? I'm
> > sure its doable, but I cant work out which locking / transaction
> > isolation levels to use.
>
> See my chapter on transactions. I think you want SERIALIZABLE
> transaction mode.
>
> http://www.postgresql.org/docs/awbook.html