
Enybody knows as to receive the information
about the users transmitting inquiries as:
- username,
- string of sql-request, transmitted by him.

Thank you for your answer.
 


Mon, 6 Jul 1998 12:49:34 +0300 (EEST)
Alexzander Blashko <black@lins.ospu.odessa.ua>
Information about user`s procces:username and his sql-request?
> 
> Enybody knows as to receive the information
> about the users transmitting inquiries as:
> - username,
> - string of sql-request, transmitted by him.
> 
> Thank you for your answer.
>  
> 
> 
> 

Not sure if that shows the username too.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Mon, 6 Jul 1998 05:57:05 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Information about user`s procces:username and his
	sql-request?
Hi all.

As nobody answered my previous post, I decided to correct PostgreSQL
buffer leaks caused by large objects methods. 

Theses buffer leaks are caused by indexes that are kept open between
calls. Outside a transaction, the backend detects them as buffer leaks; it
sends a NOTICE, and frees them. This sometimes cause a segmentation fault
(at least on Linux). These indexes are initialized on the first
lo_read/lo_write/lo_tell call, and (normally) closed on a lo_close call.
Thus the buffer leaks appear when lo direct access functions are used, and
not with lo_import/lo_export functions (libpq version calls lo_close
before ending the command, and the backend version uses another path).

The included patches (against recent snapshot, and against 6.3.2) cause
indexes to be closed on transaction end (that is on explicit 'END'
statment, or on command termination outside trasaction blocks), thus
preventing the buffer leaks while increasing performance inside
transactions. Some (all?) 'classic' memory leaks are also removed.
 
I hope it will be ok.
 
---
Pascal ANDRE, graduated from Ecole Centrale Paris
andre@via.ecp.fr
"Use the source, Luke. Be one with the Code."  -- Linus Torvalds
Mon, 20 Jul 1998 11:30:41 +0200 (MEST)
<andre@via.ecp.fr>
Large Objects buffer leak patch(es)
Patch applied.

> 
> 	Hi all.
> 
> As nobody answered my previous post, I decided to correct PostgreSQL
> buffer leaks caused by large objects methods. 
> 
> Theses buffer leaks are caused by indexes that are kept open between
> calls. Outside a transaction, the backend detects them as buffer leaks; it
> sends a NOTICE, and frees them. This sometimes cause a segmentation fault
> (at least on Linux). These indexes are initialized on the first
> lo_read/lo_write/lo_tell call, and (normally) closed on a lo_close call.
> Thus the buffer leaks appear when lo direct access functions are used, and
> not with lo_import/lo_export functions (libpq version calls lo_close
> before ending the command, and the backend version uses another path).
> 
> The included patches (against recent snapshot, and against 6.3.2) cause
> indexes to be closed on transaction end (that is on explicit 'END'
> statment, or on command termination outside trasaction blocks), thus
> preventing the buffer leaks while increasing performance inside
> transactions. Some (all?) 'classic' memory leaks are also removed.
>  
> I hope it will be ok.


-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Tue, 21 Jul 1998 00:17:49 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: Large Objects buffer leak patch(es)