[HACKERS] New PostgreSQL Tool available : pg_autotune
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
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
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
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
$ 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
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
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 (alvherre[a]atentus.com) 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
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
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
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 (alvherre[a]atentus.com) 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
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...)
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
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
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
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...
[ 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
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?
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?
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
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 http://www.atnf.csiro.au/people/rgooch/linux/docs/kernel-newsflash.html 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
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?
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?
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?
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?
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
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
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
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...
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
