postgresql socket读数据返回-1

发布时间 2023-12-27 11:23:50作者: lightdb

如下所示:

    {
        n = secure_raw_read(port, ptr, len);   // pg的socket读是非阻塞读,所以返回-1不影响,后面等到socket可读之后继续读。见下文socket返回值解释
        waitfor = WL_SOCKET_READABLE;
    }

    /* In blocking mode, wait until the socket is ready */
    if (n < 0 && !port->noblock && (errno == EWOULDBLOCK || errno == EAGAIN))   // 非阻塞读,且errono==EAGAIN,所以就是每次处理完一个SQL语句后,会继续读下一个SQL,发现读不到,进到这里,通过latch设置等待客户端可读事件
    {
        WaitEvent    event;

        Assert(waitfor);

        ModifyWaitEvent(FeBeWaitSet, 0, waitfor, NULL);

        WaitEventSetWait(FeBeWaitSet, -1 /* no timeout */ , &event, 1,
                         WAIT_EVENT_CLIENT_READ);

        /*
         * If the postmaster has died, it's not safe to continue running,
         * because it is the postmaster's job to kill us if some other backend
         * exits uncleanly.  Moreover, we won't run very well in this state;
         * helper processes like walwriter and the bgwriter will exit, so
         * performance may be poor.  Finally, if we don't exit, pg_ctl will be
         * unable to restart the postmaster without manual intervention, so no
         * new connections can be accepted.  Exiting clears the deck for a
         * postmaster restart.
         *
         * (Note that we only make this check when we would otherwise sleep on
         * our latch.  We might still continue running for a while if the
         * postmaster is killed in mid-query, or even through multiple queries
         * if we never have to wait for read.  We don't want to burn too many
         * cycles checking for this very rare condition, and this should cause
         * us to exit quickly in most cases.)
         */
        if (event.events & WL_POSTMASTER_DEATH)
            ereport(FATAL,
                    (errcode(ERRCODE_ADMIN_SHUTDOWN),
                     errmsg("terminating connection due to unexpected postmaster exit")));

        /* Handle interrupt. */
        if (event.events & WL_LATCH_SET)
        {
            ResetLatch(MyLatch);
            ProcessClientReadInterrupt(true);

            /*
             * We'll retry the read. Most likely it will return immediately
             * because there's still no data available, and we'll wait for the
             * socket to become ready again.
             */
        }
        goto retry;
    }

在调用socket读写函数read(),write()时,都会有返回值。如果没有正确处理返回值,就可能引入一些问题

总结了以下几点

1当read()或者write()函数返回值大于0时,表示实际从缓冲区读取或者写入的字节数目

2当read()函数返回值为0时,表示对端已经关闭了 socket,这时候也要关闭这个socket,否则会导致socket泄露。netstat命令查看下,如果有closewait状态的socket,就是socket泄露了

当write()函数返回0时,表示当前写缓冲区已满,是正常情况,下次再来写就行了。

3当read()或者write()返回-1时,一般要判断errno

如果errno == EINTR,表示系统当前中断了,直接忽略

如果errno == EAGAIN或者EWOULDBLOCK,非阻塞socket直接忽略;如果是阻塞的socket,一般是读写操作超时了,还未返回。这个超时是指socket的SO_RCVTIMEO与SO_SNDTIMEO两个属性。所以在使用阻塞socket时,不要将超时时间设置的过小。不然返回了-1,你也不知道是socket连接是真的断开了,还是正常的网络抖动。一般情况下,阻塞的socket返回了-1,都需要关闭重新连接。

4.另外,对于非阻塞的connect,可能返回-1.这时需要判断errno,如果 errno == EINPROGRESS,表示正在处理中,否则表示连接出错了,需要关闭重连。之后使用select,检测到该socket的可写事件时,要判断getsockopt(c->fd, SOL_SOCKET, SO_ERROR, &err, &errlen),看socket是否出错了。如果err值为0,则表示connect成功;否则也应该关闭重连

5 在使用epoll时,有ET与LT两种模式。ET模式下,socket需要read或者write到返回-1为止。对于非阻塞的socket没有问题,但是如果是阻塞的socket,正如第三条中所说的,只有超时才会返回。所以在ET模式下千万不要使用阻塞的socket。那么LT模式为什么没问题呢?一般情况下,使用LT模式,我们只要调用一次read或者write函数,如果没有读完或者没有写完,下次再来就是了。由于已经返回了可读或者可写事件,所以可以保证调用一次read或者write会正常返回。