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)---
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
-Original Message-
From: Matthew T. O'Connor [mailto:[EMAIL PROTECTED]
Sent: 10 August 2004 21:41
To: Tom Lane
Cc: Dave Page; PostgreSQL-development;
[EMAIL PROTECTED]; Bruce Momjian
Subject: Re: [HACKERS] pg_autovacuum Win32 Service Code
One comment: IMHO the pg_autovacuum
I just noticed that we support NT4 according to the draft release notes
at http://developer.postgresql.org/beta-history.txt. In actual fact, it
probably won't work well as Andreas' tablespace/symlink code uses
junction points which are not available on NT4, in addition to which, we
have been
will PITR in 8.0 be usable for hot spare/log shipping type of
replication or is it just for Point In Time RECOVERY ?
---
Hannu
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
Dave Page wrote:
I just noticed that we support NT4 according to the draft release notes
at http://developer.postgresql.org/beta-history.txt. In actual fact, it
probably won't work well as Andreas' tablespace/symlink code uses
junction points which are not available on NT4,
There's still a chance
Josh Berkus wrote:
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)?
Seems that many RDBMS regard that FROM as a noise word. Making it
On 08/06/04:31/5, Joe Conway wrote:
I just reread your comment and thought about it more. I think most of
what I said in the last post holds, but in addition part of the problem
lies in the fact that we don't implement multidimensional arrays as
nested arrays, but rather as one monolithic
Am Mittwoch, 11. August 2004 04:34 schrieb Christopher Kings-Lynne:
en_BR would be cool, then I don't have to put up with all that American
spelling :)
It would be en_GB (BR = Brazil), but by all means, feel free to do it. The
market would certainly be large enough.
--
Peter Eisentraut
Am Mittwoch, 11. August 2004 00:01 schrieb Serguei A. Mokhov:
So? It is still valid in most part for 8.0. The parts that are not, won't
do any bad.
I think at the time I thought that a 7.5 version was going to be sent soon
thereafter. Anyway, I've put the 7.4 file in the head branch now.
Some recent change in libpq seems to interfere with gtk.
After I tested a new pgadmin3 version on linuy yesterday, I found that
the GUI is hanging after PQconnectdb was called. After the call, the db
connection is fully functional, but the GUI mouse will show waiting
and the program doesn't
In article [EMAIL PROTECTED],
Josh Berkus [EMAIL PROTECTED] writes:
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
Tom Lane wrote:
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 ...
$ LANG=en_OZ initdb
Stone the bloody crows, mate! Where's yer PGDATA? Don't come the raw
Andreas Pflug wrote:
Some recent change in libpq seems to interfere with gtk.
After I tested a new pgadmin3 version on linuy yesterday, I found that
the GUI is hanging after PQconnectdb was called. After the call, the db
connection is fully functional, but the GUI mouse will show waiting
and
Maybe I'm losing it, but I forced to apologize for trying to push for
open_sync as the default.
I have spent the last few days trying to come to some solid, documented
and verifyable, conclusions about which is the best fsync method. At a
minimum, what is the best fsync method for Linux. I can't
Against CVS HEAD:
test=# select version();
version
---
PostgreSQL 8.0.0beta1 on i686-pc-linux-gnu, compiled by GCC
In 8.0 beta 1 I just tried:
psql template1
begin;
select * from pg_class;
... got stuff ...
select * from aaa;
ERROR: relation zzz does not exist
select * from pg_class;
ERROR: current transaction is aborted
Should psql run every statement in a nested
[EMAIL PROTECTED] writes:
What would be a good strategy for addressing this issue? Is it an issue at
all? Is it simply a documentation issue? Do we craft some sort of test
that can characterize the behavior? What would that test need to do?
It seems to me that it's a documentation issue.
On Wed, 11 Aug 2004, Harald Fuchs wrote:
In article [EMAIL PROTECTED],
Josh Berkus [EMAIL PROTECTED] writes:
A) In what order are the rows deleted, from which table first?
In exactly the same order as for single-table DELETEs -
implementation-defined.
I think you probably meant in an
Tom Lane wrote:
While investigating Satoshi Okada's bug report here
...
What I am thinking of doing to fix the problem is to introduce
a new LWLock that RecordTransactionCommit will take a shared lock on
before writing its WAL record, and not release until it has updated
pg_clog. Checkpoint
In 8.0 beta 1 I just tried:
psql template1
begin;
select * from pg_class;
... got stuff ...
select * from aaa;
ERROR: relation zzz does not exist
select * from pg_class;
ERROR: current transaction is aborted
Should psql run every
On Wed, 2004-08-11 at 01:11, Tom Lane wrote:
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!
Hannu Krosing [EMAIL PROTECTED] writes:
will PITR in 8.0 be usable for hot spare/log shipping type of
replication or is it just for Point In Time RECOVERY ?
It should work; dunno if anyone has tried it yet.
regards, tom lane
---(end of
The default setting of 'false' is a pain. And the fact it can't be changed
by an option is even more of a pain. Any objections to adding an option to
pg_restore to allow 'die_on_errors' to be set to 'true'?
-D(?) --die-on-errors
At 01:47 AM 12/08/2004, Tom Lane wrote:
It might be reasonable to offer that behavior as an option, but I think
I'd only want it on for interactive input.
My preference would be for something like:
set savepoint_per_statement=true
then interactive scripts could choose to use either feature.
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
I don't think any test that we could build would be as useful as simply
trying the different settings with an installation's real workload.
Benchmarking the real workload isn't always so easy, and might be quite
time
CREATE FUNCTION xxx() RETURNS integer
AS $$ begin return 1;
2004-08-12 01:38:48 ESTzzz,birds: ERROR: unterminated dollar-quoted
string at or near $$ begin return 1; at character 115
Just realized the problem; pg_restore uses a trivial parser to work out
when statements
Should psql run every statement in a nested transaction and only rollback
that TX?
psql is designed to follow the same logical statement progression as any
other connection to the database. Your suggestion could muck up sql
scripts piped through it to the database.
The other objection is
Just found this:
createdb zzz
createlang plpgsql zzz
psql zzz
create function xxx() returns integer as
$$ begin return 1; end; $$
language plpgsql;
\q
pg_dump -Fc zzz zzz.bck
dropdb zzz
createdb zzz
createlang plpgsql zzz
pg_restore
Andreas Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
I don't think any test that we could build would be as useful as simply
trying the different settings with an installation's real workload.
Benchmarking the real workload isn't always so easy, and might be quite
time consuming to
Min Xu (Hsu) [EMAIL PROTECTED] writes:
It seems to me this is an interesting phenomena of interactions between
frequent events of transaction commits and infrequent events of system
checkpoints. A potential alternative solution to adding a new shared
lock to the frequent commit operation is
Tom Lane wrote:
I don't think any test that we could build would be as useful as simply
trying the different settings with an installation's real workload.
Benchmarking the real workload isn't always so easy, and might be quite
time consuming to obtain meaningful values. Don't you think that some
I'll take a swing at making the language a little stronger. We could
also add it as a mailing list hint. Chris, you have any other ideas
where you would like to see it?
Literally in the release notes - that's all that anyone reads of a new
release :) Wherever it says 'upgrading to 8.0 requires
Philip Warner [EMAIL PROTECTED] writes:
Just realized the problem; pg_restore uses a trivial parser to work out
when statements start/end. It knows about quotes but not about dollar-quotes.
Blech. Do you have time to fix it?
regards, tom lane
Am Mittwoch, 11. August 2004 15:07 schrieb Andreas Pflug:
Some recent change in libpq seems to interfere with gtk.
You could use nm to find common symbols that might be clashing. Besides
that, it's hard to tell more. Alternatively, compile with versioned symbols
and see whether the problem
In article [EMAIL PROTECTED],
Stephan Szabo [EMAIL PROTECTED] writes:
In exactly the same order as for single-table DELETEs -
implementation-defined.
I think you probably meant in an unspecified order.
Implementation-defined really doesn't mean anything when you're trying to
define what it
Am Dienstag, 10. August 2004 17:55 schrieb Fabien COELHO:
(1) all makefiles in contrib include directly src/Makefile.global which
is generated by configure, although it is already included by the
src/makefiles/pgxs.mk makefile anyway, so it seems to me that it
is useless because
Dear Philip,
The default setting of 'false' is a pain. And the fact it can't be
changed by an option is even more of a pain. Any objections to adding an
option to pg_restore to allow 'die_on_errors' to be set to 'true'?
If I remember correctly, I'm the one who implemented that ignore error
Philip Warner [EMAIL PROTECTED] writes:
The default setting of 'false' is a pain. And the fact it can't be changed
by an option is even more of a pain. Any objections to adding an option to
pg_restore to allow 'die_on_errors' to be set to 'true'?
If you like, but that change was deliberate
On Wed, 11 Aug 2004, Harald Fuchs wrote:
In article [EMAIL PROTECTED],
Stephan Szabo [EMAIL PROTECTED] writes:
In exactly the same order as for single-table DELETEs -
implementation-defined.
I think you probably meant in an unspecified order.
Implementation-defined really doesn't mean
I have seen similar when running under heavy load with high frequent
insert+delete+vacuum. What happens is that adding another item to an
index page in the btree access method fails. It seems to me that the
decision to add an item to a page and the real work of actually adding
it are not
Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
will PITR in 8.0 be usable for hot spare/log shipping type of
replication or is it just for Point In Time RECOVERY ?
It should work; dunno if anyone has tried it yet.
I was thinking about it but I soon realized that actually is
impossible to
Gaetano Mendola [EMAIL PROTECTED] writes:
Tom Lane wrote:
It should work; dunno if anyone has tried it yet.
I was thinking about it but I soon realized that actually is
impossible to do, postgres replay the log only if during the
start the file recover.conf is present in $DATA directory :-(
Jan Wieck wrote:
I have seen similar when running under heavy load with high frequent
insert+delete+vacuum. What happens is that adding another item to an
This fits the profile of this application perfectly.
index page in the btree access method fails. It seems to me that the
decision to add an
Jan Wieck [EMAIL PROTECTED] writes:
I have seen similar when running under heavy load with high frequent
insert+delete+vacuum. What happens is that adding another item to an
index page in the btree access method fails. It seems to me that the
decision to add an item to a page and the real
Tom Lane wrote:
We've seen reports like this once or twice before, so I think that there
may indeed be some corner-case bug involved, but it's not going to be
possible to find it without a test case ... or at least a debuggable
core dump from the PANIC.
I just talked to the guy who sent the log
The core committee has agreed that this bug
http://archives.postgresql.org/pgsql-hackers/2004-08/msg00639.php
is serious enough that we'd better push out update releases for
all the affected versions. I want to hold off a day or so and see
if a couple of currently-open bug reports can be
On Wed, Aug 11, 2004 at 06:08:10PM -0400, Tom Lane wrote:
The core committee has agreed that this bug
http://archives.postgresql.org/pgsql-hackers/2004-08/msg00639.php is
serious enough that we'd better push out update releases for all the
affected versions. I want to hold off a day or so and
Tom Lane wrote:
Somebody should hack this together and try it during beta. I don't
have time myself.
Will see, if I have spare time I will try.
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 2: you can get off all lists at once with the
I wonder if there will be assumptions in the startup code concerning
time. What if the startup takes 18 months, would there be some sort
of problem with this approach you think?
On Aug 11, 2004, at 6:14 PM, Gaetano Mendola wrote:
Tom Lane wrote:
Somebody should hack this together and try it
Philip Warner [EMAIL PROTECTED] writes:
Con someone confirm how dollar quoting works:
'$[tag]$'
where tag is alpha chars? any chars? \n? \r?
IIRC the tag is either empty or anything that looks like a
(dollar-sign-less) identifier. But check the rules in scan.l to be sure.
Is there any
At 12:15 PM 12/08/2004, Tom Lane wrote:
IIRC we tried to do ad-hoc code for dollar quoting in psql, and gave it
up as a bad job. You might need to bite the bullet and implement a flex
lexer.
Looks like the psql side of things is not ideal (see other post).
Any idea how backslashes should handled
At 12:15 PM 12/08/2004, Tom Lane wrote:
Why exactly does pg_restore need to parse the SQL anyway?
It just looks for complete statements. From memory it relates to the
possibility that TOC entries can have more than one statement, or it may
relate to handling COPY statements. I think it has to
Philip Warner [EMAIL PROTECTED] writes:
At 02:31 AM 12/08/2004, Tom Lane wrote:
result of
considerable experience that says die_on_errors is NOT the right
behavior for pg_restore.
Can you point me to examples?
Trawl the archives for pg_restore complaints ... but basically the point
is that
Philip Warner [EMAIL PROTECTED] writes:
Any idea how backslashes should handled in and out of the tag?
Backslashes aren't legal in the tag, I'm quite sure. In the body of the
quoted string they are not special in any way.
regards, tom lane
Philip Warner [EMAIL PROTECTED] writes:
At 12:15 PM 12/08/2004, Tom Lane wrote:
Why exactly does pg_restore need to parse the SQL anyway?
It just looks for complete statements. From memory it relates to the
possibility that TOC entries can have more than one statement, or it may
relate to
Philip Warner [EMAIL PROTECTED] writes:
While trying to understand dollar-quoting, I found the following in psql:
select $a$ hello $a$;
behaves as expected, but psql does not like
select $a$ \ $a$;
or
select $a$ \\ $a$;
Define does not like. The behavior seems correct to me.
Brian Hirt [EMAIL PROTECTED] writes:
I wonder if there will be assumptions in the startup code concerning
time. What if the startup takes 18 months, would there be some sort
of problem with this approach you think?
I don't know of any such assumptions, but this sort of question is why
At 12:42 PM 12/08/2004, Tom Lane wrote:
Hm. But we could assume that a COPY will be all by itself in a TOC
entry, couldn't we?
Maybe. I know I hit a couple of nasty examples in the original code. Isn't
the COPY combined with the data? If so, we still have to scan for it's end.
The existing
At 12:47 PM 12/08/2004, Tom Lane wrote:
Backslashes are not special inside
dollar quotes --- nor is anything else, except the matching close tag
If they are not special, then shouldnt:
select $a$\$a$;
result in
?column?
\
rather than an error?
At 12:47 PM 12/08/2004, Tom Lane wrote:
Backslashes are not special inside
dollar quotes --- nor is anything else, except the matching close tag
If they are not special, then shouldnt:
select $a$\$a$;
result in
?column?
\
rather than an error?
Oops. It does.
Philip Warner wrote:
While trying to understand dollar-quoting, I found the following in psql:
select $a$ hello $a$;
behaves as expected, but psql does not like
select $a$ \ $a$;
or
select $a$ \\ $a$;
Should it? How should a dollar-quote handle:
$a$ \$a\$a $a$
?
andrew=# select $a$ \
At 01:07 PM 12/08/2004, Andrew Dunstan wrote:
\ is not magical inside dollar quotes,
Sorry, I was confused by the manual: the paragraph that starts C-style
backslash escapes are also available... is right after the paragraphs on
dollar-quoting.
The section on dollar-quoting is also not explicit
Philip Warner [EMAIL PROTECTED] writes:
At 12:42 PM 12/08/2004, Tom Lane wrote:
Hm. But we could assume that a COPY will be all by itself in a TOC
entry, couldn't we?
Maybe. I know I hit a couple of nasty examples in the original code. Isn't
the COPY combined with the data? If so, we still
Philip Warner [EMAIL PROTECTED] writes:
At 12:47 PM 12/08/2004, Tom Lane wrote:
Backslashes are not special inside
dollar quotes --- nor is anything else, except the matching close tag
If they are not special, then shouldnt:
select $a$\$a$;
result in
?column?
\
rather than
Tom Lane wrote:
Philip Warner [EMAIL PROTECTED] writes:
At 02:31 AM 12/08/2004, Tom Lane wrote:
result of
considerable experience that says die_on_errors is NOT the right
behavior for pg_restore.
Can you point me to examples?
Trawl the archives for pg_restore complaints ... but
Philip Warner [EMAIL PROTECTED] writes:
At 01:07 PM 12/08/2004, Andrew Dunstan wrote:
\ is not magical inside dollar quotes,
Sorry, I was confused by the manual: the paragraph that starts C-style
backslash escapes are also available... is right after the paragraphs on
dollar-quoting.
The
Philip Warner wrote:
At 01:07 PM 12/08/2004, Andrew Dunstan wrote:
\ is not magical inside dollar quotes,
Sorry, I was confused by the manual: the paragraph that starts
C-style backslash escapes are also available... is right after the
paragraphs on dollar-quoting.
The section on
At 01:27 PM 12/08/2004, Bruce Momjian wrote:
Set client_min_messages to WARNING?
Sounds like a plan.
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498)
At 12:15 PM 12/08/2004, Tom Lane wrote:
You might need to bite the bullet and implement a flex
lexer.
I'd like to avoid this if I can; AFAICT, for statement detection on
pg_restore, I can require white space before the $tag. Since I also skip
over all quoted text, the bodies of functions are
70 matches
Mail list logo
