Re: Unnecessary delay in streaming replication due to replay lag

lchch1990@sina.cn

From: "lchch1990@sina.cn" <lchch1990@sina.cn>

To: "Asim Praveen" <pasim@vmware.com>, "Masahiko Sawada" <masahiko.sawada@2ndquadrant.com>

Cc: pgsql-hackers <pgsql-hackers@postgresql.org>, michael <michael@paquier.xyz>, "Hao Wu (Pivotal)" <hawu@pivotal.io>, ahsan.hadi <ahsan.hadi@highgo.ca>

Date: 2020-09-15T09:30:22Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Generate GUC tables from .dat file
- 63599896545c 19 (unreleased) cited
Skip WAL recycling and preallocation during archive recovery.
- cc2c7d65fc27 15.0 cited
Fix scenario where streaming standby gets stuck at a continuation record.
- 066871980183 11.0 cited

Hello

I read the code and test the patch, it run well on my side, and I have several issues on the
patch.

1. When call RequestXLogStreaming() during replay, you pick timeline straightly from control
file, do you think it should pick timeline from timeline history file?

2. In archive recovery mode which will never turn to a stream mode, I think in current code it
will call RequestXLogStreaming() too which can avoid.

3. I found two 018_xxxxx.pl when I do make check, maybe rename the new one?




Regards,
Highgo Software (Canada/China/Pakistan) 
URL : www.highgo.ca 
EMAIL: mailto:movead(dot)li(at)highgo(dot)ca