Обсуждение: Table locks
Is there any way to view the locks being held on a table?? Thanks in Advance, Dale.
"Dale Anderson" <danderso@crystalsugar.com> writes:
> Is there any way to view the locks being held on a table??
There is not any good way --- lock.c has a routine called DumpAllLocks,
but it's not even compiled by default, let alone connected up to any
reasonable calling method. I've been thinking for awhile that we
desperately need some simple way of dumping out the state of the lock
manager...
regards, tom lane
I want to write an admin utility that will view backend SQL queries, and be able to view locks and statistics using gdb on the running backend. > "Dale Anderson" <danderso@crystalsugar.com> writes: > > Is there any way to view the locks being held on a table?? > > There is not any good way --- lock.c has a routine called DumpAllLocks, > but it's not even compiled by default, let alone connected up to any > reasonable calling method. I've been thinking for awhile that we > desperately need some simple way of dumping out the state of the lock > manager... > > regards, tom lane > -- 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
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I want to write an admin utility that will view backend SQL queries, and
> be able to view locks and statistics using gdb on the running backend.
gdb on a backend doesn't seem to me like a reasonable component of a
production situation. I was thinking something along the line of a
SHOW command that would show the state of the lock table.
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I want to write an admin utility that will view backend SQL queries, and > > be able to view locks and statistics using gdb on the running backend. > > gdb on a backend doesn't seem to me like a reasonable component of a > production situation. I was thinking something along the line of a > SHOW command that would show the state of the lock table. 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? -- 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
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I want to write an admin utility that will view backend SQL queries, and > > be able to view locks and statistics using gdb on the running backend. > > gdb on a backend doesn't seem to me like a reasonable component of a > production situation. I was thinking something along the line of a > SHOW command that would show the state of the lock table. Yes, SHOW would be nicer. I was thinking of a more general solution. -- 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
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.
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.
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.
I think the information-grabbing routines need to be C code in the
backend.
regards, tom lane
> 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
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> 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.
Unless, of course, you follow a now-dangling pointer and cause a backend
crash. But even without that, how do you know whether you grabbed a
self-consistent snapshot or not?
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > 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. > > Unless, of course, you follow a now-dangling pointer and cause a backend > crash. But even without that, how do you know whether you grabbed a > self-consistent snapshot or not? Not sure, yet... -- 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
When I start postmaster, I get the following: IpcSemaphoreCreate: semget failed (No space left on device) key = ... I know that this is caused by not having enough semaphores and can be fixed by increasing some settings. However, it normall works fine with the setting, and a nasty crash killed it this morning. I think that for some reason, some semaphores are still being held. I have ps -aux'd and killed all the postgresql processes, and have erased all my files in the /tmp directory. What else can I do? Thanks, ---------------------------------------------------------------- Travis Bauer | CS Grad Student | IU |www.cs.indiana.edu/~trbauer ----------------------------------------------------------------
Travis Bauer <trbauer@cs.indiana.edu> writes:
> When I start postmaster, I get the following:
> IpcSemaphoreCreate: semget failed (No space left on device) key = ...
> However, it normall works fine with the setting, and a nasty
> crash killed it this morning. I think that for some reason, some
> semaphores are still being held.
Sounds likely. The standard utility programs ipcs and ipcrm will help you
clean up --- see their man pages. (You probably will need to zap the
old shared-memory segments as well as the old semaphores; these tools
will handle both tasks.)
Our distribution includes a shell script "ipcclean" that purports to
do this for you, but I wouldn't trust it too far, since the output
format of ipcs is somewhat platform-specific.
regards, tom lane
Tom, Thanks. Running ipcclean fixed it right away. ---------------------------------------------------------------- Travis Bauer | CS Grad Student | IU |www.cs.indiana.edu/~trbauer ---------------------------------------------------------------- On Mon, 9 Oct 2000, Tom Lane wrote: > Travis Bauer <trbauer@cs.indiana.edu> writes: > > When I start postmaster, I get the following: > > IpcSemaphoreCreate: semget failed (No space left on device) key = ... > > > However, it normall works fine with the setting, and a nasty > > crash killed it this morning. I think that for some reason, some > > semaphores are still being held. > > Sounds likely. The standard utility programs ipcs and ipcrm will help you > clean up --- see their man pages. (You probably will need to zap the > old shared-memory segments as well as the old semaphores; these tools > will handle both tasks.) > > Our distribution includes a shell script "ipcclean" that purports to > do this for you, but I wouldn't trust it too far, since the output > format of ipcs is somewhat platform-specific. > > regards, tom lane >