Tom Lane writes:
I believe the idea is that instead of
--with-krb5=/usr/kerberos
you now need
--with-krb5 --with-includes=/usr/kerberos/include --with-libs=/usr/kerberos/lib
or some variant like that. It'd be good for the docs to be more
explicit about this change.
If you have
Tom Lane [EMAIL PROTECTED] writes:
I believe the idea is that instead of
--with-krb5=/usr/kerberos
you now need
--with-krb5 --with-includes=/usr/kerberos/include \
--with-libs=/usr/kerberos/lib
Rather than silenty accepting but ignoring the old syntax, could we
have configure bail out
Neil Conway writes:
Rather than silenty accepting but ignoring the old syntax, could we
have configure bail out with an appropriate error message if
--with-krb5 is specified with an argument? That might make the change
less subtle.
That's what it does:
peter ~/pgsql$ ./configure
pg 7.4.0
Hi,
From the server log:
Nov 28 16:31:02 srv postgres[2484]: [1076-7] ^I-- Disable triggers
Nov 28 16:31:02 srv postgres[2484]: [1076-8] ^IUPDATE pg_catalog.pg_class SET
reltriggers = 0 WHERE oid = 'test'::pg_catalog.regclass;
If table with the name test exists in several schemas,
I ran Tom's second script for two hours on an AMD Duron on Linux 2.4.18.
No problems.
Gavin
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
On Fri, Nov 28, 2003 at 08:22:30PM -0500, Tom Lane wrote:
One variable I didn't think to ask about is whether you are running
NTP. In my experience an ntp daemon that has achieved lock will never
step the clock back by even 1 usec (it's supposed to use much more
subtle methods than that to
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
It'd be good for the docs to be more
explicit about this change.
If you have anything to add to this, let me know:
I was thinking of an explicit statement along the lines of
note
Formerly, one could say --with-krb5=/usr/kerberos as
ow [EMAIL PROTECTED] writes:
Nov 28 16:31:02 srv postgres[2484]: [1076-8] ^IUPDATE pg_catalog.pg_class SET
reltriggers = 0 WHERE oid = 'test'::pg_catalog.regclass;
If table with the name test exists in several schemas, wouldn't the above
update disable triggers on table test in ALL schemas?
On Friday 28 November 2003 12:31 pm, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
I've tried building PostgreSQL with -fpic on Sparc and saw no problems.
So I suggest that we change back to -fpic until we get detailed evidence.
Okay with me. It never struck me that we'd
Lamar Owen [EMAIL PROTECTED] writes:
The project lead for the Aurora SPARC Linux project is who recommended it in
the first place;
We were told equally positively, by equally well-informed persons, that
we should prefer -fpic if at all possible.
The best I have been able to tell is that none
Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
The project lead for the Aurora SPARC Linux project is who recommended it in
the first place;
We were told equally positively, by equally well-informed persons, that
we should prefer -fpic if at all possible.
The best I have been
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
The best I have been able to tell is that none of our .so's are anywhere
near large enough to require -fPIC.
One question would be what happens when it fails? Does it fail visibly
so we would hear about it? If so, we can take the
Alvaro Herrera wrote:
On Wed, Nov 26, 2003 at 05:34:28PM +0100, Hans-Jürgen Schönig wrote:
The reason why I came up with this posting is slightly different: Assume
a JDBC application which works with PostgreSQL + some other database. If
you want to use both databases without PostgreSQL being
[sNip]
Why shall 1752 be the default date? The original introduction of
gregorian dates after all was in 1582. And some parts of the earth
didn't switch before the 20th century. So, as pointed out, we'd need a
locale dependant default.
Since a database can be serving someone in a
[sNip]
I would add that this is not a bug as much as a feature request.
count() works. It may not be as feature
filled as we would like (e.g; it won't use an index) but it does work.
count will use an index just fine where it's useful. If you say select
count(*) where foo = ? and there's
Tom Lane wrote:
This failure is actually entirely pointless, because (AFAIK) any page
that is brought in during WAL recovery is going to be overwritten in
toto from the WAL log. So it would be safe to run WAL recovery with
zero_damaged_pages enabled. Rather than expecting DBAs to think of that
Randolf Richardson [EMAIL PROTECTED] writes:
What about adding a total number of rows value to the internal
header of each table which gets incremented/decremented after each row is
INSERT/DELETE has been committed. This way, a generic count(*) by itself
could simply return this
Bruce is going to do whatever magic he needs to on Tuesday, after while
I'll bundle it up for testing (at which point in time Peter should point
out any oops I happen to have made, no after, eh? *evil grin*) ... then
we'll do an announce of its availability on Wednesday ...
Marc G. Fournier
On Sat, Nov 29, 2003 at 11:31:03AM -0800, Joe Conway wrote:
Tom Lane wrote:
This failure is actually entirely pointless, because (AFAIK) any page
that is brought in during WAL recovery is going to be overwritten in
toto from the WAL log. So it would be safe to run WAL recovery with
Alvaro Herrera [EMAIL PROTECTED] writes:
Yes, but is the error message going to stay verbatim? Maybe the
category could be decreased ...
The patch I proposed would still cause a WARNING to come out in the
postmaster log. We could perhaps reduce it to a NOTICE if InRecovery
is true, or have
Assuming I didn't miss any files, this is now complete ... I grep'd for
both $Header: and $Id:, and appear to have gotten them all ...
On Fri, 28 Nov 2003, Marc G. Fournier wrote:
On Thu, 27 Nov 2003, Rod Taylor wrote:
On Thu, 2003-11-27 at 00:50, Marc G. Fournier wrote:
Based on
Marc G. Fournier [EMAIL PROTECTED] writes:
Bruce is going to do whatever magic he needs to on Tuesday, after while
I'll bundle it up for testing (at which point in time Peter should point
out any oops I happen to have made, no after, eh? *evil grin*) ... then
we'll do an announce of its
On Saturday 29 November 2003 01:07 pm, Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
The project lead for the Aurora SPARC Linux project is who recommended it
in the first place;
We were told equally positively, by equally well-informed persons, that
we should prefer -fpic if at all
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 26 November 2003 10:58 am, Jonathan Gardner wrote:
On Wednesday 26 November 2003 09:19, Hannu Krosing wrote:
What is needed is good algorithms. Writing C code is secondary to that.
Similar problem has kept us from implementing
Marc G. Fournier [EMAIL PROTECTED] writes:
Assuming I didn't miss any files, this is now complete ... I grep'd for
both $Header: and $Id:, and appear to have gotten them all ...
From here it looks like the $Id$ headers are all still there.
regards, tom lane
k, I see why ... fixing right now ...
On Sat, 29 Nov 2003, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
Assuming I didn't miss any files, this is now complete ... I grep'd for
both $Header: and $Id:, and appear to have gotten them all ...
From here it looks like the $Id$
On Fri, 28 Nov 2003, Rod Taylor wrote:
k, there was no options file already, so I just added it containing the
one line ...
And tested in on GNUMakefile.in, and appears okay:
#
# $PostgreSQL: pgsql-server/GNUmakefile.in,v 1.36 2003/11/28 20:32:09 pgsql Exp $
#
Looks good. Once
Just as an FYI, there are continuing talks on FreeBSD's mailng lists about
this issue, in hopes of getting it corrected ... if anyone here is using
FreeBSD, you'll want to check out the -current mailing list, where
discussions are taking place ...
Update code for testing is included here,
Jonathan Gardner [EMAIL PROTECTED] writes:
3) We would implement some sort of differential view update scheme
based on the paper Efficiently Updating Materialized Views[1].
One resource on this topic that appears to be quite authoritative is
Materialized Views: Techniques, Implementations,
Doug McNaught wrote:
Randolf Richardson [EMAIL PROTECTED] writes:
What about adding a total number of rows value to the internal
header of each table which gets incremented/decremented after each row is
INSERT/DELETE has been committed. This way, a generic count(*) by itself
could simply
Gaetano Mendola [EMAIL PROTECTED] writes:
Doug McNaught wrote:
Because different sessions have a (validly) different concept of what
that number should be, due to MVCC.
The count(*) information can be revisioned too, am I wrong ? I'm able to
create a trigger that store the count(*)
Oops! [EMAIL PROTECTED] (Gaetano Mendola) was seen spray-painting on a wall:
Doug McNaught wrote:
Randolf Richardson [EMAIL PROTECTED] writes:
What about adding a total number of rows value to the
internal header of each table which gets incremented/decremented
after each row is
Added to TODO:
Make LENGTH() of CHAR() not count trailing spaces
---
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Well, that certainly is interesting. Oracle and MS-SQL preserve the
trailing space
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Andrew Dunstan wrote:
Andrew
I have loaded the patch queue with all patches that were in my main
mailbox:
http://momjian.postgresql.org/cgi-bin/pgpatches
I still have to go through the saved patches in:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
--
Bruce Momjian|
Bruce Momjian wrote:
I have loaded the patch queue with all patches that were in my main
mailbox:
http://momjian.postgresql.org/cgi-bin/pgpatches
I posted an alternative to this one
http://candle.pha.pa.us/mhonarc/patches/msg4.html
for comment last night (however I can't find it in the
36 matches
Mail list logo
