,
PostgreSQL Development
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 a
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 se
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 mea
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
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:
Bruce Momjian 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 Windows.
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
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 ou
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
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
> platform
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
unconditio
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
> > reacts to whatever the current settings are, I think, but I could be wrong.
>
> If that's the case, why would it be bothering
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> AFAICT, perl doesn't keep any state about locale settings, it just
> reacts to whatever the current settings are, I think, but I could be wrong.
If that's the case, why would it be bothering to issue setlocale during
startup at all? If you look in loc
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 call
> 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 P
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 i
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 i
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
and
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 broad
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 al
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 <[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 b
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
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 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 t
"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 avoi
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
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 funct
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
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
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 or
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 --
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 t
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 d
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 d
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 a
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, so
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
f
38 matches
Mail list logo