[HACKERS] New PostgreSQL Tool available : pg_autotune

[Justin Clift]

Hi everyone,

Have been putting together a tool called "pg_autotune" for automatically
tuning a PostgreSQL database (either local or remote).  It does this by
repetitively benchmarking PostgreSQL (using Tatsuo's pgbench code) with
different buffer settings, then fine tuning those settings depending on
the results returned.  All of the data generated is stored into a
separate PostgreSQL database for further aggregate analysis later on.

This should be a default tool for all new PostgreSQL installations.

The URL for pg_autotune is:

http://gborg.postgresql.org/project/pgautotune

It was created on a FreeBSD system, but should also work on at least
Linux, Solaris, and MacOS X.

This is a time & load intensive tool, so you'll need to ensure you only
run it when you have a couple of hours to wait for the results. 
Overnight is good.  :)

Regards and best wishes,

Justin Clift

-- 
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
   - Indira Gandhi

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

[HACKERS] Gborg projects

[Shridhar Daithankar]

Hi all,

I just submitted a project to GBorg. I got it submitted and it told me that 
GBorg staff would be back to me after review.

I would love to have a check box on project registration page which asks 
whether you have some code to submit or not. 

Because in my case I have some..;-)

TIA..
Bye
 Shridhar

--
Silverman's Law:If Murphy's Law can go wrong, it will.


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] [GENERAL] New PostgreSQL Tool available : pg_autotune

[Tom Lane]

Justin Clift <[EMAIL PROTECTED]> writes:
> Have been putting together a tool called "pg_autotune" for automatically
> tuning a PostgreSQL database (either local or remote).  It does this by
> repetitively benchmarking PostgreSQL (using Tatsuo's pgbench code) with
> different buffer settings, then fine tuning those settings depending on
> the results returned.

You should have chosen a better foundation.  pg_bench is notorious for
producing results that are (a) nonrepeatable and (b) not relevant to
a wide variety of situations.  All it really tells you about is the
efficiency of a large number of updates to a small number of rows.

I'd take the results with a large grain of salt.

regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[HACKERS] Schema vs Namespace

[Peter Eisentraut]

What's the strategy for naming things schema or namespace?  In notice that
pg_dump messages are all about namespaces.  That seems confusing from a
user's viewpoint.

-- 
Peter Eisentraut   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

[HACKERS] Postmaster help output

[Peter Eisentraut]

$ postmaster --help
...
Report bugs to <[EMAIL PROTECTED]>.
DEBUG:  proc_exit(0)
DEBUG:  shmem_exit(0)
DEBUG:  exit(0)
$

This is from a fresh installation, no debugging turned on.

-- 
Peter Eisentraut   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] [GENERAL] New PostgreSQL Tool available : pg_autotune

[Justin Clift]

Tom Lane wrote:
> 
> Justin Clift <[EMAIL PROTECTED]> writes:
> > Have been putting together a tool called "pg_autotune" for automatically
> > tuning a PostgreSQL database (either local or remote).  It does this by
> > repetitively benchmarking PostgreSQL (using Tatsuo's pgbench code) with
> > different buffer settings, then fine tuning those settings depending on
> > the results returned.
> 
> You should have chosen a better foundation.  pg_bench is notorious for
> producing results that are (a) nonrepeatable and (b) not relevant to
> a wide variety of situations.  All it really tells you about is the
> efficiency of a large number of updates to a small number of rows.

Hi Tom,

You're totally right about this.  Have been forced to ensure that each
client connection does a minimum of 200 transactions per connection,
etc, just to get anything in the way of reliable results.

It's just that this started out as playing around with pgbench, then
grew from that.  However, it's been put together so that other tests can
be added easily, and it doesn't even have to use Tatsuo's pgbench code.

Was thinking of asking Andy Riebs if we'd be ok to use his OSDB code, as
we'd need him to ok this in order to have it still be under the BSD
license.

> I'd take the results with a large grain of salt.

It takes the inaccuracy of Tatsuo's pgbench code into account.

:-)

Regards and best wishes,

Justin Clift

 
> regards, tom lane

-- 
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
   - Indira Gandhi

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Postmaster help output

[Alvaro Herrera]

Peter Eisentraut dijo: 

> $ postmaster --help
> ...
> Report bugs to <[EMAIL PROTECTED]>.
> DEBUG:  proc_exit(0)
> DEBUG:  shmem_exit(0)
> DEBUG:  exit(0)
> $

This is weird:

$ postmaster -d1 --help
FATAL:  --help requires argument
$

-- 
Alvaro Herrera ()
"La espina, desde que nace, ya pincha" (Proverbio africano)


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] DROP COLUMN misbehaviour with multiple inheritance

[Tom Lane]

Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Another interesting case is multiple inheritance.
>> 
>> create table p1 (f1 int);
>> create table p2 (f1 int);
>> create table c () inherits(p1, p2);
>> 
>> drop ONLY column p1.f1;
>> drop column p2.f1;
>> 
>> After this sequence, what is the state of c.f1?  Is it still there?
>> Should it be?

> Well, in this case the column is dropped.  If the last drop is ONLY, the
> column will stay (regardless of what the first drop did).

It seems to me that DROP ONLY should set attislocal true on each child
for which it decrements the inherit count, whether the count reaches
zero or not.  This would cause the behavior in the above case to be that
c.f1 stays around after the second drop (but can be dropped with a third
drop of c.f1 itself).  I think this is correct, since the implication of
DROP ONLY is that child columns are being cut loose from their parent's
apron strings and now have independent existence.

This is a minor tweak to your patch, and I'll make it work that way
unless I hear squawks...

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] Schema vs Namespace

[Tom Lane]

Peter Eisentraut <[EMAIL PROTECTED]> writes:
> What's the strategy for naming things schema or namespace?  In notice that
> pg_dump messages are all about namespaces.  That seems confusing from a
> user's viewpoint.

Probably the user-visible messages should all mention schemas.

I named the catalog pg_namespace because I didn't want to nail down
a presumption that the things in it are exactly equivalent to SQL
schemas; namespaces are an implementation mechanism to support schemas,
but not necessarily an equivalent concept.  But this bit of
implementation philosophy isn't very relevant for users.

regards, tom lane

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] DROP COLUMN misbehaviour with multiple inheritance

[Alvaro Herrera]

Tom Lane dijo: 

> It seems to me that DROP ONLY should set attislocal true on each child
> for which it decrements the inherit count, whether the count reaches
> zero or not.  This would cause the behavior in the above case to be that
> c.f1 stays around after the second drop (but can be dropped with a third
> drop of c.f1 itself).  I think this is correct, since the implication of
> DROP ONLY is that child columns are being cut loose from their parent's
> apron strings and now have independent existence.

Yes, I think it's more consistent the way you are proposing.

-- 
Alvaro Herrera ()
"Acepta los honores y aplausos y perderas tu libertad"


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Postmaster help output

[Tom Lane]

Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Peter Eisentraut dijo: 
>> $ postmaster --help
>> ...
>> Report bugs to <[EMAIL PROTECTED]>.
>> DEBUG:  proc_exit(0)
>> DEBUG:  shmem_exit(0)
>> DEBUG:  exit(0)
>> $

Fixed: someone was sloppy about the initial value of server_min_messages.

> This is weird:

> $ postmaster -d1 --help
> FATAL:  --help requires argument
> $

This is because --help is special-cased and only works at the first
argument position.  As you have it, it's being taken as a GUC switch
name.

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: SIMILAR TO syntax (Was: Re: The TODO List (Was: Re: [HACKERS] O...)

[Tom Lane]

> On Thu, 19 Sep 2002, Tom Lane wrote:
>> AFAICS, getting SIMILAR TO to operate per spec would require adding some
>> sort of translation function that converts the spec-style pattern into
>> a Posix pattern that our regex match engine would handle.

I did something about this.  The translation function probably needs
work (for one thing, it's not multibyte-aware) but it's a start; and
we shouldn't need any more initdbs to tweak it.

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] ECPG

[Tom Lane]

I had a thought about what to do with the ECPG grammar-too-big problem:
rather than depending on a beta release of bison, we could attack the
problem directly by omitting some of the backend grammar from what ECPG
supports.  Surely there are not many people using ECPG to issue obscure
utility commands like, for example, DROP OPERATOR CLASS.

I haven't tried this to see just how much we'd have to dike out, but
my guess is that we could push the ecpg grammar down to something that
would get through stock bison without omitting anything anyone's even
remotely likely to miss.

This is, of course, an ugly hack that we'd want to undo once more
capable versions of bison are readily available.  But I think it could
tide us over for a release or two.

Comments?

regards, tom lane

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] ECPG

[Bruce Momjian]

Tom Lane wrote:
> I had a thought about what to do with the ECPG grammar-too-big problem:
> rather than depending on a beta release of bison, we could attack the
> problem directly by omitting some of the backend grammar from what ECPG
> supports.  Surely there are not many people using ECPG to issue obscure
> utility commands like, for example, DROP OPERATOR CLASS.
> 
> I haven't tried this to see just how much we'd have to dike out, but
> my guess is that we could push the ecpg grammar down to something that
> would get through stock bison without omitting anything anyone's even
> remotely likely to miss.
> 
> This is, of course, an ugly hack that we'd want to undo once more
> capable versions of bison are readily available.  But I think it could
> tide us over for a release or two.
> 
> Comments?

I think we should just go with the bison beta for ecpg and be done with
it.  If we find bugs, we can ask the bison folks to fix it, or work
around it ourselves.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] ECPG

[Bruce Momjian]

Michael Meskes wrote:
> Hi,
> 
> I just removed the prepare/execute/deallocate function from ecpg's
> parser so there are no conflicts anymore. But for the future (that is
> after 7.3 is released) I'd like to work something out. The only problem
> I see with using the backend functions is that the backend prepare needs
> the data type for each variable and I have no idea how to present it
> given the embedded syntax. I take it the backend prepare cannot work
> without this info, can it?
> 
> Also I still have some open bug reports but on the other hand few to no
> available time. Shall we add these reports to the TODO list? I doubt
> I'll be able to fix them ntil release time, at least not all of them.

Yes, please send over additional TODO items.  Thanks.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] Memory Errors...

[Bruce Momjian]

[ Previous version removed from patches queue..]

Thanks for doing both interfaces.

Your patch has been added to the PostgreSQL unapplied patches list at:

http://candle.pha.pa.us/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

---


Nigel J. Andrews wrote:
> 
> Ok, below is the original email I sent, which I can not remember seeing come
> across the patches list. Please do read the assumptions since they might throw
> up problems with what I have done.
> 
> I have attached the pltcl patch again, just in case. For the sake of clarity
> let's say this patch superscedes the previous one.
> 
> I have also attached a patch addressing the similar memory leak problem in
> plpython. This includes a slight adjustment of the tests in the source
> directory. The patch also includes a cosmetic change to remove a compiler
> warning although I think the change makes the code look worse though.
> 
> Once again, please read my text below and also take a quick look at the comment
> I've added in the plpython patch since it may well show that that
> particular change is complete rubbish.
> 
> BTW, by my reckoning the memory leak would occur with prepared plans and
> without. If that is not the case then I've been barking up the wrong tree.
> 
> Of further note, I have not tested for the memory leak in plpython but the
> build passes the normal and big checks. However, I have tried testing using the
> test.sh script in src/pl/plpython. This seems to be generating errors where
> before there were warnings. Can anyone comment on the correctness of this?
> Reversing my changes doesn't really help matters so I presume it is something
> else that is causing the different behaviour.
> 
> 
> -- 
> Nigel J. Andrews
> 
> 
> On Fri, 20 Sep 2002, Nigel J. Andrews wrote:
> 
> > On Thu, 19 Sep 2002, Tom Lane wrote:
> > 
> > > "Ian Harding" <[EMAIL PROTECTED]> writes:
> > > > It is pltcl [not plpgsql]
> > > 
> > > Ah.  I don't think we've done much of any work on plugging leaks in
> > > pltcl :-(.
> > > 
> > > > It hurts when I do this:
> > > 
> > > > drop function memleak();
> > > > create function memleak() returns int as '
> > > > for {set counter 1} {$counter < 10} {incr counter} {
> > > > set sql "select ''foo''"
> > > > spi_exec "$sql"
> > > > }
> > > > ' language 'pltcl';
> > > > select memleak();
> > > 
> > > Yeah, I see very quick memory exhaustion also :-(.  Looks like the
> > > spi_exec call is the culprit, but I'm not sure exactly why ...
> > > anyone have time to look at this?
> > 
> > Attached is a patch that frees the SPI_tuptable in all post SPI_exec
> > non-elog paths in both pltcl_SPI_exec() and pltcl_SPI_execp().
> > 
> > The fault as triggered by the above code has been fixed by this patch but
> > please read my assumptions below to ensure they are correct.
> > 
> > I have assumed that Tom's comment about this only being required in non-elog
> > paths is correct, which seems a reasonable assumption to me.
> > 
> > I have also assumed, rather than verified, that freeing the tuptable does
> > indeed free the tuples as well. Tests with the above function show that the
> > process does not increase it's memory footprint during it's operation, although
> > if my assumption here is wrong this could be a feature of selecting
> > insignificantly sized tuples.
> > 
> > I have not worried about other uses of SPI_exec for selects in pltcl.c on the
> > basis that those are not under the control of the function writer and the
> > normal function management will release the storage.
> 

Content-Description: 

[ Attachment, skipping... ]

Content-Description: 

[ Attachment, skipping... ]

Content-Description: 

[ Attachment, skipping... ]

> 
> ---(end of broadcast)---
> TIP 6: Have you searched our list archives?
> 
> http://archives.postgresql.org

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] NUMERIC's transcendental functions

[Bruce Momjian]

When you say:

> So proposal #1 is to rip out the numeric versions of these functions.

you mean remove the ability to do transendentals on numerics to prevent
such unusual auto-casting?  Are you suggesting that in all other cases,
autocast to numeric is OK?  I am a little confused.

---

Tom Lane wrote:
> I have noticed a change in behavior following the recent changes for
> casting of numeric constants.  In prior releases, we got
> 
> regression=# select log(10.1);
>log
> --
>  1.00432137378264
> (1 row)
> 
> CVS tip gives
> 
> regression=# select log(10.1);
>  log
> --
>  1.0043213738
> (1 row)
> 
> The reason for the change is that 10.1 used to be implicitly typed as
> float8, but now it's typed as numeric, so this command invokes
> log(numeric) instead of log(float8).  And log(numeric)'s idea of
> adequate output precision seems low.
> 
> Similar problems occur with sqrt(), exp(), ln(), pow().
> 
> I realize that there's a certain amount of cuteness in being able to
> calculate these functions to arbitrary precision, but this is a database
> not a replacement for bc(1).  ISTM the numeric datatype is intended for
> exact calculations, and so transcendental functions (which inherently
> have inexact results) don't belong.
> 
> So proposal #1 is to rip out the numeric versions of these functions.
> 
> If you're too attached to them, proposal #2 is to force them to
> calculate at least 16 digits of output, so that we aren't losing any
> accuracy compared to prior behavior.
> 
> Comments?
> 
>   regards, tom lane
> 
> ---(end of broadcast)---
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to [EMAIL PROTECTED] so that your
> message can get through to the mailing list cleanly
> 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] PGXLOG variable worthwhile?

[Marc G. Fournier]

On Fri, 20 Sep 2002, Bruce Momjian wrote:

> In fact, I tried to open a dialog with you on this issue several times,
> but when I got no reply, I had to remove PGXLOG.  If we had continued
> discussion, we might have come up with the GUC compromise.

Ya know, I'm sitting back and reading this, and other threads, and
assimilating what is being bantered about, and start to think that its
time to cut back on the gatekeepers ...

Thomas implemented an option that he felt was useful, and that doesn't
break anything inside of the code ... he provided 2 methods of being able
to move the xlog's to another location (through command line and
environment variable, both of which are standard methods for doing such in
server software) ... but, because a small number of ppl "voted" that it
should go away, it went away ...

You don't :vote: on stuff like this ... if you don't like it, you just
don't use it ... nobody is forcing you to do so.  If you think there are
going to be idiots out here that aren't going to use it right, then you
document it appropriately, with *strong* wording against using it ...



---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] PGXLOG variable worthwhile?

[Bruce Momjian]

Marc G. Fournier wrote:
> 
> On Fri, 20 Sep 2002, Bruce Momjian wrote:
> 
> > In fact, I tried to open a dialog with you on this issue several times,
> > but when I got no reply, I had to remove PGXLOG.  If we had continued
> > discussion, we might have come up with the GUC compromise.
> 
> Ya know, I'm sitting back and reading this, and other threads, and
> assimilating what is being bantered about, and start to think that its
> time to cut back on the gatekeepers ...
> 
> Thomas implemented an option that he felt was useful, and that doesn't
> break anything inside of the code ... he provided 2 methods of being able
> to move the xlog's to another location (through command line and
> environment variable, both of which are standard methods for doing such in
> server software) ... but, because a small number of ppl "voted" that it
> should go away, it went away ...
> 
> You don't :vote: on stuff like this ... if you don't like it, you just
> don't use it ... nobody is forcing you to do so.  If you think there are
> going to be idiots out here that aren't going to use it right, then you
> document it appropriately, with *strong* wording against using it ...

I understand your thought of reevaluating how we decide things.

However, if you don't accept voting as a valid way to determine if a
patch is acceptible, what method do you suggest?  I don't think we want
to go down the road of saying that you can't vote "no" on a feature
addition. 

We just rejected a patch today on LIMIT with UPDATE/DELETE via an
informal vote, and I think it was a valid rejection.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] SCSI Error

[Christopher Kings-Lynne]

> > the hardware. On the other hand I do believe I saw a message
> > recently saying that some of the 2.4 series kernels had file system
> > bugs.
>
> I recall problems, offhand, with 2.4.5, 2.4.10, 2.4.11 (which was so
> broken that you couldn't recover), and 2.4.15.  I seem to recall a
> report on 2.4.12, also.  There's a page at
> 
> that provides some summaries of known problems, and filesystem
> corruption doesn't show up for all the ones I mentioned, so maybe my
> memory is faulty (alas, I didn't get the ECC option).

Hehehe - those poor sad people who use Linux - try FreeBSD for a change, at
least it works ;)

Chris


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

[HACKERS] FW: PostgreSQL for Netware

[Christopher Kings-Lynne]

> >From /.
> 
> 
>  "Ever since Oracle announced they wouldn't port 9i to NetWare, Novell
> has been scrambling to find an enterprise-capable DB. Now it looks like
> they're settling on PostgreSQL. This follows their decision to ship
> Apache as the default web server for NetWare 6. Linux aficionados might
> sneer at an old workhorse like NetWare, but it's got more than 80
> million client licenses worldwide, and it ain't going anywhere anytime
> soon." 
> 
> http://developer.novell.com/connections/091902.html


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] PGXLOG variable worthwhile?

[Marc G. Fournier]

On Sun, 22 Sep 2002, Bruce Momjian wrote:

> Marc G. Fournier wrote:
> >
> > On Fri, 20 Sep 2002, Bruce Momjian wrote:
> >
> > > In fact, I tried to open a dialog with you on this issue several times,
> > > but when I got no reply, I had to remove PGXLOG.  If we had continued
> > > discussion, we might have come up with the GUC compromise.
> >
> > Ya know, I'm sitting back and reading this, and other threads, and
> > assimilating what is being bantered about, and start to think that its
> > time to cut back on the gatekeepers ...
> >
> > Thomas implemented an option that he felt was useful, and that doesn't
> > break anything inside of the code ... he provided 2 methods of being able
> > to move the xlog's to another location (through command line and
> > environment variable, both of which are standard methods for doing such in
> > server software) ... but, because a small number of ppl "voted" that it
> > should go away, it went away ...
> >
> > You don't :vote: on stuff like this ... if you don't like it, you just
> > don't use it ... nobody is forcing you to do so.  If you think there are
> > going to be idiots out here that aren't going to use it right, then you
> > document it appropriately, with *strong* wording against using it ...
>
> I understand your thought of reevaluating how we decide things.
>
> However, if you don't accept voting as a valid way to determine if a
> patch is acceptible, what method do you suggest?  I don't think we want
> to go down the road of saying that you can't vote "no" on a feature
> addition.
>
> We just rejected a patch today on LIMIT with UPDATE/DELETE via an
> informal vote, and I think it was a valid rejection.

Its not the concept of 'the vote', its what is being voted on that I have
a major problem with ... for instance, with the above LIMIT patch ... you
are talking about functionality ... I haven't seen that thread yet, so am
not sure why it was rejected, but did the submitter agree with the
reasons?  Assuming he did, is this something he's going to re-submit later
after makign fixes?

See, that is one thing I have enjoyed over the years ... someone submit's
a patch and a few ppl jump on top of it, point out a few problems iwth it
and the submitter re-submits with appropriate fixes ...

Actually, I just went to my -patches folder and read the thread ... first
off, the 'informal vote' appears to have consisted of Tom Lane and Alvaro
Herrera, which isn't a vote ... second of all, in that case, the
implementation of such, I believe, would go against SQL specs, no?  Second
of all, doesn't it just purely go against the point of a RDBMS if there
are multiple rows in a table with nothing to identify them except for the
ctid/oid? *scratch head*

My point is, the use of an ENVIRONMENT variable for pointing ot a
directory is nowhere near on the scale of implementing an SQL statement
(or extension) that serves to take us steps backwards against the progress
we've made to improve our compliance ...

one has been removed due to personal preferences and nothign else ... the
other rejected as it will break (unless I've misread things?) standard,
accepted procedures ...




---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] PGXLOG variable worthwhile?

[Neil Conway]

"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Ya know, I'm sitting back and reading this, and other threads, and
> assimilating what is being bantered about, and start to think that
> its time to cut back on the gatekeepers ...

On the contrary, the quality of code accepted into a DBMS is really
important. If you disagree with the definition of "code quality" that
some developers are employing, then we can discuss that -- but I think
that as the project matures, we should be more picky about the
features we implement, not less.

> Thomas implemented an option that he felt was useful, and that
> doesn't break anything inside of the code

The problem with this line of thinking is that "it doesn't break
stuff" is not sufficient reason for adding a new feature. The burden
of proof is on the person implementing the new feature.

>  ... he provided 2 methods of being able to move the xlog's to
>  another location

Yes, but why do we need 2 different ways to do exactly the same thing?

> but, because a small number of ppl "voted" that it should go away,
> it went away ...

They didn't just vote, they provided reasons why they thought the
feature was brain-damaged -- reasons which have not be persuasively
refuted, IMHO. If you'd like to see this feature in the code, might I
suggest that you spend less time complaining about "gate keepers"
(hint: it's called code review), and more time explaining exactly why
the feature is worth having?

Cheers,

Neil

-- 
Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] PGXLOG variable worthwhile?

[Bruce Momjian]

Marc G. Fournier wrote:
> > However, if you don't accept voting as a valid way to determine if a
> > patch is acceptible, what method do you suggest?  I don't think we want
> > to go down the road of saying that you can't vote "no" on a feature
> > addition.
> >
> > We just rejected a patch today on LIMIT with UPDATE/DELETE via an
> > informal vote, and I think it was a valid rejection.
> 
> Its not the concept of 'the vote', its what is being voted on that I have
> a major problem with ... for instance, with the above LIMIT patch ... you
> are talking about functionality ... I haven't seen that thread yet, so am
> not sure why it was rejected, but did the submitter agree with the
> reasons?  Assuming he did, is this something he's going to re-submit later
> after makign fixes?
> 
> See, that is one thing I have enjoyed over the years ... someone submit's
> a patch and a few ppl jump on top of it, point out a few problems iwth it
> and the submitter re-submits with appropriate fixes ...
> 
> Actually, I just went to my -patches folder and read the thread ... first
> off, the 'informal vote' appears to have consisted of Tom Lane and Alvaro
> Herrera, which isn't a vote ... second of all, in that case, the
> implementation of such, I believe, would go against SQL specs, no?  Second
> of all, doesn't it just purely go against the point of a RDBMS if there
> are multiple rows in a table with nothing to identify them except for the
> ctid/oid? *scratch head*
> 
> My point is, the use of an ENVIRONMENT variable for pointing ot a
> directory is nowhere near on the scale of implementing an SQL statement
> (or extension) that serves to take us steps backwards against the progress
> we've made to improve our compliance ...

The issue isn't really compliance because LIMIT in SELECT isn't
compliant either, so adding it to UPDATE/DELETE is just as non-standard
as in SELECT.  The real question we vote on, I think, is, "Should this
feature be given to our users?  What value does it provide, and what
confusion does it cause?  Does the standard suggest anything?"  

I think that is the usual criteria.  For LIMIT on UPDATE/DELETE, it
provides little value, and adds confusion, i.e. an extra clause in those two
commands that really doesn't add any functionality.

Now, for the PG_XLOG environment variable/-X flag, it is almost the same
result, i.e. it doesn't add much value (use a symlink) and does add
confusion (oops, I forgot to set it).

The idea of having the pg_xlog location in GUC I think was a good
compromise, but too late to be discovered.  If the patch author had
continued discussion at the time, I think it would be in 7.3.

> one has been removed due to personal preferences and nothign else ... the
> other rejected as it will break (unless I've misread things?) standard,
> accepted procedures ...

PG_XLOG was remove for a few reasons:

It didn't add much functionality
It was ugly to add -X to all those commands
It was error-prone

Again, the same criteria.  Are you saying the criteria I mentioned above
is wrong?

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] PGXLOG variable worthwhile?

[Tom Lane]

"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> You don't :vote: on stuff like this ...

Why not, exactly?

I wasn't aware that any of core had a non-vetoable right to apply
any patch we liked regardless of the number and strength of the
objections.  AFAIK, we resolve differences of opinion by discussion,
followed by a vote if the discussion doesn't produce a consensus.

It was pretty clear that Thomas' original patch lost the vote, or
would have lost if we'd bothered to hold a formal vote.  I don't
see anyone arguing against the notion of making XLOG location more
easily configurable --- it was just the notion of making it depend
on environment variables that scared people.

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] ECPG

[Tom Lane]

Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I had a thought about what to do with the ECPG grammar-too-big problem:
>> rather than depending on a beta release of bison, we could attack the
>> problem directly by omitting some of the backend grammar from what ECPG
>> supports.

> I think we should just go with the bison beta for ecpg and be done with
> it.  If we find bugs, we can ask the bison folks to fix it, or work
> around it ourselves.

Using the beta bison has a lot of disadvantages though, particularly if
we want to follow the conservative route of using it only for ecpg and
not for the other .y files.  How exactly will you cause the build to
work that way?  How will you make it work for everyone who pulls CVS
rather than a prebuilt tar file?

Also, I was quite unthrilled when I experimented tonight with bison
1.49b, and found it to be a factor of 16 slower than bison 1.28.
(<2 seconds versus >32 seconds to process the backend gram.y file.)
If they don't fix that, bison 1.49+ will have roughly zero uptake
among real users --- who's going to hold still for that much slowdown,
to get a tool whose only obvious improvement is that it now rejects
optional commas?

Bottom line is that I don't think we can require bison > 1.28 for a
good while yet.

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

[HACKERS] European Vacation

[Christopher Kings-Lynne]

Hi Guys,

I'm heading off on a 5 week European trip tommorrow, so I'm not going to be
around until the 31st oct.

I hope there'll be a nice new release version of Postgres I can upgrade to
when I get back!

Chris


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

[HACKERS] HISTORY updated for 7.3beta2

[Bruce Momjian]

I have updated /HISTORY for 7.3beta2.  Looking at the open items list, I
think we are ready for beta2 now.

---

   P O S T G R E S Q L

  7 . 3  O P E NI T E M S


Current at ftp://candle.pha.pa.us/pub/postgresql/open_items.

Source Code Changes
---
Schema handling - ready? interfaces? client apps?
Drop column handling - ready for all clients, apps?
Fix BeOS, QNX4 ports
Fix AIX large file compile failure of 2002-09-11 (Andreas)
Get bison upgrade on postgresql.org for ecpg only (Marc)
Fix vacuum btree bug (Tom)
Fix client apps for autocommit = off
Fix clusterdb to be schema-aware
Change log_min_error_statement to be off by default (Gavin)
Fix return tuple counts/oid/tag for rules
Loading 7.2 pg_dumps
functions no longer public executable
languages no longer public usable
Add schema dump option to pg_dump
Add param for length check for char()/varchar()
Fix $libdir in loaded functions?
Make SET not start a transaction with autocommit off, document it
Add GRANT EXECUTE to all /contrib functions

On Going

Security audit

Documentation Changes
-
Document need to add permissions to loaded functions and languages
Move documation to gborg for moved projects

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Optimization levels when compiling PostgreSQL...

[Florian Weimer]

Sean Chittenden <[EMAIL PROTECTED]> writes:

> I'm thinking about changing this from a beta port to a -devel port
> that I'll periodically update with snapshots.  I'll turn on -O6 for
> the -devel port and -O2 for production for now.  If I don't hear of
> any random bogons in the code I'll see if I can't increase it further
> to -O3 and beyond at a slow/incremental rate.

-O3 is usually slower than -O2 because of increased code size due to
automatic inlining. With GCC, -O4 etc. are all equivalent to -O3.

-- 
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart   http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT  fax +49-711-685-5898

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Improving speed of copy

[Shridhar Daithankar]

On 20 Sep 2002 at 18:41, Nigel J. Andrews wrote:

> On Fri, 20 Sep 2002, Shridhar Daithankar wrote:
> 
> > In select test where approx. 15 rows where reported with query on index field, 
> > mysql took 14 sec. and psotgresql took 17.5 sec. Not bad but other issues 
> > eclipse the result..
> 
> I don't know about anyone else but I find this aspect strange. That's 1 second
> (approx.) per row retrieved. That is pretty dire for an index scan. The
> data/index must be very non unique.

Sorry for late reply.. The numbers were scaled off.. Actually my fiend forgot 
to add units to those number.. The actual numbers are 140ms for mysql and 17
5ms for postgresql.. Further since result are obtained via 'time psql' higher 
overhead of postgres connection establishement is factored in..

Neck to neck I would say..

Bye
 Shridhar

--
Steele's Law:   There exist tasks which cannot be done by more than ten men or 
fewer than one hundred.


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] regression test failure in CVS HEAD

[Karel Zak]

On Fri, Sep 20, 2002 at 01:12:17PM -0400, Bruce Momjian wrote:
> 
> Tom has fixed it.  Sorry I didn't test earlier.

 Thanks.

> Neil Conway wrote:
> > It seems the 'numeric' and 'int8' tests are failing in CVS HEAD. The
> > culprit seems to be the recent to_char() change made by Karel, but I
> > haven't verified that. The diff follows.

 You're right. Sorry.

> >   SELECT '' AS to_char_14, to_char(q2, 'FM.999') FROM INT8_TBL;
> >to_char_14 |  to_char   
> > ! +
> > ! | 456.
> > ! | 4567890123456789.
> > ! | 123.
> > ! | 4567890123456789.
> > ! | -4567890123456789.


 The results like this are right.

Karel

-- 
 Karel Zak  <[EMAIL PROTECTED]>
 http://home.zf.jcu.cz/~zakkr/
 
 C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] [PATCHES] to_char(FM9.9) bug fix

[Karel Zak]

On Fri, Sep 20, 2002 at 09:24:00PM +0200, Peter Eisentraut wrote:
> Karel Zak writes:
> 
> > test=# select to_char(0,'FM9.9');
> >  to_char
> > -
> >  0.
> > (1 row)
> >
> > test=# select to_char(1,'FM9.9');
> >  to_char
> > -
> >  1.
> > (1 row)
> 
> I find this highly bizzare.  The FM modifier means to omit unnecessary

 In the code it's commented as "terrible Ora format" :-)

> trailing stuff.  There is no reasonable business or scientific custom to
> leave a trailing point after a number.

 I think so. I don't know who can use format number like '1.' or '.0'. 
 Can somebody explain why Oracle implement it, who use it?

> Or perhaps a more pragmatic question is, how would I print a number
> without the trailing point?

 Don't use FM or use FM9.0

 Examples:

 'SVRMGR' = Oracle8 Release 8.0.5.0.0
 'test=#' = PostgreSQL 7.3b1

test=# select to_char(1, 'FM9.9');
 to_char 
-
 1.

SVRMGR> select to_char(1, 'FM9.9') from dual;
TO_C

1.  
 
test=# select to_char(1, '9.9');
 to_char 
-
  1.0
 
SVRMGR> select to_char(1, '9.9') from dual;
TO_C

 1.0

test=# select to_char(1, 'FM9.0');
 to_char 
-
 1.0

SVRMGR> select to_char(1, 'FM9.0') from dual;
TO_C

1.0 


-- 
 Karel Zak  <[EMAIL PROTECTED]>
 http://home.zf.jcu.cz/~zakkr/
 
 C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] DROP COLUMN misbehaviour with multiple inheritance

[Hannu Krosing]

Tom Lane kirjutas P, 22.09.2002 kell 18:56:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> >> Another interesting case is multiple inheritance.
> >> 
> >> create table p1 (f1 int);
> >> create table p2 (f1 int);
> >> create table c () inherits(p1, p2);
> >> 
> >> drop ONLY column p1.f1;
> >> drop column p2.f1;
> >> 
> >> After this sequence, what is the state of c.f1?  Is it still there?
> >> Should it be?
> 
> > Well, in this case the column is dropped.  If the last drop is ONLY, the
> > column will stay (regardless of what the first drop did).
> 
> It seems to me that DROP ONLY should set attislocal true on each child
> for which it decrements the inherit count, whether the count reaches
> zero or not. 

This would not be what I e'd expect - if c inherited f1 twice and then
one of the parents disinherits it, then it would still be inherited from
the other parent

> This would cause the behavior in the above case to be that
> c.f1 stays around after the second drop (but can be dropped with a third
> drop of c.f1 itself).

I'd vote for the way Alvaro describes it - keep the attislocal=false
while there exist parents from which the column was inherited.

> I think this is correct, since the implication of
> DROP ONLY is that child columns are being cut loose from their parent's
> apron strings and now have independent existence.

For me the implication is that ONLY this parent cuts loose the strings
from its side, but should not mess with anything the child inherits from
other parties.

> This is a minor tweak to your patch, and I'll make it work that way
> unless I hear squawks...

I was disconnected for the weekend, I hope this is not too late to
squawk ;)

-
Hannu


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]