On Thu, Dec 13, 2012 at 5:25 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> That would solve the consistency problem, yes. Would we need a special
> kind of permission for this? I would say superuser/database owner only?
Yeah, I doubt we would need a whole new permission for it, but it
would certainly have to be disallowed for ordinary users.
> It should actually even work for standbys in contrast to my FOR SHARE
> hack idea as we could "just" make it conflict with the exclusive locks
> logged into the WAL.
>
> I don't think that it will against the too-many-locks problem itself
> though, unless we play some additional tricks. The locks will be
> acquired later when the tables are dumped anyway. Now, given the
> snapshot import/export feature we actually could dump them table by
> table in a single transaction, but thats a bit more complicated.
Well, I was thinking that if a transaction already had the
no-DDL-on-nontemp-objects lock then perhaps we could optimize away
AccessShareLocks on individual relations. Of course that would rely
on the global lock being an adequate substitute for all cases where an
AccessShareLock would otherwise be needed. Not sure how feasible that
is. But it would be really cool.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company