"Tom Lane" <[EMAIL PROTECTED]> writes: > 2. WAL-reading process receives and executes DROP TABLE X. > > (It doesn't even have to be a DROP; most varieties of ALTER are enough > to create problems for a concurrently-running query.) > > It's really hard to see how to defend against that without a fairly > complete simulation of locking on the slave side.
Well, it's not hard to see ways to do it. It may be hard to see *good* ways to do it. In the limit you can just block WAL replay of such records (I think vacuum page defragmenting is also in this category) until there are no queries running. This means a single long-running query can block log replay for a long time though. There's an additional problem from commands like create index concurrently and vacuum's deleting of dead tuples which aren't safe to execute if there are any standby queries running unless we can prove they're not "too old". CLUSTER and most varieties of ALTER suffer from this problem as well. It does seem like the shortest path solution is just to get things working first with a "one big lock" implementation and then work on refining it after that. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
