Re: [Tigerlead] [BUGS] BUG #5334: Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL 8.4

[Tim Bunce]

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 problem is in perl and Safe but sadly there's no
> > reasonable way to fix Safe such that PostgreSQL would work without
> > changes.
> 
> 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 method without a problem.

Tim.

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #5334: Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL 8.4

[Tim Bunce]

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 you happen to fix it in another way
> with your refactoring?

To be honest I'm not sure. I plan to look into that today.

> Another Idea that comes to mind would be instead of (in ::mksafefunc):
> my $subref = ->reval(sub {} );
> $subref->();
> 
> do:
> my $subref = ->reval(sub {});
> return sub { ->reval("$subreb->();"); }
> 
> or something...
> 
> I did a few quick tests but it failed miserably for me...  Im also not
> fond of adding yet another closure. :)

No amount of closure wrapping will fix the problem.

> > This allows the perl regex logic to call the SWASHNEW method that's
> > called when information from the Unicode character database is needed.
> > (The lack of that method was causing the regex logic to think that the
> > utf8 module wasn't loaded, so it would try to 'require' it but fail due
> > to the restrictions of the Safe compartment.)
> 
> Makes me think we might just be able to share some of utf8 package in the 
> safe?

I tried. The perl utf8.c code does a method lookup of SWASHNEW to decide
if the utf8 module has been loaded. So if SWASHNEW is shared _before_
utf8 is loaded *and used* then the method lookup works (it finds the
shared stub) and the utf8 module never gets loaded.

(The *and used* complication is due to utf8.pm being a thin wrapper with
an AUTOLOAD trampoline that loads utf8_heavy.pl on first use. More fun.)

I do have a patch for Safe that, if utf8 is loaded, will ensure it's
'used' and then auto-share SWASHNEW. That won't fix PostgreSQL 8.x
though because utf8 isn't loaded at the time Safe->new is called.

> > The rest of the patch is updates the surrounding code to the same
> > simplified 'utf8fix' logic used in PostgreSQL 9.0, and the same Safe
> > version checks.
> 
> From a quick look it looks ok.

Thanks.

Tim.

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #5334: Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL 8.4

[Tim Bunce]

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 needed. (Other than it possibly being worthwhile
to detect the 'bad' versions of Safe.)

Tim.

On Fri, Feb 19, 2010 at 09:30:41AM +, 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:
> > > 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 you happen to fix it in another way
> > with your refactoring?
> 
> To be honest I'm not sure. I plan to look into that today.
> 
> > Another Idea that comes to mind would be instead of (in ::mksafefunc):
> > my $subref = ->reval(sub {} );
> > $subref->();
> > 
> > do:
> > my $subref = ->reval(sub {});
> > return sub { ->reval("$subreb->();"); }
> > 
> > or something...
> > 
> > I did a few quick tests but it failed miserably for me...  Im also not
> > fond of adding yet another closure. :)
> 
> No amount of closure wrapping will fix the problem.
> 
> > > This allows the perl regex logic to call the SWASHNEW method that's
> > > called when information from the Unicode character database is needed.
> > > (The lack of that method was causing the regex logic to think that the
> > > utf8 module wasn't loaded, so it would try to 'require' it but fail due
> > > to the restrictions of the Safe compartment.)
> > 
> > Makes me think we might just be able to share some of utf8 package in the 
> > safe?
> 
> I tried. The perl utf8.c code does a method lookup of SWASHNEW to decide
> if the utf8 module has been loaded. So if SWASHNEW is shared _before_
> utf8 is loaded *and used* then the method lookup works (it finds the
> shared stub) and the utf8 module never gets loaded.
> 
> (The *and used* complication is due to utf8.pm being a thin wrapper with
> an AUTOLOAD trampoline that loads utf8_heavy.pl on first use. More fun.)
> 
> I do have a patch for Safe that, if utf8 is loaded, will ensure it's
> 'used' and then auto-share SWASHNEW. That won't fix PostgreSQL 8.x
> though because utf8 isn't loaded at the time Safe->new is called.
> 
> > > The rest of the patch is updates the surrounding code to the same
> > > simplified 'utf8fix' logic used in PostgreSQL 9.0, and the same Safe
> > > version checks.
> > 
> > From a quick look it looks ok.
> 
> Thanks.
> 
> Tim.
> 

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #4785: Installation fails

[big col]

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 Postgres installation wizard). Selecting a diferent
Locale (e.g. English, Australian) would resolve the issue and the
PostgreSQL\8.*\data folder is now created with all the files.

Dave, perhaps the install script needs to be change, so as not to offer this
Default Locale option



goldenhawking wrote:
> 
> En, I have that damm problem sloved.
> Are you using a Non-English Version of Windows? for example, JPN, CHS?
> If you install your PSQL in an Asian-language windows, be sure that
> "locale" settings should be setted manualy to a supported language, I
> choosed "C" for it is the first item in the combo.
> 
> this is the errmsg when you're using default local settings:
> 
> Running the post-installation/upgrade actions:
> Delete the temporary scripts directory...
> Write the base directory to the ini file...
> Write the version number to the ini file...
> Initialising the database cluster (this may take a few minutes)...
> Executing cscript
> Script exit code: 0
> 
> Script output:
> 
> Ensuring we can write to the data directory (using cacls):
> 数据无效。(Means data is unavaliable)
> 
> 
> The files belonging to this database system will be owned by user
> "".
> This user must also own the server process.
> 
> The database cluster will be initialized with locale Chinese_XXX.936.
> initdb: could not find suitable text search configuration for locale
> Chinese_XXX.936
> The default text search configuration will be set to "simple".
> 
> fixing permissions on existing directory D:/XX... ok
> creating subdirectories ... ok
> selecting default max_connections ... 100
> selecting default shared_buffers ... 32MB
> creating configuration files ... ok
> creating template1 database in D:/XXX/base/1 ... ok
> initializing pg_authid ... FATAL:  database locale is incompatible with
> operating system
> DETAIL:  The database was initialized with LC_COLLATE
> "Chinese_.936",  which is not recognized by setlocale().
> HINT:  Recreate the database with another locale or install the missing
> locale.
> child process exited with exit code 1
> initdb: removing contents of data directory "D:/XX"
> 
> Granting service account access to the data directory (using cacls):
> 处理的目录: D:\X(Processed folder:D:\X)
> 
> initcluster.vbs ran to completion
> 
> Script stderr:
> 
> 
> Configuring database server startup...
> Executing cscript
> Script exit code: 0
> 
> Script output:
> startupcfg.vbs ran to completion
> 
> Script stderr:
> 

-- 
View this message in context: 
http://old.nabble.com/BUG--4785%3A-Installation-fails-tp23323059p27649038.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [Tigerlead] [BUGS] BUG #5334: Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL 8.4

[David E. Wheeler]

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 that PostgreSQL would work without
> changes.

Hrm. I don't have this bug with Safe 3.19, FWIW.

Best,

David

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #5334: Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL 8.4

[Alex Hunsaker]

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
> > line.  Did I just miss it?  Or did you happen to fix it in another way
> > with your refactoring?

> To be honest I'm not sure. I plan to look into that today.

My hunch is it has to do with the require strict;  require feature;
That's the only major difference I see (other than the require_op and
it being in its own package/file).

>> I did a few quick tests but it failed miserably for me...  Im also not
>> fond of adding yet another closure. :)
>
> No amount of closure wrapping will fix the problem.

Yeah, brain fart... That's essentially what Safe.pm does now (and why
there is a problem :) )

>> Makes me think we might just be able to share some of utf8 package in the 
>> safe?
>
> I tried. The perl utf8.c code does a method lookup of SWASHNEW to decide
> if the utf8 module has been loaded. So if SWASHNEW is shared _before_
> utf8 is loaded *and used* then the method lookup works (it finds the
> shared stub) and the utf8 module never gets loaded.

Hrm...  That seems wrong to me. Let me see If I can explain why.  The
below is what you seem to be saying:

package utf8;
sub import {  # or maybe this is a BEGIN
  return if(\&{'utf8::SWASHNEW'}; # already loaded
  # ok not loaded open the Unicode database and do junk which will
'trap' in safe
  do 'utf8_heavy.pl';
}

So if we define SWASHNEW without loading the unicode database how will
utf8/unicode work exactly?  I guess as long as it gets loaded at some
point it works.  So for postgres because we do the utf8 fix after
Safe->new and at that point we cant have any 'bad' strings, it will
work. (with your hack).  Sound right?

It seems to me a more correct fix would be to require utf8; inside of
the safe like we do strict.  Sorry thats a bit handwavy.  You have
obviously spent more time then me looking into this...

Im thinking (in pseudo code):

#define SAFE_OK

sub ::mksafefunc {
   permit->(qw(caller require));
   reval->('require utf8; 1;');
   deny->(qw(caller require));
...
}
sub ::mk_strict_safefunc {
...reval->('use strict; require utf8;)

}

static void
plperl_safe_init
{
if (GetDatabaseEncoding() == PG_UTF8)
   {
eval_pv("my $a=pack('U',0xC4); $a =~ /\\xE4\\d/i;", FALSE);
   }

   eval_pv(SAFE_MODULE, FALSE);
   eval_pv(SAFE_OK, FALSE)
}

One thing that stinks is while we might not do the utf8fix if we are
not PG_UTF8 we would always require utf8;.  And I dont see an easy way
around that in 8.4 :(  Also note that is all entirely untested :(  If
you think its sane (and it might not be) Im happy to work up a patch.
Id favor this approach as if you have utf8 strings the likely hood
that you want ::upgrade, ::downgrade, ::encode, ::valid or ::is_utf8
is fairly high.  Then again, no one has complained thus far...  Maybe
thats just me :)

Thoughts?

Anywhoo I cant reproduce this outside of postgres.  Maybe you can give
me a pointer?

use Safe();
binmode(STDOUT, ':utf8');
print $Safe::VERSION . "\n";
my $safe = Safe->new('t');
$safe->permit('print');
$safe->reval('sub { print "\x{263a}\n"; }')->();
print $@ ."\n" if($@);
-
2.22
☺

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #5334: Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL 8.4

[Alex Hunsaker]

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 utf8::VERSION.  SWASHNEW
seems likely to be changed as it "feels" more like a implementation
detail.  But if thats what utf8 checks... well then thats what it
checks.

> Assuming perl5-porters agree then the next release of Safe will do that
> ad this patch won't be needed. (Other than it possibly being worthwhile
> to detect the 'bad' versions of Safe.)

It seems safer if there was some way to 'opt' in say if utf8 was
loaded then make safe do the above.  Or maybe a pragma? use utf8
qw(utf8);   We would still have to patch postgres...  But I can
imagine there are some users of utf8 that dont want utf8 strings.  BTW
as I could not reproduce this does this mean that reval->('"\x{}...")
works while reval->('sub { "\x{}"}') does not ?  Or is it before the
first one failed while the closure based one worked?

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #5334: Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL 8.4

[Alex Hunsaker]

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_utf8
> is fairly high.  Then again, no one has complained thus far...  Maybe
> thats just me :)

On second thought, I dont think we should import any of those by
default.  And your hack for just SWASHNEW is better.

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [Tigerlead] [BUGS] BUG #5334: Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL 8.4

[David E. Wheeler]

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 method without a problem.

Oh, so 2.19 is less secure in that regard, yes?

David


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] Fw: Postgress-Crashing

[somatel.technique]

- 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
Subject: Postgress-Crashing


Hello ,
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 : 


2010-02-12 13:29:10 CETLOG:  le système de bases de données a été interrompu ; 
dernier lancement connu à 2010-02-12 13:26:18 CET
2010-02-12 13:29:10 CETLOG:  le système de bases de données n'a pas été arrêté 
proprement ; restauration
 automatique en cours
2010-02-12 13:29:10 CETLOG:  enregistrement de longueur nulle à 0/53C12D0
2010-02-12 13:29:10 CETLOG:  la ré-exécution n'est pas nécessaire
2010-02-12 13:29:10 CETLOG:  le système de bases de données est prêt pour 
accepter les connexions
2010-02-12 13:29:14 CETLOG:  lancement du processus autovacuum
2010-02-12 13:32:02 CETERREUR:  erreur de syntaxe sur ou près de « est » au 
caractère 43
2010-02-12 13:32:02 CETINSTRUCTION :  UPDATE received set message='m momo oui 
c'est ça 
2010-02-12 13:32:32 CETERREUR:  erreur de syntaxe sur ou près de « est » au 
caractère 43
2010-02-12 13:32:32 CETINSTRUCTION :  UPDATE received set message='m momo oui 
c'est ça 
2010-02-12 13:33:02 CETERREUR:  erreur de syntaxe sur ou près de « est » au 
caractère 43
2010-02-12 13:33:02 CETINSTRUCTION :  UPDATE received set message='m momo oui 
c'est ça 
2010-02-12 13:33:32 CETERREUR:  erreur de syntaxe sur ou près de « est » au 
caractère 43
2010-02-12 13:33:32 CETINSTRUCTION :  UPDATE received set message='m momo oui 
c'est ça 
2010-02-12 13:34:02 CETERREUR:  erreur de syntaxe sur ou près de « est » au 
caractère 43
2010-02-12 13:34:02 CETINSTRUCTION :  UPDATE received set message='m momo oui 
c'est ça 
2010-02-12 13:34:33 CETERREUR:  erreur de syntaxe sur ou près de « est » au 
caractère 43
2010-02-12 13:34:33 CETINSTRUCTION :  UPDATE received set message='m momo oui 
c'est ça 
2010-02-12 13:35:03 CETERREUR:  erreur de syntaxe sur ou près de « est » au 
caractère 43
2010-02-12 13:35:03 CETINSTRUCTION :  UPDATE received set message='m momo oui 
c'est ça 
2010-02-12 13:35:33 CETERREUR:  erreur de syntaxe sur ou près de « est » au 
caractère 43
2010-02-12 13:35:33 CETINSTRUCTION :  UPDATE received set message='m momo oui 
c'est ça 
2010-02-12 13:36:03 CETERREUR:  erreur de syntaxe sur ou près de « est » au 
caractère 43
2010-02-12 13:36:03 CETINSTRUCTION :  UPDATE received set message='m momo oui 
c'est ça 
2010-02-12 13:36:33 CETERREUR:  erreur de syntaxe sur ou près de « est » au 
caractère 43
2010-02-12 13:36:33 CETINSTRUCTION :  UPDATE received set message='m momo oui 
c'est ça 
2010-02-12 13:37:03 CETLOG:  processus serveur (PID 7744) quitte avec le code 
de sortie 128
2010-02-12 13:37:03 CETLOG:  arrêt des autres processus serveur actifs
2010-02-12 13:37:03 CETATTENTION:  arrêt de la connexion à cause de l'arrêt 
brutal d'un autre processus serveur
2010-02-12 13:37:03 CETDÉTAIL:  Le postmaster a commandé à ce processus 
serveur d'annuler la transaction
 courante et de quitter car un autre processus serveur a quitté anormalement
 et qu'il existe probablement de la mémoire partagée corrompue.
2010-02-12 13:37:03 CETASTUCE :  Dans un moment, vous devriez être capable de 
vous reconnecter à la base de
 données et de relancer votre commande.
2010-02-12 13:37:03 CETATTENTION:  arrêt de la connexion à cause de l'arrêt 
brutal d'un autre processus serveur
2010-02-12 13:37:03 CETDÉTAIL:  Le postmaster a commandé à ce processus 
serveur d'annuler la transaction
 courante et de quitter car un autre processus serveur a quitté anormalement
 et qu'il existe probablement de la mémoire partagée corrompue.
2010-02-12 13:37:03 CETASTUCE :  Dans un moment, vous devriez être capable de 
vous reconnecter à la base de
 données et de relancer votre commande.
2010-02-12 13:37:03 CETATTENTION:  arrêt de la connexion à cause de l'arrêt 
brutal d'un autre processus serveur
2010-02-12 13:37:03 CETDÉTAIL:  Le postmaster a commandé à ce processus 
serveur d'annuler la transaction
 courante et de quitter car un autre processus serveur a quitté anormalement
 et qu'il existe probablement de la mémoire partagée corrompue.
2010-02-12 13:37:03 CETASTUCE :  Dans un moment, vous devriez être capable de 
vous reconnecter à la base de
 données et de relancer votre commande.
2010-02-12 13:37:03 CETATTENTION:  arrêt de la connexion à cause de l'arrêt 
brutal d'un autre processus serveur
2010-02-12 13:37:03 CETDÉTAIL:  Le postmaster a commandé à ce processus 
serveur d'annuler la transaction
 courante et de quitter car un autre processus serveur a quitté anormalement
 et qu'il existe probablement de la mémoire partagée corrompue.
2010-02-12 13:37:03 CETASTU

Re: [BUGS] Fw: Postgress-Crashing

[Heikki Linnakangas]

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 debugging this.

> the log is in frensh language i can translate for you the problem , in fact 
> the server process (PID 7744) exited with exit code 128 . 
>  the pid is not always the 7744  every time i had a different pid. the most 
> important thing is the code 128.
> When the problem occure , a message box appear on postgresql telling me that 
> : An Unhandled exception occured , Press "Abort" to terminate the prhram , 
> "Retry" To exit the programe "
> and whatever the choice i choose , the postgress stack and i have to restart 
> it .
> what i do in the server is that i have many windows services developped in 
> java , and all services use the same database for different purpeses 
> What i have to do to resolve that problem ?

Can you narrow down what query or queries causes the crash? Can you
create a self-contained test case to reproduce the crash?

-- 
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [Tigerlead] [BUGS] BUG #5334: Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL 8.4

[Tim Bunce]

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 when the regex executes at
> > runtime the C code looks up the utf8::SWASHNEW method without a problem.
> 
> Oh, so 2.19 is less secure in that regard, yes?

Yes.

When code that was compiled outside the compartment is executed by a
plperl function, including internal regex implementation code, that
code could call eval/require/do etc. and the newly compiled code
wouldn't have any restrictions. With Safe 2.20+ the newly compiled code
is subject to the same restrictions as plperl.

So what we're seeing is the knock-on effects of that tighting of security.
That's why I'd rather move forward rather than back (though there have
been times over the last 48 hours where moving back to Safe 1.19 looked
very appealing :)

Tim.

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #5334: Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL 8.4

[Tim Bunce]

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 hood
> > that you want ::upgrade, ::downgrade, ::encode, ::valid or ::is_utf8
> > is fairly high.  Then again, no one has complained thus far...  Maybe
> > thats just me :)
> 
> On second thought, I dont think we should import any of those by
> default.  And your hack for just SWASHNEW is better.

Here's the corresponding perlbug 
http://rt.perl.org/rt3/Ticket/Display.html?id=72942

I'll retest 8.4 and 9.0 against this on Monday.

Tim.

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] Cache lookup failure for index during pg_dump

[Bob Lunney]

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 for years.  

Recently the job takes a little longer to run and is still going when the 
database dump starts. That's when I started getting this:

ERROR:  cache lookup failed for index 70424
STATEMENT:  SELECT t.tableoid, t.oid, t.relname AS indexname, 
pg_catalog.pg_get_indexdef(i.indexrelid) AS indexdef, t.relnatts AS indnkeys, 
i.indkey, i.indisclustered, c.contype, c.conname, c.tableoid AS contableoid, 
c.oid AS conoid, (SELECT spcname FROM pg_catalog.pg_tablespace s WHERE s.oid = 
t.reltablespace) AS tablespace, array_to_string(t.reloptions, ', ') AS options 
FROM pg_catalog.pg_index i JOIN pg_catalog.pg_class t ON (t.oid = i.indexrelid) 
LEFT JOIN pg_catalog.pg_depend d ON (d.classid = t.tableoid AND d.objid = t.oid 
AND d.deptype = 'i') LEFT JOIN pg_catalog.pg_constraint c ON (d.refclassid = 
c.tableoid AND d.refobjid = c.oid) WHERE i.indrelid = '56448'::pg_catalog.oid 
ORDER BY indexname

The oid value changes daily, of course.  pg_dump then disconnects and stops.  I 
checked the source code and the query is definitely coming from pg_dump.  When 
I run the dump a few minutes later it works beautifully, so I don't think the 
system catalogs are corrupt.

My questions are: can making DDL changes during a dump cause this error?  Are 
the queries used by pg_dump transactionally consistent, i.e. do they run in a 
transaction and get a single view of the database system catalogs?  Other than 
finer coordination of jobs, how can this situation be avoided?

I'm running PG 8.4.1 on linux.

Thanks in advance for your responses.

Bob Lunney


  

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #5334: Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL 8.4

[Alex Hunsaker]

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 favor this approach as if you have utf8 strings the likely hood
>> > that you want ::upgrade, ::downgrade, ::encode, ::valid or ::is_utf8
>> > is fairly high.  Then again, no one has complained thus far...  Maybe
>> > thats just me :)
>>
>> On second thought, I dont think we should import any of those by
>> default.  And your hack for just SWASHNEW is better.

Funny.. Safe.pm already does this (share various utf8:: functions) so
I think there should be no question that what you did in the patch
below is correct and a bug with Safe.  Sorry for the handwaves, that
was me trying to understand the problem and your fix. :)

> Here's the corresponding perlbug 
> http://rt.perl.org/rt3/Ticket/Display.html?id=72942

Hrm... Is the require utf8; strictly needed? A reading of perldoc utf8
seems to say the do { my $unicode = ... } (aka load utf8_heavy.pl)
part should make it all work fine.

It also seems to still work
t/safeutf8.t ... ok

*shrug*

> I'll retest 8.4 and 9.0 against this on Monday.

Ill see if I can squeeze in some pg 8.4 perl 5.10.1 linux x86_64
testing tonight of the above.  (Ill just reply to the perl bug )

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] BUG #5337: PostgreSQL install fails with 1603 error

[Mitesh Patel]

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 fails with exit code 1603.

Any idea?? what could be wrong. I am running install from console. I mean no
RDP and using administrator AD account. 

Thanks,
Mitesh

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #5015: MySQL migration wizard does not start

[Aris Setyawan]

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-MigrationWizard" then i replace
C:\Windows\system32\wscript.exe //NoLogo "C:\Program
Files\PostgreSQL\EnterpriseDB-MigrationWizard\scripts\launchMigrationWizard.vbs"
"" "C:/Program Files/Java/jdk1.5.0_06/jre/bin/java.exe" "-jar
MigrationWizard.jar" "C:\Program
Files\PostgreSQL\EnterpriseDB-MigrationWizard" command with
C:\Windows\system32\wscript.exe //NoLogo "scripts\launchMigrationWizard.vbs"
"" "java.exe" "-jar MigrationWizard.jar" "", and worked.

Re: [BUGS] Cache lookup failure for index during pg_dump

[Tom Lane]

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.   Easy, runs great, has for 
> years.  
> Recently the job takes a little longer to run and is still going when the 
> database dump starts. That's when I started getting this:

> ERROR:  cache lookup failed for index 70424

> My questions are: can making DDL changes during a dump cause this error?  Are 
> the queries used by pg_dump transactionally consistent, i.e. do they run in a 
> transaction and get a single view of the database system catalogs?  Other 
> than finer coordination of jobs, how can this situation be avoided?

It's a bit messy.  pg_dump runs in a serializable transaction, so it
sees a consistent snapshot of the database including system catalogs.
However, it relies in part on various specialized backend functions like
pg_get_indexdef(), and those things tend to run on SnapshotNow time, ie
they look at the currently committed state.  So it is possible to get
this type of error if someone performs DDL changes while a dump is
happening: pg_dump sees index 70424 still listed in the catalogs,
so it asks about it, and the backend says "there is no such index",
which there isn't anymore because somebody dropped it since pg_dump's
transaction started.

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.

The right fix for this is to make all those inquiry functions use the
calling query's snapshot; but duplicating a lot of backend
infrastructure is going to be a major pain in the rear, so the
discussion has kind of petered out every time it's come up in the past.

In practice, because pg_dump does lock out DDL changes for the bulk of
its run, it's not a great idea to be scheduling DDL-changing jobs during
your dumps anyhow.  Most of the time they'll just get blocked till the
dump finishes, and if they touch more than one table it's not at all
unlikely for them to end up deadlocked against pg_dump's locks.  A fix
for the snapshot-timing problem wouldn't do a thing for that problem.

So in short, the path of least resistance is to reschedule your dumps.
Or reconsider whether you really need to drop and recreate those indexes
--- could you use REINDEX instead?

regards, tom lane

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] Cache lookup failure for index during pg_dump

[Euler Taveira de Oliveira]

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 documented anywhere. Should we at least add a comment at the
top of pg_dump documenting this behavior? Attached is a proposed patch using
your own words.


-- 
  Euler Taveira de Oliveira
  http://www.timbira.com/
*** src/bin/pg_dump/pg_dump.c.orig	2010-02-19 23:22:56.0 -0200
--- src/bin/pg_dump/pg_dump.c	2010-02-19 23:43:08.0 -0200
***
*** 11,16 
--- 11,27 
   *	script that reproduces the schema in terms of SQL that is understood
   *	by PostgreSQL
   *
+  *	Note that pg_dump runs in a serializable transaction, so it sees a
+  *	consistent snapshot of the database including system catalogs.
+  *	However, it relies in part on various specialized backend functions
+  *	like pg_get_indexdef(), and those things tend to run on SnapshotNow
+  *	time, ie they look at the currently committed state.  So it is
+  *	possible to get 'cache lookup failed' error if someone performs DDL
+  *	changes while a dump is happening. The window for this sort of thing
+  *	is from the beginning of the serializable transaction to
+  *	getSchemaData() (when pg_dump acquires AccessShareLock on every
+  *	table it intends to dump). It isn't very large but it can happen.
+  *
   * IDENTIFICATION
   *	  $PostgreSQL$
   *

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #5015: MySQL migration wizard does not start

[Robert Haas]

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 change directory to "C:\Program
> Files\PostgreSQL\EnterpriseDB-MigrationWizard" then i replace
> C:\Windows\system32\wscript.exe //NoLogo "C:\Program
> Files\PostgreSQL\EnterpriseDB-MigrationWizard\scripts\launchMigrationWizard.vbs"
> "" "C:/Program Files/Java/jdk1.5.0_06/jre/bin/java.exe" "-jar
> MigrationWizard.jar" "C:\Program
> Files\PostgreSQL\EnterpriseDB-MigrationWizard" command with
> C:\Windows\system32\wscript.exe //NoLogo "scripts\launchMigrationWizard.vbs"
> "" "java.exe" "-jar MigrationWizard.jar" "", and worked.

This is not a PostgreSQL bug.  Sounds like you need to contact
EnterpriseDB.  To quote from the bug reporting form:

"This bug report form should only be used for reporting bugs and
problems with the PostgreSQL database. Problems with database
connectors such as ODBC and JDBC, graphical administration tools such
as pgAdmin or other external projects should not be reported here;
please report to those projects directly. For products closely
connected with PostgreSQL, there may be an appropriate mailing list
available."

Robert

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs