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 reque
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" 2>&1
pg_regres
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 t
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.
Ju
"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 includ
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 vi
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" sho
>
> 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
---(
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
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 broadcast)
[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 DEL
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 allo
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
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 pg
> 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 t
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.
re
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
P
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
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 for no
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 archi
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
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 hav
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 e
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.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 6
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 delet
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 ha
[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 flu
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
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 us
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 arg
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
SELECT
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 t
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 DE
[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 necessari
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 a
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.
Allow me to refresh your memory about the principles of write-ahead
logging. The one that e
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 broadcast)---
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.outTu
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 ar
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 Fr
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 { [, ...] ]
[WHERE ]
Note that the first FROM is optional (as in Oracle), we can have
DELETE a FROM b
The USING wo
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 fi
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 tr
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 st
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 = erro
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 pro
(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 spac
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, ev
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
(B>OKADA Satoshi <[EMAIL PROTECTED]> writes:
(B>
(B>
(B>>I'm testing PITR using pgbench and postgresql ver.8.0bata.
(B>>I think that result of recovery is wrong.
(B>>
(B>>
(B>
(B>Many thanks for this bug report. I have developed a patch (attached)
(B>that seems
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 thi
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 f
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 us
> 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 t
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 differe
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
Oh, just the pronunciation that's different then?
Y're rite cobber, c'mon ofer here and check a prawin on tha barbie, mate!
PS: just teasing of course
Of course :) I could make fun of Americans, but where do you start? :)
---(end of broadcast)---
TIP
Hi Tom,
After a downgrade to Postgres 7.2.2, I still got the xlateSqlType symbol
not found message. The install includes the packages:
libpgsql2-7.2.2-1mdk
postgresql-7.2.2-1mdk
postgresql-jdbc-7.2.2-1mdk
postgresql-server-7.2.2-1mdk
libecpg3-7.2.2-1mdk
libpgsqlodbc0-7.2.2-1mdk
librrdtool0-1.0.38
66 matches
Mail list logo
