Roberto Fichera [EMAIL PROTECTED] writes:
At 10.40 23/09/02 -0400, you wrote:
I think you've got *serious* hardware problems. Hard to tell if it's
disk or memory, but get out those diagnostic programs now ...
database=# DROP TABLE TS;
ERROR: cannot find attribute 1 of relation ts_pkey
On Mon, Sep 23, 2002 at 09:56:59AM -0400, Tom Lane wrote:
What about removing this feature that used to exist: being able to build
ecpg with reasonably-standard tools?
How many people do use bison themselves? Most people I talked to use the
precompiled preproc.c.
I think you should be
Michael Meskes [EMAIL PROTECTED] writes:
On Mon, Sep 23, 2002 at 09:56:59AM -0400, Tom Lane wrote:
What about removing this feature that used to exist: being able to build
ecpg with reasonably-standard tools?
How many people do use bison themselves?
*Everyone* who checks out from our CVS
Rohit Seth recently added support for the use of large TLB pages on
Linux if the processor architecture supports them (I believe the
SPARC, IA32, and IA64 have hugetlb support, more archs will probably
be added). The patch was merged into Linux 2.5.36, so it will more
than likely be in Linux 2.6.
Hello!
On Mon, 23 Sep 2002, Tom Lane wrote:
I am thinking that the better course might be to have newly created
languages default to USAGE PUBLIC, at least for a release or two.
We might also consider letting newly created functions default to
EXECUTE PUBLIC. I think this is less
On Tue, Sep 24, 2002 at 03:59:33AM -0400, Vince Vielhaber wrote:
On Tue, 24 Sep 2002, Gavin Sherry wrote:
Hi all,
It occurs to me that opening web page on www.postgresql.org, asking the
user to select the mirror, is rather unprofessional. I am sure this has
been discussed before but
On Tue, 24 Sep 2002, Ross J. Reedstrom wrote:
On Tue, Sep 24, 2002 at 03:59:33AM -0400, Vince Vielhaber wrote:
On Tue, 24 Sep 2002, Gavin Sherry wrote:
Hi all,
It occurs to me that opening web page on www.postgresql.org, asking the
user to select the mirror, is rather
On Tue, Sep 24, 2002 at 11:26:55AM -0400, Vince Vielhaber wrote:
On Tue, 24 Sep 2002, Ross J. Reedstrom wrote:
I'd suggest setting a cookie, so I only see the 'pick a mirror' the
first time. And provide a link to 'pick a different mirror' that resets
or ignores the cookie.
Or choose
Joe Conway [EMAIL PROTECTED] writes:
replica=# create table foo(f1 int);
CREATE TABLE
replica=# SELECT * FROM foo t WHERE NOT EXISTS (SELECT remoteid FROM (SELECT
f1 as remoteid FROM foo WHERE f1 = t.f1) AS t1);
server closed the connection unexpectedly
Ick.
I'm just starting to dig in to
Tom Lane wrote:
I'm just starting to dig in to this, but was hoping for any thoughts or
guidance I can get.
I can look at this, unless you really want to solve it yourself ...
I'll look into it a bit for my own edification, but if you have the time to
solve it, I wouldn't want to get in
Gavin Sherry [EMAIL PROTECTED] writes:
It occurs to me that opening web page on www.postgresql.org, asking the
user to select the mirror, is rather unprofessional.
I agree; not only that, it has advertisements on it. What's the
justification for that, considering that none of the mirror sites
At 09.31 24/09/02 -0400, Tom Lane wrote:
Roberto Fichera [EMAIL PROTECTED] writes:
At 10.40 23/09/02 -0400, you wrote:
I think you've got *serious* hardware problems. Hard to tell if it's
disk or memory, but get out those diagnostic programs now ...
database=# DROP TABLE TS;
ERROR:
I have to say that during beta testing I ALWAYS do an initdb and a reload
just to make sure the pg_dumpall and pg_restore stuff works right. Plus
to make sure problems that might only pop up with a new initdb are found
as well. I probably burn it to the ground several times on a single
beta
The Makefile for contrib/earthdistance indicates that there should be a
regression test, but the files seem to be missing from CVS. The change to the
Makefile was made here:
http://developer.postgresql.org/cvsweb.cgi/contrib/earthdistance/Makefile.diff?r1=1.11r2=1.12
Was the Makefile change a
At 09.31 24/09/02 -0400, Tom Lane wrote:
Roberto Fichera [EMAIL PROTECTED] writes:
At 10.40 23/09/02 -0400, you wrote:
I think you've got *serious* hardware problems. Hard to tell if it's
disk or memory, but get out those diagnostic programs now ...
database=# DROP TABLE TS;
ERROR:
On 19 Sep 2002, Greg Copeland wrote:
I think Marc made a pretty good case about the use of command line
arguments but I think I have to vote with Tom. Many of the command line
arguments you seem to be using do sorta make sense to have for easy
reference or to help validate your runtime
Neil Conway wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
It occurs to me that opening web page on www.postgresql.org, asking the
user to select the mirror, is rather unprofessional.
I agree; not only that, it has advertisements on it. What's the
justification for that, considering that
Joe Conway [EMAIL PROTECTED] writes:
replica=# create table foo(f1 int);
CREATE TABLE
replica=# SELECT * FROM foo t WHERE NOT EXISTS (SELECT remoteid FROM (SELECT
f1 as remoteid FROM foo WHERE f1 = t.f1) AS t1);
server closed the connection unexpectedly
Got it --- this bug has been there
Tom Lane writes:
How do you feel about allowing functions to default to EXECUTE PUBLIC?
Less excited, but if it gets us to the point of no known problems during
upgrade we might as well do it.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of
Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
You don't :vote: on stuff like this ...
Why not, exactly?
I wasn't aware that any of core had a non-vetoable right to apply
any patch we liked regardless of the number and strength of the
objections. AFAIK, we resolve
Jan Wieck wrote:
Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
You don't :vote: on stuff like this ...
Why not, exactly?
I wasn't aware that any of core had a non-vetoable right to apply
any patch we liked regardless of the number and strength of the
Jan Wieck [EMAIL PROTECTED] writes:
And AFAICS it is scary only because screwing that up will simply corrupt
your database. Thus, a simple random number (okay, and a timestamp of
initdb) in two files, one in $PGDATA and one in $PGXLOG would be a
totally sufficient safety mechanism to prevent
On Tue, Sep 24, 2002 at 10:43:51 -0700,
Joe Conway [EMAIL PROTECTED] wrote:
The Makefile for contrib/earthdistance indicates that there should be a
regression test, but the files seem to be missing from CVS. The change to
the
Makefile was made here:
Ross J. Reedstrom wrote:
On Tue, Sep 24, 2002 at 03:59:33AM -0400, Vince Vielhaber wrote:
On Tue, 24 Sep 2002, Gavin Sherry wrote:
Hi all,
It occurs to me that opening web page on www.postgresql.org, asking
the
user to select the mirror, is rather unprofessional. I am sure this
On Tue, Sep 24, 2002 at 15:02:20 -0500,
Bruno Wolff III [EMAIL PROTECTED] wrote:
There is supposed to be a regression test. I may have forgotten to use
-N or -r on the diff. If it is confirmed that the files needed for the
regression test didn't make it into the submitted diff file, I can
Bruno Wolff III wrote:
On Tue, Sep 24, 2002 at 15:02:20 -0500,
Bruno Wolff III [EMAIL PROTECTED] wrote:
There is supposed to be a regression test. I may have forgotten to use
-N or -r on the diff. If it is confirmed that the files needed for the
regression test didn't make it into
On Tue, Sep 24, 2002 at 16:10:19 -0400,
Bruce Momjian [EMAIL PROTECTED] wrote:
Bruno Wolff III wrote:
On Tue, Sep 24, 2002 at 15:02:20 -0500,
Bruno Wolff III [EMAIL PROTECTED] wrote:
There is supposed to be a regression test. I may have forgotten to use
-N or -r on the diff. If
Bruno Wolff III wrote:
On Tue, Sep 24, 2002 at 16:10:19 -0400,
Bruce Momjian [EMAIL PROTECTED] wrote:
Bruno Wolff III wrote:
On Tue, Sep 24, 2002 at 15:02:20 -0500,
Bruno Wolff III [EMAIL PROTECTED] wrote:
There is supposed to be a regression test. I may have forgotten to
Bruce Momjian [EMAIL PROTECTED] writes:
No. The new files are:
expected/earthdistance.out (which you metion above)
sql/earthdistance.sql
OK, here's what I see now in CVS:
#$ pwd
/pgtop/contrib/earthdistance
#$ lf
CVS/README.earthdistance
In answer to the question posed at the end of the message below:
Yes, I do get the similar results.
A quick investigation shows that the SPI_freetuptable at the end of
pltcl_SPI_exec is trying to free a tuptable of value 0x82ebe64 (which looks
sensible to me) but which has a memory context of
Hi,
I'm looking at pg_dump/common.c:flagInhAttrs() and suspect that it can
be more or less rewritten completely, and probably should to get rigth
all the cases mentioned in the past attisinherited discussion. Is this
desirable for 7.3? It can probably be hacked around and the rewrite
kept for
Hi,
I'm looking at pg_dump/common.c:flagInhAttrs() and suspect that it can
be more or less rewritten completely, and probably should to get rigth
all the cases mentioned in the past attisinherited discussion. Is this
desirable for 7.3? It can probably be hacked around and the rewrite
kept for
On Mon, 2002-09-23 at 18:41, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
Alvaro Herrera kirjutas E, 23.09.2002 kell 10:30:
The former drops f1 from c, while the latter does not. It's
inconsistent.
But this is what _should_ happen.
On what grounds do you claim that? I
Hannu Krosing [EMAIL PROTECTED] writes:
1)
create table p1 (f1 int, g1 int);
create table p2 (f1 int, h1 int);
create table c () inherits(p1, p2);
drop column p2.f1; -- this DROP is in fact implicitly ONLY
Surely not? At least, I don't see why it should be
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
How do you feel about allowing functions to default to EXECUTE PUBLIC?
Less excited, but if it gets us to the point of no known problems during
upgrade we might as well do it.
Okay, I've changed the defaults for both languages and
On Wed, 2002-09-25 at 04:13, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
1)
create table p1 (f1 int, g1 int);
create table p2 (f1 int, h1 int);
create table c () inherits(p1, p2);
drop column p2.f1; -- this DROP is in fact implicitly ONLY
news.postgresql.org seems to be down (and has been for a while -- I think I
tried a day or so ago and found it down then also)
Joe
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister
Hannu Krosing dijo:
On Wed, 2002-09-25 at 04:13, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
1)
create table p1 (f1 int, g1 int);
create table p2 (f1 int, h1 int);
create table c () inherits(p1, p2);
drop column p2.f1; -- this DROP
On Wed, 2002-09-25 at 04:33, Alvaro Herrera wrote:
Hannu Krosing dijo:
On Wed, 2002-09-25 at 04:13, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
1)
create table p1 (f1 int, g1 int);
create table p2 (f1 int, h1 int);
create table
Hannu Krosing dijo:
For me it feels assymmetric (unless we will make attislocal also int
instead of boolean ;). This assymetric nature will manifest itself when
we will have ADD COLUMN which can put back the DROP ONLY COLUMN and it
has to determine weather to remove the COLUMN definition
On Tue, 24 Sep 2002, Jan Wieck wrote:
And AFAICS it is scary only because screwing that up will simply corrupt
your database. Thus, a simple random number (okay, and a timestamp of
initdb) in two files, one in $PGDATA and one in $PGXLOG would be a
totally sufficient safety mechanism to
As far as getting into base postgresql distro. I don't mind it rewriting but I
have some reservations.
1) As it is postgresql source code is huge. Adding functions to it which
directly taps into it's nervous system e.g. cache, would take far more time to
perfect in all conditions.
It
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
No. The new files are:
expected/earthdistance.out (which you metion above)
sql/earthdistance.sql
OK, here's what I see now in CVS:
#$ pwd
/pgtop/contrib/earthdistance
#$ lf
CVS/
Bruce Momjian [EMAIL PROTECTED] writes:
How do I run the regression tests for /contrib stuff?
make
make install
make installcheck
AFAICT, earthdistance is nowhere near passing yet :-(. It looks to
me like the regression test is depending on the cube-based features
that we decided to hold off
Alvaro Herrera [EMAIL PROTECTED] writes:
I'm looking at pg_dump/common.c:flagInhAttrs() and suspect that it can
be more or less rewritten completely, and probably should to get rigth
all the cases mentioned in the past attisinherited discussion. Is this
desirable for 7.3? It can probably be
Neil Conway [EMAIL PROTECTED] writes:
I'd like to enable PostgreSQL to use large TLB pages, if the OS and
processor support them.
Hmm ... it seems interesting, but I'm hesitant to do a lot of work
to support something that's only available on one hardware-and-OS
combination. (If we were
Nigel J. Andrews [EMAIL PROTECTED] writes:
Yes, I do get the similar results.
A quick investigation shows that the SPI_freetuptable at the end of
pltcl_SPI_exec is trying to free a tuptable of value 0x82ebe64
(which looks sensible to me) but which has a memory context of
0x7f7f7f7f (the
It doesn't have to make its way into the postgresql daemon itself -- in
fact since some people like tuning the vacuuming, it makes more sense to
make this a daemon. No, my suggestion is simple that some sort of
auto-vacuumer be compiled as a stand-alone app and included in the standard
On 25 Sep 2002 at 1:10, Matthew T. O'Connor wrote:
It doesn't have to make its way into the postgresql daemon itself -- in
fact since some people like tuning the vacuuming, it makes more sense to
make this a daemon. No, my suggestion is simple that some sort of
auto-vacuumer be compiled as
Am Dienstag, 24. September 2002 08:16 schrieb Shridhar Daithankar:
I will play with it more and give you some more feedback.
Awaiting that.
IMO there are still several problems with that approach, namely:
* every database will get polluted with the autovacuum table, which is undesired
*
On 24 Sep 2002 at 8:42, Mario Weilguni wrote:
Am Dienstag, 24. September 2002 08:16 schrieb Shridhar Daithankar:
IMO there are still several problems with that approach, namely:
* every database will get polluted with the autovacuum table, which is undesired
I agree. But that was the best
On Tue, 24 Sep 2002, Gavin Sherry wrote:
Hi all,
It occurs to me that opening web page on www.postgresql.org, asking the
user to select the mirror, is rather unprofessional. I am sure this has
been discussed before but I thought I would bring it up again anyway.
Your point?
So, why not
At 10.40 23/09/02 -0400, you wrote:
Roberto Fichera [EMAIL PROTECTED] writes:
database=# select count(*) from detail;
count
181661
(1 row)
database=# select count(*) from detail;
count
181660
(1 row)
database=# select count(*) from detail;
53 matches
Mail list logo
