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 t...@sss.pgh.pa.us
Zoltan Kovacs kov...@particio.com 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
Thanks!, when it will be released on 8.3.X?
On Wed, Feb 24, 2010 at 6:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Oleg Serov sero...@gmail.com writes:
When it could be fixed?
Oh, it is fixed, but I forgot to reply to this thread about it.
Sorry about that.
regards,
=?UTF-8?B?S292w6FjcyBab2x0w6Fu?= kov...@particio.com 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
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
On Thu, Feb 25, 2010 at 12:20, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com 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
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 can
On Thu, Feb 25, 2010 at 1:58 AM, Toni Helenius
toni.helen...@syncrontech.com 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
2010/2/25 Oleg Serov sero...@gmail.com:
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
On Wed, Feb 24, 2010 at 10:58:17PM -0500, Tom Lane wrote:
Alex Hunsaker bada...@gmail.com writes:
On Wed, Feb 24, 2010 at 20:37, Alex Hunsaker bada...@gmail.com wrote:
On Wed, Feb 24, 2010 at 20:19, Tom Lane t...@sss.pgh.pa.us wrote:
Seems entirely unacceptable.
I think we will see if
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 will revert
On Thu, Feb 25, 2010 at 11:04, David E. Wheeler
david.whee...@pgexperts.com 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
-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 that
On Thu, Feb 25, 2010 at 13:03, Alex Hunsaker bada...@gmail.com wrote:
On Thu, Feb 25, 2010 at 12:59, Greg Sabino Mullane g...@turnstep.com 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
On Thu, Feb 25, 2010 at 12:31, David E. Wheeler
david.whee...@pgexperts.com 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
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 offer a better
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.
There
Tim Bunce tim.bu...@pobox.com 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
On Thu, Feb 25, 2010 at 14:06, David E. Wheeler
david.whee...@pgexperts.com 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
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 security
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 will revert
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
On Thu, Feb 25, 2010 at 04:06:51PM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com 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
Alex Hunsaker bada...@gmail.com 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
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
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:
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 didn't
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
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 that the
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
Lou Picciano loupicci...@comcast.net 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?
31 matches
Mail list logo
