I guess the subject says it all. I replaced 1.4.0 with
1.4.1 and many, many commands kill the application.
(even select * from foo limit 100).

I am running the latest MacOS X 10.4.3 and Postgresql 8.1.1.

Where can I find 1.4.0, it seemed to be reasonably stable!

Jerry

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

On 14/12/05 7:05 pm, "Jerry LeVan" <jerry.levan@eku.edu> wrote:

> I guess the subject says it all. I replaced 1.4.0 with
> 1.4.1 and many, many commands kill the application.
> (even select * from foo limit 100).

Eeep, that's not good :-(. I'm investigating now (thanks for the report)

> I am running the latest MacOS X 10.4.3 and Postgresql 8.1.1.
>
> Where can I find 1.4.0, it seemed to be reasonably stable!

http://www.postgresql.org/ftp/pgadmi...ase/v1.4.0/osx


Regards, Dave



---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

On 14/12/05 9:12 pm, "Dave Page" <dpage@vale-housing.co.uk> wrote:

>
>
>
> On 14/12/05 7:05 pm, "Jerry LeVan" <jerry.levan@eku.edu> wrote:
>
>> I guess the subject says it all. I replaced 1.4.0 with
>> 1.4.1 and many, many commands kill the application.
>> (even select * from foo limit 100).
>
> Eeep, that's not good :-(. I'm investigating now (thanks for the report)
>

Now this is strange - I can reproduce this in 1.4.1 with any query in the
query tool, including SELECT 1; or SELECT * fROM pg_class; However, SVN
trunk, and 1.4.0 work just fine (I've done complete rebuilds of trunk and
1.4.1 on the same box. Didn't bother with 1.4.0).

It bails out with the following at the tip of the back trace:

#0 0x00008c40 in pgConnBase::RegisterNoticeProcessor(void (*)(void*, char
const*), void*) ()
#1 0x0000ab08 in pgQueryThreadBase:gQueryThreadBase(pgConnBase*, wxString
const&, int) ()
#2 0x00014a04 in pgQueryThread:gQueryThread(pgConnBase*, wxString const&,
int) ()
#3 0x000bb714 in ctlSQLResult::Execute(wxString const&, int) ()
#4 0x000e20bc in frmQuery::execQuery(wxString const&, int, bool, int, bool)
()
#5 0x000e1b44 in frmQuery::OnExecute(wxCommandEvent&) ()

Now I can't see any changes at all that should affect
RegisterNoticeProcessor - which is even wierder when you consider that all
the changes to 1.4.x are also present in trunk. On a hunch I rolled back to
PostgreSQL 8.1.0, but that didn't make any difference.

Anyone got any ideas? Florian, could you try a build of 1.4.1 and trunk, and
if so, do they work for you?

Regards, Dave



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Dave Page wrote:
>
>
> On 14/12/05 9:12 pm, "Dave Page" <dpage@vale-housing.co.uk> wrote:
>
>
>>
>>
>>On 14/12/05 7:05 pm, "Jerry LeVan" <jerry.levan@eku.edu> wrote:
>>
>>
>>>I guess the subject says it all. I replaced 1.4.0 with
>>>1.4.1 and many, many commands kill the application.
>>>(even select * from foo limit 100).
>>
>>Eeep, that's not good :-(. I'm investigating now (thanks for the report)
>>
>
>
> Now this is strange - I can reproduce this in 1.4.1 with any query in the
> query tool, including SELECT 1; or SELECT * fROM pg_class; However, SVN
> trunk, and 1.4.0 work just fine (I've done complete rebuilds of trunk and
> 1.4.1 on the same box. Didn't bother with 1.4.0).
>
> It bails out with the following at the tip of the back trace:
>
> #0 0x00008c40 in pgConnBase::RegisterNoticeProcessor(void (*)(void*, char
> const*), void*) ()
> #1 0x0000ab08 in pgQueryThreadBase:gQueryThreadBase(pgConnBase*, wxString
> const&, int) ()
> #2 0x00014a04 in pgQueryThread:gQueryThread(pgConnBase*, wxString const&,
> int) ()
> #3 0x000bb714 in ctlSQLResult::Execute(wxString const&, int) ()
> #4 0x000e20bc in frmQuery::execQuery(wxString const&, int, bool, int, bool)
> ()
> #5 0x000e1b44 in frmQuery::OnExecute(wxCommandEvent&) ()
>
> Now I can't see any changes at all that should affect
> RegisterNoticeProcessor - which is even wierder when you consider that all
> the changes to 1.4.x are also present in trunk. On a hunch I rolled back to
> PostgreSQL 8.1.0, but that didn't make any difference.
>
> Anyone got any ideas? Florian, could you try a build of 1.4.1 and trunk, and
> if so, do they work for you?

Try using the previous ctlComboBox.h version. GetSelection is a virtual
method, maybe it's some compiler problem. I noticed the last wxComboBox
problem just in frmQuery, maybe the connections stored in the combobox
are screwed up.

Regards,
Andresa

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Dave Page wrote:
> On 14/12/05 9:12 pm, "Dave Page" <dpage@vale-housing.co.uk> wrote:
>>On 14/12/05 7:05 pm, "Jerry LeVan" <jerry.levan@eku.edu> wrote:
>>>I guess the subject says it all. I replaced 1.4.0 with
>>>1.4.1 and many, many commands kill the application.
>>>(even select * from foo limit 100).
>>
>>Eeep, that's not good :-(. I'm investigating now (thanks for the report)
> Now this is strange - I can reproduce this in 1.4.1 with any query in the
> query tool, including SELECT 1; or SELECT * fROM pg_class; However, SVN
> trunk, and 1.4.0 work just fine (I've done complete rebuilds of trunk and
> 1.4.1 on the same box. Didn't bother with 1.4.0).
>
> It bails out with the following at the tip of the back trace:
>
> #0 0x00008c40 in pgConnBase::RegisterNoticeProcessor(void (*)(void*, char
> const*), void*) ()
> #1 0x0000ab08 in pgQueryThreadBase:gQueryThreadBase(pgConnBase*, wxString
> const&, int) ()
> #2 0x00014a04 in pgQueryThread:gQueryThread(pgConnBase*, wxString const&,
> int) ()
> #3 0x000bb714 in ctlSQLResult::Execute(wxString const&, int) ()
> #4 0x000e20bc in frmQuery::execQuery(wxString const&, int, bool, int, bool)
> ()
> #5 0x000e1b44 in frmQuery::OnExecute(wxCommandEvent&) ()
>
> Now I can't see any changes at all that should affect
> RegisterNoticeProcessor - which is even wierder when you consider that all
> the changes to 1.4.x are also present in trunk. On a hunch I rolled back to
> PostgreSQL 8.1.0, but that didn't make any difference.
>
> Anyone got any ideas? Florian, could you try a build of 1.4.1 and trunk, and
> if so, do they work for you?
I tried my nighty-build of the 1.4 branch
(http://developer.pgadmin.org/snapsho...51214.tar.bz2),
and it seems to work fine. At least I was able to start pgAdmin3,
connect to a db, open a sql window, and issue a few simple queries
(Inserts and Selects). Non of the selects returned a lot of rows, though.

I'm building against wxMac 2.6.2 and postgresql 8.1.0
I'm bulding on panther, using gcc version
"3.3 20030304 (Apple Computer, Inc. build 1671)".

greetings, Florian Pflug

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings