CREATE OR REPLACE FUNCTION public."testlock"()
RETURNS TABLE
(
id integer,
name character varying,
state integer,
owner character varying
)
LANGUAGE 'plpgsql'
AS $BODY$
BEGIN
Hi,
You cannot set the statement_timeout within a function.
You have to set it before you call the function.
For example, you can try :
BEGIN;
SET LOCAL statement_timeout = 6000;
SELECT * from public.”testlock”();
COMMIT;
The reason why is explained in this post :
https://dba.stackexchange.c
I would not think that behavior would extend to lock_timeout based on the
explanation on stackexchange. I would assume that the potentially long
runtime in this function is mostly in acquiring the lock and not doing the
update given the implied primary key in the where clause, so perhaps
lock_timeo
Michael Lewis schrieb am 03.01.2020 um 18:00:
Why take an exclusive lock on an entire table to update a single row?
That's what I was asking myself as well.
Cross post from Stack Overflow:
https://stackoverflow.com/questions/59554144/are-postgresql-functions-that-return-sets-or-tables-evaluated-lazily-or-eagerly
I'm learning to write functions in PostgreSQL. When I got to the
documentation chapter on cursors, I came across this interesting comment:
Gerald Britton writes:
> I'm learning to write functions in PostgreSQL. When I got to the
> documentation chapter on cursors, I came across this interesting comment:
> A more interesting usage is to return a reference to a cursor that a
> function has created, allowing the caller to read the rows.
> "Gerald" == Gerald Britton writes:
Gerald> That leads me to ask:
Gerald> If (and under what circumstances) PostgreSQL evaluates
Gerald> functions lazily (returning rows as requested by the caller) or
Gerald> eagerly (evaluation all rows before returning the first one)?
This isn't triv
