[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-hackers
Subject:    Re: Optimization for hot standby XLOG_STANDBY_LOCK redo
From:       Amit Kapila <amit.kapila16 () gmail ! com>
Date:       2020-04-30 11:24:02
Message-ID: CAA4eK1JKAQxo1suRy6tTRjWTW=+yMpg5z7cR-7wtLAvGzYKHYg () mail ! gmail ! com
[Download RAW message or body]

On Thu, Apr 30, 2020 at 4:07 PM 邱宇航 <iamqyh@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


[prev in list] [next in list] [prev in thread] [next in thread]