On Mon, Aug 9, 2010 at 3:59 AM, Patric de Waha wrote:
> Hello,
> I found something weird in the logs.
> Apparently the automated analyze process has some
> problems with custom functions.
>
> Using my regular database user for this db, i get no problems
> using the functions which
On Sat, Feb 6, 2010 at 9:09 PM, Chris Travers wrote:
> On Sat, Feb 6, 2010 at 2:36 PM, Robert Haas wrote:
>> That's really odd. Nothing pgAdmin does should be able to crash the
>> PostgreSQL server, I would think. Have you got any custom code loaded
>> into PostgreSQL? Or non-custom, but buggy
On Aug 19, 2010, at 3:24 PM, Tom Lane wrote:
> Steven Schlansker writes:
>>
>> I'm not at all experienced with character encodings so I could
>> be totally off base, but isn't it wrong to ever call isspace(0x85),
>> whatever the result may be, given that the actual character is 0xCF85?
>> (U+03
On Aug 19, 2010, at 2:35 PM, Tom Lane wrote:
> Steven Schlansker writes:
>> I'm having a rather annoying problem - a particular string is causing the
>> Postgres COPY functionality to lose a byte, causing data corruption in
>> backups and transferred data.
>
> I was able to reproduce this on m
We run essentially the following commands to create the table of contents in
order to prevent pg_restore from failing:
pg_restore -l database.dump | \
eval fgrep -v -e "' SCHEMA - public '" \
-e "' COMMENT - SCHEMA public '" \
-e "' PROCEDURAL LANGUAGE - plpgsql'" database.toc
Where w
> We generally assume that in server-safe encodings, the ctype.h functions
> will behave sanely on any single-byte value.
I think this "wisedom" is only true for C locale. I'm not surprised
all that it does not work with non C locales.
>From array_funcs.c:
while (isspace((unsign
On Thu, Aug 19, 2010 at 5:19 PM, Tom Lane wrote:
> Thue Janus Kristensen writes:
> > I finally succeeded in creating a test case, after much experimentation.
> > Running the attached sql crashes my postgresql server 100% of the time.
>
> Cute problem.
Generating the test case was very "interes
Steven Schlansker writes:
> On Aug 19, 2010, at 2:35 PM, Tom Lane wrote:
>> I was able to reproduce this on my own Mac. Some tracing shows that the
>> problem is that isspace(0x85) returns true when in locale en_US.utf-8.
>> This causes array_in to drop the final byte of the array element string,
Steven Schlansker writes:
> I'm having a rather annoying problem - a particular string is causing the
> Postgres COPY functionality to lose a byte, causing data corruption in
> backups and transferred data.
I was able to reproduce this on my own Mac. Some tracing shows that the
problem is that
Hello PostgreSQL developers,
Martin Pitt [2010-08-17 6:49 +0200]:
> I received a request to support system-wide root certificates in
> libpq. Right now it only looks in ~/.postgresql/root.crt, but since
> such certificates are usually set up system wide and be maintained by
> the sysadmins, it wo
"Albert Ullrich" writes:
> Description:Parallel pg_restore fails with "tuple concurrently
> updated"
> pg_restore -e -v -j 4 -Fc -L /tmp/fp_basic.toc -d fp_basic
> /tmp/fp_basic.dump
Apparently you've used the -L option to reorder the dump objects in a way
that won't work with parallel
Thue Janus Kristensen writes:
> I finally succeeded in creating a test case, after much experimentation.
> Running the attached sql crashes my postgresql server 100% of the time.
Cute problem. The attached fix cures it for me; would you see if it
solves your original case too?
On a freshly untared archive, make uuid-ossp woked fine now.
Jens
--
Affinitas GmbH | Kohlfurter Straße 41/43 | 10999 Berlin | Germany
Geschäftsführer: Lukas Brosseder, David Khalil, Kai Rieke, Christian Vollmann
Eingetragen beim Amtsgericht Berlin, HRB 115958
--
Sent via pgsql-bugs ma
13 matches
Mail list logo
