Re: Auditing extension for PostgreSQL (Take 2)

From: Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>
To: David Steele <david(at)pgmasters(dot)net>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Auditing extension for PostgreSQL (Take 2)
Date: 2015-04-03 07:59:42
Message-ID: CAD21AoBJQwwFm_S5TitohbHVbb-TWga4=7uOPofgaj+V6hrsmA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 2, 2015 at 2:46 AM, David Steele <david(at)pgmasters(dot)net> wrote:
> Hi Sawada,
>
> On 3/25/15 9:24 AM, David Steele wrote:
>> On 3/25/15 7:46 AM, Sawada Masahiko wrote:
>>> 2.
>>> I got ERROR when executing function uses cursor.
>>>
>>> 1) create empty table (hoge table)
>>> 2) create test function as follows.
>>>
>>> create function test() returns int as $$
>>> declare
>>> cur1 cursor for select * from hoge;
>>> tmp int;
>>> begin
>>> open cur1;
>>> fetch cur1 into tmp;
>>> return tmp;
>>> end$$
>>> language plpgsql ;
>>>
>>> 3) execute test function (got ERROR)
>>> =# select test();
>>> LOG: AUDIT: SESSION,6,1,READ,SELECT,,,selecT test();
>>> LOG: AUDIT: SESSION,6,2,FUNCTION,EXECUTE,FUNCTION,public.test,selecT test();
>>> LOG: AUDIT: SESSION,6,3,READ,SELECT,,,select * from hoge
>>> CONTEXT: PL/pgSQL function test() line 6 at OPEN
>>> ERROR: pg_audit stack is already empty
>>> STATEMENT: selecT test();
>>>
>>> It seems like that the item in stack is already freed by deleting
>>> pg_audit memory context (in MemoryContextDelete()),
>>> before calling stack_pop in dropping of top-level Portal.
>
> This has been fixed and I have attached a new patch. I've seen this
> with cursors before where the parent MemoryContext is freed before
> control is returned to ProcessUtility. I think that's strange behavior
> but there's not a lot I can do about it.
>

Thank you for updating the patch!

> The code I put in to deal with this situation was not quite robust
> enough so I had to harden it a bit more.
>
> Let me know if you see any other issues.
>

I pulled HEAD, and then tried to compile source code after applied
following "deparsing utility command patch" without #0001 and #0002.
(because these two patches are already pushed)
<http://www.postgresql.org/message-id/20150325175954.GL3636@alvh.no-ip.org>

But I could not use new pg_audit patch due to compile error (that
deparsing utility command patch might have).
I think I'm missing something, but I'm not sure.
Could you tell me which patch should I apply before compiling pg_audit?

Regards,

-------
Sawada Masahiko

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2015-04-03 09:35:49 Re: The return value of allocate_recordbuf()
Previous Message Amit Langote 2015-04-03 07:07:03 Re: Possibly a typo in expand_inherited_rtentry()