From: | "Gerhard Hintermayer" <g(dot)hintermayer(at)inode(dot)at> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-committers(at)postgresql(dot)org |
Subject: | Re : Re: pgsql-server/src/interfaces/libpgtcl pgtclCmds ... |
Date: | 2002-08-18 19:05:03 |
Message-ID: | E17gVMF-00056E-00@flurry.inode.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
---------------------------------------------------------------------------
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-08-18 20:15:52 | pgsql-server/contrib/cube cube.c cube.sql.in |
Previous Message | Tom Lane | 2002-08-18 18:46:15 | pgsql-server/src/backend/parser parse_clause.c |