Re: table locking

From: Shane Wright <me(at)shanewright(dot)co(dot)uk>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: pgsql-sql(at)postgresql(dot)org
Subject: Re: table locking
Date: 2002-02-18 15:22:11
Message-ID: 200202181521.g1IFLwk24097@fullerruss.dsvr.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

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

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Tom Lane 2002-02-18 15:33:29 Re: Sequence in the rules
Previous Message Bruce Momjian 2002-02-18 15:16:15 Re: table locking