Re: Potential bug in pg_dump ...

From: Brent Verner <brent(at)rcfile(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Philip Warner <pjw(at)rhyme(dot)com(dot)au>, "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Potential bug in pg_dump ...
Date: 2002-01-10 00:19:34
Message-ID: 20020110001934.GA3789@rcfile.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

[2002-01-09 18:55] Tom Lane said:
| Brent Verner <brent(at)rcfile(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Elliot Lee 2002-01-10 01:37:52 postgresql-7.2b3-betterquote.patch
Previous Message Tom Lane 2002-01-09 23:55:46 Re: Potential bug in pg_dump ...