I found this error message in my log files repeatedly:
Error: failed to re-find parent key in ledgerdetail_2008_03_idx2 for
deletion target page 64767
I though hmm, that index looks broken. I'd better re-create it. So, I
dropped the index and then tried to create a new one to replace it. Which
Hi,
I'm getting following error while envoking psql:
$ psql
psql: symbol lookup error: /usr/lib/libreadline.so.5: undefined symbol: BC
This is Linux glibc 2.3.4 and readline 5.1.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Jeffrey Baker wrote:
The way I read it, the current btree index stores the index value and the
TID of every tuple having that value. When you have a table with three
columns, you index one of them and you get an index which is practically as
large as the table itself.
Supposing the table is
Andrew Hammond wrote:
I found this error message in my log files repeatedly:
Error: failed to re-find parent key in ledgerdetail_2008_03_idx2 for
deletion target page 64767
I though hmm, that index looks broken. I'd better re-create it. So, I
dropped the index and then tried to create a new
Hello !
I'm trying to use postgresql in an application that by design will give
access to users to a subset of the database.
For example for customers access to products_view (wich will only show
public offers), orders (only their own orders).
I'll provide an application as user interface for
Hello !
I'm trying to use postgresql in an application that by design will give
access to users to a subset of the database.
For example for customers access to products_view (wich will only show
public offers), orders (only their own orders).
I'll provide an application as user interface for
Hi,
After pondering on the problem for quite some time and discussing it on IRC
with RhodiumToad I thought the most sensible thing is to post the problem
here (as RhodiumToad suggested as well).
The original (although already quite reduced) problematic query and the
related plan:
On Wed, Jun 25, 2008 at 2:58 AM, Heikki Linnakangas [EMAIL PROTECTED]
wrote:
Andrew Hammond wrote:
I found this error message in my log files repeatedly:
Error: failed to re-find parent key in ledgerdetail_2008_03_idx2 for
deletion target page 64767
I though hmm, that index looks broken.
Mark,
Not that I disagree with your change, but 5 Mbytes in 4 Gbytes of RAM
for my main PostgreSQL system that I manage seems like a drop in the
bucket. Even if 40% of pg_class_relname and pg_proc_proname indices was
saved - we're talking about 154 Kbytes saved on both those indices
I have a VIEW that consists of two tables, of which contain a POINT
column. When trying to select from the view I get an error...
ERROR: could not identify an ordering operator for type point
HINT: Use an explicit ordering operator or modify the query.
Any suggestions??? -Nick
--
Sent via
Nick wrote:
I have a VIEW that consists of two tables, of which contain a POINT
column. When trying to select from the view I get an error...
ERROR: could not identify an ordering operator for type point
HINT: Use an explicit ordering operator or modify the query.
Any suggestions??? -Nick
Howdy,
I just wanted to report the latest on my pet project: implementing a
new case-insensitive text type, citext, to be locale-aware and to
build and run on PostgreSQL 8.3. I'm not much of a C programmer (this
is only the second time I've written *anything* in C), so I also have
a few
Hi,
I noticed the other day that the branches in the GIT postgresql.git
repository do not contain any patch after it was released. For example,
in
http://git.postgresql.org/?p=postgresql.git;a=shortlog;h=REL8_3_STABLE
the last commit is on 2008-02-12. For example this commit is not there:
Tatsuo Ishii [EMAIL PROTECTED] writes:
I'm getting following error while envoking psql:
$ psql
psql: symbol lookup error: /usr/lib/libreadline.so.5: undefined symbol: BC
I believe this is the typical symptom of failing to link to the correct
variant of curses/termcap needed by readline. We
Nope, im not ordering by the POINT column. Heres an example...
CREATE TABLE table1 (
title character varying,
sorter integer,
xy point
);
CREATE TABLE table2 (
title character varying,
sorter integer,
xy point
);
INSERT INTO table1 VALUES ('one', 1, '(1,1)');
INSERT INTO
Tatsuo Ishii ishii(at)postgresql(dot)org writes:
I'm getting following error while envoking psql:
$ psql
psql: symbol lookup error: /usr/lib/libreadline.so.5: undefined symbol: BC
I believe this is the typical symptom of failing to link to the correct
variant of curses/termcap needed by
Nick wrote:
Nope, im not ordering by the POINT column. Heres an example...
CREATE VIEW myview AS
SELECT table1.title, table1.sorter, table1.xy FROM table1 UNION
SELECT table2.title, table2.sorter, table2.xy FROM table2;
Hmm, the error seems to be coming from UNION. It's because Postgres
Tatsuo Ishii [EMAIL PROTECTED] writes:
So the difference seems:
--as-needed -Wl,
is added to CVS Head.
There is code in configure that's supposed to check whether or not that
breaks readline. Would you look at the portion of config.log where it
tests that, and see why it failed to notice a
Tatsuo Ishii [EMAIL PROTECTED] writes:
So the difference seems:
--as-needed -Wl,
is added to CVS Head.
There is code in configure that's supposed to check whether or not that
breaks readline. Would you look at the portion of config.log where it
tests that, and see why it failed to
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= [EMAIL PROTECTED] writes:
All three try to sort the table first, and as there's no comparision
operator for the POINT datatype, they fail. Which seems to be wrong - if
there is no comparision operator, you still can do DISTINCT, only less
efficiently.
Type
Tatsuo Ishii [EMAIL PROTECTED] writes:
It seems configure only checks whether linking was successful. I think
it should check whether ./conftest was successful.
Wouldn't work when cross-compiling. What platform is this exactly?
regards, tom lane
--
Sent via
Tatsuo Ishii [EMAIL PROTECTED] writes:
It seems configure only checks whether linking was successful. I think
it should check whether ./conftest was successful.
Wouldn't work when cross-compiling.
But configure already does this, doesn't it?
configure:24466: checking for working memcmp
Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= [EMAIL PROTECTED] writes:
All three try to sort the table first, and as there's no comparision
operator for the POINT datatype, they fail. Which seems to be wrong - if
there is no comparision operator, you still can do DISTINCT, only less
Tatsuo Ishii [EMAIL PROTECTED] writes:
What platform is this exactly?
The Linux distributions is Vine Linux, which is a variant of Red Hat
Linux (I think).
If it's rpm-based, could we see the RPM package version numbers for
binutils, readline, and ncurses?
regards,
The Linux distributions is Vine Linux, which is a variant of Red Hat
Linux (I think).
If it's rpm-based, could we see the RPM package version numbers for
binutils, readline, and ncurses?
Sure.
binutils-2.15.92.0.2-5vl2
readline-5.1-0vl1
readline-devel-5.1-0vl1
ncurses-devel-5.4-0vl3
Thanks for all yours suggestions, use cases and opinion about this
thread, I saw that there are more things to consider than I was
thinking and this make me consider that it is a hard work to do for
now.
--
[]s
Dickson S. Guedes
-
Projeto Colmeia - Curitiba -
On Sat, May 24, 2008 at 12:27 AM, Dickson S. Guedes [EMAIL PROTECTED] wrote:
Hi all,
These patch implements the TODO item: Have psql show current values
for a sequence.
Hi all,
There are some comments or suggestions about this patch?
Thanks all.
--
[]s
Dickson S. Guedes
Mark Mielke [EMAIL PROTECTED] writes:
The problem here seems to that point should have an equality operator?
For starters ;-). The current implementation of UNION requires it to
have a complete btree opclass. In principle I suppose we could
implement hash-based DISTINCT, which would require
Tatsuo Ishii [EMAIL PROTECTED] writes:
binutils-2.15.92.0.2-5vl2
readline-5.1-0vl1
readline-devel-5.1-0vl1
ncurses-devel-5.4-0vl3
ncurses-5.4-0vl3
Okay, it seems fairly close to RHEL-4 --- at least almost the same
version of binutils, which is probably what counts here. Doesn't
look like
Mark Mielke wrote:
Tom Lane wrote:
Type point has no btree opclass, no hash opclass, and not even an
operator named = (it looks like the functionality is named ~=
for some odd reason). I'd be interested to hear either a proposal of
a principled way to define DISTINCT, or a way to implement it
i am studying the source code of postgresql and want to become a developer of
it.What should i do?
thanks
_
Explore the seven wonders of the world
http://search.msn.com/results.aspx?q=7+wonders+worldmkt=en-USform=QBRE
Nick wrote:
I have a VIEW that consists of two tables, of which contain a POINT
column. When trying to select from the view I get an error...
ERROR: could not identify an ordering operator for type point
HINT: Use an explicit ordering operator or modify the query.
Any suggestions???
I wrote:
Okay, it seems fairly close to RHEL-4 --- at least almost the same
version of binutils, which is probably what counts here.
I was able to reproduce the problem on current RHEL-4, and on
examination I don't think it's really ld's fault. The problem is that
libreadline hasn't got a
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= [EMAIL PROTECTED] writes:
Tom Lane wrote:
Type point has no btree opclass, no hash opclass, and not even an
operator named = (it looks like the functionality is named ~=
for some odd reason). I'd be interested to hear either a proposal of
a principled way to
Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= [EMAIL PROTECTED] writes:
Tom Lane wrote:
Type point has no btree opclass, no hash opclass, and not even an
operator named = (it looks like the functionality is named ~=
for some odd reason). I'd be interested to hear either a proposal of
a
Andres Freund [EMAIL PROTECTED] writes:
SELECT *
FROM
ab LEFT OUTER JOIN (
bc JOIN cd
ON bc.c = cd.d
)
ON ab.b = bc.b
WHERE
ab.a = 2
As ab.a = 2 occurs only once in ab one would expect that it just does an
index scan
Added to TODO:
* Improve LDAP authentication configuration options
http://archives.postgresql.org/pgsql-hackers/2008-04/msg01745.php
---
steve layland wrote:
-- Start of PGP signed section.
Thank you all for your
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= [EMAIL PROTECTED] writes:
OK, there might have been a mental shortcut there. Can't be compared
was supposed to mean can't decide whether one value of that type is
bigger than another. Doing DISTINCT without an equality operator is
nonsense. Doing it without
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= [EMAIL PROTECTED] writes:
Same thing for GROUP BY.
Yeah. The GROUP BY case is even more annoying, because we *have* the
planner/executor infrastructure to do it via hashing; but the parser
barfs immediately if there is not btree opclass support for the type.
I'm
Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= [EMAIL PROTECTED] writes:
OK, there might have been a mental shortcut there. Can't be compared
was supposed to mean can't decide whether one value of that type is
bigger than another. Doing DISTINCT without an equality operator is
nonsense.
SELECT * FROM ab LEFT OUTER JOIN (bc JOIN cd ON bc.c = cd.d) ON ab.b = bc.b
WHERE ab.a = 2
As ab.a = 2 occurs only once in ab one would expect that it just does an
index scan on bc for ab.b = bc.b.
The only way it could do that would be by interchanging the order of the
left and
Added to TODO:
* Improve server security options
http://archives.postgresql.org/pgsql-hackers/2008-04/msg01875.php
http://archives.postgresql.org/pgsql-hackers/2008-05/msg0.php
---
KaiGai Kohei wrote:
I updated
Robert Haas [EMAIL PROTECTED] writes:
I can predict that Tom will say that the planning time it would take
to avoid this problem isn't justified by the number of queries that it
would improve.
Took the words right out of my mouth ;-)
It would be *possible* to do this sort of thing, but what
43 matches
Mail list logo
