Re: Logical decoding & exported base snapshot
От | Robert Haas |
---|---|
Тема | Re: Logical decoding & exported base snapshot |
Дата | |
Msg-id | CA+TgmoZi_12sDW7vLcaFzHcASaQfYJvvJCbL45ASX=_1BX-Dkw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Logical decoding & exported base snapshot (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Logical decoding & exported base snapshot
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: