Re: [BUGS] BUG #6234: Memory leak from PQexec

2011-09-29 Thread Craig Ringer 

On 29/09/2011 6:22 AM, Vikas Mehta wrote:

The following bug has been logged online:

Bug reference:  6234
Logged by:  Vikas Mehta
Email address:  me...@roguewave.com
PostgreSQL version: 8.4.8
Operating system:   Windows
Description:Memory leak from PQexec
Details:

Purify shows 448 bytes of memory leaks with PQexec:

[W] Summary of all memory leaks... {448 bytes, 11 blocks}
 [W] MLK: Memory leak of 128 bytes from 1 block allocated in
ERR_load_SSL_strings [SSLEAY32.DLL]

It's not a leak, and it's not a bug. Please search the pgsql-general 
archives for "valgrind" or "SSL_config".


--
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] PostGre compatible to RHEL 6.1

2011-09-29 Thread Robert Haas 
On Thu, Sep 29, 2011 at 7:23 AM, Yaamini Bist wrote:

> Hi,
> It would be really great if you can provide me information *Is PostGre
> compatible to RHEL 6.1 ?*
>

1. Yes.

2. This is not a bug.

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

Re: [BUGS] "no relation entry for relid 1"

2011-09-29 Thread Tom Lane 
Peter Geoghegan  writes:
> On 29 September 2011 23:15, Tom Lane  wrote:
>> Looks like I broke it here:
>> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=1cb108efb0e60d87e4adec38e7636b6e8efbeb57

> Hmm. Although it was obvious to me that this was an internal error, I
> have to wonder what a novice would have made of it. Specifically, I
> wonder if there should be an INTERNAL_ERROR severity level, to
> explicitly advertise that you're not supposed to see this, and to help
> log analysis tools (including grep) bring these sorts of things to the
> DBA's attention, as they are surely much more severe than most errors
> seen in practice.

Well, the SQLSTATE for this sort of thing is already
ERRCODE_INTERNAL_ERROR.  As to whether it's more severe than other
errors, I'm not convinced.  It didn't crash, nor corrupt your data.

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] "no relation entry for relid 1"

2011-09-29 Thread Peter Geoghegan 
On 29 September 2011 23:15, Tom Lane  wrote:
> Peter Geoghegan  writes:
>> I've built Postgres from master, and found that the following fairly
>> simple query breaks:
>
>> select count(*)
>> from
>> (
>>       select
>>       schemaname
>>       from            pg_stat_user_tables
>>       order by        1
>> ) sub
>> group by schemaname
>
>> This produces the internal error message "no relation entry for relid
>> 1". Why is that?
>
> Looks like I broke it here:
>
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=1cb108efb0e60d87e4adec38e7636b6e8efbeb57

Hmm. Although it was obvious to me that this was an internal error, I
have to wonder what a novice would have made of it. Specifically, I
wonder if there should be an INTERNAL_ERROR severity level, to
explicitly advertise that you're not supposed to see this, and to help
log analysis tools (including grep) bring these sorts of things to the
DBA's attention, as they are surely much more severe than most errors
seen in practice.

-- 
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services

-- 
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] "no relation entry for relid 1"

2011-09-29 Thread Tom Lane 
Peter Geoghegan  writes:
> I've built Postgres from master, and found that the following fairly
> simple query breaks:

> select count(*)
> from
> (
>   select
>   schemaname
>   frompg_stat_user_tables
>   order by1   
> ) sub
> group by schemaname

> This produces the internal error message "no relation entry for relid
> 1". Why is that?

Looks like I broke it here:

http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=1cb108efb0e60d87e4adec38e7636b6e8efbeb57

Fixed, thanks for the report!

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] "no relation entry for relid 1"

2011-09-29 Thread Mark Kirkwood 

On 30/09/11 10:08, Dickson S. Guedes wrote:

2011/9/29 Peter Geoghegan:

On 29 September 2011 21:59, Merlin Moncure  wrote:

hm -- works for me (9.1.0)

It works for me on REL9_1_STABLE too, unsurprisingly, as I would think
it highly unlikely that such a glaring bug would slip into a stable
release.

Have you did a make distclean before build, then init a new $PGDATA?



I can confirm this - checkout from 2 days ago, maintainer-clean + build 
and initdb.


--
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] "no relation entry for relid 1"

2011-09-29 Thread Dickson S. Guedes 
2011/9/29 Peter Geoghegan :
> On 29 September 2011 21:59, Merlin Moncure  wrote:
>> hm -- works for me (9.1.0)
>
> It works for me on REL9_1_STABLE too, unsurprisingly, as I would think
> it highly unlikely that such a glaring bug would slip into a stable
> release.

Have you did a make distclean before build, then init a new $PGDATA?

-- 
Dickson S. Guedes
mail/xmpp: gue...@guedesoft.net - skype: guediz
http://guedesoft.net - http://www.postgresql.org.br

-- 
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] "no relation entry for relid 1"

2011-09-29 Thread Peter Geoghegan 
On 29 September 2011 21:59, Merlin Moncure  wrote:
> hm -- works for me (9.1.0)

It works for me on REL9_1_STABLE too, unsurprisingly, as I would think
it highly unlikely that such a glaring bug would slip into a stable
release.

-- 
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services

-- 
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] "no relation entry for relid 1"

2011-09-29 Thread Merlin Moncure 
On Thu, Sep 29, 2011 at 3:26 PM, Peter Geoghegan  wrote:
> I've built Postgres from master, and found that the following fairly
> simple query breaks:
>
> select count(*)
> from
> (
>        select
>        schemaname
>        from            pg_stat_user_tables
>        order by        1
> ) sub
> group by schemaname
>
> This produces the internal error message "no relation entry for relid
> 1". Why is that?

hm -- works for me (9.1.0)

merlin

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

[BUGS] "no relation entry for relid 1"

2011-09-29 Thread Peter Geoghegan 
I've built Postgres from master, and found that the following fairly
simple query breaks:

select count(*)
from
(
select
schemaname
frompg_stat_user_tables
order by1   
) sub
group by schemaname

This produces the internal error message "no relation entry for relid
1". Why is that?

-- 
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services

-- 
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 #6231: weird to_timestamp behaviour with out of range values

2011-09-29 Thread Robert Haas 
On Wed, Sep 28, 2011 at 11:43 AM, Tom Lane  wrote:
> "Henk Enting"  writes:
>> I would expect the to_timestamp function to return an error when I feed it
>> out of range values, e.g. months > 13 and days > 31. Instead it seems to add
>> the surplus to the timestamp and then return it.
>
> What is your reason for using to_timestamp at all?  The timestamp input
> converter is perfectly capable of dealing with standard formats like
> -mm-dd, and it does what most people expect in the way of data
> validation checks.

Well, you might want to insist that the input is in some particular
format, rather than just "whatever the input function will accept"...

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL 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] PostGre compatible to RHEL 6.1

2011-09-29 Thread Christopher Browne 
On Thu, Sep 29, 2011 at 7:23 AM, Yaamini Bist  wrote:
>
> Hi,
>
> It would be really great if you can provide me information Is PostGre 
> compatible to RHEL 6.1 ?

This is a mailing list for addressing bugs that are found with PostgreSQL.

There isn't any such system as "PostGre", and whether that is
compatible with a particular Linux-based system is not a bug in
PostgreSQL.

If you were interested in what support there is for PostgreSQL in
RHEL, you might want to check with the vendor.  They document this
reasonably well, even within their marketing literature.  See:

--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

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

[BUGS] PostGre compatible to RHEL 6.1

2011-09-29 Thread Yaamini Bist 
Hi,

It would be really great if you can provide me information Is PostGre 
compatible to RHEL 6.1 ?




YAAMINI BIST
Configuration Engineer

Ericsson India Global Service Private Ltd
RM R&D India
10th Floor, Building No 9A, DLF Cyberciti, Sector 25A
122 002, Gurgaon ,Haryana, India, India
Phone +91 124 437 2854
Fax +91 124 437 2999
SMS/MMS +91 9582236739
yaamini.b...@ericsson.com
www.ericsson.com


 

This Communication is Confidential. We only send and receive email on the basis 
of the terms set out at 
www.ericsson.com/email_disclaimer


<><>
-- 
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] Problems with ENUM type manipulation in 9.1

2011-09-29 Thread depstein 
Thanks everyone for the explanations.  I posted a feature request for improved 
enum manipulation in psql-general.

Dmitry Epstein | Developer
 
Allied Testing

www.alliedtesting.com
We Deliver Quality.

-- 
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 #6233: pg_dump hangs with Access Violation C0000005

2011-09-29 Thread Craig Ringer 

On 09/29/2011 05:18 AM, Holec wrote:


The following bug has been logged online:

Bug reference:  6233
Logged by:  Holec
Email address:  ho...@email.cz
PostgreSQL version: 8.4.8
Operating system:   Windows 7
Description:pg_dump hangs with Access Violation C005
Details:

I use pg_dump on Windows 7 with:
pg_dump -i -h 192.168.2.2 -p 5432 -U user -F c -b -v -f file.backup mydb



Does this crash happen when you back up a different database? Say, if 
you back up the `template1' database, does it crash then too?


Is this a 32-bit or 64-bit install of Windows 7? If 64-bit, are you 
using a 32-bit or 64-bit build of PostgreSQL?


Is there any antivirus software on the machine? If so, what type and 
version? Does the problem still happen if you turn it off and re-test?


--
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 #5800: "corrupted" error messages (encoding problem ?)

2011-09-29 Thread Craig Ringer 

First, sorry for the slow reply.

Response inline.

On 09/17/2011 08:34 AM, Tom Lane wrote:

Craig Ringer  writes:

On 09/17/2011 05:10 AM, Carlo Curatolo wrote:

Just tried with PG 9.1...same problem...



Yep. There appears to be no interest in fixing this bug. All the
alternatives I proposed were rejected, and there doesn't seem to be any
concern about the issue.

>

The problem is to find a cure that's not worse than the disease.
I'm not exactly convinced that forcing all log messages into a common
encoding is a better behavior than allowing backends to log in their
native database encoding.

>

If you do want a common encoding, there's a very easy way to get it, ie,
standardize on one encoding for all your databases.


The postmaster may still emit messages in a different encoding if the 
system encoding is not the same as the standard database encoding chosen.



People who aren't
doing that already probably have good reasons why they want to stay with
the encoding choices they've made; forcing their logs into some other
encoding isn't necessarily going to improve their lives.


I'm not convinced.

Mixing their logs with messages in other encodings makes it *impossible* 
for most people to read them at all. A file with (say) mixed UTF-8, 
latin-1 and Shift-JIS is effectively hopelessly corrupted as far as most 
people are concerned. If lines are differently encoded, the file is a 
totally mangled mess. Try it and see what I mean. As such, I disagree: 
forcing all their logs into one encoding WILL improve their lives over 
the current situation, and won't affect people whose databases are all 
already in the system encoding.


In any case, if the system uses a utf8 encoding and the databases are 
latin-1 (for example) the admin might actually prefer to have utf8 logs 
for easy reading and processing by system tools, no matter what encoding 
the databases are in.


The database encoding is an internal thing. The log encoding is an 
external thing. Writing messages to stdout/stderr in an encoding other 
than that specified by LC_CTYPE and LC_MESSAGES is wrong as it'll cause 
garbage to be shown on a terminal; so IMO is logging in a different 
encoding.


Because there's no standard way to flag a file as having a certain 
encoding, I contend that the correct default is to write files in the 
default encoding used by the system. That is what programs that consume 
the logs will expect. The only other correct alternative would be to 
write UTF-8 logs with a BOM that lets programs unamgiguously identify 
the encoding. That said, users probably should be able to override the 
log file location and encoding so a particular database's logs go to a 
separate file in a user-defined encoding and/or override the default 
encoding Pg writes.




... The only valid fixes are to log them to different files (with some
way to identify which encoding is used)


I don't recall having heard any serious discussion of such a design, but
perhaps doing that would satisfy some use-cases.  One idea that comes to
mind is to provide a %-escape for log_filename that expands to the name
of the database encoding (or more likely, some suitable abbrevation).
The logging collector protocol would have to be expanded to include that
information, but that seems do-able.


That'd work, though it doesn't solve the problem for people logging to 
syslog or to a single file.


I think Pg should also be able to convert all messages into a common 
encoding for logging to a single file and should default to using the 
system encoding as that encoding.


The user could configure a different encoding - for example, they might 
want to force utf-8 logging because their databases may have all sorts 
of different encodings, but they're logging to syslog so they can't 
split logs out to different files.


A special log destination encoding name, say "log_encoding = database" 
could be used to bypass all encoding conversion, retaining the current 
behaviour of logging in whatever encoding the database happens to use.


I'm willing to implement this setup (or try, at least) if you think it's 
a reasonable thing to do. I don't know how I'll go with multi-file 
logging in log_filename, but I'm pretty sure I can handle the log 
message encoding conversion and associated configuration directives.


There's some overhead to encoding conversion, but it's pretty minimal. 
It can be avoided entirely by ensuring that your log destination 
encoding is the same as your Pg database encoding, which under this 
scheme you can do by setting "log_encoding = database" and sticking to 
one encoding or using multi-file logging.


Reasonable plan?

--
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