On Wed, Dec 16, 2009 at 7:07 PM, Tom Lane wrote:
> Chris Travers writes:
>> It looks like this could be added without a disruption to programmer
>> interfaces, but it seems like any major change in this area would
>> create binary compatibility issues (i.e. require recompile of linked
>> software
Chris Travers writes:
> It looks like this could be added without a disruption to programmer
> interfaces, but it seems like any major change in this area would
> create binary compatibility issues (i.e. require recompile of linked
> software). Is this correct in what you mean by API incompatibi
Just to be clear (before I consider attempting a patch maybe I can
hand off to someone else to double-check)...
On Wed, Dec 16, 2009 at 5:31 PM, Tom Lane wrote:
> Yeah. The problem is that the only infrastructure libpq has for returning
> individual error message fields (like the SQLSTATE) is a
On Wed, Dec 16, 2009 at 9:03 PM, Craig Ringer
wrote:
> On 16/12/2009 11:55 PM, Robert Haas wrote:
>>
>> On Wed, Dec 16, 2009 at 10:45 AM, Magnus Hagander
>> wrote:
>>>
>>> On Wed, Dec 16, 2009 at 16:12, Tom Lane wrote:
Alvaro Herrera writes:
>
> Alexey Luchko wrote:
>>
>>>
On 16/12/2009 11:55 PM, Robert Haas wrote:
On Wed, Dec 16, 2009 at 10:45 AM, Magnus Hagander wrote:
On Wed, Dec 16, 2009 at 16:12, Tom Lane wrote:
Alvaro Herrera writes:
Alexey Luchko wrote:
postgres.exe!mdpostckpt+0x181b38
postgres.exe!mdpostckpt+0x18bbdb
This stack trace seems bogus.
Chris Travers writes:
> 2) As of 8.1, tshark shows that the server does send the SQLSTATE to
> the client regarding why the login fails (for example 3D000 in the
> case of bad db name). Libpq as far as I can tell (from reading the
> code) doesn't do anything with this code. Certainly there seems
Hi Tom and everyone else;
After significant additional research this is what I have turned up:
1) The problem was a problem in DBD::Pg which didn't quite succeed in
setting the connection state to 08006. I have submitted a patch for
that to the DBD::Pg project.
2) As of 8.1, tshark shows that t
Philip Graham wrote:
The following bug has been logged online:
Bug reference: 5244
Logged by: Philip Graham
Email address: phi...@lightbox.org
PostgreSQL version: 8.3.8
Operating system: Linux
Description:Attempting to rollback to a savepoint after receiving an
error
On Wed, Dec 16, 2009 at 1:39 PM, Tom Lane wrote:
> Chris Travers writes:
>> trying again. Sorry for the duplicate.
>> On Wed, Dec 16, 2009 at 1:12 PM, Tom Lane wrote:
>>> Exactly what "frontend" are you talking about here? Because what this
>>> sounds like to me is a client-side programming er
On Mon, Dec 14, 2009 at 10:06 PM, Robert Haas wrote:
> On Mon, Dec 14, 2009 at 12:59 PM, Robert Haas wrote:
>>> The new explain formats break if you have a multi-query statement.
>> I will fix this, unless someone else beats me to it.
>
> Proposed patch attached. [...discussion...]
Hearing no o
Chris Travers writes:
> trying again. Sorry for the duplicate.
> On Wed, Dec 16, 2009 at 1:12 PM, Tom Lane wrote:
>> Exactly what "frontend" are you talking about here? Because what this
>> sounds like to me is a client-side programming error. It's certainly
>> not the backend's fault, and I d
trying again. Sorry for the duplicate.
On Wed, Dec 16, 2009 at 1:12 PM, Tom Lane wrote:
> "Chris Travers" writes:
>> I am noticing that that a failed database connection results in an unusable
>> SQLSTATE in libpq, and a very different SQLSTATE than the backend
>> registers.
>
>> For example, i
"Chris Travers" writes:
> I am noticing that that a failed database connection results in an unusable
> SQLSTATE in libpq, and a very different SQLSTATE than the backend
> registers.
> For example, if a connection fails due to a database not found, the backend
> registers 3D000 as a SQL state, bu
On Wed, Dec 16, 2009 at 17:43, Alexey Luchko wrote:
> On 16-12-2009 17:45, Magnus Hagander wrote:
>>
>> If that is so, the OP should follow:
>>
>> http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows
>>
>> specifically the part about symbols.
>>
>> Which
On Wed, Dec 16, 2009 at 12:35 PM, Kevin Grittner
wrote:
> "Chris Travers" wrote:
>
>> I am noticing that that a failed database connection results in an
>> unusable SQLSTATE in libpq, and a very different SQLSTATE than the
>> backend registers.
>
> Well, if the client fails to connect to the serv
"Chris Travers" wrote:
> I am noticing that that a failed database connection results in an
> unusable SQLSTATE in libpq, and a very different SQLSTATE than the
> backend registers.
Well, if the client fails to connect to the server, I'm not sure how
the server could communicate its SQLSTATE t
Robert Haas wrote:
On Mon, Dec 14, 2009 at 11:15 PM, Philip Graham wrote:
The following bug has been logged online:
Bug reference: 5244
Logged by: Philip Graham
Email address: phi...@lightbox.org
PostgreSQL version: 8.3.8
Operating system: Linux
Description:Atte
The following bug has been logged online:
Bug reference: 5246
Logged by: Chris Travers
Email address: chris.trav...@gmail.com
PostgreSQL version: 8.1.18
Operating system: Fedora Linux 12
Description:Misleading/inconsistent SQLSTATE behavior
Details:
Hi all;
I am no
On 16-12-2009 17:45, Magnus Hagander wrote:
If that is so, the OP should follow:
http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows
specifically the part about symbols.
Which it certainly looks like :)
How can I find the stats collector's process?
On Wed, Dec 16, 2009 at 11:05 AM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>
>> We should really take some of the vast quantity of really useful
>> information that is in the wiki and try to index it somehow or
>> incorporate it into the docs. I'm always learning about new pages
>> that have
Robert Haas escribió:
> We should really take some of the vast quantity of really useful
> information that is in the wiki and try to index it somehow or
> incorporate it into the docs. I'm always learning about new pages
> that have good stuff on them, but I never seem to stumble across them
> o
On Wed, Dec 16, 2009 at 10:45 AM, Magnus Hagander wrote:
> On Wed, Dec 16, 2009 at 16:12, Tom Lane wrote:
>> Alvaro Herrera writes:
>>> Alexey Luchko wrote:
postgres.exe!mdpostckpt+0x181b38
postgres.exe!mdpostckpt+0x18bbdb
>>
>>> This stack trace seems bogus. The stats collector shoul
On Wed, Dec 16, 2009 at 16:12, Tom Lane wrote:
> Alvaro Herrera writes:
>> Alexey Luchko wrote:
>>> postgres.exe!mdpostckpt+0x181b38
>>> postgres.exe!mdpostckpt+0x18bbdb
>
>> This stack trace seems bogus. The stats collector should not be calling
>> mdpostckpt at all.
>
> Given the size of the o
Alvaro Herrera writes:
> Alexey Luchko wrote:
>> postgres.exe!mdpostckpt+0x181b38
>> postgres.exe!mdpostckpt+0x18bbdb
> This stack trace seems bogus. The stats collector should not be calling
> mdpostckpt at all.
Given the size of the offsets, it's pretty clear that it's not actually
in mdpostc
On Tue, Dec 15, 2009 at 11:18 PM, Philip Graham wrote:
> Robert Haas wrote:
>>
>> On Mon, Dec 14, 2009 at 11:15 PM, Philip Graham
>> wrote:
>>
>>>
>>> The following bug has been logged online:
>>>
>>> Bug reference: 5244
>>> Logged by: Philip Graham
>>> Email address: phi...@li
On Wed, Dec 16, 2009 at 4:35 AM, Stefan Kaltenbrunner
wrote:
> updated the website with that wording - should be up on the next site
> reload.
Thanks!
...Robert
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailp
On 16-12-2009 16:28, Alvaro Herrera wrote:
Alexey Luchko wrote:
We've tried to restart the service. It was looking like the service
stopped successfully, but two postgres.exe processes left running.
One of them was utilizing one core. It had no tcp connections in any
state. It was
"C:/Program F
Alexey Luchko wrote:
> We've tried to restart the service. It was looking like the service
> stopped successfully, but two postgres.exe processes left running.
> One of them was utilizing one core. It had no tcp connections in any
> state. It was
> "C:/Program Files/PostgreSQL/8.4/bin/postgres.exe
Hi!
We've got the same issue with PostgreSQL 8.4.1 on 32 bit Windows 2003
Server RC2. Every minute the message "pgstat wait timeout" appears in Event
Viewer / Application Log.
We've tried to restart the service. It was looking like the service stopped
successfully, but two postgres.exe proce
Robert Haas wrote:
On Tue, Dec 15, 2009 at 2:42 PM, Alvaro Herrera
wrote:
"This bug report form can be used for reporting bugs and problems with
the PostgreSQL database, for problems with database connectors such as
ODBC and JDBC, graphical administration tools such as pgAdmin or other
external
30 matches
Mail list logo
