Bruce Momjian writes:
> I have an idea! Currently we write the backup pages (copies of pages
> modified since the last checkpoint) when we write the WAL changes as
> part of the commit. See the XLogCheckBuffer() call in XLogInsert().
Can someone explain exactly what the problem being defeated
On Sun, Jul 03, 2005 at 04:24:31PM +1000, Russell Smith wrote:
> On Sun, 3 Jul 2005 03:32 pm, Michael Fuhr wrote:
> > I've noticed that contrib/pgcrypto/pgcrypto.sql.in doesn't include
> > a volatility category in its CREATE FUNCTION statements, so the
> > functions are all created VOLATILE. Shoul
On Sun, 3 Jul 2005 03:32 pm, Michael Fuhr wrote:
> I've noticed that contrib/pgcrypto/pgcrypto.sql.in doesn't include
> a volatility category in its CREATE FUNCTION statements, so the
> functions are all created VOLATILE. Shouldn't most of them be
> IMMUTABLE? Or do the algorithms have side effec
Marc G. Fournier wrote:
> If it did produce different output, why haven't we noticed it prior
> to this? Has there actually *been* a problem that nobody has
> reported?
Note that we have never used Autoconf 2.59 before, so nobody could have
ever noticed and reported anything. This FreeBSD vs. G
Bruce Momjian wrote:
I realize this needs review, but I will put it the queue so we don't
forget it.
The patch does not need review, as it doesn't even attempt to fix the
problem. (I just wrote the patch while analyzing the problem to make the
error condition more easily reproduceable). I hav
I've noticed that contrib/pgcrypto/pgcrypto.sql.in doesn't include
a volatility category in its CREATE FUNCTION statements, so the
functions are all created VOLATILE. Shouldn't most of them be
IMMUTABLE? Or do the algorithms have side effects? So far I've
found no discussion about this except fo
On Jul 3, 2005, at 8:35 AM, Bruce Momjian wrote:
Andreas Pflug wrote:
Dave Page wrote:
Yup, attached. Per our earlier conversation, pg_dbfile_size() now
returns the size of a table or index, and pg_relation_size()
returns the
total size of a relation and all associated indexes and toast
Tom Lane wrote:
> Josh Berkus writes:
> >> Uh, what exactly did you cut out? I suggested dropping the dumping of
> >> full page images, but not removing CRCs altogether ...
>
> > Attached is the patch I used.
>
> OK, thanks for the clarification. So it does seem that dumping full
> page images
Bruce Momjian wrote:
Peter Eisentraut wrote:
Does the FreeBSD one actually produce different output? I don't
remember seeing any of that and I am not running FreeBSD.
On my 5.4 system autoconf259 and gnu-autoconf both fetch the *same* src
file (autoconf-2.59.tar.bz2 with md5sum 1ee40f7a676b
On Sat, 2 Jul 2005, Andrew Dunstan wrote:
Marc G. Fournier wrote:
On Sat, 2 Jul 2005, Peter Eisentraut wrote:
Bruce Momjian wrote:
Does the FreeBSD one actually produce different output?
If it did not, why would they bother making a separate package called
"gnu-autoconf" with the note
I realize this needs review, but I will put it the queue so we don't
forget it.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
Andreas Pflug wrote:
> Dave Page wrote:
> >
> >
> >
> >>-Original Message-
> >>From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> >>Sent: 02 July 2005 21:30
> >>To: Bruce Momjian
> >>Cc: Dave Page; PostgreSQL-patches; PostgreSQL-development
> >>Subject: Re: [PATCHES] Dbsize backend integr
Patch applied. Thanks.
---
Jim C. Nasby wrote:
> On Tue, Jun 28, 2005 at 02:28:11PM -0400, Andrew Dunstan wrote:
> >
> >
> > Jim C. Nasby wrote:
> >
> > >All the logs for the most recent run against HEAD are now at
> >
Dave Page wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 02 July 2005 21:30
To: Bruce Momjian
Cc: Dave Page; PostgreSQL-patches; PostgreSQL-development
Subject: Re: [PATCHES] Dbsize backend integration
Is a new version of this patch coming?
Yup,
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Marc G. Fournier wrote:
>> If it did produce different output, why haven't we noticed it prior to
>> this? Has there actually *been* a problem that nobody has reported?
>>
> Is autoconf actually run as part of any of our packaging scripts?
I don't th
Marc G. Fournier wrote:
On Sat, 2 Jul 2005, Peter Eisentraut wrote:
Bruce Momjian wrote:
Does the FreeBSD one actually produce different output?
If it did not, why would they bother making a separate package called
"gnu-autoconf" with the note "This port is specifically designed for
dev
On Sat, 2 Jul 2005, Peter Eisentraut wrote:
Bruce Momjian wrote:
Does the FreeBSD one actually produce different output?
If it did not, why would they bother making a separate package called
"gnu-autoconf" with the note "This port is specifically designed for
developers that want to create cr
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> Sent: 02 July 2005 21:30
> To: Bruce Momjian
> Cc: Dave Page; PostgreSQL-patches; PostgreSQL-development
> Subject: Re: [PATCHES] Dbsize backend integration
>
>
> Is a new version of this patch coming?
Yup, attach
Is a new version of this patch coming?
---
Bruce Momjian wrote:
> Dave Page wrote:
> >
> >
> >
> > -Original Message- From: Bruce Momjian
> > [mailto:[EMAIL PROTECTED] Sent: Wed 6/29/2005 2:16 AM To: Dave
> > Page
These patches will require some refactoring and documentation, but I
will do that when I apply it.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers review
Christopher Kings-Lynne wrote:
> I think the whole GiST limitations page can be removed now...
>
> http://developer.postgresql.org/docs/postgres/limitations.html
Done.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
Bruce Momjian wrote:
> Does the FreeBSD one actually produce different output?
If it did not, why would they bother making a separate package called
"gnu-autoconf" with the note "This port is specifically designed for
developers that want to create cross-platform software distributions on
FreeB
Peter Eisentraut wrote:
> Marc G. Fournier wrote:
> > 'k, just checked, and we have the FreeBSD one installed, and always
> > have used in the in the past ... I can install the gnu-* one if you
> > think it will make a difference though, but I don't believe we've had
> > any problem reports on any
Marc G. Fournier wrote:
> 'k, just checked, and we have the FreeBSD one installed, and always
> have used in the in the past ... I can install the gnu-* one if you
> think it will make a difference though, but I don't believe we've had
> any problem reports on any of our past releases ... ?
I thin
'k, just checked, and we have the FreeBSD one installed, and always have
used in the in the past ... I can install the gnu-* one if you think it
will make a difference though, but I don't believe we've had any problem
reports on any of our past releases ... ?
On Sat, 2 Jul 2005, Peter Eisen
Greg Stark wrote:
Just as a bit of supporting anecdotal evidence. I ended up storing longitude
and latitude redundantly in my tables as a point and also as a 0-area box just
so I could use the box box operator because there's no
contains operator.
If necessary, I will add missing operators.
Tom Lane <[EMAIL PROTECTED]> writes:
> As an example, contains/contained in are pretty meaningless for two points;
> but it would be very useful to directly support queries like "point is
> contained in box?", "point is contained in circle?" on a point column.
Just as a bit of supporting anecdot
It certainly helps if you need to debug a process.
Ken
On Fri, Jul 01, 2005 at 09:06:03PM +0300, Heikki Linnakangas wrote:
> On Fri, 1 Jul 2005, Oliver Jowett wrote:
>
> >PS: noticed in passing: psql's help doesn't seem to know about the 2PC
> >command syntax yet.
>
> True.
>
> Should we add s
Tom Lane wrote:
I'm not sure that you want to think of this as a direct copy of "what
rtree would do". The set of interesting operators isn't really the same
for all these types ... which was hard or impossible to support in rtree
but is trivial in GIST. As an example, contains/contained in are
Tom Lane wrote:
> (The TODO item as written is pretty much a dead letter anyway: nobody
> is going to do any more work on rtree. It should probably read "add
> more gist index support for geometric data types".)
TODO updated.
--
Bruce Momjian| http://candle.pha.pa.us
Janko Richter <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What changes have you got in mind exactly?
> At first, I would implement all RTREE supported operators in GIST.
> Then, the GIST implementation may be a full replacement/alternative for RTREE.
That's already done.
> Futhermore, I wou
Tom Lane wrote:
Janko Richter <[EMAIL PROTECTED]> writes:
Is currently anybody working on extending rtree_gist? I have seen, it is moved
to core now. I had a look at it and because I have some experience with PGSQL's
Gist API,
I would do the job.
What changes have you got in mind exactly?
Janko Richter wrote:
> Bruce Momjian wrote:
>
> >Janko Richter wrote:
> >
> >
> >>Is currently anybody working on extending rtree_gist? I have seen, it is
> >>moved
> >>to core now. I had a look at it and because I have some experience with
> >>PGSQL's Gist API,
> >>I would do the job.
> >>
Janko Richter <[EMAIL PROTECTED]> writes:
> Is currently anybody working on extending rtree_gist? I have seen, it is moved
> to core now. I had a look at it and because I have some experience with
> PGSQL's Gist API,
> I would do the job.
What changes have you got in mind exactly?
"Janko Richter" <[EMAIL PROTECTED]> writes:
> OK. If I start developing now, is there a chance to put it in 8.1 or is it
> better to do it for 8.2. I'm not sure about feature freezing of 8.1.
Feature freeze for 8.1 is on Monday.
regards, tom lane
-
Bruce Momjian wrote:
Janko Richter wrote:
Is currently anybody working on extending rtree_gist? I have seen, it is moved
to core now. I had a look at it and because I have some experience with PGSQL's
Gist API,
I would do the job.
I don't think anyone is working in improving it, no.
OK.
Janko Richter wrote:
> Is currently anybody working on extending rtree_gist? I have seen, it is moved
> to core now. I had a look at it and because I have some experience with
> PGSQL's Gist API,
> I would do the job.
I don't think anyone is working in improving it, no.
--
Bruce Momjian
Is currently anybody working on extending rtree_gist? I have seen, it is moved
to core now. I had a look at it and because I have some experience with PGSQL's
Gist API,
I would do the job.
Regards,
Janko Richter
---(end of broadcast)---
TI
Pavel Stehule wrote:
this patch allows optional using label with END and END LOOP. Ending label
has only informational value, but can enhance readability large block and
enhance likeness with Oracle.
Reviewed and applied -- thanks for the patch.
-Neil
---(end of broad
Marc G. Fournier wrote:
> Pick your version:
>
> # ls -lt /usr/local/bin/autoconf*
> -r-xr-xr-x 1 root wheel 7672 Aug 22 2004
> /usr/local/bin/autoconf259 -r-xr-xr-x 1 root wheel 6194 Aug 22
> 2004 /usr/local/bin/autoconf253 -rwxr-xr-x 1 root wheel 5007 Jul
> 27 2003 /usr/local/bin/auto
40 matches
Mail list logo
