[BUGS] [8.4.4] Strange bus error on Solaris 10/sparc

2010-09-16 Thread BERTRAND Joel 

Hello,

	A have written a program that randomly crashes on Solaris 10. This 
program has been tested with valgrind without any error and runs fine on 
all other systems I have. I cannot reproduce this bug with a minimal 
program.


Backtrace :
Core was generated by `/usr/local/bin/rpl -csdnp ./serveur.rpl'.
Program terminated with signal 10, Bus error.
#0  0x0b828854 in __memget () from /lib/sparcv9//libresolv.so.2
(gdb) bt
#0  0x0b828854 in __memget () from /lib/sparcv9//libresolv.so.2
#1  0x0b81c090 in __net_data_create () from 
/lib/sparcv9//libresolv.so.2
#2  0x0b81c018 in __net_data_init () from 
/lib/sparcv9//libresolv.so.2

#3  0x0b81ee38 in init () from /lib/sparcv9//libresolv.so.2
#4  0x0b81d864 in res_gethostbyname2 () from 
/lib/sparcv9//libresolv.so.2

#5  0x0fe012e4 in _nss_dns_gethostbyname2 ()
   from /usr/lib/sparcv9//nss_dns.so.1
#6  0x0fe01e88 in getbyname () from /usr/lib/sparcv9//nss_dns.so.1
#7  0x7d8695dc in nss_search () from /lib/sparcv9//libc.so.1
#8  0x7cf35264 in _switch_getipnodebyname_r ()
   from /lib/sparcv9//libnsl.so.1
#9  0x7cf33c38 in _get_hostserv_inetnetdir_byname ()
   from /lib/sparcv9//libnsl.so.1
#10 0x7cf30f08 in getipnodebyname () from /lib/sparcv9//libnsl.so.1
#11 0x7dc0626c in get_addr () from /lib/sparcv9//libsocket.so.1
#12 0x7dc060cc in _getaddrinfo () from /lib/sparcv9//libsocket.so.1
#13 0x00010049c9b4 in pg_getaddrinfo_all ()
#14 0x000100486b5c in connectDBStart ()
#15 0x0001004865a8 in PQsetdbLogin ()
#16 0x00010016c370 in librpl_parametres_sql (
s_etat_processus=0x7cd00010, s_parametres=0x7a60bac0)
at sql-conv.c:315
#17 0x00010013b110 in librpl_instruction_sqlquery (
s_etat_processus=0x7cd00010) at instructions_s8-conv.c:914

	I don't understand. All PQsetdblogin() parameters are valid and I have 
no idea to avoid this bug.


Regards,

JKB

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] [8.4.4] Strange bus error on Solaris 10/sparc

2010-09-16 Thread Tom Lane 
BERTRAND Joel  writes:
>   A have written a program that randomly crashes on Solaris 10. This 
> program has been tested with valgrind without any error and runs fine on 
> all other systems I have. I cannot reproduce this bug with a minimal 
> program.

Given that the crash is way down inside getaddrinfo(), I'd say this is
a Solaris bug.  You should probably file it with Sun^H^H^HOracle.

regards, tom lane

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] BUG #5660: Can't start db service if specify effective_io_concurrency

2010-09-16 Thread Mikio 

The following bug has been logged online:

Bug reference:  5660
Logged by:  Mikio
Email address:  tkbysh2...@yahoo.co.jp
PostgreSQL version: 9.0 RC1
Operating system:   Windows XP SP3 Japanese
Description:Can't start db service if specify
effective_io_concurrency
Details: 

I'm using postgresql 9.0 rc1, and I specified 10 for
effective_io_concurrency in postgresql.conf.
I restarted postgresql windows service, but the service didn't start.
I looked a log file in pg_log directory, but no relative entries.
I looked windows event viewer, I found an event from PostgreSQL, and it was
below.(The characters in the message were broken.)

>FATAL:  p[^"effective_io_concurrency"ύXł܂

I changed the value from 10 to 1, but the symptom was same.
I commented the line out like as default, the service started up successful.

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] BUG #5661: The character encoding in logfile is confusing.

2010-09-16 Thread Mikio 

The following bug has been logged online:

Bug reference:  5661
Logged by:  Mikio
Email address:  tkbysh2...@yahoo.co.jp
PostgreSQL version: 9.0 RC1
Operating system:   Windows XP SP3 Japanese
Description:The character encoding in logfile is confusing.
Details: 

I'm using postgresql 9.0 rc1 on Japanese Windows XP.
I found character encoding is confusing in log files in pg_log directory.
Default character encoding of all of databases are UTF-8, and almost message
strings in log files are described by UTF-8 correctly.
But few lines are described by EUC_JP.
So 2 character encoding strings are existing in 1 log file and I can't read
the messages parts of logs.
Incidentally, client_encoding in postgresql.conf is commented out.

Thank you.

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #5660: Can't start db service if specify effective_io_concurrency

2010-09-16 Thread Itagaki Takahiro 
On Thu, Sep 16, 2010 at 7:52 PM, Mikio  wrote:
> Operating system:   Windows XP SP3 Japanese
> I'm using postgresql 9.0 rc1, and I specified 10 for
> effective_io_concurrency in postgresql.conf.
> I restarted postgresql windows service, but the service didn't start.

Unfortunately, effective_io_concurrency is not supported on Windows.
It works on Linux and UNIXes, but must be 1 on Windows.

-- 
Itagaki Takahiro

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #5660: Can't start db service if specify effective_io_concurrency

2010-09-16 Thread Tom Lane 
"Mikio"  writes:
> I'm using postgresql 9.0 rc1, and I specified 10 for
> effective_io_concurrency in postgresql.conf.
> I restarted postgresql windows service, but the service didn't start.

This is unsurprising: you can only set effective_io_concurrency on
platforms that have posix_fadvise(), which I rather doubt Windows does.

> I looked windows event viewer, I found an event from PostgreSQL, and it was
> below.(The characters in the message were broken.)

>> FATAL:  p[^"effective_io_concurrency"ύXł܂

Hm, what I get when I try that on a machine without posix_fadvise()
is

FATAL:  parameter "effective_io_concurrency" cannot be changed

I think you have some other configuration problem that's messing up
your log entries.

regards, tom lane

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #5650: Postgres service showing as stopped when in fact it is running

2010-09-16 Thread Robert Haas 
On Thu, Sep 9, 2010 at 12:22 PM, Mark Llewellyn  wrote:
>
> The following bug has been logged online:
>
> Bug reference:      5650
> Logged by:          Mark Llewellyn
> Email address:      mark_llewel...@adp.com
> PostgreSQL version: 9.0 RC1
> Operating system:   Windows XP
> Description:        Postgres service showing as stopped when in fact it is
> running
> Details:
>
> The postgresql-9.0 service is showing as *not running* in pgAdmin 3 1.12 RC1
> and as *stopped* in the Windows services list, although the database is
> actually running and I can connect to it and create databases, tables etc.
> It also shows multiple postgresql tasks in Windows task manager.
> However, because Windows XP is not aware that the postgresql-9.0 service is
> running it is not possible to stop the service.

Maybe this is a dumb question, but how did you start the service?

And applying the good old Windows troubleshooting meme...  if you
reboot, does that fix it?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #5644: Selecting ROW() in variable with 9.0 not compatible with 8.4

2010-09-16 Thread Robert Haas 
On Wed, Sep 8, 2010 at 11:42 AM, Tom Lane  wrote:
> Valentine Gogichashvili  writes:
>> CREATE TYPE ta AS (a1 integer, a2 text);
>> CREATE TYPE tb AS (b1 integer, b2 ta);
>
>> DECLARE
>>  a ta;
>>  b tb;
>> BEGIN
>
>>  SELECT 1, 'a' INTO a;      -- ok
>
>>  SELECT ROW(10, 'a') INTO b.b2; -- ok in 8.4 but fails in 9.0 [ERROR:
>>  invalid input syntax for integer: "(10,a)"]
>
>>  SELECT 100, 'a' INTO b.b2;   -- ok in 9.0 but fails in 8.4 [ERROR:  cannot
>> assign non-composite value to a row variable]
>
> [ pokes around for a bit ... ]  This is a consequence of the plpgsql
> lexer rewrite I did for 9.0.  In the previous code, "INTO b.b2" was
> treated by the lexer as an assignment to a scalar variable, regardless
> of the actual data type of b2.  Which means that the SELECT has to
> produce a single column that gets assigned to b.b2, so your first case
> works and your second doesn't.  The new code looks at the data type
> of b2 rather than whether it's syntactically a field reference, so it
> decides this is an assignment to a composite variable.  That results in
> behavior similar to the "INTO a" case: the SELECT is supposed to produce
> one column for each field of the composite variable.  Hence, second case
> works and first doesn't.
>
> I am not sure how ugly a kluge would be needed to restore the previous
> behavior.  I'm inclined to say that the new behavior is more
> self-consistent and so we should call this a bug fix rather than a bug.

If we know the types of everything, is it possible to make both cases work?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #5652: Optimizer does wrong thing with partitioned tables

2010-09-16 Thread Robert Haas 
On Fri, Sep 10, 2010 at 9:31 AM, Euler Taveira de Oliveira
 wrote:
> Mladen Gogala escreveu:
>> Optimizer chooses to scan each partitioned table sequentially, instead of
>> using the available index:
>>
> This is not a bug. How would the optimizer know that the maximum value is in
> that specific partition? There is neither a global index for a partitioned
> table nor an optimizer artifact to know aggregate information before scanning
> all of the partitions. Maybe when we have a better support for table
> partitioning such optimizer artifact would be implemented but don't hold your
> breath.

I wonder if Merge Append could be made to help with this case.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #5644: Selecting ROW() in variable with 9.0 not compatible with 8.4

2010-09-16 Thread Tom Lane 
Robert Haas  writes:
> On Wed, Sep 8, 2010 at 11:42 AM, Tom Lane  wrote:
>>>  SELECT ROW(10, 'a') INTO b.b2; -- ok in 8.4 but fails in 9.0 [ERROR:
>>>  invalid input syntax for integer: "(10,a)"]

>>>  SELECT 100, 'a' INTO b.b2;   -- ok in 9.0 but fails in 8.4 [ERROR:  cannot 
>>> assign non-composite value to a row variable]

> If we know the types of everything, is it possible to make both cases work?

We don't know the types of everything at the point where the decision
needs to be made.  Even if we did, allowing both would be a klugy
unmaintainable mess IMO --- far more work than it's worth.

regards, tom lane

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #5644: Selecting ROW() in variable with 9.0 not compatible with 8.4

2010-09-16 Thread Robert Haas 
On Thu, Sep 16, 2010 at 9:30 PM, Tom Lane  wrote:
> Robert Haas  writes:
>> On Wed, Sep 8, 2010 at 11:42 AM, Tom Lane  wrote:
  SELECT ROW(10, 'a') INTO b.b2; -- ok in 8.4 but fails in 9.0 [ERROR:
  invalid input syntax for integer: "(10,a)"]
>
  SELECT 100, 'a' INTO b.b2;   -- ok in 9.0 but fails in 8.4 [ERROR:  
 cannot assign non-composite value to a row variable]
>
>> If we know the types of everything, is it possible to make both cases work?
>
> We don't know the types of everything at the point where the decision
> needs to be made.  Even if we did, allowing both would be a klugy
> unmaintainable mess IMO --- far more work than it's worth.

Bummer.  Maybe we should have more-different syntax for the two cases
then.  I've been bitten by this quite a few times over the years.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #5661: The character encoding in logfile is confusing.

2010-09-16 Thread Craig Ringer 

On 09/16/2010 07:12 PM, Mikio wrote:


The following bug has been logged online:

Bug reference:  5661
Logged by:  Mikio
Email address:  tkbysh2...@yahoo.co.jp
PostgreSQL version: 9.0 RC1
Operating system:   Windows XP SP3 Japanese
Description:The character encoding in logfile is confusing.
Details:

I'm using postgresql 9.0 rc1 on Japanese Windows XP.
I found character encoding is confusing in log files in pg_log directory.
Default character encoding of all of databases are UTF-8, and almost message
strings in log files are described by UTF-8 correctly.
But few lines are described by EUC_JP.
So 2 character encoding strings are existing in 1 log file and I can't read
the messages parts of logs.
Incidentally, client_encoding in postgresql.conf is commented out.


Thankyou for your report. This certainly sounds like a potential bug - 
but to do anything about it, we will need to see the contents of the 
actual log file in question and the contents of postgresql.conf .


Only partial log file contents should be necessary, showing the EUC_JP 
encoded parts of the logs and say ten lines either side. If the EUC_JP 
contents were generated by client code (say, RAISE NOTICE statements in 
PL/PgSQL) then you will also need to supply the client code.


Please bundle all the files up in a zip file to protect them from 
possible text encoding  conversion during transfer, and post them to a 
file hosting site. If you don't want them to be public, just collect the 
logs up and wait for people to ask you to send them to them by private 
email. Please send a copy to me, as I've dealt with encoding issues in 
software (though not PostgreSQL) quite a bit.


--
Craig Ringer


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #5650: Postgres service showing as stopped when in fact it is running

2010-09-16 Thread Ashesh Vashi 
Hi Mark,

On of my college (Sujeet) has found a way to reproduce the same behaviour.
1. Installed PG 9.0 on Win XP SP3
2. Stop the Postgresql-9.0 service from service manager console
3. Create pgpass.conf in postgres (service account) user's profile with an
incorrect password deliberately.
(Refer: http://www.postgresql.org/docs/8.4/interactive/libpq-pgpass.html)
4. Now start the postgresql-9.0 service, it will return an error and the
status
   shows stopped
5. However i could connect to the psql shell and get the prompt which means
the server is running.

So, please check if pgpass.conf file exists in service account (postgres)
user's %APPDATA%\postgresql directory with wrong password.


--
Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise Postgres Company


On Thu, Sep 9, 2010 at 9:52 PM, Mark Llewellyn wrote:

>
> The following bug has been logged online:
>
> Bug reference:  5650
> Logged by:  Mark Llewellyn
> Email address:  mark_llewel...@adp.com
> PostgreSQL version: 9.0 RC1
> Operating system:   Windows XP
> Description:Postgres service showing as stopped when in fact it is
> running
> Details:
>
> The postgresql-9.0 service is showing as *not running* in pgAdmin 3 1.12
> RC1
> and as *stopped* in the Windows services list, although the database is
> actually running and I can connect to it and create databases, tables etc.
> It also shows multiple postgresql tasks in Windows task manager.
> However, because Windows XP is not aware that the postgresql-9.0 service is
> running it is not possible to stop the service.
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
>