--- Original Message ---
From: Tom Lane [EMAIL PROTECTED]
To: Dave Page [EMAIL PROTECTED]
Sent: 1/5/07, 10:48:17 PM
Subject: Re: [HACKERS] -f output file option for pg_dumpall
Wouldn't it be easier/better to re-point stdout at the -f file, and not
touch pg_dump at all?
First
--- Original Message ---
From: Tom Lane [EMAIL PROTECTED]
To: Dave Page [EMAIL PROTECTED]
Sent: 1/5/07, 10:52:37 PM
Subject: Re: [HACKERS] -f output file option for pg_dumpall
I think this will be an exercise in time-wasting, and very possibly
destabilize *both* tools. pg_dump
What's about spronsoring ? I and Teodor would like to present
new full text search, now built into PostgreSQL core.
We already have patch for 8.3 and current documentation is available
http://mira.sai.msu.su/~megera/pgsql/ftsdoc/
Oleg
On Fri, 5 Jan 2007, Dan Langille wrote:
I have the
On Fri, 2007-01-05 at 20:19 -0500, Tom Lane wrote:
The only other solution I can see is to make use of the lookahead filter
we already have in filtered_base_yylex() to combine NULLS FIRST and
NULLS LAST into single tokens. This is not an ideal solution: consider
SELECT * FROM nulls
Dave Page wrote:
In pgAdmin we use pg_dump's -f option to write backup files. The IO
streams are redirected to display status and errors etc. in the GUI.
In order to enhance the interface to allow backup of entire clusters
as well as role and tablespace definitions, we need to be able to get
On 6 Jan 2007 at 12:09, Oleg Bartunov wrote:
What's about spronsoring ?
Are you asking if your and Teodor can be sponsored?
I and Teodor would like to present new full text search, now built into
PostgreSQL core. We already have patch for 8.3 and current
documentation is available
On Mon, 2007-01-01 at 19:04 -0500, Bruce Momjian wrote:
I will start processing the patches held for 8.3 this week or next, now
that the holiday break is over:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
The following patches don't appear on this list:
Concurrent psql
Simon Riggs wrote:
All have been awaiting review for at least a month (though in one case
the latest version is quite recent). They probably ought to be on the
hold queue; all are ready to be reviewed for final
application/rejection.
I'd hasten to add that none of those are mine. My patches
On Fri, 2007-01-05 at 22:57 -0500, Tom Lane wrote:
Jim Nasby [EMAIL PROTECTED] writes:
On Jan 5, 2007, at 6:30 AM, Zeugswetter Andreas ADI SD wrote:
Ok, so when you need CRC's on a replicate (but not on the master) you
Which sounds to me like a good reason to allow the option in
Dave Page [EMAIL PROTECTED] writes:
From: Tom Lane [EMAIL PROTECTED]
I think forking a separate
pg_dump for each database is a perfectly fine arrangement, and should be
left alone.
Hmm, would you be happy with my original proposal to add an append option to
pg_dump?
I don't object to it
Bruce Momjian [EMAIL PROTECTED] writes:
FYI, I am going need to add documentation in the COPY manual page or no
one will know about this performance enhancement.
I don't think it belongs in COPY. What would make more sense is another
item under the populating a database performance tips,
Simon Riggs [EMAIL PROTECTED] writes:
Presumably you could put extra grammar rules in to throw errors when you
see FROM NULLS FIRST?
It'll throw an error just fine without any extra rules, because there
won't be any production allowing the NULLS_FIRST pseudo-token there.
You already see this in
Bruce Momjian wrote:
Log Message:
---
Check for ERANGE in exp() as well.
this broke the regression tests on a number of boxes:
http://buildfarm.postgresql.org/cgi-bin/show_status.pl
example:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=spongedt=2007-01-06%2015:30:02
Euler Taveira de Oliveira [EMAIL PROTECTED] writes:
Simon Riggs wrote:
The enclosed patch implements this, as discussed. There is no user
interface to enable/disable, just as with CTAS and CREATE INDEX; no
docs, just code comments.
IMHO, this deserves an GUC parameter (use_wal_in_copy?).
Patch applied. Thanks.
---
Euler Taveira de Oliveira wrote:
Peter Eisentraut wrote:
On the name of the option, it's not actually a data directory, so I'd
just
call it --xlogdir, parallel to --datadir.
Seems
Stefan Kaltenbrunner wrote:
Bruce Momjian wrote:
Log Message:
---
Check for ERANGE in exp() as well.
this broke the regression tests on a number of boxes:
http://buildfarm.postgresql.org/cgi-bin/show_status.pl
example:
Peter Eisentraut wrote:
Dave Page wrote:
In pgAdmin we use pg_dump's -f option to write backup files. The IO
streams are redirected to display status and errors etc. in the GUI.
In order to enhance the interface to allow backup of entire clusters
as well as role and tablespace definitions, we
I have looked over this patch, and it completes part of this TODO item:
o Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM
ANALYZE, and CLUSTER
Here is the foundation of it:
For an incoming EXPLAIN command, the planner generates the plan and, if
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
From: Tom Lane [EMAIL PROTECTED]
I think forking a separate
pg_dump for each database is a perfectly fine arrangement, and should be
left alone.
Hmm, would you be happy with my original proposal to add an append option to
pg_dump?
I
Simon Riggs wrote:
I'm not clear about the difference between the unapplied patches list
and the hold list. What is the significance of the two lists?
There's a number of patches submitted to pgsql-patches that don't show
up on either list. I haven't made a list of these, but they include
On Sat, 2007-01-06 at 10:56 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
All have been awaiting review for at least a month (though in one case
the latest version is quite recent). They probably ought to be on the
hold queue; all are ready to be reviewed for final
application/rejection.
Kenneth Marshall wrote:
One problem with only putting this information in the system logs
is that when we provide database services to a member of our
community we do not actually give them an account of the DB server
or log server. This means that this very useful information would
need to
Simon Riggs wrote:
On Sat, 2007-01-06 at 10:56 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
All have been awaiting review for at least a month (though in one case
the latest version is quite recent). They probably ought to be on the
hold queue; all are ready to be reviewed for final
Simon Riggs wrote:
Somehow, neither of these statements seem likely to be uttered by
a sane DBA ...
If I take a backup of a server and bring it up on a new system, the
blocks in the backup will not have been CRC checked before they go to
disk.
If I take the same server and now stream
Bruce Momjian wrote:
The issue is that the _hold_ patches are for patches that arrived after
feature freeze. The patches that arrived after 8.2 was released don't
go in there because it might cause confusion. I also have to control
how quickly I push out patches from the queue so as not to
Dave Page wrote:
Bruce Momjian wrote:
The issue is that the _hold_ patches are for patches that arrived after
feature freeze. The patches that arrived after 8.2 was released don't
go in there because it might cause confusion. I also have to control
how quickly I push out patches from
Bruce Momjian wrote:
Dave Page wrote:
Bruce Momjian wrote:
The issue is that the _hold_ patches are for patches that arrived after
feature freeze. The patches that arrived after 8.2 was released don't
go in there because it might cause confusion. I also have to control
how quickly I push out
Dave Page wrote:
Bruce Momjian wrote:
Dave Page wrote:
Bruce Momjian wrote:
The issue is that the _hold_ patches are for patches that arrived after
feature freeze. The patches that arrived after 8.2 was released don't
go in there because it might cause confusion. I also have to
Ron Mayer wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
What value is allowing multiple queies via PQexec()
The only argument I can think of is that it allows applications to be
sloppy about parsing a SQL script into individual commands before they
send it. (I think
Do we need a TODO for this?
---
Tom Lane wrote:
Markus Schiltknecht [EMAIL PROTECTED] writes:
I've just found the stumbling block: the -c option of psql wraps all in
a transaction, as man psql says:
...
Thank you
I saw no replies to this.
---
Simon Riggs wrote:
Merge Joins require us to potentially Mark and Restore positions in the
tuples arriving from executor sub-nodes.
This currently means that if the tuples arrive from a
Added to TODO:
* Make consistent use of long/short command options --- pg_ctl needs
long ones, pg_config doesn't have short ones, postgres doesn't have
enough long ones, etc.
---
Andrew Dunstan wrote:
I notice that
On Sat, 6 Jan 2007, Dan Langille wrote:
On 6 Jan 2007 at 12:09, Oleg Bartunov wrote:
What's about spronsoring ?
Are you asking if your and Teodor can be sponsored?
yes
I and Teodor would like to present new full text search, now built into
PostgreSQL core. We already have patch for
Dhanaraj M wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Dhanaraj M wrote:
I am sending the patch for the following TODO item:
Allow the identifier length to be increased via a configure option
You should use pg_config.h, not mangle
Bruce Momjian wrote:
Added to TODO:
* Make consistent use of long/short command options --- pg_ctl needs
long ones, pg_config doesn't have short ones, postgres doesn't have
enough long ones, etc.
Certainly postgres has plenty of long ones. And I don't know why
pg_config would need
Peter Eisentraut wrote:
Bruce Momjian wrote:
Added to TODO:
* Make consistent use of long/short command options --- pg_ctl needs
long ones, pg_config doesn't have short ones, postgres doesn't have
enough long ones, etc.
Certainly postgres has plenty of long ones. And I don't
Tom Lane wrote:
I'm wondering how this got into the TODO list. It seems rather
pointless, and likely to create client compatibility problems (if
not, why is NAMEDATALEN exported at all?)
I think because it used to be used in libpq's notification structure.
--
Peter Eisentraut
Hi!
I'm trying to implement a top level node that must have a lefttree and a
righttree. The lefttree consists of a regular tree of other nodes required
for the query (that I let postgres' optimizer build on its own) and the
righttree should be a table scan (of a table called for in the FROM
Bruce Momjian wrote:
pg_config would need short ones.
Seems we should have some,
But why? What is the use case? It's not like pg_config is a frequently
typed command.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
... why is NAMEDATALEN exported at all?)
I think because it used to be used in libpq's notification structure.
Yeah, you're probably right. Maybe we should take it out of
postgres_ext.h and move it to pg_config_manual.h. If no one
On 7 Jan 2007 at 1:39, Oleg Bartunov wrote:
On Sat, 6 Jan 2007, Dan Langille wrote:
On 6 Jan 2007 at 12:09, Oleg Bartunov wrote:
What's about spronsoring ?
Are you asking if your and Teodor can be sponsored?
yes
I and Teodor would like to present new full text search, now
Peter Eisentraut wrote:
Bruce Momjian wrote:
pg_config would need short ones.
Seems we should have some,
But why? What is the use case? It's not like pg_config is a frequently
typed command.
I thought consistency. Why do any of the commands have long and short
options?
--
On Fri, Jan 05, 2007 at 08:45:51PM -0500, Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] writes:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
What value is allowing multiple queies via PQexec()
The only argument I can think of is that it allows applications to be
sloppy about
elein wrote:
On Fri, Jan 05, 2007 at 08:45:51PM -0500, Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] writes:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
What value is allowing multiple queies via PQexec()
The only argument I can think of is that it allows applications
Bruce Momjian [EMAIL PROTECTED] writes:
Do we need a TODO for this?
Well, if we *don't* change the backend to disallow multi statements per
PQexec, then we'd probably better do something about this. If we do
make that change then it's not a problem anymore.
Hm, that's an interesting point.
On Sat, 2007-01-06 at 20:14 -0500, Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian wrote:
pg_config would need short ones.
Seems we should have some,
But why? What is the use case? It's not like pg_config is a frequently
typed command.
I thought consistency.
Bruce Momjian [EMAIL PROTECTED] writes:
We aren't going to disable that --- we are considering disabling the
backend from treating it as a single transaction.
Or even more specifically, making sure that that only happens if you
explicitly put begin/commit into the -c string.
One thing I think
Simon Riggs [EMAIL PROTECTED] writes:
The rule is: if the relfilenode for a table is new in this transaction
(and therefore the whole things will be dropped at end-of-transaction)
then *all* COPY commands are able to avoid writing WAL safely, if:
- PITR is not enabled
- there is no active
Bruce Momjian [EMAIL PROTECTED] writes:
Simon Riggs wrote:
Reason for no documentation was that CREATE INDEX and CREATE TABLE AS
SELECT already use this optimisation, but to my knowledge neither was/is
documented on those command pages.
I wasn't aware those used the optimization. Seems they
Bruce Momjian [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
Certainly postgres has plenty of long ones. And I don't know why
I don't see them.
postgres/postmaster accept --any-guc-variable=value. AFAIR all the
single-letter options these days are equivalent to one of those.
There's not
Robert Treat [EMAIL PROTECTED] writes:
On Saturday 06 January 2007 16:36, Simon Riggs wrote:
snip
BEGIN;
CREATE TABLE foo...
INSERT INTO foo --uses WAL
COPY foo.. --no WAL
INSERT INTO foo --uses WAL
COPY foo.. --no WAL
INSERT INTO foo --uses WAL
COPY foo... --no WAL
Is there some technical reason that the INSERT statements need to use WAL
in
these scenarios?
First, there's enough other overhead to an INSERT that you'd not save
much percentagewise. Second, not using WAL doesn't come for free: the
cost is having to fsync the whole table
Bruce Momjian [EMAIL PROTECTED] writes:
Tom, on HPPA, does ERANGE get set for both overflow and underflow? I
assume only overflow.
Yeah, AFAICT exp() just returns zero for underflow cases. I get
regression=# select exp(-2000);
ERROR: value out of range: underflow
but I was getting that
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom, on HPPA, does ERANGE get set for both overflow and underflow? I
assume only overflow.
Yeah, AFAICT exp() just returns zero for underflow cases. I get
regression=# select exp(-2000);
ERROR: value out of range: underflow
Joshua D. Drake [EMAIL PROTECTED] writes:
cost is having to fsync the whole table afterwards. So it really only
makes sense for commands that one can expect are writing pretty much
all of the table. I could easily see it being a net loss for individual
INSERTs.
What about multi value
On Sat, 2007-01-06 at 22:09 -0500, Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
cost is having to fsync the whole table afterwards. So it really only
makes sense for commands that one can expect are writing pretty much
all of the table. I could easily see it being a net loss
Bruce Momjian [EMAIL PROTECTED] writes:
The attached patch warns users when they create documentation output
that has no index, and suggests re-running 'gmake'.
This is just useless noise. If it could tell the difference between an
up-to-date index and a not-up-to-date one, there might be some
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The attached patch warns users when they create documentation output
that has no index, and suggests re-running 'gmake'.
This is just useless noise. If it could tell the difference between an
up-to-date index and a not-up-to-date
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The attached patch warns users when they create documentation output
that has no index, and suggests re-running 'gmake'.
This is just useless noise. If it could tell the difference between an
up-to-date
On Sat, 2007-01-06 at 23:38 -0500, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The attached patch warns users when they create documentation output
that has no index, and suggests re-running 'gmake'.
This is just useless noise. If it could tell the difference between an
Joshua D. Drake wrote:
On Sat, 2007-01-06 at 23:38 -0500, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The attached patch warns users when they create documentation output
that has no index, and suggests re-running 'gmake'.
This is just useless noise. If it could tell the
61 matches
Mail list logo
