Re: [INTERFACES] libpgtcl modifications
От | Bruce Momjian |
---|---|
Тема | Re: [INTERFACES] libpgtcl modifications |
Дата | |
Msg-id | 200208171219.g7HCJZk22900@candle.pha.pa.us обсуждение исходный текст |
Список | pgsql-patches |
Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --------------------------------------------------------------------------- Gerhard Hintermayer wrote: > Bruce Momjian wrote: > > Can I have some description of what this patch does? > > > > Unfortunately some of my postings seem to vanish in cyberspace ;-) > > What I have done for libpgtcl: > Everytime if I do PQconsumeInput (when the backend channel gets > readable) I check for the return value. (0 == error) and generate a > notification manually, e.g. fixed string connection_closed) and pass it to the > TCL event queue. The only other thing I had to do is to comment out removing > all pending events in PgStopNotifyEventSource whenever the connection was > unexpectedly closed (so the manually generated event will not be deleted). > > A broken backend connection triggers a notify event to the client (fixed > notification string "connection_closed") so proper action can be taken to switch > to another database server etc. Remember that this is event driven. If you have > applications, that have idle database connections most of the time, you'll get > immediate feedback of a dying server. Upon connection to the server issue a > pg_notify for notify event "connection_closed" and whenever the backend crashes > (which it does do in very very rare cases) you get an event driven recovery. (of > course the Tcl-Event loop has to be processed). Issuing a notification > "connection_closed" on a still working database could be used for switching to > another db-server (which I've actually impelemented right now). > > I did this not because we have crashing db-servers all the time, in fact we have > running pg for many years without any major problems in a production environment > (recipe and batch data for petfood production). > One reason was to get notifications to applications, that run permanently and > have a persistent db connection, in case the primary server should be changed > for whatever reason (network problems, server shutdown, maintenance etc.) > > Gerhard. > > PS: > >[ application/x-gunzip is not supported, skipping... ] > are you joking, which file format do you suggest for a patch ? > > > -- > Gerhard Hintermayer > http://www.inode.at/g.hintermayer > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
В списке pgsql-patches по дате отправления: