Re: Patch review for logging hooks (CF 2012-01)

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Greg Smith <greg(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Patch review for logging hooks (CF 2012-01)
Date: 2012-03-04 15:45:15
Message-ID: 4F538E0B.9010600@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 01/20/2012 10:01 AM, Robert Haas wrote:
> On Fri, Jan 20, 2012 at 2:47 AM, Greg Smith<greg(at)2ndquadrant(dot)com> wrote:
>>> The updated patch looks good, marking as 'Ready for Committer'
>> Patches without documentation are never ready for commit. For this one, I'm
>> not sure if that should be in the form of a reference example in contrib, or
>> just something that documents that the hook exists and what the ground rules
>> are for grabbing it.
> Hooks are frequently not documented, and we only sometimes even bother
> to include an example in contrib. We should probably at least have a
> working example for testing purposes, though, whether or not we end up
> committing it.
>

I'm just looking at this patch, and I agree, it should be testable. I'm
wondering if it wouldn't be a good idea to have a module or set of
modules for demonstrating and testing bits of the API that we expose.
src/test/api or something similar? I'm not sure how we'd automate a test
for this case, though. I guess we could use something like pg_logforward
and have a UDP receiver catch the messages and write them to a file.
Something like that should be possible to rig up in Perl. But all that
seems a lot of work at this stage of the game. So the question is do we
want to commit this patch without it?

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2012-03-04 15:50:39 Re: Command Triggers, patch v11
Previous Message Boszormenyi Zoltan 2012-03-04 15:33:32 Re: ECPG FETCH readahead