The following bug has been logged online:
Bug reference: 3855
Logged by: Scot Loach
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: freebsd 6.1
Description:backend sends corrupted data on EHOSTDOWN error
Details:
On FreeBSD, it is possib
The following bug has been logged online:
Bug reference: 3856
Logged by:
Email address: [EMAIL PROTECTED]
PostgreSQL version: ALL
Operating system: Windows 2003 sp2
Description:faile to run initdb:1!
Details:
Below is my initdb.log:
" The files belonging to this da
Thanks a lot Stefan. You are right.
Thanks for your support.
Diego Spano
-Mensaje original-
De: Stefan Kaltenbrunner [mailto:[EMAIL PROTECTED]
Enviado el: Lunes, 07 de Enero de 2008 04:03 p.m.
Para: Diego Spano
CC: pgsql-bugs@postgresql.org
Asunto: Re: [BUGS] BUG #3850: Incompatibil
The following bug has been logged online:
Bug reference: 3857
Logged by: Jochen Schwarz
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.6
Operating system: Windows and Linux
Description:pg_restore -t tablename doesn't restore constraints of
this table
Details
"Scot Loach" <[EMAIL PROTECTED]> writes:
> On FreeBSD, it is possible for a send() call on the backend socket to return
> an error code of EHOSTDOWN.
That's fine as long as the error condition is reasonably persistent.
I think what you are describing is a bug in FreeBSD's TCP stack: it
obviously i
On Tue, 2008-01-08 at 01:50 +, Scot Loach wrote:
> The following bug has been logged online:
>
> Bug reference: 3855
> Logged by: Scot Loach
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.2.4
> Operating system: freebsd 6.1
> Description:backend sends c
This may be true, but I still think PostgreSQL should be more defensive
and actively terminate the connection when this happens (like ssh does)
scot.
-Original Message-
From: Jeff Davis [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 08, 2008 12:52 PM
To: Scot Loach
Cc: pgsql-bugs@pos
I agree this would be fine if PostgreSQL works the way you say below.
However, PostgreSQL does not look at the # of bytes written and continue
sending after that many bytes. PostgreSQL actually simply clears its
buffer of bytes to send on this error, in this code:
pqcomm.c:1075
/*
On Tue, 2008-01-08 at 12:57 -0500, Scot Loach wrote:
> This may be true, but I still think PostgreSQL should be more defensive
> and actively terminate the connection when this happens (like ssh does)
I think postgresql's behavior is well within reason. Let me explain:
What is happening is that F
On Tue, 2008-01-08 at 14:06 -0500, Scot Loach wrote:
> I agree this would be fine if PostgreSQL works the way you say below.
>
> However, PostgreSQL does not look at the # of bytes written and continue
> sending after that many bytes. PostgreSQL actually simply clears its
> buffer of bytes to sen
Yes that is what I am trying to explain.
So I think this is still a bug that should be fixed in the backend code.
scot.
-Original Message-
From: Jeff Davis [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 08, 2008 2:40 PM
To: Scot Loach
Cc: pgsql-bugs@postgresql.org
Subject: RE: [BUGS]
The following bug has been logged online:
Bug reference: 3858
Logged by: Faisal N. Jawdat
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: Mac OS X
Description:psql hangs if called as postgres is coming online
Details:
If I use psql on a
Faisal N. Jawdat wrote:
> If I use psql on a local database while the daemon is coming online, psql
> hangs and most be killed. Subsequent psql processes will connect without
> incident.
This is strange. When the postmaster is not ready to receive
connections, psql is supposed to die with an er
(gdb) backtrace
#0 0x91542152 in poll$UNIX2003 ()
#1 0x0004867a in pqSocketCheck ()
#2 0x00048a41 in pqWaitTimed ()
#3 0x00042cbc in connectDBComplete ()
#4 0x00044b02 in PQsetdbLogin ()
#5 0xd30f in main ()
-faisal
On Jan 8, 2008, at 6:34 PM, Alvaro Herrera wrote:
Faisal N. Jawdat
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Can you get a backtrace of the hung psql process?
strace'ing it up to the point of the hang might be informative too.
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/
Faisal N. Jawdat wrote:
> Using a Mac, so no strace. dtruss of any use?
Sure.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
---(end of broadcast)---
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Faisal N. Jawdat wrote:
>> Using a Mac, so no strace. dtruss of any use?
> Sure.
Or ktrace, which seems standard on my Macs whereas I don't see dtruss.
Take your pick, we just want to see the sequence of kernel calls ...
regar
17 matches
Mail list logo
