Was there supposed to be a patch attached to this email?
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Evgen Potemkin
> Sent: Friday, 15 November 2002 5:38 PM
> To: [EMAIL PROTECTED]
> Subject: [HACKERS] Proposal of hierarchical queries, a l
It updates every 15 minutes. You have to give it time. :-)
---
Christopher Kings-Lynne wrote:
> > Ports list updated:
>
>
> Sure? Still says 7.2 for openbsd and has old submission date...
>
> > http://candle.pha.pa.us/
> Ports list updated:
Sure? Still says 7.2 for openbsd and has old submission date...
> http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Ports list updated:
http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html
---
Christopher Kings-Lynne wrote:
> This is a successful report for OpenBSD 3.2 on sparc and i386
>
> > -Original Message-
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Let's just fix it and roll an RC2 with the fix. If not, we can just fix
> > it in 7.3.1 but I see little problem in rolling an RC2.
>
> Since Marc hasn't yet announced RC1, I think we could get away with just
> a quick fix and re-rol
Alvaro Herrera wrote:
>
> On Sun, Nov 17, 2002 at 06:43:38PM -0500, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> > > > And what about REINDEX? That seems to have a different
> > > > syntax from the other two. Seems there shoul
> In looking at the CLUSTER ALL patch I have applied, I am now wondering
> why the ALL keyword is used. When we do VACUUM, we don't use ALL.
> VACUUM vacuums all tables. Shouldn't' CLUSTER alone do the same thing.
> And what about REINDEX? That seems to have a different syntax from the
> other
This is a successful report for OpenBSD 3.2 on sparc and i386
> -Original Message-
> From: bpalmer [mailto:[EMAIL PROTECTED]]
> Sent: Monday, 18 November 2002 2:14 AM
> To: Christopher Kings-Lynne
> Subject: Re: PostgreSQL 7.3 Platform Testing
>
>
> Sorry for taking so long to get back to
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> What I don't understand is what are the parameters in the
> ReindexDatabase function for. For example, the boolean all is always
> false in tcop/utility.c (and there are no other places that the function
> is called). Also, the database name is checked
On Sun, Nov 17, 2002 at 06:43:38PM -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > And what about REINDEX? That seems to have a different syntax from the
> > > other two. Seems there should be some consistency.
> >
> > We don't have a REINDEX AL
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Let's just fix it and roll an RC2 with the fix. If not, we can just fix
> it in 7.3.1 but I see little problem in rolling an RC2.
Here is the patch I am testing (in current sources; I don't think it
needs any adjustments for REL7_3, but haven't tried to
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Let's just fix it and roll an RC2 with the fix. If not, we can just fix
> it in 7.3.1 but I see little problem in rolling an RC2.
Since Marc hasn't yet announced RC1, I think we could get away with just
a quick fix and re-roll of RC1 ...
Let's just fix it and roll an RC2 with the fix. If not, we can just fix
it in 7.3.1 but I see little problem in rolling an RC2.
---
Tom Lane wrote:
> snpe <[EMAIL PROTECTED]> writes:
> > When I call DECLARE CURSOR out of
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > In looking at the CLUSTER ALL patch I have applied, I am now wondering
> > why the ALL keyword is used. When we do VACUUM, we don't use ALL.
> > VACUUM vacuums all tables. Shouldn't' CLUSTER alone do the same thing.
>
> I agree, l
I totally agree with what you have said. Peter, can you clarify your
reasoning for OID for user/group id?
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I'd recommend not making any
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Actually, I'm planning to do the freelist thing, then the btree
> compaction and then replace the current REINDEX code with the compaction
> code, probably including some means to
On Sun, Nov 17, 2002 at 04:42:01PM -0500, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > In looking at the CLUSTER ALL patch I have applied, I am now wondering
> > why the ALL keyword is used. When we do VACUUM, we don't use ALL.
> > VACUUM vacuums all tables. Shouldn't' CLUSTER
Bruce Momjian <[EMAIL PROTECTED]> writes:
> In looking at the CLUSTER ALL patch I have applied, I am now wondering
> why the ALL keyword is used. When we do VACUUM, we don't use ALL.
> VACUUM vacuums all tables. Shouldn't' CLUSTER alone do the same thing.
I agree, lose the ALL.
> And what abo
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'd recommend not making any piecemeal changes, especially not when
>> there's not yet a consensus which way to converge.
> Well, seems we should make it consistent at least.
I think the original argument stemmed from the idea that we
In looking at the CLUSTER ALL patch I have applied, I am now wondering
why the ALL keyword is used. When we do VACUUM, we don't use ALL.
VACUUM vacuums all tables. Shouldn't' CLUSTER alone do the same thing.
And what about REINDEX? That seems to have a different syntax from the
other two. See
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > In the pg_stat_activity view, the usesysid is shown as having type Oid.
> > However pg_shadow says it's an integer. Is there a reason?
>
> There's been disagreement for a long time over whether userids should be
> OIDs or ints. If
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> For 7.4 I would like to add a function for importing float8 values
> into cube. But because the cube data type is variable length I am
> not sure what a good approach would be.
I'm not clear on what you want to accomplish. How are you expecting
the so
On Sun, Nov 17, 2002 at 01:16:29PM -0500, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > In the pg_stat_activity view, the usesysid is shown as having type Oid.
> > However pg_shadow says it's an integer. Is there a reason?
>
> There's been disagreement for a long time over whet
For 7.4 I would like to add a function for importing float8 values
into cube. But because the cube data type is variable length I am
not sure what a good approach would be.
Currently this can be poorly done using text as an intermediate type.
As far as I can tell functions can't take sets as argum
snpe <[EMAIL PROTECTED]> writes:
> When I call DECLARE CURSOR out of transaction command success,
> but cursor is not created
> Reference manual say that this get error :
> ERROR: DECLARE CURSOR may only be used in begin/end transaction blocks
Oops. I removed that test on 21-Oct as part of t
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> + Deletions are handled by getting a super-exclusive lock on the target
>page, so that no other backend has a pin on the page when the deletion
>starts. This means no scan is pointing at the page. This is OK for
>deleting leaf items, proba
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> In the pg_stat_activity view, the usesysid is shown as having type Oid.
> However pg_shadow says it's an integer. Is there a reason?
There's been disagreement for a long time over whether userids should be
OIDs or ints. If you want to introduce consis
On Thu, Nov 14, 2002 at 08:55:22PM +, Patrick Welche wrote:
> Believe it or not, I'm trying to compile today's cvs pgsql on a
> Debian 2.2.19 system. Compilation dies while compiling pg_dump with
>
> ../../../src/interfaces/libpq/libpq.so: undefined reference to `atexit'
>
> In the mail archi
Hello,
I'm just taking the btree shrinking problem, and saw in the README:
+ Deletions are handled by getting a super-exclusive lock on the target
page, so that no other backend has a pin on the page when the deletion
starts. This means no scan is pointing at the page. This is OK for
Hello hackers,
In the pg_stat_activity view, the usesysid is shown as having type Oid.
However pg_shadow says it's an integer. Is there a reason? Looks like
a bug.
This patch seems to corrects this issue, but I don't know if there's
something else involved.
Index: src/include/catalog/pg_proc.h
Christopher Kings-Lynne writes:
> Seems there's a few errors in the SQL99 compatibility list. For one, it
> says we support WITH CHECK OPTION on views which I'm pretty sure we don't.
I've gone through the list and made some corrections. It makes for a nice
to-do list now (with the possible exce
Joe,
I've been told by Tom Lane that the problem is related to having Perl
working, so I'm assuming theres a change that needs to go into the win32
makefile that builds this file using perl.
I'm going to have a go at finding the relevant commands and create a patch.
I've also attached the output
32 matches
Mail list logo
