On Sat, Aug 12, 2006 at 12:11:21AM +0800, William ZHANG wrote:
I have found the cause.
...
Thanks a lot for your effort.
In a few minutes I will commit a change that fixed this in my tests
(don't worry about the timestamp of this email, I'm writing while
sitting in a train).
All it does is
Hello,
On Mon, 2006-08-14 at 21:09 -0700, Darcy Buskermolen wrote:
It is with great enthuasim I announce that I have accepted an offer
from Joshua D. Drake of Command Prompt Inc, to join his team. As
former Vice President of Software Development with Wavefire
Technologies Corp, I endeavor to
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I am more than somewhat perplexed as to why the NUL device should be a
security risk ... what are they thinking??
Frankly, I don't believe it; even Microsoft can't be that stupid.
And I can't find any suggestion that they've
Darcy Buskermolen wrote:
Dear Community members,
It is with great enthuasim I announce that I have accepted an offer from
Joshua D. Drake of Command Prompt Inc, to join his team. As former Vice
President of Software Development with Wavefire Technologies Corp, I endeavor
to leverage over 10
Gavin Sherry [EMAIL PROTECTED] writes:
On Mon, 14 Aug 2006, Tom Lane wrote:
Correct me if I'm wrong, but isn't the patch's present hacking on the
executor intended to make it happen like this?
Not really. It reads ahead on the bitmap index and passes back the bitmap
words. The other executor
dror [EMAIL PROTECTED] writes:
Hi Andrew, Regarding to your comments: 1. a patch is generated by the pro=
gram diffI will do it ,if needed 2. before we do anything, as Tom Lane s=
ays, we need verification of the problem, preferably in writing from Micr=
osoft.I do understand that, but,
Hi All,
I agree with all of you that it is strange behavior, more then that :
On two win 2003 machines with the same SP and last hot fixes, on one the nul device is accessible by non admin user and on other it is not.
I also agree that the source of the problem might be something that effect
Andreas Pflug wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I am more than somewhat perplexed as to why the NUL device should be a
security risk ... what are they thinking??
Frankly, I don't believe it; even Microsoft can't be that stupid.
And I can't
On Fri, 11 Aug 2006, Alvaro Herrera wrote:
I am suggesting that. I have heard all the old discussions about not
using a bugtracker, but in all fairness, I think some of us have to
create critical mass and get something started.
I will install anything, and everything, if you can get some
Bruce, Andrew, Tom.
I little bit confuse now, what status of this patch is? I check your
observation and I agree with them. But I don't where is ball now and
what I can/must do now like author of this patch?
Thanks for explanation
Zdenek
Bruce Momjian napsal(a):
OK,
Andrew Dunstan napsal(a):
Even at 32 this hardly seems to be a likely cause of the problem. I
think the maximum parallelism of our tests is around 20. Anyway, lets's
get the patch installed - I have a test regime set up that will
reproduce the error moderately reliably within about a dozen
Zdenek Kotala wrote:
Bruce, Andrew, Tom.
I little bit confuse now, what status of this patch is? I check your
observation and I agree with them. But I don't where is ball now and
what I can/must do now like author of this patch?
I am unsure too. I would not back out a patch for
On Mon, Aug 14, 2006 at 11:41:29PM +0300, Hannu Krosing wrote:
??hel kenal p??eval, E, 2006-08-14 kell 18:21, kirjutas Peter Eisentraut:
Perez wrote:
I thought, from watching the list for a while, that the planner
statistics needed were known but that how to gather the statistics
was
On Tue, Aug 15, 2006 at 01:29:02AM -0400, Bruce Momjian wrote:
Wouldn't it be weird if an update to pg_stat_activity.current_query
actually ran that query for the selected backend:
UPDATE pg_stat_activity SET current_query = SELECT 1
WHERE procpid = 19522;
Interesting thought,
On Aug 15, 2006, at 10:40 , Jim C. Nasby wrote:
Yeah, unless someone comes up with some kind of 'magic', I think
trying
to handle every cross-column possibility is a non-starter. IIRC, that
argument is what's stalled cross-column stats every time in the
past. It
makes a lot more sense to
Michael Meskes [EMAIL PROTECTED]
On Sat, Aug 12, 2006 at 12:11:21AM +0800, William ZHANG wrote:
I have found the cause.
...
Thanks a lot for your effort.
You are welcome.
In a few minutes I will commit a change that fixed this in my tests
(don't worry about the timestamp of this
Bruce,
I think you have misunderstood.
If you and Peter have reviewed it thoroughly then I see no reason the
patch should not be applied.
My post below was merely to agree with Tom that in principle, patches
should be be reviewed before application and not after. I still think
that's
Andrew Dunstan wrote:
Bruce,
I think you have misunderstood.
If you and Peter have reviewed it thoroughly then I see no reason the
patch should not be applied.
We have. I did extensive rework, and Peter exchanged emails with the
author asking questions. I did have questions about how
Bruce Momjian wrote:
My post below was merely to agree with Tom that in principle, patches
should be be reviewed before application and not after. I still think
that's right - I have been concerned lately that the buildfarm has been
broken a bit too much.
Well, just because they
AgentM wrote:
I've always found it odd that database didn't determine which
statistics are the most interesting from the queries themselves.
The overhead of doing that on the fly is probably prohibitive. More
explicit profiling support could be helpful, but that would seem a lot
more
Hi,
I'm doing some tests of Bernd's updatable views patch and found
something interesting about the RETURNING behavior
testing_uv=# create table bar (field1 integer);
CREATE TABLE
testing_uv=# create view v_bar as select * from bar;
CREATE VIEW
the rules are created as:
_DELETE AS
ON
Andrew Dunstan wrote:
If you and Peter have reviewed it thoroughly then I see no reason the
patch should not be applied.
I merely said that the way the patch was presented, with significant
code refactoring mixed in, I couldn't review it (as effectively as
perhaps otherwise). FWIW, I believe
On Aug 15, 2006, at 12:26 , Peter Eisentraut wrote:
AgentM wrote:
I've always found it odd that database didn't determine which
statistics are the most interesting from the queries themselves.
The overhead of doing that on the fly is probably prohibitive. More
explicit profiling support
On Fri, 2006-08-11 at 08:04 +0100, Simon Riggs wrote:
On Thu, 2006-08-10 at 08:57 -0400, Tom Lane wrote:
Anyway, after further thought I've concluded that we really should
supply something that returns the Insert pointer, as this would be
useful for debugging and system-monitoring
Bruce Momjian wrote:
Andreas Pflug wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I am more than somewhat perplexed as to why the NUL device should be a
security risk ... what are they thinking??
Frankly, I don't believe it; even Microsoft can't be that stupid.
Andreas Pflug wrote:
Bruce Momjian wrote:
Andreas Pflug wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I am more than somewhat perplexed as to why the NUL device should be a
security risk ... what are they thinking??
Frankly, I don't believe it; even
Simon Riggs wrote:
postgres=# select pg_xlogfile_name_offset(pg_switch_xlog());
pg_xlogfile_name_offset
---
00010001 16777216
(1 row)
I've not taken up Jim Nasby's suggestion to make this an SRF with
multiple return rows/columns
Andreas Pflug [EMAIL PROTECTED] writes:
what issues might arise if the output is redirected to a legal tmp file?
Well, (1) finding a place to put the temp file, ie a writable directory;
(2) ensuring the file is removed afterwards; (3) not exposing the user
to security hazards due to unsafe use
AgentM wrote:
Couldn't the session be explicitly transferred into a special
analysis mode? Explain analyze could run on every query implicitly
and point out time and row count discrepancies as HINTs. Multi-column
joins, for example, could be pointed out and display whether or not
there are
Darcy Buskermolen wrote:
Dear Community members,
It is with great enthuasim I announce that I have accepted an offer from
Joshua D. Drake of Command Prompt Inc, to join his team. As former Vice
President of Software Development with Wavefire Technologies Corp, I endeavor
to leverage over 10
On Tue, 2006-08-15 at 11:10 -0400, Alvaro Herrera wrote:
Simon Riggs wrote:
postgres=# select pg_xlogfile_name_offset(pg_switch_xlog());
pg_xlogfile_name_offset
---
00010001 16777216
(1 row)
I've not taken up Jim Nasby's
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
what issues might arise if the output is redirected to a legal tmp file?
Well, (1) finding a place to put the temp file, ie a writable directory;
(2) ensuring the file is removed afterwards; (3) not exposing the user
to
Jim C. Nasby wrote:
Meet EXPLAIN ANALYZE.
Which does no good for apps that you don't control the code on. Even
if you do control the code, you have to find a way to stick EXPLAIN
ANALYZE in front of every query, and figure out how to deal with
what's comming back.
It would not be hard to
On Tue, 2006-08-15 at 12:13 -0500, Jim C. Nasby wrote:
On Tue, Aug 15, 2006 at 06:07:12PM +0100, Simon Riggs wrote:
On Tue, 2006-08-15 at 11:10 -0400, Alvaro Herrera wrote:
Simon Riggs wrote:
postgres=# select pg_xlogfile_name_offset(pg_switch_xlog());
On Aug 15, 2006, at 13:55 , Peter Eisentraut wrote:
Jim C. Nasby wrote:
Meet EXPLAIN ANALYZE.
Which does no good for apps that you don't control the code on. Even
if you do control the code, you have to find a way to stick EXPLAIN
ANALYZE in front of every query, and figure out how to deal
On Tue, Aug 15, 2006 at 07:55:28PM +0200, Peter Eisentraut wrote:
Jim C. Nasby wrote:
Meet EXPLAIN ANALYZE.
Which does no good for apps that you don't control the code on. Even
if you do control the code, you have to find a way to stick EXPLAIN
ANALYZE in front of every query, and
In addition to Andreas respond:
1+2) Currently the initDB is used the tmp folder to write other "Helper files" that are deleted afterwards.
The fix is suggested only for win machines ,I think that redirection is more risky (as we saw with this bug) than to do redirect output to alog file that
On Tue, Aug 15, 2006 at 07:11:24PM +0100, Simon Riggs wrote:
On Tue, 2006-08-15 at 12:13 -0500, Jim C. Nasby wrote:
On Tue, Aug 15, 2006 at 06:07:12PM +0100, Simon Riggs wrote:
On Tue, 2006-08-15 at 11:10 -0400, Alvaro Herrera wrote:
Simon Riggs wrote:
postgres=#
[EMAIL PROTECTED] [EMAIL PROTECTED] writes:
This is an updated version of the PL instrumentation plugin patch that I
submitted on July-28. The new version re-implements the plugin loader
code to use rendezvous variables as suggested by Tom Lane (thanks Tom,
very elegant design).
Applied with
Peter Eisentraut [EMAIL PROTECTED] writes:
I merely said that the way the patch was presented, with significant
code refactoring mixed in, I couldn't review it (as effectively as
perhaps otherwise). FWIW, I believe that the general approach is
sound, but I haven't actually reviewed the
Jaime Casanova [EMAIL PROTECTED] writes:
I'm doing some tests of Bernd's updatable views patch and found
something interesting about the RETURNING behavior
...
but if i insert using the rules the returning clause is ignored
testing_uv=# insert into v_bar values (3), (4) returning *;
INSERT 0
Marc G. Fournier wrote:
On Fri, 11 Aug 2006, Alvaro Herrera wrote:
I am suggesting that. I have heard all the old discussions about not
using a bugtracker, but in all fairness, I think some of us have to
create critical mass and get something started.
I will install anything, and
Applied with a few small changes --- I renamed the GUC variables after a
suggestion by Simon Riggs, and fixed things so that
backend_load_libraries could actually do something useful (you had it as
PGC_POSTMASTER, making it effectively no more flexible than the existing
preload_libraries
On 8/15/06, Tom Lane [EMAIL PROTECTED] wrote:
Jaime Casanova [EMAIL PROTECTED] writes:
I'm doing some tests of Bernd's updatable views patch and found
something interesting about the RETURNING behavior
...
but if i insert using the rules the returning clause is ignored
testing_uv=# insert
Jaime Casanova [EMAIL PROTECTED] writes:
On 8/15/06, Tom Lane [EMAIL PROTECTED] wrote:
What are you testing exactly? I think this recent fix might be
relevant:
http://archives.postgresql.org/pgsql-committers/2006-08/msg00299.php
i have tested again against current HEAD... what i do is to
RT is easy to setup/configure/use and works well with PostgreSQL
as the backend. CPAN uses it for their bug tracker. Was there a
list of features and requirements?
Ken
On Tue, Aug 15, 2006 at 10:59:52AM -0300, Marc G. Fournier wrote:
On Fri, 11 Aug 2006, Alvaro Herrera wrote:
I am suggesting
Jim C. Nasby [EMAIL PROTECTED] writes:
True, but making people parse the output of a function to seperate the
two fields seems pretty silly. Is there some reason why
pg_xlogfile_name_offset shouldn't be a SRF, or use two out parameters?
It'd definitely be nicer that way, but given the current
On Tue, Aug 15, 2006 at 10:53:28AM -0500, Kenneth Marshall wrote:
RT is easy to setup/configure/use and works well with PostgreSQL
as the backend. CPAN uses it for their bug tracker. Was there a
list of features and requirements?
I don't know if we ever came up with one, but I know that the
On Tue, 15 Aug 2006, Jim C. Nasby wrote:
On Tue, Aug 15, 2006 at 10:53:28AM -0500, Kenneth Marshall wrote:
RT is easy to setup/configure/use and works well with PostgreSQL
as the backend. CPAN uses it for their bug tracker. Was there a
list of features and requirements?
I don't know if we
I wrote:
It'd definitely be nicer that way, but given the current limitations of
bootstrap mode I see no non-kluge way to make a built-in function have
OUT parameters. (Hint: array_in doesn't work in bootstrap mode.)
Actually, that turns out not to be so hard to fix as I thought.
array_in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Is there a better solution to the index bloat problem with regards
to minimizing locking while reducing an ever-growing use of disk
space? In particular, it would be nice if there was a way to force
VACUUM [FULL] to do some of the compression that
Jim C. Nasby wrote:
On Tue, Aug 15, 2006 at 10:53:28AM -0500, Kenneth Marshall wrote:
RT is easy to setup/configure/use and works well with PostgreSQL
as the backend. CPAN uses it for their bug tracker. Was there a
list of features and requirements?
I don't know if we ever came up with
Greg Sabino Mullane wrote:
Is there a better solution to the index bloat problem with regards
to minimizing locking while reducing an ever-growing use of disk
space? In particular, it would be nice if there was a way to force
VACUUM [FULL] to do some of the compression that REINDEX now does.
I've used and use RT. It is web based for admin, but all the transactions
are E-Mail based.
http://www.bestpractical.com
I can also make a test queue on my instance if someone wants to play.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 512-248-2683
On 8/15/06, Tom Lane [EMAIL PROTECTED] wrote:
But even this seems like it would fail in complicated cases. What if
the view is a join, and your ON INSERT rule inserts into two different
underlying tables in two commands? If you need fields from both tables
to generate a full RETURNING list
Andrew Dunstan wrote:
Bruce Momjian wrote:
My post below was merely to agree with Tom that in principle, patches
should be be reviewed before application and not after. I still think
that's right - I have been concerned lately that the buildfarm has been
broken a bit too much.
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
I merely said that the way the patch was presented, with significant
code refactoring mixed in, I couldn't review it (as effectively as
perhaps otherwise). FWIW, I believe that the general approach is
sound, but I haven't
In an attempt to throw the authorities off his trail, ler@lerctr.org (Larry
Rosenman) transmitted:
I've used and use RT. It is web based for admin, but all the transactions
are E-Mail based.
http://www.bestpractical.com
I can also make a test queue on my instance if someone wants to play.
see. Collecting the statistics thereafter isn't that hard, but there
needs to be a way to not collect an exponential volume of statistics on
all column combinations.
You could collect them on all FK relationships - is that enough?
Chris
---(end of
We have three candidates already -- debbugs, RT and Gnats. The first
has the advantage that was written by hackers, for hackers, so it
doesn't have any of the insane for end users stuff which annoys so
many people around here ;-) (On the other hand it does have some web
stuff for generating
Martha Stewart called it a Good Thing when [EMAIL PROTECTED] (Christopher
Kings-Lynne) wrote:
We have three candidates already -- debbugs, RT and Gnats. The
first has the advantage that was written by hackers, for hackers,
so it doesn't have any of the insane for end users stuff which
annoys
Christopher Kings-Lynne wrote:
We have three candidates already -- debbugs, RT and Gnats. The first
has the advantage that was written by hackers, for hackers, so it
doesn't have any of the insane for end users stuff which annoys so
many people around here ;-) (On the other hand it does have
Trac does support PostgreSQL...
The thing I don't understand at this point is what exactly is the
nature of the integration with the SCM.
I don't see it being likely that there will be a deep integration of
the PostgreSQL SCM (whatever the SCM platform) with Trac; that's way
too much change to
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
see. Collecting the statistics thereafter isn't that hard, but there
needs to be a way to not collect an exponential volume of statistics on
all column combinations.
You could collect them on all FK relationships - is that enough?
As
Jim C. Nasby [EMAIL PROTECTED] writes:
I don't know if we ever came up with one, but I know that the big deal
killer for a bug tracker is that a lot of hackers don't want to be
forced to use a web interface instead of email. So basically, to be
accepted, a bug tracker would have to have an
Thanks. I have committed your patches.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Hi Tatsuo-san and folks,
This is a fix in pgbench to handle empty lines in external scripts.
The manual says
| Empty lines and lines begging with -- will be ignored.
but AFAICS, it cannot accept empty lines and exit
Hi guys
Andrew and I got together and worked out a more detailed idea of how we
want to add enums to the postgresql core. This follows on from his
original enumkit prototype last year [1]. Here's a more formal proposal
/ design with what we came up with. Comments / criticism hereby solicited.
On Aug 16, 2006, at 12:29 , Tom Lane wrote:
So my current take on this would be that the bug tracker
would have to have a reasonable output email capability, but I'd not
necessarily insist on being able to input to it by mail.
Setting aside the email in, how would people feel about Atom or
Tom Lane wrote:
that the bug tracker would have to have a reasonable output email
capability, but I'd not necessarily insist on being able to input
to it by mail. Red Hat's present bugzilla system could be described
that way --- and while I can't say I'm in love with it, I can deal
with it.
Bruce,
Wouldn't it be weird if an update to pg_stat_activity.current_query
actually ran that query for the selected backend:
Wierd? Yes. Useful? No.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)---
TIP 2: Don't 'kill
Tom,
These days I doubt there's anyone around the project who refuses to use
a web browser at all. However, I still personally find it much more
convenient to read and respond to mailing-list postings than to have to
go and visit random web pages to find out if there's something I need to
71 matches
Mail list logo
