> On Aug 27, 2018, at 5:13 PM, Peter Eisentraut
> wrote:
>
> On 23/08/2018 17:35, Jonathan S. Katz wrote:
>> Applied the patch against head. make check passed, all the tests I ran
>> earlier in this thread passed as well.
>>
>> Reviewed the code - looks to match above reasoning, and comments
>
On 23/08/2018 17:35, Jonathan S. Katz wrote:
> Applied the patch against head. make check passed, all the tests I ran
> earlier in this thread passed as well.
>
> Reviewed the code - looks to match above reasoning, and comments
> are clear.
>
> From my perspective it looks good, but happy to hear
> On Aug 23, 2018, at 9:34 AM, Peter Eisentraut
> wrote:
>
> I think I've found a reasonable fix for this.
>
> The problem arises with the combination of CALL with output parameters
> and doing a COMMIT inside the procedure. When a CALL has output
> parameters, the portal uses the strategy PO
I think I've found a reasonable fix for this.
The problem arises with the combination of CALL with output parameters
and doing a COMMIT inside the procedure. When a CALL has output
parameters, the portal uses the strategy PORTAL_UTIL_SELECT instead of
PORTAL_MULTI_QUERY. Using PORTAL_UTIL_SELECT
On 16/08/2018 19:26, Tom Lane wrote:
>> When a CALL has output parameters, the portal uses the strategy
>> PORTAL_UTIL_SELECT instead of PORTAL_MULTI_QUERY. Using
>> PORTAL_UTIL_SELECT causes the portal's snapshot to be registered with
>> the current resource owner (portal->holdSnapshot). I'm not
Peter Eisentraut writes:
> The problem arises with the combination of CALL with output parameters
> and doing a COMMIT inside the procedure.
> When a CALL has output parameters, the portal uses the strategy
> PORTAL_UTIL_SELECT instead of PORTAL_MULTI_QUERY. Using
> PORTAL_UTIL_SELECT causes the
Alvaro Herrera writes:
> Hmm, this got me thinking whether the current resource owner setup for a
> procedure is appropriate. Maybe the problem is that resowners are still
> thought of in terms of transactions plus portals, so that if
> transactions are done then everything is over; maybe we need
On 2018-Aug-16, Peter Eisentraut wrote:
> There are, technically, three ways to fix this: silence the warning,
> unregister the snapshot explicitly, or don't register the snapshot to
> begin with.
>
> Silencing the warning, other than by just deleting it, might require
> passing in some more cont
On 14/08/2018 15:35, Peter Eisentraut wrote:
> The commit that started this is
>
> commit 59a85323d9d5927a852939fa93f09d142c72c91a
> Author: Peter Eisentraut
> Date: Mon Jul 9 13:58:08 2018
>
> Add UtilityReturnsTuples() support for CALL
>
> This ensures that prepared statements for C
The commit that started this is
commit 59a85323d9d5927a852939fa93f09d142c72c91a
Author: Peter Eisentraut
Date: Mon Jul 9 13:58:08 2018
Add UtilityReturnsTuples() support for CALL
This ensures that prepared statements for CALL can return tuples.
The change whether a statement returns
> On Jul 23, 2018, at 3:06 AM, Michael Paquier wrote:
>
> On Mon, Jul 23, 2018 at 12:19:12PM +0530, Prabhat Sahu wrote:
>> While testing with PG procedure, I found a memory leak on HEAD, with below
>> steps:
>>
>> postgres=# CREATE OR REPLACE PROCEDURE proc1(v1 INOUT INT)
>> AS $$
>> BEGIN
>> c
On Mon, Jul 23, 2018 at 12:19:12PM +0530, Prabhat Sahu wrote:
> While testing with PG procedure, I found a memory leak on HEAD, with below
> steps:
>
> postgres=# CREATE OR REPLACE PROCEDURE proc1(v1 INOUT INT)
> AS $$
> BEGIN
> commit;
> END; $$ LANGUAGE plpgsql;
> CREATE PROCEDURE
>
> postgres
Hi Hackers,
While testing with PG procedure, I found a memory leak on HEAD, with below
steps:
postgres=# CREATE OR REPLACE PROCEDURE proc1(v1 INOUT INT)
AS $$
BEGIN
commit;
END; $$ LANGUAGE plpgsql;
CREATE PROCEDURE
postgres=# call proc1(10);
WARNING: Snapshot reference leak: Snapshot 0x23678e
13 matches
Mail list logo
