Optimization for hot standby XLOG_STANDBY_LOCK redo

Поиск
Список
Период
Сортировка
От 邱宇航
Тема Optimization for hot standby XLOG_STANDBY_LOCK redo
Дата
Msg-id 2403B554-09D6-4006-9A1F-866E2E6BEF46@gmail.com
обсуждение исходный текст
Ответы Re: Optimization for hot standby XLOG_STANDBY_LOCK redo
Список pgsql-hackers
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.
And I wonder will LogStandbySnapshot influence the consistency in hot standby, for the redo is not by order. And how to avoid this.

// ------ startup ------
StartupXLOG()
{
    while (readRecord())
    {
        check_lock_get_state();
        if (record.tx is in pending tbl):
            append this record to the pending lock for further redo.
        redo_record();
    }
}

check_lock_get_state()
{
    for (tx in pending_tx):
        if (tx.all_lock are got):
             redo the rest record for this tx
             free this tx
}

standby_redo
{
    if (XLOG_STANDBY_LOCK redo falied)
    {
        add_lock_to_pending_tx_tbl();
    }
}

// 
------ worker process ------
main()
{
     while(true)
    {
        for (lock in pending locks order by lsn)
            try_to_get_lock_from_pending_tbl();
    }
}


regards.
Yuhang

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

Предыдущее
От: Sumanta Mukherjee
Дата:
Сообщение: Re: WIP/PoC for parallel backup
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: WIP/PoC for parallel backup