From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Vladlen Popolitov <v(dot)popolitov(at)postgrespro(dot)ru> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Avoiding roundoff error in pg_sleep() |
Date: | 2025-09-26 15:10:19 |
Message-ID: | 4062677.1758899419@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Vladlen Popolitov <v(dot)popolitov(at)postgrespro(dot)ru> writes:
> Tom Lane писал(а) 2025-09-25 22:36:
>> How is this different from any other long-running query?
> I will try to explain my worries about this. Long running queries could
> run long
> due to higher input-output, and they are limited at least by work_mem
> parameter.
> pg_sleep() is not limited by anything.
So I assume for example, that you would also argue for removing
all looping constructs from pl/pgsql so that users could not
write infinite loops?
DO $$ BEGIN LOOP END LOOP; END $$;
is just as effective a blocking transaction as pg_sleep,
plus it consumes a CPU.
I think the right answer to concerns like this is transaction_timeout
and similar features, not arbitrary restrictions.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2025-09-26 15:11:52 | test_json_parser/002_inline is kind of slow |
Previous Message | David G. Johnston | 2025-09-26 15:08:10 | Re: Avoiding roundoff error in pg_sleep() |