On Thu, Feb 18, 2010 at 01:36:59PM -0800, David E. Wheeler wrote:
> On Feb 18, 2010, at 10:09 AM, Tim Bunce wrote:
>
> > It took a depressingly large number of intense hours to work out what
> > was going on and then more to try to work out a relatively clean solution.
> >
> > The underlying prob
On Thu, Feb 18, 2010 at 11:32:38AM -0700, Alex Hunsaker wrote:
> On Thu, Feb 18, 2010 at 11:09, Tim Bunce wrote:
> > The key line is:
> >
> > *PLPerl::utf8::SWASHNEW = \&utf8::SWASHNEW;
>
> Hrm... It seems to work for me in HEAD and AFAICS we dont have that
> line. Did I just miss it? Or did
I've got the patch to Safe ready but the more I think about it the more
I think the right fix is for Safe to automatically fully load utf8.pm
(and utf8_heavy.pl) and to always share SWASHNEW itself.
Assuming perl5-porters agree then the next release of Safe will do that
ad this patch won't be need
Please Note that this problem is caused even with an English version of
Windows.
I tried 3 different versions of PostGres (8.3.7.1 , 8.3.7.2, and 8.4) and
they all gave this same, annoying problem.
The problem is caused by using the first (default) option for the Locale
(i.e. as prompted in the
On Feb 18, 2010, at 10:09 AM, Tim Bunce wrote:
> It took a depressingly large number of intense hours to work out what
> was going on and then more to try to work out a relatively clean solution.
>
> The underlying problem is in perl and Safe but sadly there's no
> reasonable way to fix Safe such
On Fri, Feb 19, 2010 at 02:30, Tim Bunce wrote:
> On Thu, Feb 18, 2010 at 11:32:38AM -0700, Alex Hunsaker wrote:
> > On Thu, Feb 18, 2010 at 11:09, Tim Bunce wrote:
> >*PLPerl::utf8::SWASHNEW = \&utf8::SWASHNEW;
> >
> > Hrm... It seems to work for me in HEAD and AFAICS we dont have that
> > l
On Fri, Feb 19, 2010 at 06:06, Tim Bunce wrote:
> I've got the patch to Safe ready but the more I think about it the more
> I think the right fix is for Safe to automatically fully load utf8.pm
> (and utf8_heavy.pl) and to always share SWASHNEW itself.
It seems cleaner if we could just share say
On Fri, Feb 19, 2010 at 09:18, Alex Hunsaker wrote:
> It seems to me a more correct fix would be to require utf8; inside of
> the safe like we do strict.
>
> Id favor this approach as if you have utf8 strings the likely hood
> that you want ::upgrade, ::downgrade, ::encode, ::valid or ::is_ut
On Feb 19, 2010, at 1:13 AM, Tim Bunce wrote:
>> Hrm. I don't have this bug with Safe 3.19, FWIW.
>
> That's because Safe 1.19 (which I presume you meant) doesn't execute
> closures 'inside' the Safe compartment. So when the regex executes at
> runtime the C code looks up the utf8::SWASHNEW metho
- Original Message -
From: somatel.technique
To: majordomo-ow...@postgresql.org
Sent: Monday, February 15, 2010 11:03 AM
Subject: Postgress-Crashing
- Original Message -
From: somatel.technique
To: majordomo-ow...@postgresql.org
Sent: Monday, February 15, 2010 11:03 AM
Sub
somatel.technique wrote:
> I use potgres 8.4.1 in my server turning on system sql server 2003. i have
> some troubles with Postgres it crash this is the log i had :
You should upgrade to 8.4.2. I don't know if there was any related fixes
in it, but it's trying first before spending more time d
On Fri, Feb 19, 2010 at 09:00:59AM -0800, David E. Wheeler wrote:
> On Feb 19, 2010, at 1:13 AM, Tim Bunce wrote:
>
> >> Hrm. I don't have this bug with Safe 3.19, FWIW.
> >
> > That's because Safe 1.19 (which I presume you meant) doesn't execute
> > closures 'inside' the Safe compartment. So whe
On Fri, Feb 19, 2010 at 09:32:38AM -0700, Alex Hunsaker wrote:
> On Fri, Feb 19, 2010 at 09:18, Alex Hunsaker wrote:
> > It seems to me a more correct fix would be to require utf8; inside of
> > the safe like we do strict.
> >
> > Id favor this approach as if you have utf8 strings the likely
I have a job that summarizes some data from a table, truncates the table, drops
the indexes, writes the summarized data back into the table, then recreates the
indexes. The operations above are not in a single transaction, but separate
statements executed by a script. Easy, runs great, has fo
On Fri, Feb 19, 2010 at 14:00, Tim Bunce wrote:
> On Fri, Feb 19, 2010 at 09:32:38AM -0700, Alex Hunsaker wrote:
>> On Fri, Feb 19, 2010 at 09:18, Alex Hunsaker wrote:
>> > It seems to me a more correct fix would be to require utf8; inside of
>> > the safe like we do strict.
>> >
>> > Id fav
The following bug has been logged online:
Bug reference: 5337
Logged by: Mitesh Patel
Email address: pmite...@yahoo.com
PostgreSQL version: 8.2.15
Operating system: Windows 2003
Description:PostgreSQL install fails with 1603 error
Details:
PostgreSQL 8.2 install fai
I didn't update the MigrationWizard.jar file, because download link was
error. In my command prompt, I change dir to "EnterpriseDB-MigrationWizard"
directory then change some full path file to relative path file. In my
environment, i change directory to "C:\Program
Files\PostgreSQL\EnterpriseDB-Mig
Bob Lunney writes:
> I have a job that summarizes some data from a table, truncates the table,
> drops the indexes, writes the summarized data back into the table, then
> recreates the indexes. The operations above are not in a single transaction,
> but separate statements executed by a script
Tom Lane escreveu:
> The window for this sort of thing isn't very large, because the first
> thing pg_dump does is acquire AccessShareLock on every table it intends
> to dump, and past that point it won't be possible for anyone to modify
> the table's DDL. But it can happen.
>
I did not see it do
On Fri, Feb 19, 2010 at 5:51 PM, Aris Setyawan wrote:
> I didn't update the MigrationWizard.jar file, because download link was
> error. In my command prompt, I change dir to "EnterpriseDB-MigrationWizard"
> directory then change some full path file to relative path file. In my
> environment, i ch
20 matches
Mail list logo
