> -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_aut
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 unsucc
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?
http://www.postgresql.org
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 i
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
optio
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 monolithi
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
h
Am Mittwoch, 11. August 2004 07:04 schrieb Serguei Mokhov:
> > 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 th
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 re
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 arg
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
pra
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 t
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 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 t
[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. Ma
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 mean
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 sta
> 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
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 br
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 consum
CREATE FUNCTION xxx() RETURNS integer
AS $$ begin return 1;
2004-08-12 01:38:48 EST: 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 start/end.
>> 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 objectio
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 --functi
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
"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 opera
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 a
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
> defin
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 bec
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 delibera
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 re
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 atomic
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
impossib
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 directo
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 r
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 fil
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 resolved,
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
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 unreg
At 03:33 AM 12/08/2004, Tom Lane wrote:
Do you have time to fix it?
Should do; I'll add the die-on-error option as well.
Con someone confirm how dollar quoting works:
'$[tag]$'
where tag is alpha chars? any chars? \n? \r?
and closing tag must match.
All dollar-quotes inside any kind of quotes c
At 02:33 AM 12/08/2004, Fabien COELHO wrote:
Maybe the time has come;-)
Sounds good to me. We've had the original behaviour since 7.1, I can
understand there may be a desire to make it consistent with the
carr-on-regardless behaviour of psql, but changing it in one release
without the ability to
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? Is it just an expectation problem that could
be fixed with better docs? I tend to expect scripts to die when they
encounter an
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$
?
David Fetter <[EMAIL PROTECTED]> writes:
> Are the packaged versions (OK, the Dea^WRed Hat RPMs) going out at the
> same time?
No, but I'll be working on those as soon as the tarballs are wrapped.
> On a slightly related topic, I'm thinking I should only put the
> latest, greatest on the bt serve
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 d
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
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 i
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 loo
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
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
> rel
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 correc
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 scann
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 explici
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,
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?
>\
>
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 comp
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-quoti
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 dollar-quot
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 igno
The pg_dump fix in 8.0 that stops the destruction of existing users in
the target database via "DELETE FROM pg_shadow WHERE usesysid <> (..."
would be great!
regards
Mark
Tom Lane wrote:
Comments anyone? Backpatches for other bugs?
---(end of broadcast)---
Sorry - I meant pg_dump*all* rather than pg_dump.
Mark Kirkwood wrote:
The pg_dump fix in 8.0 that stops the destruction of existing users in
the target database via "DELETE FROM pg_shadow WHERE usesysid <> (..."
would be great!
regards
Mark
Tom Lane wrote:
Comments anyone? Backpatches for othe
Robert,
Are you planning to use Intel's C compiler in production?
We tried that some time ago and corrupted our database cluster almost
instantly (for some reason we have not investigated any further).
I highly recommend to do some stress testing to see if everything works
nicely.
I'd be pleased
77 matches
Mail list logo
