On Tuesday 01 May 2007 2:46 pm, Ed L. wrote:
> It is indeed a local connection using PGHOST=`hostname`. That
> name maps to one of the external NIC IPs, not to the normal
> 127.0.0.1 loopback address. For context, I've seen this a
> number of times over the past couple years, from pgsql 7.3.x
> t
On Tuesday 01 May 2007 2:23 pm, Tom Lane wrote:
> Well, it's going wrong here:
>
> socket(AF_INET, SOCK_STREAM, 0) .. = 4
> setsockopt(4, 0x6, TCP_NODELAY, 0x9fffe210, 4) ... = 0
> fcntl(4, F_SETFL, 65536) . = 0
> fcntl(4, F_SETFD, 1)
"Ed L." <[EMAIL PROTECTED]> writes:
> Attached is a small tar.gz file containing a short perl DBI
> connection script that repeatedly demonstrates this problem.
> There are also two log files containing tusc output (an HP
> syscall trace utility), one for the 32-bit run (which works) and
> ano
On Thursday 26 April 2007 9:42 am, Tom Lane wrote:
> "Ed L." <[EMAIL PROTECTED]> writes:
> > After a reboot (and usually after an OS patch) on our HP-UX
> > 11.23 64-bit Itanium DB servers, our libpq/DBD::Pg libraries
> > cease to work. Instead, they give the standard message you
> > get when the
"Ed L." <[EMAIL PROTECTED]> writes:
> After a reboot (and usually after an OS patch) on our HP-UX 11.23
> 64-bit Itanium DB servers, our libpq/DBD::Pg libraries cease to
> work. Instead, they give the standard message you get when the
> DB cluster is not running.
Try ktrace'ing the client to s
On Thursday 26 April 2007 8:50 am, Ed L. wrote:
> After a reboot (and usually after an OS patch) on our HP-UX
> 11.23 64-bit Itanium DB servers, our libpq/DBD::Pg libraries
> cease to work. Instead, they give the standard message you
> get when the DB cluster is not running. But we *know* it is
>
After a reboot (and usually after an OS patch) on our HP-UX 11.23
64-bit Itanium DB servers, our libpq/DBD::Pg libraries cease to
work. Instead, they give the standard message you get when the
DB cluster is not running. But we *know* it is running and all
access paths are working. We have f
