The following bug has been logged online:
Bug reference: 3723
Logged by: Sam Mason
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: Linux
Description:dropping an index that doesn't refer to table's columns
Details:
Hi,
I've just discover
The following bug has been logged online:
Bug reference: 3722
Logged by: Henning Nitschke
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2
Operating system: Java
Description:PSQLWarning missing call to super in CTOR
Details:
public PSQLWarning(ServerErrorMes
"Sam Mason" <[EMAIL PROTECTED]> writes:
> I've just discovered that an index that doesn't refer to any of its table's
> columns isn't automatically dropped when its table is.
A straightforward solution would be to ban such "indexes".
> p.s. the reason for creating this strange index was to ensure
Tom Lane wrote:
"Sam Mason" <[EMAIL PROTECTED]> writes:
p.s. the reason for creating this strange index was to ensure that a maximum
of one row was inserted into the table---I can do this different ways for
now.
Please explain how you thought it would help you do that, because
without some evi
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Please explain how you thought it would help you do that, because
>> without some evidence that there's a use-case, I'm inclined to fix it
>> as above ...
> Note that it was a unique index:
Missed that --- obviously need more caf
On Tue, Nov 06, 2007 at 10:00:43AM -0500, Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > Not sure that's enough of a use case to justify not banning it...
>
> Yeah, it probably is.
It's reasonably easy to do this instead:
CREATE TABLE foo (
one INTEGER NOT NULL UNIQUE
The following bug has been logged online:
Bug reference: 3724
Logged by: Mason Hale
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: Redhat Linux (kernel: Linux 2.6.18-8.1.15.el5PAE)
Description:Duplicate values added to table despite uniqu
"Mason Hale" <[EMAIL PROTECTED]> writes:
> However running the same query on the original 8.2.4 database returns zero
> rows:
> prod_1=> select page_id, count(*) from topic_version_page where
> topic_version_id = 263 group by 1 having count(*) > 1;
> page_id | count
> -+---
> (0 rows
On Nov 6, 2007 11:16 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mason Hale" <[EMAIL PROTECTED]> writes:
> > However running the same query on the original 8.2.4 database returns
> zero
> > rows:
>
> > prod_1=> select page_id, count(*) from topic_version_page where
> > topic_version_id = 263 group
Hi *:
Martin Pitt escribió:
Hi,
Tom Lane [2007-11-03 14:27 -0400]:
Martin Pitt <[EMAIL PROTECTED]> writes:
The testsuite of 8.3 beta 2 fails on the Alpha architecture (versions
up to 8.2 worked fine).
We redid some of the float error handling for 8.3, in hopes of getting
closer to the IEEE s
The following bug has been logged online:
Bug reference: 3725
Logged by: Roger
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3 beta 2
Operating system: Windows/Linux
Description:plsql does not report unknown functions at compile time
Details:
Hi,
At compil
=?ISO-8859-1?Q?=22Jos=E9_Luis_Rivero_=28yoswink=29=22?= <[EMAIL PROTECTED]>
writes:
> Since Debian is having some problems with its alpha development machine,
> the Gentoo/Alpha port is happy to offer some help with this problem.
> We can provide with shell account access (or even a chroot) in o
"Roger" <[EMAIL PROTECTED]> writes:
> At compile time, plpgsql does not report unknown functions. For example, if
> I have a function.
> p_Func(a,b,c)
> and I have calls to it such as:
> p_Func(a)
> p_Func(a,b)
> these are not reported at compile time. They are only found at run time.
This
"Mason Hale" <[EMAIL PROTECTED]> writes:
>> For that matter, do you still see dups if you prevent use of the index
>> in the 8.2.5 query? Maybe it's that index that is corrupt.
> Unfortunately, I'm not able to test that at this point.
> To get our production db (the 8.2.5 instance) back in operat
On Tue, 6 Nov 2007, Henning Nitschke wrote:
Bug reference: 3722
PostgreSQL version: 8.2
Operating system: Java
Description:PSQLWarning missing call to super in CTOR
Details:
public PSQLWarning(ServerErrorMessage err)
{
super(err.toString()); // <== missing
this.serverError =
Hi!
On Tue, 06 Nov 2007, Tom Lane wrote:
> If you could set me up a shell account accessible by ssh, I should have
> time to poke at this tomorrow. I don't need root access but will need
> all the usual C development tools (gcc, gdb, etc).
Just send me a (preferably signed) mail with desired us
I don't have a full test case yet, but I did finally manage to get an
explain analyze to finish in a sane amount of time on 8.2.5. Attached
are two cleaned up explain analyze results, using the exact same data
directory but different executables: one is 8.2.3 and returns as
expected, the other is 8
On Nov 6, 2007 1:06 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mason Hale" <[EMAIL PROTECTED]> writes:
> >> For that matter, do you still see dups if you prevent use of the index
> >> in the 8.2.5 query? Maybe it's that index that is corrupt.
>
> > Unfortunately, I'm not able to test that at this
"Mason Hale" <[EMAIL PROTECTED]> writes:
> On Nov 6, 2007 1:06 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Mph. I'm afraid the evidence is mostly gone then, and we probably won't
>> be able to figure out what happened.
> Sorry about that. But I had to get things back up and running.
Understood, b
On Tue, Nov 06, 2007 at 12:52:34PM -0500, Tom Lane wrote:
> =?ISO-8859-1?Q?=22Jos=E9_Luis_Rivero_=28yoswink=29=22?= <[EMAIL PROTECTED]>
> writes:
> > Since Debian is having some problems with its alpha development machine,
> > the Gentoo/Alpha port is happy to offer some help with this problem.
Greg Sabino Mullane <[EMAIL PROTECTED]> writes:
> I don't have a full test case yet, but I did finally manage to get an
> explain analyze to finish in a sane amount of time on 8.2.5. Attached
> are two cleaned up explain analyze results, using the exact same data
> directory but different executabl
I wrote:
> This might be a bug in the LIKE estimator (if so, it's in 8.2.3 as
> well). I don't have time to look closer right now, but can you show us
> the pg_stats row for orders_smaller.order_number?
Oh, never mind that ... on inspection, the NOT LIKE selectivity
estimator is obviously broken:
22 matches
Mail list logo
