Re: Locking to restrict rowcounts.

From: Richard Huxton <dev(at)archonet(dot)com>
To: Glen Parker <glenebob(at)nwlink(dot)com>
Cc: pgsql-general(at)postgresql(dot)org, Shakil Shaikh <sshaikh(at)hotmail(dot)com>
Subject: Re: Locking to restrict rowcounts.
Date: 2009-05-19 19:07:30
Message-ID: 4A130372.2010705@archonet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Glen Parker wrote:
> Richard Huxton wrote:

>> 3. Check after an insert on the items table and raise an exception if
>> there are 11+ items.
>>
>> I'd be tempted by #3 - assuming most of the time you won't breach this
>> limit.
>
> #3 won't work unless the other transactions have all committed by the
> time you do the check. It is guaranteed to fail at some point.

If it's in an AFTER INSERT/UPDATE trigger then whatever transaction
takes you beyond 10 rows you will always get a failure. If you get a lot
of insert/delete pairings then you could spend a lot of time counting
rows, but that's all.

> There would be nothing wrong with creating a table with rows that
> exist solely for the purpose of locking. This is a (usually) better
> version of option #2 above.

Of course, if you're going to have a separate table then you might as
well store the count in there and actually update it on every
insert/update/delete. Assuming you might find the count of some use
somewhere. Set the fill-factor for the lock table and HOT should prevent
the table bloating too.

--
Richard Huxton
Archonet Ltd

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Glen Parker 2009-05-19 19:27:03 Re: Locking to restrict rowcounts.
Previous Message Malinka Rellikwodahs 2009-05-19 19:04:19 Re: Error while including PQXX library