On Sat, Mar 22, 2025 at 5:43 AM Antonin Houska <a...@cybertec.at> wrote: > Can you please give me an example? I don't recall seeing a lock upgrade in the > tree. That's the reason I tried rather hard to avoid that.
VACUUM has to upgrade the lock in order to truncate away pages at the end of the table. Or just: BEGIN; SELECT * FROM sometable; VACUUM FULL sometable; COMMIT; I don't think we should commit something that handles locking the way this patch does. I mean, it would be one thing if you had a strategy for avoiding erroring out when a deadlock would otherwise occur by doing something clever. But it seems like you would just need to detect the same problem in a different way. Doing something non-standard doesn't make sense unless we get a clear benefit from it. (Even then it might be unsafe, of course, but at least then you have a motivation to take the risk.) > > - 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. > > The patch itself does guarantee that by checking the amount of unprocessed WAL > regularly when it's copying the data into the new table. If too much WAL > appears to be unprocessed, it enforces the decoding before the copying is > resumed. Hmm. If the source table is not locked against writes, it seems like we could always get into a situation where this doesn't converge -- you just need to modify the table faster than those changes can be decoded and applied. Maybe that's different from what we're talking about here, though. > > - What happens if we crash? > > The replication slot we create is RS_TEMPORARY, so it disappears after > restart. Everything else is as if the current implementation of CLUSTER ends > due to crash. Cool. -- Robert Haas EDB: http://www.enterprisedb.com
