-hackers@postgresql.org
Subject: Re: plperl vs LC_COLLATE (was Re: [HACKERS] Possible savepoint
bug)
Date: Tue, 10 Jan 2006 10:22:45 -0500
On Mon, 2006-01-09 at 11:03 -0500, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
AFAICT, perl doesn't keep any state about locale settings, it just
Greg Stark wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
The attached patch against cvs tip does seem to work. Instead of playing
with the environment, we simply allow perl to do its worst and then put
things back the way we wanted them.
How does that affect to the API calls
Andrew Dunstan [EMAIL PROTECTED] writes:
I don't know. Reading that code just makes my head spin ...
Yeah, too many ifdefs :-(. But I suppose that the initial
#ifdef LOCALE_ENVIRON_REQUIRED block is not compiled on sane
platforms, meaning that the first code in the routine is the
unconditional
On Mon, 2006-01-09 at 12:06 -0500, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I don't know. Reading that code just makes my head spin ...
Yeah, too many ifdefs :-(. But I suppose that the initial
#ifdef LOCALE_ENVIRON_REQUIRED block is not compiled on sane
platforms, meaning
Andrew Dunstan [EMAIL PROTECTED] writes:
On Mon, 2006-01-09 at 12:06 -0500, Tom Lane wrote:
We could just file a Perl bug report and wait for them to fix it.
What's the data risk?
Given that it took us this long to identify the problem, I'm guessing
that it doesn't affect too many people.
Tom Lane wrote:
I'm just about out of ideas and right out of time to spend on this.
We could just file a Perl bug report and wait for them to fix it.
done
cheers
andrew
---(end of broadcast)---
TIP 4: Have you searched
Is there a TODO here, even if the Perl folks are supposed to fix it?
---
Andrew Dunstan wrote:
Tom Lane wrote:
I'm just about out of ideas and right out of time to spend on this.
We could just file a Perl
Bruce Momjian pgman@candle.pha.pa.us writes:
Is there a TODO here, even if the Perl folks are supposed to fix it?
When and if they fix it, it'd be useful for us to document the gotcha
someplace (not sure where, though). Maybe we should even go so far as
to refuse to work with older libperls on
It has probably been sufficiently mitigated on *nix. On Windows, the
choice seems to be between living with the risk and trying my put the
locales back where they were patch, which as Tom and Greg point out
might have other consequences. Take your pick.
cheers
andrew
Bruce Momjian wrote:
I can put it in the Win32 section of the TODO list. If we have
something not working on Win32, I would like to document it.
Is it:
plperl changes the locale in Win32?
---
Andrew Dunstan wrote:
It has probably
Bruce Momjian wrote:
I can put it in the Win32 section of the TODO list. If we have
something not working on Win32, I would like to document it.
Is it:
plperl changes the locale in Win32?
As long as the locale is consistent I think we're OK (is that right, Tom?)
Would that
Andrew Dunstan [EMAIL PROTECTED] writes:
As long as the locale is consistent I think we're OK (is that right, Tom?)
Right.
Would that mean not using any of initdb's locale settings?
Yeah, you'd want to not use the --locale switch for initdb, and also not
to change the system-wide locale
I wrote:
After some analysis of perl's locale.c, I came up with the attached
patch, which seems to cure the previously observed problem on my
Windows box.
Further testing shows the problem persisting. Back to the drawing board.
cheers
andrew
---(end of
I wrote:
Further testing shows the problem persisting. Back to the drawing board.
The attached patch against cvs tip does seem to work. Instead of playing
with the environment, we simply allow perl to do its worst and then put
things back the way we wanted them.
Comments?
cheers
Andrew Dunstan [EMAIL PROTECTED] writes:
The attached patch against cvs tip does seem to work. Instead of playing
with the environment, we simply allow perl to do its worst and then put
things back the way we wanted them.
Doesn't that screw up Perl, though? Its idea of what the locale is
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
The attached patch against cvs tip does seem to work. Instead of playing
with the environment, we simply allow perl to do its worst and then put
things back the way we wanted them.
Doesn't that screw up Perl, though? Its
Andrew Dunstan [EMAIL PROTECTED] writes:
The attached patch against cvs tip does seem to work. Instead of playing
with the environment, we simply allow perl to do its worst and then put
things back the way we wanted them.
How does that affect to the API calls you can make from Perl back
Tom Lane wrote:
Michael Paesold [EMAIL PROTECTED] writes:
This is a theory. The whole database was loaded using pg_restore, I still
have the original dump so I will have a look at the dump now. The database
actually contains some plperl functions.
OK, I think I have reproduced the
Andrew Dunstan [EMAIL PROTECTED] writes:
However, to the best of my knowledge, Windows does NOT consult the
environment when set_locale is called. ISTM we probably need to call
set_locale ourselves on Windows with the desired values.
We already do, during process startup. The question
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
However, to the best of my knowledge, Windows does NOT consult the environment
when set_locale is called. ISTM we probably need to call set_locale ourselves
on Windows with the desired values.
We already do, during process
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
However, to the best of my knowledge, Windows does NOT consult the
environment when set_locale is called. ISTM we probably need to call
set_locale ourselves on Windows with the desired values.
We
Tom Lane wrote:
Michael Paesold [EMAIL PROTECTED] writes:
This is a theory. The whole database was loaded using pg_restore, I still
have the original dump so I will have a look at the dump now. The database
actually contains some plperl functions.
OK, I think I have reproduced the problem.
Tom Lane wrote:
I wrote:
Michael Paesold [EMAIL PROTECTED] writes:
I am seeing a similar unique index bug here...
This is PostgreSQL 8.1.1 on RHEL 3, Intel Xeon (i686).
It looks like the problem is that index entries are being inserted out
of order.
After further investigation, it seems
Michael Paesold [EMAIL PROTECTED] writes:
This is a theory. The whole database was loaded using pg_restore, I still
have the original dump so I will have a look at the dump now. The database
actually contains some plperl functions.
OK, I think I have reproduced the problem. initdb in C
I wrote:
So the mere act of defining a plperl function, even with
check_function_bodies = false, is sufficient to send control through
that bit of libperl code that does setlocale(LC_ALL, ). Ugh.
This is much worse than I thought.
It seems one ingredient in this is that the plperl function
Tom Lane said:
I wrote:
So the mere act of defining a plperl function, even with
check_function_bodies = false, is sufficient to send control through
that bit of libperl code that does setlocale(LC_ALL, ). Ugh.
This is much worse than I thought.
It seems one ingredient in this is that the
Andrew Dunstan [EMAIL PROTECTED] writes:
It should certainly be fixed, but surely at best this would only delay
seeing the ugly locale effect - as soon as you call a perl function you'll
be back in the same boat regardless.
Right, I was not suggesting that fixing the validator would avoid the
Tom Lane said:
Andrew Dunstan [EMAIL PROTECTED] writes:
It should certainly be fixed, but surely at best this would only delay
seeing the ugly locale effect - as soon as you call a perl function
you'll be back in the same boat regardless.
Right, I was not suggesting that fixing the validator
Rod Taylor schrieb:
On Wed, 2005-11-09 at 14:20 -0500, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
As you can see, we have duplicates within the table (heap) of a primary
key value. The index itself only references one of these tuples.
Can you put together a test case to reproduce
Michael Paesold [EMAIL PROTECTED] writes:
I am seeing a similar unique index bug here...
This is PostgreSQL 8.1.1 on RHEL 3, Intel Xeon (i686).
It looks like the problem is that index entries are being inserted out
of order. I find this pair that should be in the other order:
Item 124 --
I wrote:
Michael Paesold [EMAIL PROTECTED] writes:
I am seeing a similar unique index bug here...
This is PostgreSQL 8.1.1 on RHEL 3, Intel Xeon (i686).
It looks like the problem is that index entries are being inserted out
of order.
After further investigation, it seems that the original
On Wed, 2005-11-09 at 14:20 -0500, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
As you can see, we have duplicates within the table (heap) of a primary
key value. The index itself only references one of these tuples.
Can you put together a test case to reproduce this? It doesn't
Oh, and the duplication is not isolated but I only went through the one
case when checking the indexes.
ssdb=# select ctid, xmin, cmin, xmax, account_instance_id, keyword_id
from feature_keyword_supply_google where (account_instance_id,
keyword_id) in (select account_instance_id, keyword_id from
As you can see, we have duplicates within the table (heap) of a primary
key value. The index itself only references one of these tuples.
Nearly all data inserted into this table is wrapped in a subtransaction,
and is created a single tuple per subtransaction. About 20% of entries
are duplicate,
Rod Taylor [EMAIL PROTECTED] writes:
As you can see, we have duplicates within the table (heap) of a primary
key value. The index itself only references one of these tuples.
Can you put together a test case to reproduce this? It doesn't have to
fail every time, as long as it fails once in
On Wed, 2005-11-09 at 14:20 -0500, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
As you can see, we have duplicates within the table (heap) of a primary
key value. The index itself only references one of these tuples.
Can you put together a test case to reproduce this? It doesn't
36 matches
Mail list logo
