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

Detecting loss of client connection (was Re: Bug in walsender when calling out to do_pg_stop_backup (and others?))

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Cc: Greg Jaskiewicz <gj(at)pointblue(dot)com(dot)pl>, Florian Pflug <fgp(at)phlo(dot)org>, Magnus Hagander <magnus(at)hagander(dot)net>
Subject: Detecting loss of client connection (was Re: Bug in walsender when calling out to do_pg_stop_backup (and others?))
Date: 2011-12-05 08:53:40
Message-ID: 4EDC8694.2030709@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Thinking about this some more, why don't we just elog(FATAL) in 
internal_flush(), if the write fails, instead of setting the flag and 
waiting for the next CHECK_FOR_INTERRUPTS(). That sounds scary at first, 
but why not?

There's this comment in internal_flush():

> 			/*
> 			 * Careful: an ereport() that tries to write to the client would
> 			 * cause recursion to here, leading to stack overflow and core
> 			 * dump!  This message must go *only* to the postmaster log.

That's understandable.

> 			 * If a client disconnects while we're in the midst of output, we
> 			 * might write quite a bit of data before we get to a safe query
> 			 * abort point.  So, suppress duplicate log messages.

But what about this? Tracing back the callers, I don't see any that 
would be upset if we just threw an error there. One scary aspect is if 
you're within a critical section, but I don't think we currently send 
any messages while in a critical section. And we could refrain from 
throwing the error if we're in a critical section, to be safe.

> 			 */
> 			if (errno != last_reported_send_errno)
> 			{
> 				last_reported_send_errno = errno;
> 				ereport(COMMERROR,
> 						(errcode_for_socket_access(),
> 						 errmsg("could not send data to client: %m")));
> 			}

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

pgsql-hackers by date

Next:From: Daniel FarinaDate: 2011-12-05 09:56:19
Subject: Re: Notes on implementing URI syntax for libpq
Previous:From: Noah MischDate: 2011-12-05 07:09:20
Subject: Re: RangeVarGetRelid()

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