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 archiv
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| http://cand
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> AFAICS mkdatadir() shouldn't consider subdir == NULL as a reason to
> >> fail rather than trying mkdir_p.
>
> > Right. In fact, I can't see any good reason to call mkdir and then
> > mkdir_p at all. See my patch
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 Duns
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
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 eac
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(*
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 s
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, Implementati
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, though,
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 $
> > #
>
> L
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 t
"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
-
-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 implementin
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 i
"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
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 d
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
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
> >z
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
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
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
un
[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 d
[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
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 un
We have seen a couple instances recently of WAL recovery failing due to
the recently added code that validates a page header as soon as the page
is read in, for example Olivier Prenant's crash report here:
http://archives.postgresql.org/pgsql-hackers/2003-10/msg01505.php
This failure is actually
Tom Lane wrote:
> 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
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
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 h
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 no
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'
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 s
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
Formerly, one could say --with-krb5=/usr/kerberos
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
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
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, wo
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 --with-
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 ba
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 an
39 matches
Mail list logo
