Re: Table locks
От | Bruce Momjian |
---|---|
Тема | Re: Table locks |
Дата | |
Msg-id | 200010091825.OAA22444@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Table locks (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Table locks
|
Список | pgsql-general |
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I am thinking of a tcl/tk app that can go in and grab information from > > backends by querying the actual structure values. Does gdb > > automatically halt the running app? > > Yes. I suppose this is no big problem if you start a backend to be > used only as the gdb target, but you'd not want to take over a live > client's backend for the purpose. That was the idea. > A bigger problem is that it's not a portable approach, since gdb may not > be available/installed on a given platform. Furthermore, you won't get > far unless the installed executable was compiled with debug symbols, > which isn't (and IMHO shouldn't be) the default configuration. Good point. I certainly did not want to muck up the backend with an API just so I could grab information for a monitoring utility. > > Finally (and probably the key point): what are you going to do about > locking? You aren't going to be able to grab a spinlock via gdb, nor > would it be a good idea if you could --- holding down a critical > spinlock while a tcl-to-gdb-to-backend conversation goes on would be a > killer for performance. No spinlock. I was going to just grab a snapshot as it existed. If it changes while I am grabbing it, I just try again. > > I think the information-grabbing routines need to be C code in the > backend. Not sure. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
В списке pgsql-general по дате отправления: