On Thu, Mar 20, 2025 at 2:09 PM Antonin Houska <a...@cybertec.at> wrote: > Robert Haas <robertmh...@gmail.com> wrote: > > Is there a README or a long comment in here someplace that is a good > > place to read to understand the overall design of this feature? > > I tried to explain how it works in the commit messages. The one in 0004 is > probably the most important one.
Thanks. A couple of comments/questions: - I don't understand why this commit message seems to think that we can't acquire a stronger lock while already holding a weaker one. We can do that, and in some cases we do precisely that. Such locking patterns can result in deadlock e.g. if I take AccessShareLock and you take AccessShareLock and then I tried to upgrade to AccessExclusiveLock and then you try to upgrade to AccessExclusiveLock, somebody is going to have to ERROR out. But that doesn't keep us from doing that in some places where it seems better than the alternatives, and the alternative chosen by the patch (possibly discovering at the very end that all our work has been in vain) does not seem better than risking a deadlock. - On what basis do you make the statement in the last paragraph that the decoding-related lag should not exceed one WAL segment? I guess logical decoding probably keeps up pretty well most of the time but this seems like a very strong guarantee for something I didn't know we had any kind of guarantee about. - What happens if we crash? -- Robert Haas EDB: http://www.enterprisedb.com
