"Tom Lane" <tgl@sss.pgh.pa.us> 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