Re: Lock table in non-volatile functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gaetano Mendola <mendola(at)bigfoot(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Lock table in non-volatile functions
Date: 2007-03-17 02:17:34
Message-ID: 1180.1174097854@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gaetano Mendola <mendola(at)bigfoot(dot)com> writes:
> Tom Lane wrote:
>> Really? AFAICS, CommandIsReadOnly() will reject SELECT FOR UPDATE too.

> kalman$# FOR my_port_set IN
> kalman$# SELECT a
> kalman$# FROM test
> kalman$# FOR UPDATE
> kalman$# LOOP

Hm, that's a bug --- SPI_cursor_open is failing to check for a read-only
query.

> BTW why forbid the lock in a non volatile function or (if you fix this)
> the SELECT FOR UPDATE ?

Well, as for the lock, a non-volatile function isn't supposed to have
any side-effects, and taking a lock is certainly a side-effect no?
Now I suppose it'll be taking AccessShareLock anyway if it reads any
tables, so maybe we could negotiate about what sort of locks could be
allowed; but I'd certainly argue that allowing it to take any kind of
exclusive lock would be a Bad Idea.

As for SELECT FOR UPDATE, there's a very good reason for disallowing
that even without considering what locks it takes. In a READ COMMITTED
transaction, SELECT FOR UPDATE can return row states that aren't visible
according to the nominal transaction snapshot, and so it violates the
promise of stable results.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2007-03-17 04:37:57 Re: [PATCHES] Bitmapscan changes
Previous Message Gaetano Mendola 2007-03-17 01:17:10 Re: Lock table in non-volatile functions