"Peter Koczan" <[EMAIL PROTECTED]> writes:
> This app uses Perl/DBD::Pg, and the code is basically:
> while ($dbh->func('pg_notifies')) {
> # do stuff
> }
If I'm not mistaken, that loop would process all the currently available
notify messages and then fall out. So the real question is what's
Either it's not reading the notifies or it's not telling the server that
it's read them and flushing out the pipe.
This app uses Perl/DBD::Pg, and the code is basically:
while ($dbh->func('pg_notifies')) {
# do stuff
}
The corresponding C code in DBD::Pg appears to be:
/* =
The following bug has been logged online:
Bug reference: 3507
Logged by: alan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: XP Professional
Description:pgxml.dll not work in V8.2.4
Details:
My OS is XP Professional
I complier and gene
"Peter Koczan" <[EMAIL PROTECTED]> writes:
> A quick perusal of the other "notify interrupt" connections shows 13032 in
> the Send-Q column. They all got into this state at the same time.
That's far too much data to be a notify message, or even a small number
of notify messages. Is it possible th
It looks to me that the server is trying to send stuff to the client,
but the client is not reading it for some reason. There's nothing in the
queues in the direction client->server.
What exactly is the client doing? How does it connect to the server,
with libpq? Is it possible that the client is
Whoops, a couple quick changes. This:
[EMAIL PROTECTED] koczan $ ssh newton netstat | grep vero
tcp64260 0 newton.cs.wisc.edu:32778
vero.cs.wisc.edu:postgresqlESTABLISHED
tcp0 0 newton.cs.wisc.edu:32777
vero.cs.wisc.edu:postgresqlESTABLISHED
should be this:
[EMAIL PROTECTED]
I found something pretty interesting when running netstat's:
Before a series of 3 async notifies (second column is Recv-Q):
OK connections:
[EMAIL PROTECTED] koczan $ netstat | grep vero
tcp 180 0 ator.cs.wisc.edu:32785
vero.cs.wisc.edu:postgresqlESTABLISHED
tcp0 0 ator.cs.
Laurent Martelli wrote:
> to_number('123.0','99') returns 1230, at least on version 7.4 and 8.1. I
> think it should return 123 or raise an error.
to_number will silently ignore any character that doesn't match the
pattern. That can be confusing, and not generally a very bright idea in
applica
Peter Koczan <[EMAIL PROTECTED]> writes:
> Heikki Linnakangas wrote:
>> Does the client read the async notifies? The write in the server will
>> block if the client doesn't keep up with reading the data.
>>
> Well, the client updates it's GUI properly no matter whether the
> listening session is
Tom Lane wrote:
1Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Peter Koczan wrote:
There is a problem where connections listening for asynchronous notifies
occasionally block for writing on ther server side and never finish,
Does the client read the async notifies? The wri
Heikki Linnakangas wrote:
Peter Koczan wrote:
There is a problem where connections listening for asynchronous notifies
occasionally block for writing on ther server side and never finish,
resulting in connections that always have the status "notify interrupt".
Apparently, this causes no ill e
1Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Peter Koczan wrote:
>> There is a problem where connections listening for asynchronous notifies
>> occasionally block for writing on ther server side and never finish,
> Does the client read the async notifies? The write in the server will
> block
The following bug has been logged online:
Bug reference: 3506
Logged by: Laurent Martelli
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4,8.1
Operating system: 7.4->Linux, 8.1->Windows
Description:to_number silently ignore characters
Details:
to_number('123
Peter Koczan wrote:
> There is a problem where connections listening for asynchronous notifies
> occasionally block for writing on ther server side and never finish,
> resulting in connections that always have the status "notify interrupt".
> Apparently, this causes no ill effects for the applicati
The following bug has been logged online:
Bug reference: 3504
Logged by: Peter Koczan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: CentOS 4.5 Linux (RHEL 4), kernel 2.6.9-55.ELsmp
Description:Some listening sessions never return from wr
15 matches
Mail list logo
