On 1/16/18 15:24, Andrew Dunstan wrote:
> Looks good. Marking ready for committer.
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 16 January 2018 at 20:24, Andrew Dunstan
wrote:
> Looks good. Marking ready for committer.
Few questions/points for the docs.
Docs say: "A new transaction is started automatically after a
transaction is ended using these commands"
Presumably this would have exactly the same isolation level a
On 6 December 2017 at 22:34, Merlin Moncure wrote:
> On Wed, Dec 6, 2017 at 8:41 AM, Peter Eisentraut
> wrote:
>> On 12/5/17 13:33, Robert Haas wrote:
>>> On Tue, Dec 5, 2017 at 1:25 PM, Peter Eisentraut
>>> wrote:
I think ROLLBACK in a cursor loop might not make sense, because the
cur
On 01/16/2018 10:16 AM, Peter Eisentraut wrote:
> On 1/15/18 12:57, Andrew Dunstan wrote:
>> This confused me slightly:
>>
>> + Transactions cannot be ended inside loops through query results
>> or inside
>> + blocks with exception handlers.
>>
>> I suggest: "A transaction canno
On 1/15/18 12:57, Andrew Dunstan wrote:
> This confused me slightly:
>
> + Transactions cannot be ended inside loops through query results
> or inside
> + blocks with exception handlers.
>
> I suggest: "A transaction cannot be ended inside a loop over query
> results, nor inside
On 01/05/2018 04:30 PM, Peter Eisentraut wrote:
> A merge conflict has arisen, so for simplicity, here is an updated patch.
>
> On 12/20/17 10:08, Peter Eisentraut wrote:
>> Updated patch attached.
>>
>> I have addressed the most recent review comments I believe.
>>
>> The question about what hap
A merge conflict has arisen, so for simplicity, here is an updated patch.
On 12/20/17 10:08, Peter Eisentraut wrote:
> Updated patch attached.
>
> I have addressed the most recent review comments I believe.
>
> The question about what happens to cursor loops in PL/Perl and PL/Python
> would be a
Updated patch attached.
I have addressed the most recent review comments I believe.
The question about what happens to cursor loops in PL/Perl and PL/Python
would be addressed by the separate thread "portal pinning". The test
cases in this patch are currently marked by FIXMEs.
I have changed th
On 12/7/17 18:47, Andrew Dunstan wrote:
> Referring to anonymous blocks might be a bit mystifying for some
> readers, unless we note that they are invoked via DO.
Added parenthetical comments.
> I think this sentence should probably be worded a bit differently:
>
> (And of course, BEGIN and
On 12/06/2017 09:41 AM, Peter Eisentraut wrote:
> On 12/5/17 13:33, Robert Haas wrote:
>> On Tue, Dec 5, 2017 at 1:25 PM, Peter Eisentraut
>> wrote:
>>> I think ROLLBACK in a cursor loop might not make sense, because the
>>> cursor query itself could have side effects, so a rollback would have t
On Wed, Dec 6, 2017 at 8:41 AM, Peter Eisentraut
wrote:
> On 12/5/17 13:33, Robert Haas wrote:
>> On Tue, Dec 5, 2017 at 1:25 PM, Peter Eisentraut
>> wrote:
>>> I think ROLLBACK in a cursor loop might not make sense, because the
>>> cursor query itself could have side effects, so a rollback would
On 12/5/17 13:33, Robert Haas wrote:
> On Tue, Dec 5, 2017 at 1:25 PM, Peter Eisentraut
> wrote:
>> I think ROLLBACK in a cursor loop might not make sense, because the
>> cursor query itself could have side effects, so a rollback would have to
>> roll back the entire loop. That might need more re
On Tue, Dec 5, 2017 at 1:25 PM, Peter Eisentraut
wrote:
> I think ROLLBACK in a cursor loop might not make sense, because the
> cursor query itself could have side effects, so a rollback would have to
> roll back the entire loop. That might need more refined analysis before
> it could be allowed.
On 12/1/17 15:28, Robert Haas wrote:
> This feature doesn't have many tests. I think it should have a lot
> more of them. It's tinkering with the transaction control machinery
> of the system in a fairly fundamental way, and that could break
> things.
Thank you, these are great ideas.
> I sugge
On Fri, Dec 1, 2017 at 2:48 PM, Peter Eisentraut
wrote:
> Here is a new patch, now on top of master. The main changes are that a
> lot of documentation has been added.
This feature doesn't have many tests. I think it should have a lot
more of them. It's tinkering with the transaction control m
On 11/14/17 18:38, Peter Eisentraut wrote:
> On 10/31/17 15:38, Peter Eisentraut wrote:
>> Here is a patch that implements transaction control in PL/Python
>> procedures. (This patch goes on top of "SQL procedures" patch v1.)
>
> Here is an updated patch, now on top of "SQL procedures" v2.
Here
On Wed, Nov 29, 2017 at 3:33 AM, Peter Eisentraut
wrote:
> [snip]
Moved to next CF as the discussion is still hot.
--
Michael
On 10/31/17 15:38, Peter Eisentraut wrote:
> 2) SPI needs some work. It thinks that it can clean everything away at
> transaction end. I have found that instead of TopTransactionContext one
> can use PortalContext and get a more suitable life cycle for the memory.
> I have played with some varia
On 18 November 2017 at 02:16, Peter Eisentraut
wrote:
> On 11/16/17 18:35, Simon Riggs wrote:
>> For the first two answers above the answer was "currently executing
>> statement", yet the third answer seems to be the procedure. So that is
>> a slight discrepancy.
>
> That's the way function execut
On 11/16/17 18:35, Simon Riggs wrote:
> For the first two answers above the answer was "currently executing
> statement", yet the third answer seems to be the procedure. So that is
> a slight discrepancy.
That's the way function execution, or really any nested execution,
currently works.
> ISTM w
On Thu, Nov 16, 2017 at 5:35 PM, Simon Riggs wrote:
> On 14 November 2017 at 13:09, Peter Eisentraut
> wrote:
>
>>> *) Will pg_cancel_backend() cancel the currently executing statement
>>> or the procedure? (I guess probably the procedure but I'm curious)
>>
>> Same as the way it currently works.
On 14 November 2017 at 13:09, Peter Eisentraut
wrote:
>> *) Will pg_cancel_backend() cancel the currently executing statement
>> or the procedure? (I guess probably the procedure but I'm curious)
>
> Same as the way it currently works. It will raise an exception, which
> will travel up the stack
On 15 November 2017 at 16:36, Peter Eisentraut
wrote:
> On 11/8/17 18:48, Simon Riggs wrote:
>> What would happen if some of the INSERTs failed? Where would control
>> go to? (Maybe this is just "no change" in this particular proc)
>
> An exception is raised and unless the exception is caught (dep
On Thu, Nov 16, 2017 at 12:36 PM, Peter Eisentraut
wrote:
> On 11/16/17 07:04, legrand legrand wrote:
>> We are just opening the "close cursors on/at commit" specification ;o)
>>
>> - MS SQL server: cursor_close_on_commit
>> - Firebird: close_cursors_at_commit
>> - DB2: "with hold" syntax
>> - ..
On 11/16/17 07:04, legrand legrand wrote:
> We are just opening the "close cursors on/at commit" specification ;o)
>
> - MS SQL server: cursor_close_on_commit
> - Firebird: close_cursors_at_commit
> - DB2: "with hold" syntax
> - ...
>
> I think it a plus to support keeping opened cursors at comm
On Wed, Nov 15, 2017 at 3:42 PM, Peter Eisentraut
wrote:
> On 11/15/17 09:54, Merlin Moncure wrote:
>> ... 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?
>
> I think y
We are just opening the "close cursors on/at commit" specification ;o)
- MS SQL server: cursor_close_on_commit
- Firebird: close_cursors_at_commit
- DB2: "with hold" syntax
- ...
I think it a plus to support keeping opened cursors at commit time,
but impacts have to be checked in details ...
Or
On 11/15/17 09:54, Merlin Moncure wrote:
> ... 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?
I think you are correct. I'll include that in the next patch version.
It sh
On 11/8/17 18:48, Simon Riggs wrote:
> What would happen if some of the INSERTs failed? Where would control
> go to? (Maybe this is just "no change" in this particular proc)
An exception is raised and unless the exception is caught (depending on
the PL), control leaves the procedure. What is alre
On 11/14/17 17:40, legrand legrand wrote:
> will that kind of statement (that is permitted with Oracle but gives errors
> ora-1555 snapshot too old) be permitted ?
>
> begin
> for c in (select id from tab where cond='blabla')
> loop
> update tab set x=1 where id=c.id;
> commit;
> end lo
On Wed, Nov 15, 2017 at 7:38 AM, Merlin Moncure 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 functio
2017-11-15 14:38 GMT+01:00 Merlin Moncure :
> On Tue, Nov 14, 2017 at 5:27 PM, Peter Eisentraut
> wrote:
> > On 11/14/17 16:33, Merlin Moncure wrote:
> >>> One detail in your example is that when you enter the procedure, you
> are
> >>> already in a transaction, so you would have to run either CO
On Tue, Nov 14, 2017 at 5:27 PM, Peter Eisentraut
wrote:
> On 11/14/17 16:33, Merlin Moncure wrote:
>>> One detail in your example is that when you enter the procedure, you are
>>> already in a transaction, so you would have to run either COMMIT or
>>> ROLLBACK before the START TRANSACTION.
>>
>>
On 10/31/17 15:38, Peter Eisentraut wrote:
> Here is a patch that implements transaction control in PL/Python
> procedures. (This patch goes on top of "SQL procedures" patch v1.)
Here is an updated patch, now on top of "SQL procedures" v2.
Relative to the previous patch v1 I added transaction co
On 11/14/17 16:33, Merlin Moncure wrote:
>> One detail in your example is that when you enter the procedure, you are
>> already in a transaction, so you would have to run either COMMIT or
>> ROLLBACK before the START TRANSACTION.
>
> Ok, that's good, but it seems a little wonky to me to have to is
will that kind of statement (that is permitted with Oracle but gives errors
ora-1555 snapshot too old) be permitted ?
begin
for c in (select id from tab where cond='blabla')
loop
update tab set x=1 where id=c.id;
commit;
end loop;
end;
--
Sent from: http://www.postgresql-archive.o
On Tue, Nov 14, 2017 at 12:09 PM, Peter Eisentraut
wrote:
> On 11/14/17 09:27, Merlin Moncure wrote:
>> *) Will it be possible to do operations like this in pl/pgsql?
>>
>> BEGIN
>> SELECT INTO r * FROM foo;
>>
>> START TRANSACTION; -- perhaps we ought to have a special function
>> for this i
On 11/14/17 09:27, Merlin Moncure wrote:
> *) Will it be possible to do operations like this in pl/pgsql?
>
> BEGIN
> SELECT INTO r * FROM foo;
>
> START TRANSACTION; -- perhaps we ought to have a special function
> for this instead (BEGIN is reserved, etc).
> SET transaction_isololation T
On Wed, Nov 8, 2017 at 5:48 PM, Simon Riggs wrote:
> On 31 October 2017 at 15:38, Peter Eisentraut
> wrote:
>> Here is a patch that implements transaction control in PL/Python
>> procedures. (This patch goes on top of "SQL procedures" patch v1.)
>
> The patch is incredibly short for such a featu
39 matches
Mail list logo
