I reindexed everything and vacuumed. The system tables and our tables. It
didn't work. I get the following:
pg_dump: finding the columns and types of table "bsc_day1_001"
pg_dump: finding default expressions of table "bsc_day1_001"
Prosessi palautti lopetuskoodin -1073741819 | (lopetuskoodin =
Dear Tom, thank you for the explanation.
2010/2/24 Tom Lane
> "Zoltan Kovacs" writes:
> > I would like to create a database using SQL_ASCII encoding, but it is not
> > allowed for a normal user, only for the postgres user.
>
> There is an exception that will allow superusers to do that, but it'
Thanks!, when it will be released on 8.3.X?
On Wed, Feb 24, 2010 at 6:17 PM, Tom Lane wrote:
> Oleg Serov writes:
> > When it could be fixed?
>
> Oh, it is fixed, but I forgot to reply to this thread about it.
> Sorry about that.
>
>regards, tom lane
>
--
С уважением
=?UTF-8?B?S292w6FjcyBab2x0w6Fu?= writes:
> What can happen if I use an unsafe combination? Can the backend unexpectedly
> die? Can this cause data corruption?
Inconsistent ordering results and index corruption can be expected at
minimum. I'm not sure about actual crashes. Try looking through
th
Maximiliano Salazar skrev:
The following bug has been logged online:
Bug reference: 5346
Logged by: Maximiliano Salazar
Email address: maxisala...@hotmail.com
PostgreSQL version: 8.2
Operating system: Windows 7 Ultimate 64 Bits
Description:PostgresSQL ODBC 64 bits do
On Thu, Feb 25, 2010 at 12:20, Tom Lane wrote:
> Alex Hunsaker writes:
>> 3) patch postgres to fix the recursive issue (What I'm leaning towards)
>> [ fixes both issues ]
>
> How exactly would you propose doing that?
Well that's the thing, probably by what I described below that. Namely
get some
On Feb 25, 2010, at 11:29 AM, Alex Hunsaker wrote:
> Well that's the thing, probably by what I described below that. Namely
> get something working for 9.1 and after we know its good and solid see
> if we can back patch it. Unfeasible? If its really really simple and
> straight forward maybe we
On Thu, Feb 25, 2010 at 1:58 AM, Toni Helenius
wrote:
> I reindexed everything and vacuumed. The system tables and our tables. It
> didn't work. I get the following:
>
>
> pg_dump: finding the columns and types of table "bsc_day1_001"
> pg_dump: finding default expressions of table "bsc_day1_001"
2010/2/25 Oleg Serov :
> Thanks!, when it will be released on 8.3.X?
Looks like the last set of back-branch releases was wrapped 12/10/09,
the set before that on 9/4/09, and the previous set on 3/13/09 (but
there was a major release in the mix there). So I'd guess we're
getting close to it being
On Wed, Feb 24, 2010 at 10:58:17PM -0500, Tom Lane wrote:
> Alex Hunsaker writes:
> > On Wed, Feb 24, 2010 at 20:37, Alex Hunsaker wrote:
> >> On Wed, Feb 24, 2010 at 20:19, Tom Lane wrote:
> >>> Seems entirely unacceptable.
>
> >> I think we will see if we can get this fixed on the Safe/perl s
On Feb 25, 2010, at 10:01 AM, Tim Bunce wrote:
>> That's two unacceptable alternatives, you need to find a third one.
>> I think most people will have no trouble settling on "do not update
>> to Safe 2.2x" if you don't offer a better solution than these.
>
> I believe the next version of Safe wil
On Thu, Feb 25, 2010 at 11:04, David E. Wheeler
wrote:
> There seem to be no good answers here.
Yeah, Here is the thing I don't think we can fix 'safe' or even patch
perl to get recursive calls to work. Maybe Tim sees a way? We can
work around it in 9.0 with plperl.on_init. But breaking the ba
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Well that's the thing, probably by what I described below that. Namely
> get something working for 9.1 and after we know its good and solid see
> if we can back patch it.
Just don't break anything in 9.0 that relies on plperl please. :) To th
On Thu, Feb 25, 2010 at 12:59, Greg Sabino Mullane wrote:
> Just don't break anything in 9.0 that relies on plperl please. :) To that
> end, let me know when HEAD has something somewhat stable, and I'll
> run some tests against it (e.g. Bucardo, which uses lots of plperl)
Defiantly, the goal is t
On Thu, Feb 25, 2010 at 13:03, Alex Hunsaker wrote:
> On Thu, Feb 25, 2010 at 12:59, Greg Sabino Mullane wrote:
>> Just don't break anything in 9.0 that relies on plperl please. :) To that
>> end, let me know when HEAD has something somewhat stable, and I'll
>> run some tests against it (e.g. Buc
On Thu, Feb 25, 2010 at 12:31, David E. Wheeler
wrote:
> I think Tom meant, what sorts of changes to PostgreSQL do you think might
> solve the problem?
Here is what Tim said:
>Doesn't seem too icky. Basically plperl would need to save the values of
>PL_defstash, PL_incgv and PL_op_mask when a pl
On Thu, Feb 25, 2010 at 10:04:44AM -0800, David E. Wheeler wrote:
> On Feb 25, 2010, at 10:01 AM, Tim Bunce wrote:
>
> >> That's two unacceptable alternatives, you need to find a third one.
> >> I think most people will have no trouble settling on "do not update
> >> to Safe 2.2x" if you don't off
On Feb 25, 2010, at 12:58 PM, Tim Bunce wrote:
>> Which means losing sort $a <=> $b again, alas. Such was always the
>> case in the past, so that might be an okay tradeoff to get recursive
>> calls working again, but I certainly hope that Safe can be updated in
>> the near future to give us both.
Tim Bunce writes:
> On Thu, Feb 25, 2010 at 10:04:44AM -0800, David E. Wheeler wrote:
>> There seem to be no good answers here.
> There is one fairly good answer:
> Use a perl that's compiled to support multiplicity but not threads.
> That avoids the sort bug and, as an extra bonus, gives plperl
On Thu, Feb 25, 2010 at 14:06, David E. Wheeler
wrote:
> On Feb 25, 2010, at 12:58 PM, Tim Bunce wrote:
>> There is one fairly good answer:
>>
>> Use a perl that's compiled to support multiplicity but not threads.
> That solves the problem with recursion or with $a and $b or both?
Yes ATM becaus
On Feb 25, 2010, at 1:08 PM, Alex Hunsaker wrote:
>> That solves the problem with recursion or with $a and $b or both?
>
> Yes ATM because we only kick in the extra security if you are on
> threads... Its a bit of a kludge in Safe. I know Tim wants to rectify
> that...
By adding the extra secur
On Feb 25, 2010, at 10:01 AM, Tim Bunce wrote:
>> That's two unacceptable alternatives, you need to find a third one.
>> I think most people will have no trouble settling on "do not update
>> to Safe 2.2x" if you don't offer a better solution than these.
>
> I believe the next version of Safe wil
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Anybody know what Oracle's to_timestamp does?
>
> > The old thread reported Oracle returned an error;
> > http://archives.postgresql.org/pgsql-bugs/2009-06/msg00100.php
>
> Well, nothing's likely to get done about it for 9.0.
On Thu, Feb 25, 2010 at 04:06:51PM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > On Thu, Feb 25, 2010 at 10:04:44AM -0800, David E. Wheeler wrote:
> >> There seem to be no good answers here.
>
> > There is one fairly good answer:
>
> > Use a perl that's compiled to support multiplicity but not
Alex Hunsaker writes:
> 3) patch postgres to fix the recursive issue (What I'm leaning towards)
> [ fixes both issues ]
How exactly would you propose doing that?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your su
I can reproduce this but in current CVS by installing /contrib/intarray.
---
Joerg Kiegeland wrote:
>
> The following bug has been logged online:
>
> Bug reference: 4806
> Logged by: Joerg Kiegeland
> Email a
Where are we on this? The 9.0 behavior is the same.
---
Arjen Nienhuis wrote:
>
> The following bug has been logged online:
>
> Bug reference: 4769
> Logged by: Arjen Nienhuis
> Email address: a.g.nienh
Was this ever addressed?
---
Jeff Davis wrote:
> On Thu, 2009-03-26 at 21:45 -0400, Bruce Momjian wrote:
> > > http://archives.postgresql.org/pgsql-bugs/2009-03/msg00062.php
> > >
> > > It may or may not be a real bug, but
I wrote:
> * $(GENERATED_SGML) is removed by make clean, therefore also by
> make distclean
> Ergo, this type of failure is *guaranteed* when trying to build
> from a distribution tarball. This needs to be rethought.
I looked at this some more, and this time I noticed that the makefile
has
.SECO
Tom Lane wrote:
> I wrote:
>> * $(GENERATED_SGML) is removed by make clean, therefore also by
>> make distclean
>> Ergo, this type of failure is *guaranteed* when trying to build
>> from a distribution tarball. This needs to be rethought.
>
> I looked at this some more, and this time I noticed th
Now, you've reminded me of something: That one or more versions of tar have
trouble with very long file/directory names
I've run into this with one of the source trees we've been working in - was it
here in PostgreSQL? Could this be a culprit?
- Original Message -
From: "Joseph Conw
Lou Picciano writes:
> Now, you've reminded me of something: That one or more versions of tar have
> trouble with very long file/directory names
> I've run into this with one of the source trees we've been working in - was
> it here in PostgreSQL? Could this be a culprit?
I believe we dealt w
32 matches
Mail list logo
