From: Andrew Chernow <ac@esilo.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@commandprompt.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Cc: Merlin Moncure <mmoncure@gmail.com>
Subject: Re: [PATCHES] libpq events patch (with sgml docs)
Date: Wed, 17 Sep 2008 09:20:29 -0400
Message-ID: <48D1041D.5070808@esilo.com> (raw)
In-Reply-To: <8872.1221653812@sss.pgh.pa.us>
References: <48C18533.2000204@esilo.com>
<20080905192215.GK4353@alvh.no-ip.org>
<48C18B48.509@esilo.com>
<20080905194853.GL4353@alvh.no-ip.org>
<48C191A7.3000205@esilo.com>
<20080905201504.GM4353@alvh.no-ip.org>
<48C19759.90402@esilo.com>
<27615.1221619326@sss.pgh.pa.us>
<48D072E3.6010703@esilo.com>
<28673.1221622817@sss.pgh.pa.us>
<48D080B0.6070104@esilo.com>
<454.1221626213@sss.pgh.pa.us>
<48D0DFBE.9050900@esilo.com>
<8872.1221653812@sss.pgh.pa.us>
Tom Lane wrote:
>
> Some thought would need to be given to how that interacts with
> RESULTCOPY. Presumably on the destination side, RESULTCOPY is the
> equivalent of RESULTCREATE, ie, don't DESTROY if you didn't get COPY.
> But what of the source side? Arguably you shouldn't invoke COPY on
> events that were never initialized in this object.
>
You are correct. The resultcopy function needs to check if the src
result eventproc was initialized. BUT, that should not be possible
unless someone is not checking return values. Meaning, the only way to
have an uninitialized eventproc in this instance is if something failed
during a resultcreate. Actually, if you call PQmakeEmptyPGResult then
you can also run into this problem. That can be solved by adding an
argument to makeResult as I previously suggested.
> I also think that a little bit of thought should go into whether or
> not to call DESTROY on an event that *did* get a CREATE and failed it.
> You could argue that one either way: should a failing CREATE operation
> be expected to fully clean up after itself, or should it be expected
> to leave things in a state where DESTROY can clean up properly?
> I'm not entirely sure, but option A might force duplication of code
> between CREATE's failure path and DESTROY. Whichever semantics we
> choose needs to be documented.
>
If a resultcreate fails, than I think that resultdestroy should not be
delivered to that eventproc (same for resultcopy). That is how register
works and how I saw this patch working (eventhough it appears I have a
few logical errors). I don't think it makes sense to do it otherwise,
it would be like calling free after a malloc failure.
The needDestroy member should be called resultInitialized. Although the
conn doesn't reference the 'resultInitialized' member, I should
initialize it to FALSE. I did not do this in the last patch ...
register function.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-patches@postgresql.org
Cc: ac@esilo.com, tgl@sss.pgh.pa.us, alvherre@commandprompt.com, pgsql-hackers@postgresql.org, mmoncure@gmail.com
Subject: Re: [PATCHES] libpq events patch (with sgml docs)
In-Reply-To: <48D1041D.5070808@esilo.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox