On Thu, May 5, 2016 at 5:35 AM, Stephen Frost <sfr...@snowman.net> wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote: > > Stephen Frost <sfr...@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) Tom suggestion for adding DUMP_COMPONENTS_REQUIRING_TABLE_LOCK is the nice way to fix this issue. > Thanks! > > Stephen > -- Rushabh Lathia www.EnterpriseDB.com
