Re: ALTER TABLE lock strength reduction patch is unsafe

On Tue, Mar 4, 2014 at 10:20 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:

> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> > Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > > I don't have too much of an issue with the above, but I would like to
> > > have us figure out a solution to the deadlock problem with parallel
> > > pg_dump. The issue arises when pg_dump gets an AccessShareLock and
> then
> > > another process attempts to acquire an AccessExclusiveLock, which then
> > > blocks, and then the pg_dump worker process tries to get its
> > > AccessShareLock- we end up not being able to make any progress on
> > > anything at that point.
> >
> > The original ASL was acquired by the pg_dump master, right?
>
> Yup. It goes through and gets ASLs on everything first.
>
> > > One suggestion that was discussed at PGConf.EU was having processes
> > > which share the same snapshot (the pg_dump master and worker processes)
> > > able to either share the same locks or at least be able to "jump" the
> > > lock queue (that is, the worker process wouldn't have to wait being the
> > > AEL to get an ASL, since the ASL was already aquired for the snapshot
> > > which was exported and shared with it).
> >
> > Yeah, it seems like we need lock export not only snapshot export to make
> > this work nicely. But that sounds orthogonal to the issues being
> > discussed in this thread.
>
> Indeed, just figured I'd mention it since we're talking about
> pg_dump-related locking.
>
>
What happens for foreign key constraints? For pg_dump, do we lock the
tables referenced by the table which is being dumped right now? If that is
the case, wouldnt MVCC based approach be the best way for this?

Please ignore if I said anything silly. I am just trying to understand how
it works here.

Regards,

Atri