Re: 001_rep_changes.pl stalls
От | Fujii Masao |
---|---|
Тема | Re: 001_rep_changes.pl stalls |
Дата | |
Msg-id | 7492aa54-dabf-3791-cbc4-e653760a2288@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: 001_rep_changes.pl stalls (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: 001_rep_changes.pl stalls
|
Список | pgsql-hackers |
On 2020/04/20 16:02, Noah Misch wrote: > On Mon, Apr 20, 2020 at 02:30:08PM +0900, Fujii Masao wrote: >> + * Block if we have unsent data. XXX For logical replication, let >> + * WalSndWaitForWal(), handle any other blocking; idle receivers need >> + * its additional actions. For physical replication, also block if >> + * caught up; its send_data does not block. >> >> It might be better to s/WalSndWaitForWal()/send_data()? Because not only >> WalSndWaitForWal() but also WalSndWriteData() seems to handle the blocking. >> WalSndWriteData() is called also under send_data, i.e., XLogSendLogical(). > > Thanks for reviewing. WalSndWriteData() blocks when we have unsent data, > which is the same cause for blocking in WalSndLoop(). Since the comment you > quote says we let WalSndWaitForWal() "handle any other blocking", I don't > think your proposed change makes it more correct. I was misreading this as something like "any other blocking than the blocking in WalSndLoop()". Ok, I have no more comments on the patch. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления: