Yes, please --- the patch is at:
http://archives.postgresql.org/pgsql-patches/2005-06/msg00486.php
---
Tom Lane wrote:
> "Karsten Desler" <[EMAIL PROTECTED]> writes:
> > I've got a pretty flaky tcpip connection to a
"Karsten Desler" <[EMAIL PROTECTED]> writes:
> I've got a pretty flaky tcpip connection to a Postgres 7.4.7 database server
> and often times (once or twice a day) my program gets stuck in an endless
> busy-loop in PGconnectdb.
Hmm. Maybe you have a test case for the proposed patch for bug #1467?
The following bug has been logged online:
Bug reference: 1736
Logged by: Karsten Desler
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.7
Operating system: debian sarge
Description:endless loop in PQconnectdb
Details:
I've got a pretty flaky tcpip connectio
Tom Lane wrote:
"Bobi Ivanov" <[EMAIL PROTECTED]> writes:
Thank you for your quick responce! I don't call them directly. I use pgsql
8.0.3 under
Fedora Core and I'm writing queries through pgAdminIII.
I would say then that this is a pgAdmin bug, and should be reported on
the pgAdmin mailing
"3";"12";"0";"7 days
is the result I'm getting in pgadmin.
Regards,
Andreas
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
"Bobi Ivanov" <[EMAIL PROTECTED]> writes:
> Thank you for your quick responce! I don't call them directly. I use pgsql
> 8.0.3 under
> Fedora Core and I'm writing queries through pgAdminIII.
I would say then that this is a pgAdmin bug, and should be reported on
the pgAdmin mailing lists --- I'm
Please see the FAQ and the archives of the mailing lists. This has come
up before. It's permissions issues on your D: drive or subdirectories.
//Magnus
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Paolo Petranzan
> Sent: Tuesday, June 28, 2005
Tom Lane wrote:
"Robert Grabowski" <[EMAIL PROTECTED]> writes:
I have problem with function visibility in transaction when I do create and
drop function.
System catalog lookups generally follow SnapshotNow rules, not MVCC.
So the new function definition is visible as soon as it's committed,
The following bug has been logged online:
Bug reference: 1734
Logged by: Paolo Petranzan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.3
Operating system: Windows 2000 Workstation SP4
Description:Can't install in D:\
Details:
I'm trying to install Postgre
The following bug has been logged online:
Bug reference: 1735
Logged by: Borislav Ivanov
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.3
Operating system: Fedora Core
Description:row number -1 is out of range 0..-1 error
Details:
I get this message 'row n
On Tue, Jun 28, 2005 at 04:07:33PM +0300, Bobi Ivanov wrote:
>
> Thank you for your quick responce! I don't call them directly. I use pgsql
> 8.0.3 under Fedora Core and I'm writing queries through pgAdminIII.
How consistently do you get the error? What happens if you run the
query in psql?
--
Thank you for your quick responce! I don't call them directly. I use pgsql
8.0.3 under
Fedora Core and I'm writing queries through pgAdminIII. This is the query
that produces it:
select
billingplans_freetalktime.id, billingplans_freetalktime.seconds,
billingplans_freetalktime.accumulate, bi
Dear Gurus,
As always, please point me to the right resource if this issue is already
addressed.
Version: 7.4.6, Debian "Woody" linux.
Source: max func args increased to 64, but I doubt it matters.
In a pl/pgsql function, called from an AFTER trigger, I receive this message:
ERROR: query
On Tue, Jun 28, 2005 at 03:11:03PM +0300, Bobi Ivanov wrote:
>
> I get this message 'row number -1 is out of range 0..-1' sometimes.
> I say sometimes, because this happens unexpected when I submit absolutely
> correct query. Query succeeds, but it returns no resul although there should
> be
I get this message 'row number
-1 is out of range 0..-1' sometimes.
I say sometimes, because this happens unexpected
when I submit absolutely
correct query. Query succeeds, but it returns no
resul although there should be.
Tom Lane wrote:
System catalog lookups generally follow SnapshotNow rules, not MVCC.
So the new function definition is visible as soon as it's committed,
whether you are in a serializable transaction or not.
IMHO this is a bug, or at least not optimal behavior. But per the
discussion on -hacke
16 matches
Mail list logo