On Wed, Sep 14, 2011 at 10:52:50PM -0500, Robert Haas wrote:
> On Thu, Sep 8, 2011 at 5:09 AM, Peter Eisentraut wrote:
> > On tis, 2011-09-06 at 17:12 +0200, hubert depesz lubaczewski wrote:
> >> On Mon, Sep 05, 2011 at 02:27:23PM -0400, Tom Lane wrote:
> >> > It's not just the port, it's all the
On Thu, Sep 8, 2011 at 5:09 AM, Peter Eisentraut wrote:
> On tis, 2011-09-06 at 17:12 +0200, hubert depesz lubaczewski wrote:
>> On Mon, Sep 05, 2011 at 02:27:23PM -0400, Tom Lane wrote:
>> > It's not just the port, it's all the connection parameters ---
>> > do_connect relies on the PGconn object
On tis, 2011-09-06 at 17:12 +0200, hubert depesz lubaczewski wrote:
> On Mon, Sep 05, 2011 at 02:27:23PM -0400, Tom Lane wrote:
> > It's not just the port, it's all the connection parameters ---
> > do_connect relies on the PGconn object to remember those, and in this
> > case there no longer is a
Yeah, Definitely it's not *expected* behavior so documentation is the good
starting point unless we fix the code soon. I don't agree with Tom's comment
on we should find out the reason for crash instead. In most of the cases,
reason for the crash is because someone restarted database and user tryin
Tom Lane wrote:
> hubert depesz lubaczewski writes:
> > On Mon, Sep 05, 2011 at 02:27:23PM -0400, Tom Lane wrote:
> >> It's not just the port, it's all the connection parameters ---
> >> do_connect relies on the PGconn object to remember those, and in this
> >> case there no longer is a PGconn obj
On Tue, Sep 06, 2011 at 11:35:43AM -0400, Tom Lane wrote:
> hubert depesz lubaczewski writes:
> > On Mon, Sep 05, 2011 at 02:27:23PM -0400, Tom Lane wrote:
> >> It's not just the port, it's all the connection parameters ---
> >> do_connect relies on the PGconn object to remember those, and in this
hubert depesz lubaczewski writes:
> On Mon, Sep 05, 2011 at 02:27:23PM -0400, Tom Lane wrote:
>> It's not just the port, it's all the connection parameters ---
>> do_connect relies on the PGconn object to remember those, and in this
>> case there no longer is a PGconn object.
>>
>> We could have
On Mon, Sep 05, 2011 at 02:27:23PM -0400, Tom Lane wrote:
> It's not just the port, it's all the connection parameters ---
> do_connect relies on the PGconn object to remember those, and in this
> case there no longer is a PGconn object.
>
> We could have psql keep that information separately, but
On 09/05/2011 08:27 PM, Tom Lane wrote:
> hubert depesz lubaczewski writes:
>> ran psql with specyfying port:
>> psql -p 4329 -U postgres -d some_database
>
>> then I run query which breaks backend:
>
>> =# select * from categories limit 1;
>> The connection to the server was lost. Attempting re
hubert depesz lubaczewski writes:
> ran psql with specyfying port:
> psql -p 4329 -U postgres -d some_database
> then I run query which breaks backend:
> =# select * from categories limit 1;
> The connection to the server was lost. Attempting reset: Failed.
> !>
> When I'll try to re-issue \c s
hi,
pg version: 9.0.5 - head from 9.0 branch in git.
ran psql with specyfying port:
psql -p 4329 -U postgres -d some_database
then I run query which breaks backend:
=# select * from categories limit 1;
The connection to the server was lost. Attempting reset: Failed.
!>
When I'll try to re-issue
11 matches
Mail list logo
