Re: [SQL] idiom to mv recs => [NEW] bleeding lock?

From: Herouth Maoz <herouth(at)oumail(dot)openu(dot)ac(dot)il>
To: Thomas Good <tomg(at)nrnet(dot)org>, pgsql-sql(at)postgreSQL(dot)org
Subject: Re: [SQL] idiom to mv recs => [NEW] bleeding lock?
Date: 1998-10-26 14:57:39
Message-ID: l03110704b25a3c6c5c8a@[147.233.159.109]
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

At 15:18 +0200 on 26/10/98, Thomas Good wrote:

> My point: when attempting to do a SELECT the table lock blocks even
> this activity. Is this a bleeding lock? Shouldn't a simple SELECT
> succeed? I dunno...but this is problematic as users are looking for
> info while the data entry person is doing her thing...ouch.

This lock is an exclusive lock. There is no other kind of lock in Postgres.

One may give up the LOCK at the beginning of the transaction. This would
mean that if a reader came and went before the deletion of the record, it
would succeed, because up to that point the transaction holds a shared lock
on the table. If a writer appeared, then it would fail, because it would
try to change the lock on the table from shared to exclusive, which it
can't do until all readers relinquished their locks.

This, however, creates a possibility that the deletion phase (and the
entire transaction) would fail, because the lock would fail to convert to
exclusive because other readers are still holding it.

Herouth

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Jackson, DeJuan 1998-10-27 00:13:06 RE: [SQL] palloc failure: memory exhausted, but ulimit 'unlimited '
Previous Message Shulyak AN 1998-10-26 13:52:57 RE: [SQL] Alternate disks for Indexes