I mean that all resources protected by XLOG_STANDBY_LOCK should redo later. The semantics of XLOG_STANDBY_LOCK is still kept.
> 2020年4月30日 下午7:12，Amit Kapila <amit.kapil...@gmail.com> 写道： > > On Thu, Apr 30, 2020 at 4:07 PM 邱宇航 <iam...@gmail.com> wrote: >> >> I noticed that in hot standby, XLOG_STANDBY_LOCK redo is sometimes block by >> another query, and all the rest redo is blocked by this lock getting >> operation, which is not good and often happed in my database, so the hot >> standby will be left behind and master will store a lot of WAL which can’t >> be purged. >> >> So here is the idea: >> We can do XLOG_STANDBY_LOCK redo asynchronously, and the rest redo will >> continue. >> > > Hmm, I don't think we can do this. The XLOG_STANDBY_LOCK WAL is used > for AccessExclusiveLock on a Relation which means it is a lock for a > DDL operation. If you skip processing the WAL for this lock, the > behavior of queries running on standby will be unpredictable. > Consider a case where on the master, the user has dropped the table > <t1> and when it will replay such an operation on standby the > concurrent queries on t1 will be blocked due to replay of > XLOG_STANDBY_LOCK WAL and if you skip that WAL, the drop of table and > query on the same table can happen simultaneously leading to > unpredictable behavior. > > -- > With Regards, > Amit Kapila. > EnterpriseDB: http://www.enterprisedb.com
