Tomáš Szépe wrote:
A pg_dump run is comparatively short-lived, so if Zdenek is right then
there's no important leak here -- we're counting on program exit to
release the memory. There's probably little point in releasing things
earlier than that.
Well, I'd tend to consider any logical part of
Tom Lane wrote:
Plan B would be to set the database locale to C, which is
encoding-agnostic and hence allows different databases to have different
encodings. Do you actually need en_US sort order?
I wasn't aware of the difference in sort orders until about two months
ago when i had to comp
> A pg_dump run is comparatively short-lived, so if Zdenek is right then
> there's no important leak here -- we're counting on program exit to
> release the memory. There's probably little point in releasing things
> earlier than that.
Well, I'd tend to consider any logical part of a program that
Aggro <[EMAIL PROTECTED]> writes:
> But is the memory freed at some point? E.g. when
> program shuts down? If it is not freed ever, then it
> is a memory leak.
Program-local memory is *always* freed at process termination. Any
operating system that failed to handle this would be broken beyond
usa
Aggro wrote:
>
> --- Zdenek Kotala <[EMAIL PROTECTED]> wrote:
>
> > I think all information is collected and they are
> > used for all pg_dump run. It
> > does not make sense to free them. See line 725.
>
> But is the memory freed at some point? E.g. when
> program shuts down? If it is not fre
--- Zdenek Kotala <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] napsal(a):
> > The following bug has been logged online:
> >
> > Bug reference: 4496
> > Logged by:
> > Email address: [EMAIL PROTECTED]
> > PostgreSQL version: Latest cvs
> > Operating system: Error in source
On Oct 25, 2008, at 05:35, Tom Lane wrote:
Seems to be fixed in HEAD:
regression=# SELECT '{foo}'::name[] <> '{bar}'::name[];
ERROR: operator is only a shell: name[] <> name[]
LINE 1: SELECT '{foo}'::name[] <> '{bar}'::name[];
Great. Is it something that could be backported, or is it not wor
Harvey, Allan AC napsal(a):
Zdenek,
Hmm, It does not look good. Your OS does not return proper
information about
codeset. Following code is broken:
setlocale(LC_CTYPE, ctype);
sys = nl_langinfo(CODESET);
sys = strdup(sys);
See
http://www.opengroup.org/onlinepubs/0096
[EMAIL PROTECTED] napsal(a):
The following bug has been logged online:
Bug reference: 4496
Logged by:
Email address: [EMAIL PROTECTED]
PostgreSQL version: Latest cvs
Operating system: Error in source code
Description:Memory leak in pg_dump.c?
Details:
In file sr
Joe <[EMAIL PROTECTED]> writes:
> Going back to my options, are you saying that if I re-initdb the 8.3
> cluster to UTF8, restore the LATIN1 db as UTF8, and then do "set
> client_encoding = LATIN1" in the application code, then everything will
> work fine, even if the machine locale remains en_U
Hi Tom,
Tom Lane wrote:
Why does it have to be LATIN1? If your answer is "my client code deals
in LATIN1", just set client_encoding = LATIN1. You could do that with
ALTER DATABASE SET or possibly ALTER USER SET so that it's transparent
to the clients.
The client code is primarily encoding
Joe <[EMAIL PROTECTED]> writes:
> I can understand that creating a LATIN2, EUC_CN or some other encoding
> in a LATIN1 cluster may cause problems, but don't quite see how UTF-8
> can be a problem since in essence it includes the others. Perhaps
> someone can provide further explanation?
The lo
Hi,
I just run into this bug
(http://archives.postgresql.org/pgsql-bugs/2008-02/msg00010.php). In my
case, Roundup (Python bug tracker) is trying to CREATE DATABASE WITH
ENCODING='UNICODE' in an 8.3.4 cluster created with LATIN1 encoding, and
it gets the error:
encoding UTF8 does not match
13 matches
Mail list logo
