On Tue, 2006-08-15 at 18:42 -0400, Tom Lane wrote:
> 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, t
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
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 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
> w
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 o
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.
"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 ha
"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
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 e
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
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 whic
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 a
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 rep
> > 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 broadcast
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
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 ha
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
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 th
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
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 d
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
-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
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 o
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 eve
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
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 suggest
"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
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=
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 list
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 everythi
"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 *;
>
"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 cu
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"
"[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).
App
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:
> > > >
> > > >
> > > >
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 a log file that
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 qu
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, 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());
> > >
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 h
On Tue, Aug 15, 2006 at 07:00:49PM +0200, Peter Eisentraut wrote:
> 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
> > jo
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());
> > > pg_xlogfile_name_offset
> > >
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
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
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
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 ar
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 cou
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 believ
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 DELE
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 compli
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
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 are
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 abo
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/colum
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 right
"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 o
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 a
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 thou
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??
>
> >>> Frank
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
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
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
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 non
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 or
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, wi
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 sor
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
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 t
"dror" <[EMAIL PROTECTED]> writes:
> Hi Andrew, Regarding to your comments: > 1. a patch is generated by the pro=
> gram "diff"I 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 tha
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
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
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 t
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
73 matches
Mail list logo
