Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] keeping track of connections

From: The Hermit Hacker <scrappy(at)hub(dot)org>
To: David Gould <dg(at)illustra(dot)com>
Cc: Hal Snyder <hal(at)enteract(dot)com>, pgsql-hackers(at)hub(dot)org
Subject: Re: [HACKERS] keeping track of connections
Date: 1998-06-03 21:40:10
Message-ID: Pine.BSF.3.96.980603183107.388I-100000@thelab.hub.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, 3 Jun 1998, David Gould wrote:

> Hal Synder writes:
> > 
> > Can backend monitoring be compatible with one or more extant
> > monitoring techniques?
> > 
> > 1. syslog
> > 2. HTML (like Apache's real time status)
> > 3. SNMP/SMUX/AgentX
> 
> In Illustra, we use (gasp) SQL for this.
> 
> > select * from procs;
> 
> procc_pid     |proc_xid     |proc_database|proc_locktab |proc_locktid |proc_locktype|proc_prio    |proc_licenseid|proc_status  |proc_user    |proc_host           |proc_display |proc_spins   |proc_buffers |
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> |4787         |0            |58.201e      |tables       |(7,0)        |R            |0            |0             |lock wait    |miadmin      |warbler.illustra.com|/dev/pts/4   |[]           |[]           |
> |3997         |0            |58.201e      |-            |(-1,0)       |             |0            |0             |client input |miadmin      |warbler.illustra.com|/dev/pts/11  |[]           |[]           |
> |29597        |1320638      |58.201e      |-            |(-1,0)       |             |0            |0             |running     *|miadmin      |warbler.illustra.com|/dev/pts/5   |[]           |[]           |
> |4790         |1320646      |58.7         |-            |(-1,0)       |             |0            |0             |running     *|miadmin      |warbler.illustra.com|/dev/pts/4   |[6]          |[]           |
> -------------------------------------------------------------------------------
> 
> "procs" is a pseudo-table that is generated on the fly from the process
> data structures in the shared memory when queried. There are also
> pseudo-tables for locks and traces and other information. 
> 
> 
> The advantage of using SQL is that the data can be selected into other
> tables, grouped, projected, joined or whatever. The other advantage is
> that all the exiting clients can take advantage of the data. So if you
> wanted to write a graphical status monitor, you could do so quite simply
> in pgtcl. 
> 
> Illustra also provides a set of prewritten functions (which are just sql
> funcs) to provide convenient access to many kinds of common catalog
> queries. 

	I definitely like this...it keeps us self-contained as far as the
data is concerned, and everyone that is using it knows enough about SQL
(or should) to be able to gleam information as required...

	What would it take to do this though?  The 'postmaster' itself,
unless I've misunderstand a good many of the conversations on this, can't
access the tables themselves, only 'flat files' (re: the password issue),
so it would have to be done in the fork'd process itself.  That, IMHO,
would pose a possible inconsequential problem though...what if the backend
dies?  Its 'record' in the proc table wouldn't be removed, which would be
like having our own internal 'process zombies'...

	I think this does bear further discussion though...one 'branch' of
this would be to have a dynamic table for 'live' processes, but also one
that contains a history of past ones...?

	
Marc G. Fournier                                
Systems Administrator @ hub.org 
primary: scrappy(at)hub(dot)org           secondary: scrappy(at){freebsd|postgresql}.org 


In response to

Responses

pgsql-hackers by date

Next:From: The Hermit HackerDate: 1998-06-03 21:46:02
Subject: Re: [HACKERS] keeping track of connections
Previous:From: The Hermit HackerDate: 1998-06-03 21:26:46
Subject: Re: [HACKERS] Current sources?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group