[2002-01-09 19:19] Brent Verner said:
| [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.
Attached is a patch that implements table locking for pg_dump.
If a tablename is specified with '-t tablename', only that table will
be locked; otherwise, all tables will be locked. Locks are with
ACCESS SHARE to block only concurrent AccessExclusiveLock operations
on the table.
comments?
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