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
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
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
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
> 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
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
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
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
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
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)---
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
(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
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
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
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
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
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
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
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
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 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
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
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)---
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
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
[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
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
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
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
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
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:
>>> * 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
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,
> 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
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
[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
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
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
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
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
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
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
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:
"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
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
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
=?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
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
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 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
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
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
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
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
[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
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)
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
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
---(
>
> 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,
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
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
"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
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
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
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
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
66 matches
Mail list logo
