Re: Optimization for hot standby XLOG_STANDBY_LOCK redo

Поиск
Список
Период
Сортировка
От 邱宇航
Тема Re: Optimization for hot standby XLOG_STANDBY_LOCK redo
Дата
Msg-id 14878CE9-D0DF-4B8F-ACF5-59514E3D2CAE@gmail.com
обсуждение исходный текст
Ответ на Re: Optimization for hot standby XLOG_STANDBY_LOCK redo  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Optimization for hot standby XLOG_STANDBY_LOCK redo  (邱宇航 <iamqyh@gmail.com>)
Список pgsql-hackers
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.kapila16@gmail.com> 写道:

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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ranier Vilela
Дата:
Сообщение: Re: Unify drop-by-OID functions
Следующее
От: 邱宇航
Дата:
Сообщение: Re: Optimization for hot standby XLOG_STANDBY_LOCK redo