Christopher Kings-Lynne wrote:
Errr, unlike all the other uses for alter table and friends? ie:
OWNER TO
Which changes the attributes of the table...
And indexes.
Sure. But not *just* indexes.
RENAME TO
Same.
And indexes.
It does? I thought the indexes pointed to relations
Some time ago I posted a patch to allow pg_autovacuum to be run as a
service on Windows, on the understanding that if pg_autovacuum didn't
make it into the backend, it would be applied. I followed up Tom's
message to Matthew apologising for not including his backend integration
patches with a
Hi, just built and tried the regressions tests, but it fails here:
== initializing database system ==
./pg_regress: line 470: 10212 Trace/BPT trap $bindir/initdb -D
$PGDATA -L $datadir --noclean $initdb_options $LOGDIR/initdb.log 21
pg_regress: initdb
In article [EMAIL PROTECTED],
Tom Lane [EMAIL PROTECTED] writes:
Jan Wieck [EMAIL PROTECTED] writes:
What about
DELETE FROM staff JOIN users ...
then?
I don't much care for that, mainly because in my mind x JOIN y should
always be semantically equivalent to y JOIN x. I think we want a
Some more information:
I started to perform the tests on one of the machines in my lab, and guess
what, almost no difference between fsync and open_sync. Either on jfs or
ext2.
The difference, Linux 2.6.3? My original tests where on Linux 2.4.25.
The good part is that open_sync wasn't worse.
Dave Page [EMAIL PROTECTED] writes:
Some time ago I posted a patch to allow pg_autovacuum to be run as a
service on Windows, on the understanding that if pg_autovacuum didn't
make it into the backend, it would be applied. I followed up Tom's
message to Matthew apologising for not including his
Kevin Brown [EMAIL PROTECTED] writes:
... But what we're talking about
here is brand new functionality for which the language hasn't been
defined yet.
You're missing the point, which is that there *is* a precedent of long
standing. ALTER TABLE has worked on indexes (and sequences, and views)
On Tue, 10 Aug 2004, Harald Fuchs wrote:
In article [EMAIL PROTECTED],
Tom Lane [EMAIL PROTECTED] writes:
Jan Wieck [EMAIL PROTECTED] writes:
What about
DELETE FROM staff JOIN users ...
then?
I don't much care for that, mainly because in my mind x JOIN y should
always be
In particular, you need to offer some evidence for that completely
undocumented assertion that it won't hurt anyone else.
It should be easy enough to prove whether or not O_SYNC hurts anyone.
OK, let me ask a few questions:
(1) what is a good sample set on which to run? Linux, FreeBSD,
Bruce Momjian [EMAIL PROTECTED] writes:
There is no way to specify a table alias for the deleted table in
the DELETE WHERE clause because there is no FROM clause.
This description confuses two quite separate issues.
regards, tom lane
---(end
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
Some time ago I posted a patch to allow pg_autovacuum to be run as a
service on Windows, on the understanding that if pg_autovacuum didn't
make it into the backend, it would be applied. I followed up Tom's
message to Matthew apologising
You're talking about the deletion target table. Sorry to mention
the M word again, but MySQL allows deleting from more than one table
at the same time. Should we support that?
No, because it makes no logical sense at all...
Chris
---(end of
[EMAIL PROTECTED] writes:
Does it make sense, then, to say that WAL O_SYNC should be O_SYNC? If
there are no reasons not too, doesn't it make sense to make this the
default. It will give a boost for any 2.4 Linux machines and won't seem to
hurt anyone else.
You have got the terms of debate
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
There is no way to specify a table alias for the deleted table in
the DELETE WHERE clause because there is no FROM clause.
This description confuses two quite separate issues.
Yea, it does.
How is this text:
* Allow DELETE to
I have added the USING mention to the TODO list description for the
item.
* Allow DELETE to handle table aliases for self-joins [delete]
There is no way to specify a table alias for the deleted table in
the DELETE WHERE clause because there is no FROM clause. The agreed
approach is to
Harald Fuchs [EMAIL PROTECTED] writes:
You're talking about the deletion target table. Sorry to mention
the M word again, but MySQL allows deleting from more than one table
at the same time. Should we support that?
There is zero interest in that around here, AFAIK. I don't think it's
even
Dear Peter,
PostgreSQL extension makefile framework (pgxs), by Fabien Coelho, with
some massaging by Peter Eisentraut. This is basically a simple
generalization of the existing contrib makefiles.
Thanks for your help.
I'm having a look at CVS know, and it seems to me that one cannot pgxs
On Tue, 2004-08-10 at 07:48, [EMAIL PROTECTED] wrote:
Some more information:
I started to perform the tests on one of the machines in my lab, and
guess
what, almost no difference between fsync and open_sync. Either on jfs or
ext2.
The difference, Linux 2.6.3? My original tests where on
Hi!
Sorry if I post this mail to the wrong list, I checked each by it's
theme and this seems to be the best.
I have a strange problem with an errorcontextcallback:
Given the following code fragment:
mycallback-previous = error_context_stack;
elog(DEBUG1,1);
On Mon, Aug 09, 2004 at 09:30:09AM +0200, Peter Eisentraut wrote:
Tom Lane wrote:
I haven't seen any particular reason why we should adopt another SCM.
Perhaps BitKeeper or SubVersion would be better for our purposes than
CVS, but are they enough better to justify the switchover costs?
=?iso-8859-1?q?Mamta=20Singh?= [EMAIL PROTECTED] writes:
Also, give me some idea as to what do we
need to change to implement undo-file.
It's very unlikely that we'll ever implement WAL-based UNDO.
No one has given any convincing reason to think it's a good idea.
Thank you all once again for your hard work and dedication to quality
software! Looking forward to 8.0.
platform: Mac OS X 10.3.5
evironment and ./configure
PGVER=8.0.0
PGPORT=54800
PGUSER=postgres
PGTAGNAME=pgsql 8.0.0
PGSRCROOT=/usr/local/src/pgsql-8.0.0
PGINSTROOT=/usr/local/pgsql-8.0.0
Reinoud van Leeuwen wrote:
Why? I understood that using BitKeeper for free for Open Source
projects is allowed. (but IANAL).
It is available (on many platforms). It works great. Once you use
changesets you'll never want to go back to cvs.
There is a world of a difference between being free
Alvaro Herrera Munoz [EMAIL PROTECTED] writes:
... I'll be back on monday 16.
Okay. It's certainly not something we must fix this week.
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list
Tom Lane wrote:
Kevin Brown [EMAIL PROTECTED] writes:
... But what we're talking about
here is brand new functionality for which the language hasn't been
defined yet.
You're missing the point, which is that there *is* a precedent of long
standing. ALTER TABLE has worked on indexes
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
* Allow an alias to be provided for the target table in UPDATE/DELETE
Yea, I guess for a long table that also needed an alias you would have
to specify the long name every time you reference the table. However,
we haven't had
On Tue, Aug 10, 2004 at 12:24:06PM -0400, Tom Lane wrote:
My discovery last night of a WAL synchronization error in pg_clog led me
to take a look at pg_subtrans too. I soon realized that in fact we are
not WAL-logging pg_subtrans updates at all: subtransaction start sets up
a pg_subtrans
Harald,
You're talking about the deletion target table. Sorry to mention
the M word again, but MySQL allows deleting from more than one table
at the same time. Should we support that?
Nope. In fact, I'd argue pretty strongly against any move to do so.
MySQL supports multi-table delete
Serguei A. Mokhov wrote:
backend/po/fr.po had 99% translations done for 7.4, and nos it is
totally missing for the current CVS tip (it is in the
Attic)... why? Most of those messasge are still applicable to
the current, no? Commit message from you from 2 weeks ago says:
The file has
[EMAIL PROTECTED] wrote:
I have been considering a full sweep in my test lab off client time later on.
ext2, ext3, jfs, xfs, and ReiserFS, fsync on with fdatasync or open_sync,
and fsync off.
Before you start: double check that the disks are not lying:
At least the suse 2.4 kernel send cache
Reinoud van Leeuwen said:
On Mon, Aug 09, 2004 at 09:30:09AM +0200, Peter Eisentraut wrote:
Tom Lane wrote:
I haven't seen any particular reason why we should adopt another
SCM. Perhaps BitKeeper or SubVersion would be better for our
purposes than CVS, but are they enough better to justify
Bruce,
Yea, I guess for a long table that also needed an alias you would have
to specify the long name every time you reference the table. However,
we haven't had anyone ask for that capability, even for UPDATE which
does already have that limitation. Seems like a new TODO item but I am
Laszlo Hornyak [EMAIL PROTECTED] writes:
and the callback function logs callback, the following apears in the log:
ERROR: callback
Can anybody tell me why this happens?
Sure you didn't elog(ERROR) rather than elog(LOG) inside the
callback function?
In any case, you can't expect useful help
Bruce Momjian [EMAIL PROTECTED] writes:
* Allow an alias to be provided for the target table in UPDATE/DELETE
Yea, I guess for a long table that also needed an alias you would have
to specify the long name every time you reference the table. However,
we haven't had anyone ask for that
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
* Allow an alias to be provided for the target table in UPDATE/DELETE
This is not SQL-spec but many DBMSs allow it.
I don't think we would ever do the above item.
Why not? You can hardly argue that it's not
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
* Allow an alias to be provided for the target table in UPDATE/DELETE
This is not SQL-spec but many DBMSs allow it.
I don't think we would ever do the above item.
Why not? You can hardly argue that it's not SQL spec while
Jan Wieck wrote:
On 8/9/2004 7:41 PM, Gaetano Mendola wrote:
If I remember well this is the first command that need to change
GUC in order to change behaviour, I don't think we wrote:
set vacuum_mode = full;
set vacuum_verbosity = on;
vacuum;
You got a point here. However, we don't have
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
This description confuses two quite separate issues.
Yea, it does.
How is this text:
* Allow DELETE to handle table aliases for self-joins
There is no way to create a table alias for the deleted table
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
This description confuses two quite separate issues.
Yea, it does.
How is this text:
* Allow DELETE to handle table aliases for self-joins
There is no way to create a table alias for the deleted table for use
in the DELETE
[EMAIL PROTECTED] writes:
After delving into this a little, it seems to me that if you are going to
do this:
write(file, buffer, size);
f[data]sync(file);
Opening with O_SYNC seems to be an optimization specifically to this
methodology.
What you are missing is that we don't necessarily do
My discovery last night of a WAL synchronization error in pg_clog led me
to take a look at pg_subtrans too. I soon realized that in fact we are
not WAL-logging pg_subtrans updates at all: subtransaction start sets up
a pg_subtrans entry but makes no WAL entry for this action.
Seems like this is
While investigating Satoshi Okada's bug report here
http://archives.postgresql.org/pgsql-hackers/2004-08/msg00510.php
I realized that it actually represents a crash-safety risk that has
existed since 7.2.
lecture
Allow me to refresh your memory about the principles of write-ahead
logging. The
I need a real example of using bytea in the following scenario:
1) A large binary object is located in a C++ memory space obtained
through malloc.
2) I want to store it in the database.
What exactly does the code look like?
Thanks,
Kenny
---(end of
Dear All,
I built PG 8.0 beta1 on an Itanium 2 platform using the Intel compilers
version 8, and got one real difference in the regression tests that affected
int2, int4, union, and numerology. Here's the key difference:
horta postgres 177 diff -c int4.out ../expected/
*** int4.out
Andreas Pflug [EMAIL PROTECTED] writes:
The USING would be in place of the mandatory FROM in MSSQL. And why use
a different keyword for the same thing in DELETE and UPDATE?
Please read the earlier part of the thread... this ground was covered
already.
As for emulating MSSQL's syntax, we are
I wrote:
I'm certainly not arguing for a wholesale rework of the syntax in order
to achieve maximum consistency (nice as that might be), but it seems to
me that it would be a mistake to introduce more inconsistency than is
already there when it's not necessary to do so.
What I mean here is
Andreas,
The USING would be in place of the mandatory FROM in MSSQL. And why use
a different keyword for the same thing in DELETE and UPDATE?
Um, because for us the 1st FROM isn't optional (per SQL spec)?
--
-Josh Berkus
A developer of Very Little Brain
Aglio Database Solutions
San
Bruce Momjian wrote:
It's been agreed that the keyword should
be USING, to avoid anything as confusing as DELETE FROM a FROM b.
FYI,
MSSQL says
DELETE
[FROM]
{tablename}
[FROM {tablesource [, ...] ]
[WHERE condition]
Note that the first FROM is optional (as in Oracle), we can have
DELETE
I was sent a log file for a production system that has received several
ABORT signals while under heavy load. Here's a snippet from the logs:
---
LOG: recycled transaction log file 000A004B
LOG: recycled transaction log file 000A004D
LOG: recycled transaction log file
Peter Eisentraut [EMAIL PROTECTED] writes:
Why is the encoding WIN 1250 only for the client side? It seems that
with the new Windows port, folks will be interested in using it on the
server side.
I can't see any technical reason why not. But I find this in
doc/README.mb.jp:
- Never try to
On Tue, 10 Aug 2004, Peter Eisentraut wrote:
Date: Tue, 10 Aug 2004 20:51:52 +0200
Serguei A. Mokhov wrote:
backend/po/fr.po had 99% translations done for 7.4, and nos it is
totally missing for the current CVS tip (it is in the
Attic)... why? Most of those messasge are still
On Mon, 9 Aug 2004, Laszlo Hornyak wrote:
Hi!
Sorry if I post this mail to the wrong list, I checked each by it's
theme and this seems to be the best.
I have a strange problem with an errorcontextcallback:
Given the following code fragment:
mycallback-previous =
OKADA Satoshi [EMAIL PROTECTED] writes:
I'm testing PITR using pgbench and postgresql ver.8.0bata.
I think that result of recovery is wrong.
Many thanks for this bug report. I have developed a patch (attached)
that seems to fix it for me. Please test and see if you can still
cause the
(BTW, does a fr_CA version of it have a chance of being accepted? French
here (in Canada) is still a bit different with its own specifics.
Spelling-wise, the most notable difference is having CAPS with accents
where fr_FR normally doesn't have (for corresponding lowercase accented
letters) and
What I mean here is that I think it would be in our best interests to
define the syntax for any new operation to be as easily guessed as
possible. I believe that ALTER INDEX would be more easily guessed by
more people as the means by which one would alter an index's tablespace
than ALTER TABLE,
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
en_BR would be cool, then I don't have to put up with all that American
spelling :)
I thought you'd be looking for en_OZ ...
regards, tom lane
---(end of broadcast)---
Tom Lane wrote:
(B
(BOKADA Satoshi [EMAIL PROTECTED] writes:
(B
(B
(BI'm testing PITR using pgbench and postgresql ver.8.0bata.
(BI think that result of recovery is wrong.
(B
(B
(B
(BMany thanks for this bug report. I have developed a patch (attached)
(Bthat seems to fix it for
Can we put in a recommendation in the release notes that people use 8.0
pg_dump to do their dump? I think that will make everyone's upgrades go
much more smoothly, and we will get many fewer complaints.
I don't think many users realise they can use the next version's pg_dump
to upgrade. I
en_BR would be cool, then I don't have to put up with all that American
spelling :)
I thought you'd be looking for en_OZ ...
en_AU, but it's exactly the same as EN_BR, so that's fine :)
Chris
---(end of broadcast)---
TIP 8: explain analyze is your
On Tuesday 10 August 2004 22:57, Christopher Kings-Lynne wrote:
Can we put in a recommendation in the release notes that people use 8.0
pg_dump to do their dump? I think that will make everyone's upgrades go
much more smoothly, and we will get many fewer complaints.
I don't think many users
Date: Tue, 10 Aug 2004 21:30:23 +0200
From: Peter Eisentraut [EMAIL PROTECTED]
Why is the encoding WIN 1250 only for the client side? It seems that
with the new Windows port, folks will be interested in using it on the
server side.
Then what about WIN1251 (Cyrillic)? :) And all the
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
en_BR would be cool, then I don't have to put up with all that American
spelling :)
I thought you'd be looking for en_OZ ...
en_AU, but it's exactly the same as EN_BR, so that's fine :)
Oh, just the pronunciation that's different then?
Robert Treat [EMAIL PROTECTED] writes:
On Tuesday 10 August 2004 22:57, Christopher Kings-Lynne wrote:
I don't think many users realise they can use the next version's pg_dump
to upgrade. I think it should be put in every release notes!
Assuming we're not ready to recommend Slony for
63 matches
Mail list logo
