From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Transaction control in procedures |
Date: | 2017-11-15 14:54:43 |
Message-ID: | CAHyXU0wE87U4na8baSQQ+umJG6oqCDO5GnNo2UwazEtdicimXQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Nov 15, 2017 at 7:38 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On Tue, Nov 14, 2017 at 5:27 PM, Peter Eisentraut
>>> Can we zero in on this? The question implied, 'can you do this
>>> without being in a transaction'? PERFORM do_stuff() is a implicit
>>> transaction, so it ought to end when the function returns right?
>>> Meaning, assuming I was not already in a transaction when hitting this
>>> block, I would not be subject to an endless transaction duration?
>>
>> In the server, you are always in a transaction, so that's not how this
>> works. I think this also ties into my first response above.
>
> I'll try this out myself, but as long as we can have a *bounded*
> transaction lifetime (basically the time to do stuff + 1 second) via
> something like:
> LOOP
> <do stuff>
> COMMIT;
> PERFORM pg_sleep(1);
> END LOOP;
>
> ... I'm good. I'll try your patch out ASAP. Thanks for answering all
> my questions.
Trying this out (v2 both patches, compiled clean, thank you!),
postgres=# CREATE OR REPLACE PROCEDURE foo() AS
$$
BEGIN
LOOP
PERFORM 1;
COMMIT;
RAISE NOTICE '%', now();
PERFORM pg_sleep(1);
END LOOP;
END;
$$ LANGUAGE PLPGSQL;
CREATE PROCEDURE
Time: 0.996 ms
postgres=# call foo();
NOTICE: 2017-11-15 08:52:08.936025-06
NOTICE: 2017-11-15 08:52:08.936025-06
... I noticed that:
*) now() did not advance with commit and,
*) xact_start via pg_stat_activity did not advance
Shouldn't both of those advance with the in-loop COMMIT?
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Nicolas Barbier | 2017-11-15 15:10:47 | Re: pspg - psql pager |
Previous Message | Pavel Stehule | 2017-11-15 14:46:23 | Re: pspg - psql pager |