PostgreSQL 8.0.0 Release Candidate 5

Not sure what is going on here: why is SUSE not listed on the supported
platforms list? (still)

...is it because Reinhard seems resistant (after private conversation)
to the idea of submitting a formal port report via HACKERS, like
everybody else?

...or is it because his postings to ANNOUNCE that the port to SUSE have
gone unnoticed by those that compile the supported platforms list?

...or both?

There seems no reason for either to occur, but still - no port listed.

Please list the SUSE port, as reported by Reinhard Max.
Please can Reinhard (or another SUSE rep) submit port reports to
pgsql-hackers@postgresql.org.

Best Regards, Simon Riggs

Simon Riggs <simon@2ndquadrant.com> writes:

Not sure what is going on here: why is SUSE not listed on the supported
platforms list? (still)

I haven't seen any reports of passes on SUSE. I have zero doubt that PG
works on SUSE, since it's pretty much exactly like every other Linux,
but there's been no specific reports on the lists AFAIR.

...is it because Reinhard seems resistant (after private conversation)
to the idea of submitting a formal port report via HACKERS, like
everybody else?

See above.

...or is it because his postings to ANNOUNCE that the port to SUSE have
gone unnoticed by those that compile the supported platforms list?

If he insists on posting such routine stuff to pgsql-announce, he should
not be too surprised that his postings do not get approved. That isn't
the correct forum. We don't peruse the New York Times classified ads
for such reports, either ...

regards, tom lane

Simon,

On Wed, 12 Jan 2005 at 08:23, Simon Riggs wrote:

Not sure what is going on here: why is SUSE not listed on the supported
platforms list? (still)

...is it because Reinhard seems resistant

why do you think so?

(after private conversation) to the idea of submitting a formal port
report via HACKERS, like everybody else?

I andwered you that I will do it, but last week was a short week for
me, and this Monday I had an email from Peter Eisentraut telling me
that he will add the SUSE ports to the list, so I didn't see a need to
send a report in addition.

cu
Reinhard

Tom,

On Wed, 12 Jan 2005 at 03:53, Tom Lane wrote:

...or is it because his postings to ANNOUNCE that the port to SUSE
have gone unnoticed by those that compile the supported platforms
list?

If he insists on posting such routine stuff to pgsql-announce, he
should not be too surprised that his postings do not get approved.
That isn't the correct forum. We don't peruse the New York Times
classified ads for such reports, either ...

no need to be rude to me for posting one single email to ANNOUNCE
after years of providing the SUSE RPMs silently. There were other
posts about RPM builds on ANNOUNCE, so I thought it would be the right
place to announce mine as well.

BTW, what would be the correct forum to make PostgreSQL users aware of
the appearance of new RPMs, if it is not ANNOUNCE? They are certainly
not expected to be reading the HACKERS list.

cu
Reinhard

Reinhard Max <max@suse.de> wrote on 12.01.2005, 11:17:52:

On Wed, 12 Jan 2005 at 08:23, Simon Riggs wrote:

Not sure what is going on here: why is SUSE not listed on the supported
platforms list? (still)

...is it because Reinhard seems resistant

why do you think so?

(after private conversation) to the idea of submitting a formal port
report via HACKERS, like everybody else?

I andwered you that I will do it, but last week was a short week for
me, and this Monday I had an email from Peter Eisentraut telling me
that he will add the SUSE ports to the list, so I didn't see a need to
send a report in addition.

Forgive my admittedly blunt tactics - I want to see SUSE on the list
before we release, and time was short - that's all. If it wasn't for
RC5, no port report would be listed in the docs in the final
release.... It's better to have a SUSE contact support the port than
for me to report it.

I should note here also that SGI have replied "No" to my request for
help (or access) with porting PostgreSQL onto the latest version of
IRIX...

Anyone got access to an HP/UX development system?

Best Regards, Simon Riggs

Reinhard Max <max@suse.de> wrote on 12.01.2005, 11:38:55:

On Wed, 12 Jan 2005 at 03:53, Tom Lane wrote:

...or is it because his postings to ANNOUNCE that the port to SUSE
have gone unnoticed by those that compile the supported platforms
list?

If he insists on posting such routine stuff to pgsql-announce, he
should not be too surprised that his postings do not get approved.
That isn't the correct forum. We don't peruse the New York Times
classified ads for such reports, either ...

no need to be rude to me for posting one single email to ANNOUNCE
after years of providing the SUSE RPMs silently. There were other
posts about RPM builds on ANNOUNCE, so I thought it would be the right
place to announce mine as well.

Please no more. I started this, so I apologise now to both of you, and
to the list and hope this ends here.

We all look forward to SUSE being a listed port.

Best Regards, Simon Riggs

Simon Riggs wrote:

Not sure what is going on here: why is SUSE not listed on the
supported platforms list? (still)

RC5 contains:

SUSE Linux x86 8.0.0 Peter Eisentraut (<peter_e@gmx.net>), 2005-01-10
9.1

In the meantime I have received confirmation from Reinhard Max that his
test methods match our requirements, so the list will be completed with
the other platforms he reported in due time.

I'm sorry, but I won't just add "it works" notices if it's not clear
what kind of testing was done.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

simon@2ndquadrant.com wrote:

I should note here also that SGI have replied "No" to my request for
help (or access) with porting PostgreSQL onto the latest version of
IRIX...

Another year, some result...

Anyone got access to an HP/UX development system?

Check out HP's testdrive program. Many of the port reports for 7.4 were
done there, but I was too busy this time around to do that.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Wed, 12 Jan 2005 at 16:29, Peter Eisentraut wrote:

In the meantime I have received confirmation from Reinhard Max that
his test methods match our requirements, so the list will be
completed with the other platforms he reported in due time.

Today I've updated the RPMs on the FTP server to RC5, which implicitly
means that PostgreSQL passes the regression tests on the provided
platforms.
ftp://ftp.suse.com/pub/projects/postgresql/postgresql-8.0.0rc5

I have also successfully compiled and tested RC5 (but not yet created
RPMs) on the following platforms:

8.1-i386
8.2-i386
sles8-i386
sles8-ia64
sles8-ppc
sles8-ppc64
sles8-s390
sles8-s390x

The only failure I have to report is sles8-x86_64, where I am getting
segfaults from psql during the regression tests. I am still
investigating what's going on there....

cu
Reinhard

On Wed, 12 Jan 2005 at 17:29, Reinhard Max wrote:

The only failure I have to report is sles8-x86_64, where I am
getting segfaults from psql during the regression tests.

The segfault in a call to snprintf somewhere in libpq's kerberos5
code. So when I leave out --with-krb5 it compiles and passes the test
suite without problems.

I am still not sure whether the kerberos library, glibc, or PostgreSQL
is to blame, or if it's a combination of bugs in these components that
triggers the segfault.

More details to follow...

cu
Reinhard

Tom, Bruce, and others involved in this recurring TODO discussion�

First, let me start by saying that I understand this has been discussed
many times before; however, I�d like to see what the current state of
affairs is regarding the possibility of using a unique index scan to
speed up the COUNT aggregate.

A few of my customers (some familiar with Oracle) are confused by the
amount of time it takes PostgreSQL to come up with the result and are
hesitating to use it because they think it�s too slow. I�ve tried to
explain to them why it is slow, but in doing so I�ve come to see that
it may be worth working on.

I've reviewed the many messages regarding COUNT(*) and have looked
through some of the source (8.0-RC4) and have arrived at the following
questions:

1. Is there any answer to Bruce�s last statement in the thread, �Re:
[PERFORM] COUNT(*) again (was Re: Index/Function organized�
(http://archives.postgresql.org/pgsql-hackers/2003-10/msg00245.php)

2. What do you think about a separate plan type such as IndexOnlyScan?
Good/stupid/what is he on?

3. Assuming that Bruce�s aforementioned statement is correct, what
hidden performance bottlenecks might there be?

4. What is the consensus of updating a per-relation value containing
the row counts?

Though not exactly like PostgreSQL, Oracle uses MVCC and performs an
index scan on a unique value for all unqualified counts. Admittedly,
counts are faster than they used to be, but this is always a complaint
I hear from open source users and professionals alike.

I�ve been pretty busy, and I still need to get the user/group quota
working with 8.0 and forward the diffs to you all, but I would be
willing to work on speeding up the count(*) if you guys give me
your input.

As always, keep up the good work!

Respectfully,

Jonah H. Harris, Senior Web Administrator
Albuquerque TVI
505.224.4814

"Jonah H. Harris" <jharris@tvi.edu> writes:

Tom, Bruce, and others involved in this recurring TODO discussion�
First, let me start by saying that I understand this has been discussed
many times before; however, I�d like to see what the current state of
affairs is regarding the possibility of using a unique index scan to
speed up the COUNT aggregate.

It's not happening, because no one has come up with a workable proposal.
In particular, we're not willing to slow down every other operation in
order to make COUNT-*-with-no-WHERE-clause faster.

regards, tom lane

On Wed, 12 Jan 2005 at 18:20, Reinhard Max wrote:

I am still not sure whether the kerberos library, glibc, or
PostgreSQL is to blame, or if it's a combination of bugs in these
components that triggers the segfault.

The problem is, that the heimdal implementation of kerberos5 used on
sles8 needs an extra include statement for com_err.h in
src/interfaces/libpq/fe-auth.c to get the prototype for
error_message(), while on newer SUSE-releases using the MIT Kerberos5
implementation this prototype is provided by krb5.h itself.

So I suspect this bug might hit everyone using heimdal, but it only
gets triggered when one of the calls to kerberos in
src/interfaces/libpq/fe-auth.c returns with an error.

I am still not sure why the crash only happened on x86_64.

cu
Reinhard

Tom, Bruce, and others involved in this recurring TODO discussion...

First, let me start by saying that I understand this has been

discussed

many times before; however, I'd like to see what the current state of
affairs is regarding the possibility of using a unique index scan to
speed up the COUNT aggregate.

To sum up:
1. There are good technical reasons why not to do this. The pg
aggregate system is very elegant...not worth compromising it for a
specific case.
2. postgresql can do many things faster than oracle. If you prefer the
way oracle behaves, use oracle.
3. workaround #1: just run analyze once in a while (you should do that
anyways) and query pg_Class for the #tuples in a relation.
4. workaround #2: rig up a materialized view and query that. This will
be faster than what oracle does, btw, at the price of some coherency.
5. understand that count(*) from t, although frequently used, is of
dubious value in the general sense. Sooner or later someone will
optimize this, but in light of the currently available workarounds it
doesn't seem that important.
6. for large tables, you can get a pretty accurate count by doing:
select count(*) * 10 from t where random() > .9;
on my setup, this shaved about 15% off of the counting time...YMMV.

Merlin

Tom,

Thank you for your prompt response and I understand your statement
completely.

My thinking is that we may be able to implement index usage for not only
unqualified counts, but also on any query that can be satisfied by the
index itself. Index usage seems to be a feature that could speed up
PostgreSQL for many people. I'm working on a project right now that
could actually take advantage of it.

Looking at the message boards, there is significant interest in the
COUNT(*) aspect. However, rather than solely address the COUNT(*) TODO
item, why not fix it and add additional functionality found in
commercial databases as well? I believe Oracle has had this feature
since 7.3 and I know people take advantage of it.

I understand that you guys have a lot more important stuff to do than
work on something like this. Unlike other people posting the request and
whining about the speed, I'm offering to take it on and fix it.

Take this mesage as my willingness to propose and implement this
feature. Any details, pitfalls, or suggestions are appreciated.

Thanks again!

-Jonah

Tom Lane wrote:

Sorry for following up to myself once more...

On Wed, 12 Jan 2005 at 19:36, Reinhard Max wrote:

The problem is, that the heimdal implementation of kerberos5 used on
sles8 needs an extra include statement for com_err.h in
src/interfaces/libpq/fe-auth.c to get the prototype for
error_message(), while on newer SUSE-releases using the MIT
Kerberos5 implementation this prototype is provided by krb5.h
itself.

after finding and reading the thread on HACKERS about com_err.h from
last December, I think either should configure check if including
krb5.h is sufficient for getting the prototype of error_message(), or
a conditional include for krb5.h should be added to
src/interfaces/libpq/fe-auth.c.

A proposed patch to achieve the latter is attached to this mail.

Either way will lead to a build time error when error_message() isn't
declared or com_err.h can't be found, which is better than the current
situation where only a warning about a missing prototype is issued,
but compilation continues resulting in a broken libpq.

cu
Reinhard

"Jonah H. Harris" <jharris@tvi.edu> writes:

Looking at the message boards, there is significant interest in the COUNT(*)
aspect. However, rather than solely address the COUNT(*) TODO item, why not fix
it and add additional functionality found in commercial databases as well? I
believe Oracle has had this feature since 7.3 and I know people take advantage
of it.

I think part of the problem is that there's a bunch of features related to
these types of queries and the lines between them blur.

You seem to be talking about putting visibility information inside indexes for
so index-only plans can be performed. But you're also talking about queries
like "select count(*) from foo" with no where clauses. Such a query wouldn't
be helped by index-only scans.

Perhaps you're thinking about caching the total number of records in a global
piece of state like a materialized view? That would be a nice feature but I
think it should done as a general materialized view implementation, not a
special case solution for just this one query.

Perhaps you're thinking of the min/max problem of being able to use indexes to
pick out just the tuples satisfying the min/max constraint. That seems to me
to be one of the more tractable problems in this area but it would still
require lots of work.

I suggest you post a specific query you find is slow. Then discuss how you
think it ought to be executed and why.

--
greg

On Wed, Jan 12, 2005 at 07:36:52PM +0100, Reinhard Max wrote:

The problem is, that the heimdal implementation of kerberos5 used on
sles8 needs an extra include statement for com_err.h in
src/interfaces/libpq/fe-auth.c to get the prototype for
error_message(), while on newer SUSE-releases using the MIT Kerberos5
implementation this prototype is provided by krb5.h itself.

[...]

I am still not sure why the crash only happened on x86_64.

This is because the proper prototype is:
extern char const *error_message (long);

And C automaticly generates a prototype with in int instead.

On 32 bit platforms this ussualy isn't a problem since both int
and long are ussualy both 32 bit, but on x86_64 a long is 64 bit
while an int is only 32.

Kurt

On Wed, 12 Jan 2005 at 20:28, Kurt Roeckx wrote:

This is because the proper prototype is:
extern char const *error_message (long);

And C automaticly generates a prototype with in int instead.

On 32 bit platforms this ussualy isn't a problem since both int and
long are ussualy both 32 bit, but on x86_64 a long is 64 bit while
an int is only 32.

It's actually not the long argument, but the returned pointer that
caused the segfault.

But this only explains why it didn't crash on i386, but not why it
also didn't crash on IA64, ppc64 and s390x which are also LP64
platforms.

cu
Reinhard