Re : Re: pgsql-server/src/interfaces/libpgtcl pgtclCmds ...

---------------------------------------------------------------------------
2002 Aug 17 - 21:54
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
--------------------------------------------------------------------------
>Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>>> I am beginning to think that patch must have a hex on it.
>
>> Oops. Here it is, in mailbox format.
>
>Having looked it over, I'm not happy about it. The two big problems are
>
>* hardwired use of "connection_closed" as a NOTIFY condition name.
>It might be considered unlikely that this condition name is already in
>use out there ... or it might not.
>

What do you suggest ? I had to take a hardwired notification name.

>* not removing pending notifies from queue when connection loss
>is detected. This WILL break existing applications (note blithe
>reference to possible segfaults in notify scripts in his message).
>The reason we are killing those notifies is so that the app won't be
>fooled into trying to execute database operations because of receipt
>of a stale NOTIFY callback. While a callback intended specifically
>for connection_closed could be expected not to try to do database
>operations, I think it's unreasonable to expect existing callbacks for
>normal NOTIFY conditions to be coded to guard against this.
>

I never ever said, that the patch is 100% OK, I posted my changes and the patch to get feedback of what I've done. What are the disadvantages etc. Who could benefit from that.

>I'm also unhappy about the complete lack of documentation.
>
>I'd like to revert this patch and ask Gerhard to try again.
>
>The design I'd suggest is that there be a new command added to libpgtcl
>with a format along the lines of
> pg_on_connection_loss dbHandle [ callbackCommand ]
>This would be essentially similar to pg_listen except for omitting the
>notifyName parameter, and could share a lot of the internal
>implementation. By doing this we could avoid hardwiring an assumption
>about an unused notification name.
>

A new command came to my mind too, but what I was looking at first place was a quick and dirty (maybe more dirty) implementation for my needs. I'm going to think about that on monday.

>Also, the code *has* to be rejiggered so that ordinary notify events
>are still dropped on connection loss. And some documentation of this
>new command would be appropriate...
>

See above, quick and dirty, I commit that.

> regards, tom lane
>

2 more questions:
What command name do you suggest ?
Can I use the Close2Proc of the Tcl_Channel to store the disconnect handler script (or any information related to it), but I'd better dig the tcl-API tomorrow for that next week.

Gerhard
--
Gerhard Hintermayer
http://www.inode.at/g.hintermayer