Re: pg_dump broken for non-super user
От | Rushabh Lathia |
---|---|
Тема | Re: pg_dump broken for non-super user |
Дата | |
Msg-id | CAGPqQf3kxxYpQJ-YGjpmVwM9opOqQJMWv63ya-h_sB30x6YmvQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_dump broken for non-super user (Stephen Frost <sfrost@snowman.net>) |
Список | pgsql-hackers |
On Thu, May 5, 2016 at 5:35 AM, Stephen Frost <sfrost@snowman.net> wrote:
+1
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > Attached patch implements this change to not LOCK the table in cases
> > where we don't need to. I'll push this with my other changes to pg_dump
> > tomorrow (and I've included it in an updated, complete, set of patches
> > sent on the thread where those changes were being discussed already).
>
> > Wanted to include it here also for completeness.
>
> > Comments welcome, of course.
>
> Minor suggestion: instead of putting these comments and hardwired
> knowledge here, I'd suggest putting them adjacent to the list of
> DUMP_COMPONENT #defines, creating a symbol along the lines of
> DUMP_COMPONENTS_REQUIRING_TABLE_LOCK. That approach would make it
> far more likely that somebody changing the list of DUMP_COMPONENT
> elements in future would notice the possible need to adjust the
> requires-lock list.
Good thought, I'll do that.
+1
I liked the new approach, initially when I was looking around code
,I also thought about why we need to hold lock on the object
which we are not interested in dumping. That is the reason
I suggested patch with adding check for DUMP_COMPONENT_DEFINITION
& DUMP_COMPONENT_DATA (but ofcourse that was not perfect)
& DUMP_COMPONENT_DATA (but ofcourse that was not perfect)
Tom suggestion for adding DUMP_COMPONENTS_REQUIRING_TABLE_LOCK
is the nice way to fix this issue.
Thanks!
Stephen
--
Rushabh Lathia
В списке pgsql-hackers по дате отправления: