To,
the respective authority
pgadmin
Sub: to report a bug in posgresql version 1.10.2 (Aug 24 2010, rev 8217)
This to inform you that we are using posgre sql (pgadmin) version mentioned
above. We are using pgadmin to log on to a lnux server with the client
applicaions on our lab systems.
It has
The following bug has been logged online:
Bug reference: 5847
Logged by: Vijayakumar
Email address: mails4vijayaku...@gmail.com
PostgreSQL version: 8.2
Operating system: windows
Description:pg_restore: [archiver (db)] COPY failed: ERROR: invalid
byte sequence for enc
"David E. Wheeler" writes:
> Oh. I've probably complained to them myself. First noticed it quite some time
> ago. Anyone got a test case that doesn't involve building PostgreSQL?
Per the prior discussion, all you need is an example where there are
exactly 9 + 10*N (N>=0) possible completions. I
On Jan 24, 2011, at 3:49 PM, Tom Lane wrote:
> This has been reported before, most recently last week. It's a libedit
> bug (and yes it's been reported to Apple, but another complaint directed
> there wouldn't hurt).
Oh. I've probably complained to them myself. First noticed it quite some time
"David E. Wheeler" writes:
> try=# \d mls_fepsql(69838) malloc: *** error for object 0x6: pointer being
> freed was not allocated
> *** set a breakpoint in malloc_error_break to debug
> zsh: abort psql corp_schema
This has been reported before, most recently last week. It's a libedit
bug (a
The following bug has been logged online:
Bug reference: 5846
Logged by: David E. Wheeler
Email address: da...@kineticode.com
PostgreSQL version: 9.0.1
Operating system: Mac OS X 10.6.6
Description:Segfault Postgresql Built with --lib-libedit-preferred
Details:
Been
The following bug has been logged online:
Bug reference: 5845
Logged by: Kasia Tuszynska
Email address: ktuszyn...@esri.com
PostgreSQL version: 9.0.2
Operating system: Windows 2008 R2 (64bit)
Description:Postgres does not seem to handle unquoted upper cased
object ide
> -Original Message-
> From: Kevin Grittner [mailto:kevin.gritt...@wicourts.gov]
> Sent: Monday, January 24, 2011 10:47 AM
> To: Murray S. Kucherawy; Tom Lane
> Cc: Robert Haas; pgsql-bugs@postgresql.org
> Subject: RE: [BUGS] BUG #5837: PQstatus() fails to report lost connection
>
> A patc
"Murray S. Kucherawy" wrote:
> From: Kevin Grittner [mailto:kevin.gritt...@wicourts.gov]
>> What do you think would make this more clear?
> So maybe something like this after the paragraph you cited would
> help:
>
> "Note that after returning a PGresult object, PQresultStatus()
> could indic
> -Original Message-
> From: Kevin Grittner [mailto:kevin.gritt...@wicourts.gov]
> Sent: Monday, January 24, 2011 9:50 AM
> To: Murray S. Kucherawy; Tom Lane
> Cc: Robert Haas; pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] BUG #5837: PQstatus() fails to report lost connection
>
> "Murray
> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Sent: Monday, January 24, 2011 9:42 AM
> To: Murray S. Kucherawy
> Cc: Robert Haas; pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] BUG #5837: PQstatus() fails to report lost connection
>
> >> This is complete nonsense. I
"Murray S. Kucherawy" wrote:
> Please, at a minimum, add some documentation about it.
Current documentation at:
http://www.postgresql.org/docs/9.0/interactive/libpq-async.html
says:
| PQgetResult must be called repeatedly until it returns a null
| pointer, indicating that the command is
"Murray S. Kucherawy" writes:
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
>> This is complete nonsense. If you followed the documented method for
>> using PQgetResult -- ie, keep calling it till it returns NULL, rather
>> than assuming there will be a specific number of results --- then
>> PQsta
> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Sent: Monday, January 24, 2011 7:30 AM
> To: Murray S. Kucherawy
> Cc: Robert Haas; pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] BUG #5837: PQstatus() fails to report lost connection
>
> "Murray S. Kucherawy" writes:
>
"Murray S. Kucherawy" writes:
> Given what you say here, this seems to be an exception for which there
> is currently no detection mechanism short of looking for that one
> specific error string indicating it was administrative action causing
> the error.
This is complete nonsense. If you follow
Robert Haas writes:
> On Sat, Jan 22, 2011 at 10:44 PM, Tom Lane wrote:
>> What did you do exactly? testlibpq.c just uses PQexec(), and AFAICS the
>> connection status does end up BAD if the backend is terminated before a
>> PQexec starts.
> PFA.
Yeah, that was my first cut at it too, but it's
On Mon, Jan 24, 2011 at 12:59 AM, Murray S. Kucherawy
wrote:
> Well my other suggestion would be to assume PGRES_FATAL_ERROR always means
> the connection needs to be reset. But this blows that idea away; this would
> cause a connection reset that wouldn't actually solve the problem when it's
The following bug has been logged online:
Bug reference: 5844
Logged by: Darshana
Email address: darsh...@returnpool.com
PostgreSQL version: 9.0
Operating system: Ubuntu 10.10
Description:maverick
Details:
When I open pgadmin3 and click on right pane of the interfac
> -Original Message-
> From: Robert Haas [mailto:robertmh...@gmail.com]
> Sent: Sunday, January 23, 2011 8:59 PM
> To: Murray S. Kucherawy
> Cc: Tom Lane; pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] BUG #5837: PQstatus() fails to report lost connection
>
> > As for the reply above, I d
> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Sent: Saturday, January 22, 2011 7:44 PM
> To: Robert Haas
> Cc: Murray S. Kucherawy; pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] BUG #5837: PQstatus() fails to report lost connection
>
> Robert Haas writes:
> > On Th
20 matches
Mail list logo
