Skip site navigation (1) Skip section navigation (2)

Re: Replication server timeout patch

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Replication server timeout patch
Date: 2011-03-29 04:55:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, Mar 28, 2011 at 7:49 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> pq_flush_if_writable() calls internal_flush() without using PG_TRY block.
>> This seems unsafe because for example pgwin32_waitforsinglesocket()
>> called by secure_write() can throw ERROR.
> Perhaps it's time to give up on the assumption that the socket is in
> blocking mode except within those two functions. Attached patch adds the
> pq_set_nonblocking() function from your patch, and adds calls to it before
> all secure_read/write operations to put the socket in the right mode.
> There's only a few of those operations.

Sounds good.

+		pq_set_nonblocking(false); /* XXX: Is this required? */

No. Since secure_close and close_SSL don't use MyProcPort->sock and
MyProcPort->noblock which can be changed in pq_set_nonblocking,
I don't think that is required.

+	pq_putmessage_noblock('d', msgbuf, 1 + sizeof(WalDataMessageHeader) + nbytes);

Don't we need to check the return value of pq_putmessage_noblock? That
can return EOF when trouble happens (for example the send system call fails).

> Should we use COMMERROR instead of ERROR if we fail to put the socket in the
> right mode?



Fujii Masao
NTT Open Source Software Center

In response to


pgsql-hackers by date

Next:From: Noah MischDate: 2011-03-29 05:38:38
Subject: deadlock_timeout at < PGC_SIGHUP?
Previous:From: Euler Taveira de OliveiraDate: 2011-03-29 04:10:52
Subject: Re: Open issues for collations

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group