Re: Potential bug in pg_dump ... - Mailing list pgsql-hackers

From Brent Verner
Subject Re: Potential bug in pg_dump ...
Date
Msg-id 20020110001934.GA3789@rcfile.org
Whole thread Raw
In response to Re: Potential bug in pg_dump ...  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Potential bug in pg_dump ...  (Brent Verner <brent@rcfile.org>)
List pgsql-hackers
[2002-01-09 18:55] Tom Lane said:
| Brent Verner <brent@rcfile.org> writes:
| > [2001-12-17 17:06] Tom Lane said:
| > | A possible (partial) solution is for pg_dump to obtain a read-lock on
| > | every table in the database as soon as it sees the table mentioned in
| > | pg_class, rather than waiting till it's ready to read the contents of
| > | the table.  However this cure might be worse than the disease,
| > | particularly for people running "pg_dump -t table".
| 
| > How would this lock-when-seen approach cause problems with '-t'?
| 
| Locking the whole DB when you only want to dump one table might be seen
| as a denial of service.  Also, consider the possibility that you don't
| have the right to lock every table in the DB.
| 
| If we can arrange to lock only those tables that will end up getting
| dumped, then these problems go away.  I have not looked to see if that's
| a difficult change or not.

We can try to lock one or lock all very easily.  An ACCESS SHARE
lock is granted to the user having SELECT privs, if they don't have
SELECT privs, they'll not have much luck dumping data anyway.

thanks. brent


-- 
"Develop your talent, man, and leave the world something. Records are 
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing."  -- Duane Allman


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Potential bug in pg_dump ...
Next
From: Tom Lane
Date:
Subject: Increasing checkpoint distance helps 7.2 noticeably