[HACKERS] TODO questions
While marking up TODO for potential new-hacker items I've run across some items that probably need more explanation: o Allow commenting of variables in postgresql.conf to restore them to defaults This doesn't work already? * Allow triggers to be disabled [trigger] Isn't this going to be in 8.1? * SQL*Net listener that makes PostgreSQL appear as an Oracle database to clients Any reason not to do this for other databases; notably MySQL? o Do VACUUM FULL if table is nearly empty? Since that results in an exclusive table lock (which is vastly different from regular vacuum), wouldn't it be better to just throw a warning? * Reduce WAL traffic so only modified values are written rather than entire rows? Shouldn't this be marked as depending on eliminate need to write full pages? (At least ISTM it won't do any good as long as we're writing full pages) -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Softwarehttp://pervasive.com512-569-9461 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] beginning hackers
On Mon, Aug 22, 2005 at 07:09:10PM -0400, Bruce Momjian wrote: Jim C. Nasby wrote: Can someone turn these items into a beginning hacker's TODO as has been discussed before? Or find a way to mark them on the main TODO? If someone wants to tell me how this should be done and give me whatever files need to be changed I'd be happy to submit a patch. Sure, submit a diff against doc/TODO and mark them with something like %. Here's my stab at marking items. I picked items that I thought would either be well-contained or that would be pretty straightforward. But since I'm not very familiar with the code itself a lot of these could be way off-base. I tried to err on the side of marking things that might be boarderline since presumably it's easier for someone to see a marked item and veto it rather than look at the entire list and try and find new items. In any case, it wouldn't hurt for someone to make another pass after this is applied and look for easy items that I missed. BTW, while I was doing this it struck me that it might make sense to have a difficulty ranking of, say 1-5, instead of just marking beginner items. Thoughts? -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Softwarehttp://pervasive.com512-569-9461 Index: TODO === RCS file: /projects/cvsroot/pgsql/doc/TODO,v retrieving revision 1.1626 diff -c -r1.1626 TODO *** TODO23 Aug 2005 23:51:16 - 1.1626 --- TODO24 Aug 2005 05:49:50 - *** *** 19,28 Administration == ! * Remove behavior of postmaster -o after making postmaster/postgres flags unique * -Allow limits on per-db/role connections ! * Allow pooled connections to list all prepared queries This would allow an application inheriting a pooled connection to know the queries prepared in the current session. --- 19,28 Administration == ! * %Remove behavior of postmaster -o after making postmaster/postgres flags unique * -Allow limits on per-db/role connections ! * %Allow pooled connections to list all prepared queries This would allow an application inheriting a pooled connection to know the queries prepared in the current session. *** *** 37,43 Currently SIGTERM of a backend can lead to lock table corruption. * -Prevent dropping user that still owns objects, or auto-drop the objects ! * Set proper permissions on non-system schemas during db creation Currently all schemas are owned by the super-user because they are copied from the template1 database. --- 37,43 Currently SIGTERM of a backend can lead to lock table corruption. * -Prevent dropping user that still owns objects, or auto-drop the objects ! * %Set proper permissions on non-system schemas during db creation Currently all schemas are owned by the super-user because they are copied from the template1 database. *** *** 61,72 * Configuration files ! o Add include file functionality in postgresql.conf o Allow postgresql.conf values to be set so they can not be changed by the user o Allow commenting of variables in postgresql.conf to restore them to defaults ! o Allow pg_hba.conf settings to be controlled via SQL This would add a function to load the SQL table from pg_hba.conf, and one to writes its contents to the flat file. --- 61,72 * Configuration files ! o %Add include file functionality in postgresql.conf o Allow postgresql.conf values to be set so they can not be changed by the user o Allow commenting of variables in postgresql.conf to restore them to defaults ! o %Allow pg_hba.conf settings to be controlled via SQL This would add a function to load the SQL table from pg_hba.conf, and one to writes its contents to the flat file. *** *** 74,80 can be inserted between existing rows, e.g. row 2.5 goes between row 2 and row 3. ! o Allow postgresql.conf file values to be changed via an SQL API, perhaps using SET GLOBAL o Allow the server to be stopped/restarted via an SQL API --- 74,80 can be inserted between existing rows, e.g. row 2.5 goes between row 2 and row 3. ! o %Allow postgresql.conf file values to be changed via an SQL API, perhaps using SET GLOBAL o Allow the server to be stopped/restarted via an SQL API *** *** 102,108 requires a tool that will call that function and connect to each database to find the objects in each database for that tablespace. ! o Add a GUC variable to control the tablespace for temporary objects and sort files It could start with a random
Re: [HACKERS] 8.1 release notes
On Wed, Aug 24, 2005 at 12:26:21AM -0400, Tom Lane wrote: Jim C. Nasby [EMAIL PROTECTED] writes: Is the intention that standard_conforming_strings will always be read-only? For the moment it's read-only false; the long-term goal is that it will be read-only true. In between we will have a release or three where it is modifiable to some extent. I personally think it would be a *bad* idea if it were a mere USERSET variable --- we learned from the autocommit fiasco that changing fundamental semantics on a whim does not work. But there will need to be some way to alter it for testing purposes during the interregnum. The 'autocommit fiasco' isn't ringing a bell right now, so I'll take your word for it. :) Bruce, can you add some info about this to http://candle.pha.pa.us/cgi-bin/pgescape ? I intend to link to that when I submit a patch to the release notes that links to more info on the individual items. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Softwarehttp://pervasive.com512-569-9461 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] ECPG and escape strings
On Wed, Aug 03, 2005 at 08:31:25AM -0600, Michael Fuhr wrote: ECPG seems to be a little overzealous with the new escape string syntax: This comes from starting the string constant with ESCAPE_STRING_SYNTAX in case there is '\' inside the string. Actually I have no idea at the moment how that made it into. I comment it out for the time being. If anyone knows a reason for this behaviour please tell me and maybe fresh up my memory. CVS commit to come as soon as I'm online again. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] beginning hackers
IMHO (as a wanbe pgsql hacker) it is more important to mark tasks as suitable for beginners, if they do not require in depth knowledge of the pgsql codebase, and not according to how easy they are in other terms. for example If a task requires a significant amount of new non trivial code which has little to do with existing code and is just plugged in one little place, I would consider this task suitable for beginners, as I do not assume beginner pgsql hackers are incompetent or even inexperienced programmers they are simply to pgsql. Meir On 8/24/05, Jim C. Nasby [EMAIL PROTECTED] wrote: On Mon, Aug 22, 2005 at 07:09:10PM -0400, Bruce Momjian wrote: Jim C. Nasby wrote: Can someone turn these items into a beginning hacker's TODO as has been discussed before? Or find a way to mark them on the main TODO? If someone wants to tell me how this should be done and give me whatever files need to be changed I'd be happy to submit a patch. Sure, submit a diff against doc/TODO and mark them with something like %. Here's my stab at marking items. I picked items that I thought would either be well-contained or that would be pretty straightforward. But since I'm not very familiar with the code itself a lot of these could be way off-base. I tried to err on the side of marking things that might be boarderline since presumably it's easier for someone to see a marked item and veto it rather than look at the entire list and try and find new items. In any case, it wouldn't hurt for someone to make another pass after this is applied and look for easy items that I missed. BTW, while I was doing this it struck me that it might make sense to have a difficulty ranking of, say 1-5, instead of just marking beginner items. Thoughts? -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Softwarehttp://pervasive.com512-569-9461 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: VACUUM/t_ctid bug (was Re: [HACKERS] GiST concurrency commited)
Further I'm going to increase concurrency up to 12 parallel threads. All is ok, test is passed with approximatly 40 millions statements -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.1 release notes
On Wednesday 24 August 2005 02:01, Jim C. Nasby wrote:
On Wed, Aug 24, 2005 at 12:26:21AM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Is the intention that standard_conforming_strings will always be
read-only?
For the moment it's read-only false; the long-term goal is that it will
be read-only true. In between we will have a release or three where it
is modifiable to some extent. I personally think it would be a *bad*
idea if it were a mere USERSET variable --- we learned from the
autocommit fiasco that changing fundamental semantics on a whim does
not work. But there will need to be some way to alter it for testing
purposes during the interregnum.
The 'autocommit fiasco' isn't ringing a bell right now, so I'll take
your word for it. :)
Bruce, can you add some info about this to
http://candle.pha.pa.us/cgi-bin/pgescape ? I intend to link to that when
I submit a patch to the release notes that links to more info on the
individual items.
it seems odd to me to be linking to random pages on the net from the release
notes... could that content be folder into the docs themselves and then a
pointer to the relevent section of the docs be given instead?
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Must be owner to truncate?
On Wed, 24 Aug 2005 07:01:00 +0200, Andreas Seltenreich [EMAIL PROTECTED] wrote: However, a question arose quickly: According to the standard, revoking INSERT, UPDATE and DELETE after GRANT ALL PRIVILEGES would leave the relation read-only, but with the TRUNCATE privilege lying around, this would no longer be true for PostgreSQL. I'd say that the TRUNCATE privilege includes DELETE, so that REVOKE DELETE implicitly revokes TRUNCATE and GRANT TRUNCATE implicitly grants DELETE. Servus Manfred ---(end of broadcast)--- TIP 1: 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] Must be owner to truncate?
* Andreas Seltenreich ([EMAIL PROTECTED]) wrote: Bruce Momjian schrob: Added to TODO: * Add TRUNCATE permission Currently only the owner can TRUNCATE a table because triggers are not called, and the table is locked in exclusive mode. Is anyone working on this yet? I looked at the code involved, and it seems there are just a couple of lines needed, some regression test and documentation updates, and most importantly, tab-completion updates. I'm not working on it, though I agree that it really shouldn't be very difficult to add. I'd certainly like to see it done. While you're in there I'd really like to see analyze and vacuum as grantable permissions too... Of course, eliminating the need for them would be even better... :) However, a question arose quickly: According to the standard, revoking INSERT, UPDATE and DELETE after GRANT ALL PRIVILEGES would leave the relation read-only, but with the TRUNCATE privilege lying around, this would no longer be true for PostgreSQL. Would this open a security hole or is it okay as far as extensions to the standard go? Hrm, I'm not really sure about this one. I could see linking TRUNCATE with DELETE (ie: you must have both DELETE and TRUNCATE permissions on a table to TRUNCATE it, ala SELECT/UPDATE), or perhaps excluding TRUNCATE from GRANT ALL PRIVILEGES. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Must be owner to truncate?
* Manfred Koizar ([EMAIL PROTECTED]) wrote: On Wed, 24 Aug 2005 07:01:00 +0200, Andreas Seltenreich [EMAIL PROTECTED] wrote: However, a question arose quickly: According to the standard, revoking INSERT, UPDATE and DELETE after GRANT ALL PRIVILEGES would leave the relation read-only, but with the TRUNCATE privilege lying around, this would no longer be true for PostgreSQL. I'd say that the TRUNCATE privilege includes DELETE, so that REVOKE DELETE implicitly revokes TRUNCATE and GRANT TRUNCATE implicitly grants DELETE. I disagree with implicitly granting/revokeing. Rather, if we're going to go this route, we should require both DELETE and TRUNCATE rights on the object in order to TRUNCATE it but otherwise have TRUNCATE privileges and DELETE privileges be distinct from each other in terms of being granted/revoked. This follows the SELECT/UPDATE relationship. Granting UPDATE doesn't implicitly grant SELECT, and revoking SELECT doesn't implicitly revoke UPDATE; but in order to actually UPDATE you need SELECT rights. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] ECPG and escape strings
Michael Meskes wrote: On Wed, Aug 03, 2005 at 08:31:25AM -0600, Michael Fuhr wrote: ECPG seems to be a little overzealous with the new escape string syntax: This comes from starting the string constant with ESCAPE_STRING_SYNTAX in case there is '\' inside the string. Actually I have no idea at the moment how that made it into. I comment it out for the time being. If anyone knows a reason for this behaviour please tell me and maybe fresh up my memory. CVS commit to come as soon as I'm online again. I have removed that from CVS. It was a bug I introduced. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 1: 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] 8.1 release notes
Robert Treat wrote:
On Wednesday 24 August 2005 02:01, Jim C. Nasby wrote:
On Wed, Aug 24, 2005 at 12:26:21AM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Is the intention that standard_conforming_strings will always be
read-only?
For the moment it's read-only false; the long-term goal is that it will
be read-only true. In between we will have a release or three where it
is modifiable to some extent. I personally think it would be a *bad*
idea if it were a mere USERSET variable --- we learned from the
autocommit fiasco that changing fundamental semantics on a whim does
not work. But there will need to be some way to alter it for testing
purposes during the interregnum.
The 'autocommit fiasco' isn't ringing a bell right now, so I'll take
your word for it. :)
Bruce, can you add some info about this to
http://candle.pha.pa.us/cgi-bin/pgescape ? I intend to link to that when
I submit a patch to the release notes that links to more info on the
individual items.
it seems odd to me to be linking to random pages on the net from the release
notes... could that content be folder into the docs themselves and then a
pointer to the relevent section of the docs be given instead?
Yes, I am thinking that is best too.
I have added this to the release notes:
Also, use two single-quotes ('') to embed a literal single-quote
in a string, rather than the PostgreSQL-supported syntax of
backslash single-quote (\'). The former is standards-conforming
and does not require the use of the E'' string syntax. You can
also use the $$ string syntax, which does not treat backslashes
specially.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (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 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Pre-allocated free space for row updating (like PCTFREE)
Satoshi Nagayasu wrote: Josh Berkus wrote: Satoshi, if you can package up a patch on current CVS, I'll throw it at DBT2. Ok. I'll do it. I've created a new patch which can be applied to the current cvs tree. http://dpsql.sourceforge.net/pctfree.cvs.diff -- NAGAYASU Satoshi [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] TODO questions
Jim C. Nasby wrote: While marking up TODO for potential new-hacker items I've run across some items that probably need more explanation: o Allow commenting of variables in postgresql.conf to restore them to defaults This doesn't work already? The idea here is the when you comment something out, it should restore its default. Right now it keeps the previously uncommented out value, which confuses people. New text is: o Allow commenting of variables in postgresql.conf to restore them to defaults Currently, if a variable is commented out, it keeps the previous uncommented value until a server restarted. * Allow triggers to be disabled [trigger] Isn't this going to be in 8.1? Yes, just marked it as done because it went into CVS 12 hours ago. * SQL*Net listener that makes PostgreSQL appear as an Oracle database to clients Any reason not to do this for other databases; notably MySQL? I suppose, but no one has asked for it, while they have for Oracle. o Do VACUUM FULL if table is nearly empty? Since that results in an exclusive table lock (which is vastly different from regular vacuum), wouldn't it be better to just throw a warning? Good point. I guess that's why the question mark was there. New text: o Suggest a VACUUM FULL if table is nearly empty * Reduce WAL traffic so only modified values are written rather than entire rows? Shouldn't this be marked as depending on eliminate need to write full pages? (At least ISTM it won't do any good as long as we're writing full pages) Not really --- the per-row writes and the full page writes are two different operations for two different purposes. The first is for WAL crash recovery, the second is to prevent partial page writes. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] beginning hackers
Thanks, added. I think numbering them is too complicated. --- Jim C. Nasby wrote: On Mon, Aug 22, 2005 at 07:09:10PM -0400, Bruce Momjian wrote: Jim C. Nasby wrote: Can someone turn these items into a beginning hacker's TODO as has been discussed before? Or find a way to mark them on the main TODO? If someone wants to tell me how this should be done and give me whatever files need to be changed I'd be happy to submit a patch. Sure, submit a diff against doc/TODO and mark them with something like %. Here's my stab at marking items. I picked items that I thought would either be well-contained or that would be pretty straightforward. But since I'm not very familiar with the code itself a lot of these could be way off-base. I tried to err on the side of marking things that might be boarderline since presumably it's easier for someone to see a marked item and veto it rather than look at the entire list and try and find new items. In any case, it wouldn't hurt for someone to make another pass after this is applied and look for easy items that I missed. BTW, while I was doing this it struck me that it might make sense to have a difficulty ranking of, say 1-5, instead of just marking beginner items. Thoughts? -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Softwarehttp://pervasive.com512-569-9461 [ Attachment, skipping... ] -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] TODO questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The idea here is the when you comment something out, it should restore its default. Right now it keeps the previously uncommented out value, which confuses people. I think it will continue to confuse people. I will bring up the idea again here of simply uncommenting *all* settings, which would make things very clear and also make our conf file work like most others. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200508241037 https://www.biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEARECAAYFAkMMhngACgkQvJuQZxSWSsh6HQCgmltyTuSzRwUyP+y0IRZbWIpR eN0AoKGF5uFhtD3cM74I7mTfHawoCDLo =gBav -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: 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] FYI: 8.1beta1 today
Barring any unpleasant surprises, we'll wrap 8.1beta1 this evening (North American east coast time) and announce its availability tomorrow. There are still loose ends and open issues, of course, but nothing that looks like it will get in the way of general beta testing. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Fwd: Re: [GENERAL] Where to get 8.1 beta test version?
Per the notes for this list: If people in the other lists don't know the answer to a question and it is likely that only a developer will know the answer, you may re-post that question here. You must try elsewhere first! So here are my questions regarding 8.1. Anybody? ---BeginMessage--- Kevin Grittner wrote: My mistake. - Any idea when it will get to beta test status? - Is it currently stable enough to make a real-world test worthwhile? - Would this be the snapshot you mentioned?: http://wwwmaster.postgresql.org/download/mirrors-ftp?file=dev%2Fpostgresql-snapshot.tar.gz All beta discussion should happen on hackers. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---End Message--- ---(end of broadcast)--- TIP 1: 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] CREATE USER and pg_user
- Original Message - From: Jim C. Nasby [EMAIL PROTECTED] To: William ZHANG [EMAIL PROTECTED] Cc: pgsql-hackers@postgresql.org Sent: Wednesday, August 24, 2005 3:27 AM Subject: Re: [HACKERS] CREATE USER and pg_user skipped You should take a look at http://lnk.nu/developer.postgresql.org/3mi.html, both 17.1 and 17.2. In particular: CREATE USER is equivalent to CREATE ROLE except that CREATE USER assumes LOGIN by default, while CREATE ROLE does not. Thanks a lot. Already read it now and know sth. about pgsql's roles. Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Softwarehttp://pervasive.com512-569-9461 ---(end of broadcast)--- TIP 1: 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] TODO questions
Bruce Momjian pgman@candle.pha.pa.us writes: Jim C. Nasby wrote: o Allow commenting of variables in postgresql.conf to restore them to defaults This doesn't work already? The idea here is the when you comment something out, it should restore its default. Right now it keeps the previously uncommented out value, which confuses people. But the contrary position is that a comment is a comment, not something that should act to change the state of the postmaster. It's probably worth pointing out that there's not consensus about all of the TODO items, particularly not the ones Bruce has marked with question marks. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: VACUUM/t_ctid bug (was Re: [HACKERS] GiST concurrency commited)
On K, 2005-08-24 at 15:52 +0400, Teodor Sigaev wrote: Further I'm going to increase concurrency up to 12 parallel threads. All is ok, test is passed with approximatly 40 millions statements I have sent a patch to patches list enabling concurrent vacuums to actually reclaim space while another long vacuum is running, i.e. vacuums won't no longer block each other from removing deleted tuples. see: http://archives.postgresql.org/pgsql-patches/2005-08/msg00304.php Could you perhaps test this patch as well, while you already have a setup for testing parallel vacuums under big loads ? Or perhaps you can share the setup/scripts/data so that I could run your test myself as well ? -- Hannu Krosing [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] TODO questions
The idea here is the when you comment something out, it should restore its default. Right now it keeps the previously uncommented out value, which confuses people. But the contrary position is that a comment is a comment, not something that should act to change the state of the postmaster. Not in any conf I have ever seen. If I comment out a parameter I expect that the parameter will either be disabled or set to the default depending on the parameter. #fsync = false Should mean: fsync = false -- fsync = true Should mean: fsync = true -- #fsync = true: Should mean: fsync = false If false is the default value. -- Sincerely, Joshua D. Drake It's probably worth pointing out that there's not consensus about all of the TODO items, particularly not the ones Bruce has marked with question marks. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] FreeBSD ICU was Win32 unicode vs ICU
I was reviewing this thread about its lack of collation support in freebsd. As some of you may or may not know the PHP project is also currently working heavily on unicode support. (For PHP6) I had the chance to ask Andrei Zmievski of the php project about their support for unicode. The key items are as follows. StormTide with the new unicode support, is there any support for unicode collation andrei StormTide, there will be StormTide is it imported by the platform or custom done for php StormTide (cuz freebsd seeems to have issues with its collation support) andrei StormTide, not OS-dependent andrei StormTide, uses CLDR Should the postgresql project also be looking at CLDR for cross-platform unicode support? http://www.unicode.org/cldr/ Kevin McArthur Digifonica Canada - Original Message - From: Tom Lane [EMAIL PROTECTED] To: Magnus Hagander [EMAIL PROTECTED] Cc: pgsql-hackers@postgresql.org; Palle Girgensohn [EMAIL PROTECTED] Sent: Tuesday, August 23, 2005 9:03 AM Subject: Re: [HACKERS] Win32 unicode vs ICU I wrote: (Just looking at it again, the code in convert_string_to_scalar is pretty bogus for multibyte encodings in any case. Possibly we need to rethink the whole approach.) After studying this some more, I think the code is really so bogus for any non-ASCII situation that it's probably not worth worrying about too much. It's effectively assuming that the output of strxfrm() is still in an ASCII-superset encoding ... but I don't see anything in strxfrm's API that guarantees any such thing. As long as strxfrm() doesn't fail completely for Windows Unicode, I'd recommend just leaving this alone. As previously noted, the worst that can happen is an estimation error that's bounded by the histogram bin size anyhow. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 1: 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] Sleep functions
Added to TODO:
o Add sleep() to PL/PgSQL
---
Robert Treat wrote:
On Monday 22 August 2005 11:53, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
On Aug 22, 2005, at 12:40 AM, Michael Fuhr wrote:
To others who've written their own sleep() function: what are you
using it for?
I know I've used one for a script that reindexes various tables on an
old 7.3 server. I put a sleep of 20 seconds between reindexes to let
built up transactions have a few moments to catch up, thereby smoothing
out i/o. For a long time I used a cpu hogging plpgsql version (since I
had cpu to spare) until I switched to a better pltcl version. If a
server side one existed I would certainly have used that.
Tell you the truth, this use case qualifies as a poster child for my
concern that a server-side sleep would encourage people to write code
that sits on locks. If you'd coded some kind of plpgsql loop that did
a REINDEX, sleep N seconds, another REINDEX, etc, you'd have been
sitting on the exclusive lock for each table until the end of the whole
transaction. Your approach makes lots of sense if you commit each
REINDEX transaction and sleep *outside* the transaction --- but a server
sleep function would do exactly not that.
Note that, as I stated, this was used in a script, not a plpgsql function.
Each reindex was committed in a separate transaction, and the sleeps were
selected between transactions. I could have done the sleeps outside of the
database, but doing it inside allowed me to cut down on the number of
connections (which was critical) and also allowed me to play with settings
(work_mem for instance) on a single connection.
IMHO not having a sleep function doesn't prevent what you are worried about,
it just causes people to do what I did, writing up thier own crappy models
that starve locks _and_ cpu. Again server-side sleep is not something I
need, it's just something I needed.
Incidentally I have also used the sleep function to help test concurrency
issues in some situation, where I needed to slow the transactions down enough
to verify what was going on.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (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 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [HACKERS] Sleep functions
Michael Fuhr wrote: On Wed, Aug 24, 2005 at 12:49:57PM -0400, Bruce Momjian wrote: Added to TODO: o Add sleep() to PL/PgSQL Just to PL/pgSQL? If we're going to add it (which doesn't seem to be decided yet), why not as an ordinary function that could be called from SQL as well? Good point. TODO modified. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Sleep functions
On Wed, Aug 24, 2005 at 12:49:57PM -0400, Bruce Momjian wrote: Added to TODO: o Add sleep() to PL/PgSQL Just to PL/pgSQL? If we're going to add it (which doesn't seem to be decided yet), why not as an ordinary function that could be called from SQL as well? -- Michael Fuhr ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] TODO questions
Tom Lane wrote: But the contrary position is that a comment is a comment, not something that should act to change the state of the postmaster. I think that's a mis-statement of the issue, as I understand it, which seems to me to be this: Should the absence of an explicit setting in the config file result in keeping the previous setting of the item or in resetting it to the default value? Of course, the question is made more complex by the fact that you can set things by means other than the config file, and having your settings revert to some default might indeed cause some surprises. Notwithstanding that, I'm fairly firmly in the revert to default camp - I think on balance it conforms to the principle of least surprise. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] TODO questions
Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: Jim C. Nasby wrote: o Allow commenting of variables in postgresql.conf to restore them to defaults This doesn't work already? The idea here is the when you comment something out, it should restore its default. Right now it keeps the previously uncommented out value, which confuses people. But the contrary position is that a comment is a comment, not something that should act to change the state of the postmaster. I understand what you mean, but to be fair, it's not the comment that is changing the behavior of the postmaster. Rather, it's the absence of a setting in the configuration file that would suggest using the default. It seems to me like a question of whether the configuration file should be treated as: a) the set of options for the postmaster b) a set of changes to the options for the postmaster The current behavior is (b), but many think (a) is more intuitive in the context of a configuration file. Perhaps (b) would be more intuitive if it were in the context of (for example) an admin tool that took options on standard input. Regards, Jeff Davis ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] TODO questions
Tom Lane [EMAIL PROTECTED] writes: Bruce Momjian pgman@candle.pha.pa.us writes: The idea here is the when you comment something out, it should restore its default. Right now it keeps the previously uncommented out value, which confuses people. But the contrary position is that a comment is a comment, not something that should act to change the state of the postmaster. As someone else said I think there's a fundamental difference here on what reloading means. In every other system I've seen, when you reload a config file the system goes through the exact same process (semantically at least) that it does when starting up. Ie, it start with a fresh slate of defaults and loads the config file which sets parameters and overrides those defaults. The Postgres way is that it remembers the old values and loads the config files on top of that. You end up with a situation equivalent to having the new config file tacked onto the old one. The problem with the Postgres semantics is that you end up with a system in a state that isn't represented in either the new config file or the old one. This means if you restart Postgres will come up in a different state from what was running. The conventional semantics give the sysadmin a nice guarantee that he or she can reload the config file and if it works then he can be confident that the server is using the same configuration that it will be using after a restart. I fear a lot of sysadmins after being bitten by this confusion once will decide that it's unsafe to simply reload config files in Postgres and it's necessary to stop and start the server to be sure the new config file is correct and won't cause problems after a subsequent restart. -- greg ---(end of broadcast)--- TIP 1: 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] FreeBSD ICU was Win32 unicode vs ICU
Kevin McArthur Wrote: Should the postgresql project also be looking at CLDR for cross-platform unicode support? Afaict, from the ICU website, ICU too uses CLDR. Why reinvent the wheel? ... John ---(end of broadcast)--- TIP 1: 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] TODO questions
On Wed, Aug 24, 2005 at 03:11:31PM -0400, Greg Stark wrote: In every other system I've seen, when you reload a config file the system goes through the exact same process (semantically at least) that it does when starting up. Ie, it start with a fresh slate of defaults and loads the config file which sets parameters and overrides those defaults. I think this is a good summary of the desired behavior, and that it should be added to the TODO description. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Softwarehttp://pervasive.com512-569-9461 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] TODO questions
OK, TODO updated: o %Allow commenting of variables in postgresql.conf to restore them to defaults Currently, if a variable is commented out, it keeps the previous uncommented value until a server restarted. Logically, a reload should set the same values as a server restart. --- Jim C. Nasby wrote: On Wed, Aug 24, 2005 at 03:11:31PM -0400, Greg Stark wrote: In every other system I've seen, when you reload a config file the system goes through the exact same process (semantically at least) that it does when starting up. Ie, it start with a fresh slate of defaults and loads the config file which sets parameters and overrides those defaults. I think this is a good summary of the desired behavior, and that it should be added to the TODO description. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Softwarehttp://pervasive.com512-569-9461 -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 1: 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] Proposed patch to getaddrinfo.c to support IPv6 on Windows
Context diff, please, diff -c.
---
Chuck McDevitt wrote:
I'm proposing this change to /src/port/getaddrinfo.c to support IPv6
under windows.
10a11,14
* Windows may or may not have these routines, so we handle Windows
special
* by dynamically checking for their existence. If they already
exist, we
* use the Windows native routines, but if not, we use our own.
*
31a36,121
#ifdef WIN32
#define WIN32_LEAN_AND_MEAN
/* Bring in windows.h for LoadLibrary, FreeLibrary, and GetProcAddress
routines */
#include windows.h
/*
* The native routines may or may not exist on the Windows platform we
are on,
* so we dynamically look up the routines, and call them via function
pointers.
* Here we need to declare what the function pointers look like
*/
typedef
int
(__stdcall * getaddrinfo_ptr_t)(const char * nodename, const char *
servname,
const struct addrinfo * hints, struct addrinfo ** res);
typedef
void
(__stdcall * freeaddrinfo_ptr_t)(struct addrinfo * ai);
typedef
int
(__stdcall * getnameinfo_ptr_t)(const struct sockaddr * sa, int salen,
char * host, int hostlen, char * serv, int servlen, int flags);
/* static pointers to the native Windows IPv6 routines, so we only do
the lookup once. */
static getaddrinfo_ptr_t getaddrinfo_ptr = NULL;
static freeaddrinfo_ptr_t freeaddrinfo_ptr = NULL;
static getnameinfo_ptr_t getnameinfo_ptr = NULL;
static
bool haveNativeWindowsIPv6routines(void)
{
void * hLibrary = NULL;
static bool alreadyLookedForIpv6routines= FALSE;
if (alreadyLookedForIpv6routines)
return (getaddrinfo_ptr != NULL);
/*
* For Windows XP and Windows 2003 (and longhorn/vista), the IPv6
* routines are present the WinSock 2 library (ws2_32.dll). Try
that first
*/
hLibrary = LoadLibraryA(ws2_32);
if (hLibrary == NULL || GetProcAddress(hLibrary, getaddrinfo) ==
NULL)
{
/* Well, ws2_32 doesn't exist, or more likely doesn't have
getaddrinfo. */
if (hLibrary != NULL)
FreeLibrary(hLibrary);
/* In Windows 2000, there was only the IPv6 Technology
Preview
* look in the IPv6 WinSock library (wship6.dll).
*/
hLibrary = LoadLibraryA(wship6);
}
/* If hLibrary is null, we couldn't find a dll that supports the
functions */
if (hLibrary != NULL)
{
/* We found a dll, so now get the addresses of the routines
*/
getaddrinfo_ptr = GetProcAddress(hLibrary, getaddrinfo);
freeaddrinfo_ptr = GetProcAddress(hLibrary, freeaddrinfo);
getnameinfo_ptr = GetProcAddress(hLibrary, getnameinfo);
/* If any one of the routines is missing, let's play it safe
and ignore them all */
if (getaddrinfo_ptr == NULL || freeaddrinfo_ptr == NULL ||
getnameinfo_ptr == NULL)
{
FreeLibrary(hLibrary);
hLibrary = NULL;
getaddrinfo_ptr = NULL;
freeaddrinfo_ptr = NULL;
getnameinfo_ptr = NULL;
}
}
alreadyLookedForIpv6routines = TRUE;
return (getaddrinfo_ptr != NULL);
}
#endif
49a140,148
#ifdef WIN32
/*
* If Windows has native IPv6 support, use the native Windows
routine.
* Otherwise, fall through and use our own code.
*/
if (haveNativeWindowsIPv6routines())
return (*getaddrinfo_ptr)(node,service,hintp,res);
#endif
162a262,272
#ifdef WIN32
/*
* If Windows has native IPv6 support, use the native
Windows routine.
* Otherwise, fall through and use our own code.
*/
if (haveNativeWindowsIPv6routines())
{
(*freeaddrinfo_ptr)(node,service,hintp,res);
return;
}
#endif
218a329,338
#ifdef WIN32
/*
* If Windows has native IPv6 support, use the native Windows
routine.
* Otherwise, fall through and use our own code.
*/
if (haveNativeWindowsIPv6routines())
return
(*getnameinfo_ptr)(sa,salen,node,nodelen,service,servicelen,flags);
#endif
Content-Description: getaddrinfo.patch
[ Attachment, skipping... ]
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to
[HACKERS] Beta1 release notes
I have updated the release notes to be current so they are ready for beta1. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] TODO questions
Robert Treat wrote:
I've always been of the impression that this idea just wont work. For
example, if I set shared_buffers to some number, start my database, then
comment the line out and reload my conf file, it just isnt going to reset
to the default. (Or at least to make it do so requires a *lot* more work than
just modifing the guc / conf file mechanisms).
True, but you can't modify shared_buffers anyway unless you restart, so
people should realize that.
---
IMHO the suggestion to just uncomment out all of the variables to begin with
would cut down on confusion a great deal and actually be easy to implement,
and as such is probably the way to go for now.
Robert Treat
On Wednesday 24 August 2005 15:43, Bruce Momjian wrote:
OK, TODO updated:
o %Allow commenting of variables in postgresql.conf to restore them
to defaults
Currently, if a variable is commented out, it keeps the
previous uncommented value until a server restarted.
Logically, a reload should set the same values as a
server restart.
---
Jim C. Nasby wrote:
On Wed, Aug 24, 2005 at 03:11:31PM -0400, Greg Stark wrote:
In every other system I've seen, when you reload a config file the
system goes through the exact same process (semantically at least) that
it does when starting up. Ie, it start with a fresh slate of defaults
and loads the config file which sets parameters and overrides those
defaults.
I think this is a good summary of the desired behavior, and that it
should be added to the TODO description.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Softwarehttp://pervasive.com512-569-9461
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (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: don't forget to increase your free space map settings
Re: [HACKERS] TODO questions
I've always been of the impression that this idea just wont work. For
example, if I set shared_buffers to some number, start my database, then
comment the line out and reload my conf file, it just isnt going to reset
to the default. (Or at least to make it do so requires a *lot* more work than
just modifing the guc / conf file mechanisms).
IMHO the suggestion to just uncomment out all of the variables to begin with
would cut down on confusion a great deal and actually be easy to implement,
and as such is probably the way to go for now.
Robert Treat
On Wednesday 24 August 2005 15:43, Bruce Momjian wrote:
OK, TODO updated:
o %Allow commenting of variables in postgresql.conf to restore them
to defaults
Currently, if a variable is commented out, it keeps the
previous uncommented value until a server restarted.
Logically, a reload should set the same values as a
server restart.
---
Jim C. Nasby wrote:
On Wed, Aug 24, 2005 at 03:11:31PM -0400, Greg Stark wrote:
In every other system I've seen, when you reload a config file the
system goes through the exact same process (semantically at least) that
it does when starting up. Ie, it start with a fresh slate of defaults
and loads the config file which sets parameters and overrides those
defaults.
I think this is a good summary of the desired behavior, and that it
should be added to the TODO description.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Softwarehttp://pervasive.com512-569-9461
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] TODO questions
OK, additional sentence removed. --- Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: OK, TODO updated: o %Allow commenting of variables in postgresql.conf to restore them to defaults Currently, if a variable is commented out, it keeps the previous uncommented value until a server restarted. Logically, a reload should set the same values as a server restart. That all sounds nice, but unless you intend to fix all the constraints that force some values to be set-only-at-postmaster-start, it's never going to be possible to promise that a reload has the same effect as restarting the server. We could do this for values that are not PGC_POSTMASTER, but the argument given above for doing it is bogus. regards, tom lane -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] static libperl?
Andrew Dunstan [EMAIL PROTECTED] writes: Earlier today I noticed these lines in this buildfarm log http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypusdt=2005-08-16%2002:05:00 /usr/bin/ld: /usr/local/lib/perl5/5.6.1/mach/CORE/libperl.a(perl.o): relocation R_X86_64_32S can not be used when making a shared object; recompile with -fPIC /usr/local/lib/perl5/5.6.1/mach/CORE/libperl.a: could not read symbols: Bad value I've fixed Makefile.freebsd to assert allow_nonpic_in_shlib only on i386; that should solve the above problem (by keeping platypus from trying to build plperl :-(). It may be there are some other architectures we can safely set allow_nonpic_in_shlib for, but I don't know exactly which. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] Proposed patch to getaddrinfo.c to support
Bruce Momjian wrote:
Context diff, please, diff -c.
It needed dos2unix and pgindent as well. Here's a cleaned patch.
Thanks to Chuck for doing this work.
cheers
andrew
*** src/port/getaddrinfo.c 2005-07-28 00:03:14.0 -0400
--- /home/andrew/getaddrinfo.c 2005-08-24 16:04:29.0 -0400
***
*** 8,13
--- 8,17
* platform, we'll need to split this file and provide a separate configure
* test for getnameinfo().
*
+ * Windows may or may not have these routines, so we handle Windows special
+ * by dynamically checking for their existance. If they already exist, we
+ * use the Windows native routines, but if not, we use our own.
+ *
*
* Copyright (c) 2003-2005, PostgreSQL Global Development Group
*
***
*** 29,34
--- 33,132
#include getaddrinfo.h
+
+ #ifdef WIN32
+
+ #define WIN32_LEAN_AND_MEAN
+ /* Bring in windows.h for LoadLibrary, FreeLibrary, and GetProcAddress routines */
+ #include windows.h
+
+ /*
+ * The native routines may or may not exist on the Windows platform we are on,
+ * so we dynamically look up the routines, and call them via function pointers.
+ * Here we need to declare what the function pointers look like
+ */
+ typedef
+ int
+ (__stdcall * getaddrinfo_ptr_t) (const char *nodename, const char *servname,
+ const struct addrinfo * hints, struct addrinfo ** res);
+
+ typedef
+ void
+ (__stdcall * freeaddrinfo_ptr_t) (struct addrinfo * ai);
+
+ typedef
+ int
+ (__stdcall * getnameinfo_ptr_t) (const struct sockaddr * sa, int salen,
+ char *host, int hostlen, char *serv, int servlen, int flags);
+
+ /* static pointers to the native Windows IPv6 routines, so we only do the lookup once. */
+ static getaddrinfo_ptr_t getaddrinfo_ptr = NULL;
+ static freeaddrinfo_ptr_t freeaddrinfo_ptr = NULL;
+ static getnameinfo_ptr_t getnameinfo_ptr = NULL;
+
+ static
+ bool
+ haveNativeWindowsIPv6routines(void)
+ {
+ void *hLibrary = NULL;
+ static bool alreadyLookedForIpv6routines = FALSE;
+
+ if (alreadyLookedForIpv6routines)
+ return (getaddrinfo_ptr != NULL);
+
+ /*
+ * For Windows XP and Windows 2003 (and longhorn/vista), the IPv6
+ * routines are present the WinSock 2 library (ws2_32.dll). Try that first
+ */
+
+ hLibrary = LoadLibraryA(ws2_32);
+
+ if (hLibrary == NULL || GetProcAddress(hLibrary, getaddrinfo) == NULL)
+ {
+ /*
+ * Well, ws2_32 doesn't exist, or more likely doesn't have
+ * getaddrinfo.
+ */
+ if (hLibrary != NULL)
+ FreeLibrary(hLibrary);
+
+ /*
+ * In Windows 2000, there was only the IPv6 Technology Preview look in
+ * the IPv6 WinSock library (wship6.dll).
+ */
+
+ hLibrary = LoadLibraryA(wship6);
+ }
+
+ /* If hLibrary is null, we couldn't find a dll that supports the functions */
+ if (hLibrary != NULL)
+ {
+ /* We found a dll, so now get the addresses of the routines */
+
+ getaddrinfo_ptr = GetProcAddress(hLibrary, getaddrinfo);
+ freeaddrinfo_ptr = GetProcAddress(hLibrary, freeaddrinfo);
+ getnameinfo_ptr = GetProcAddress(hLibrary, getnameinfo);
+
+ /*
+ * If any one of the routines is missing, let's play it safe and
+ * ignore them all
+ */
+ if (getaddrinfo_ptr == NULL || freeaddrinfo_ptr == NULL || getnameinfo_ptr == NULL)
+ {
+ FreeLibrary(hLibrary);
+ hLibrary = NULL;
+ getaddrinfo_ptr = NULL;
+ freeaddrinfo_ptr = NULL;
+ getnameinfo_ptr = NULL;
+ }
+ }
+
+ alreadyLookedForIpv6routines = TRUE;
+ return (getaddrinfo_ptr != NULL);
+ }
+ #endif
+
+
/*
* get address info for ipv4 sockets.
*
***
*** 47,52
--- 145,159
*psin;
struct addrinfo hints;
+ #ifdef WIN32
+ /*
+ * If Windows has native IPv6 support, use the native Windows routine.
+ * Otherwise, fall through and use our own code.
+ */
+ if (haveNativeWindowsIPv6routines())
+ return (*getaddrinfo_ptr) (node, service, hintp, res);
+ #endif
+
if (hintp == NULL)
{
memset(hints, 0, sizeof(hints));
***
*** 160,165
--- 267,283
{
if (res)
{
+ #ifdef WIN32
+ /*
+ * If Windows has native IPv6 support, use the native Windows routine.
+ * Otherwise, fall through and use our own code.
+ */
+ if (haveNativeWindowsIPv6routines())
+ {
+ (*freeaddrinfo_ptr) (node, service, hintp, res);
+ return;
+ }
+ #endif
if (res-ai_addr)
free(res-ai_addr);
free(res);
***
*** 188,194
}
return hstrerror(hcode);
-
#else /* !HAVE_HSTRERROR */
switch (errcode)
--- 306,311
***
*** 216,221
--- 333,348
char *node, int nodelen,
char *service, int servicelen, int flags)
{
+
+ #ifdef WIN32
+ /*
+ * If Windows has native IPv6 support, use the native Windows routine.
+ * Otherwise, fall through and use our own code.
+ */
+ if (haveNativeWindowsIPv6routines())
+ return (*getnameinfo_ptr) (sa, salen, node, nodelen,
Re: [HACKERS] TODO questions
Bruce Momjian pgman@candle.pha.pa.us writes: OK, TODO updated: o %Allow commenting of variables in postgresql.conf to restore them to defaults Currently, if a variable is commented out, it keeps the previous uncommented value until a server restarted. Logically, a reload should set the same values as a server restart. That all sounds nice, but unless you intend to fix all the constraints that force some values to be set-only-at-postmaster-start, it's never going to be possible to promise that a reload has the same effect as restarting the server. We could do this for values that are not PGC_POSTMASTER, but the argument given above for doing it is bogus. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Win32 Thread safetyness
Unfortunately I just found that we still cannot build in thread safety
mode on Windows, due to an error on my part - specifically, I
concentrated on libpq, not realising that ecpglib is also thread aware.
It seems that ecpglib uses far more of pthreads than libpq does, so our
mini implementation used in libpq just won't cut it. I've bitten the
bullet (well, more of a jelly bean actually) and started rewriting
things to use the official win32 pthreads library, however I ran into an
error that I'm not sure about:
make[3]: Entering directory `/cvs/pgsql/src/interfaces/libpq'
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wold-style-definition -Wendif-labels
-fno-strict-aliasing -D_REENTRANT -D_THREAD_SAFE
-D_POSIX_PTHREAD_SEMANTICS -DFRONTEND -I. -I../../../src/include
-I./src/include/port/win32 -DEXEC_BACKEND
-I../../../src/include/port/win32 -I../../../src/port -c -o
fe-secure.o fe-secure.c
fe-secure.c: In function `pq_threadidcallback':
fe-secure.c:879: error: aggregate value used where an integer was
expected
Which relates to:
static unsigned long
pq_threadidcallback(void)
{
return (unsigned long) pthread_self();
}
In pthread.h we have:
typedef struct {
void * p; /* Pointer to actual object */
unsigned int x; /* Extra information - reuse count etc
*/
} ptw32_handle_t;
typedef ptw32_handle_t pthread_t;
PTW32_DLLPORT pthread_t PTW32_CDECL pthread_self (void);
Is it enough just to pass p back on Windows? - eg:
static unsigned long
pq_threadidcallback(void)
{
#ifdef WIN32
return (unsigned long) pthread_self().p;
#else
return (unsigned long) pthread_self();
#endif
}
Everything builds OK with this change - I'm just not sure if it's right.
Regards, Dave
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] TODO questions
-Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 24, 2005 3:40 PM To: Robert Treat Cc: pgsql-hackers@postgresql.org; Jim Nasby; Greg Stark; Tom Lane Subject: Re: [HACKERS] TODO questions Robert Treat wrote: I've always been of the impression that this idea just wont work. For example, if I set shared_buffers to some number, start my database, then comment the line out and reload my conf file, it just isnt going to reset to the default. (Or at least to make it do so requires a *lot* more work than just modifing the guc / conf file mechanisms). True, but you can't modify shared_buffers anyway unless you restart, so people should realize that. Which is why I think it would be best to get as close as we can to the configuration that you'd get during a restart and warn about everything else. So, for example, if you're runing with a non-default shared_buffers and you comment shared_buffers out and do a reload, you should get a warning that shared_buffers has changed from xxx - yyy but that change won't take effect until the server is restarted. That way there's absolutely no confusion. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Softwarehttp://pervasive.com512-569-9461 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] TODO questions
Tom Lane [EMAIL PROTECTED] writes: That all sounds nice, but unless you intend to fix all the constraints that force some values to be set-only-at-postmaster-start, it's never going to be possible to promise that a reload has the same effect as restarting the server. We could do this for values that are not PGC_POSTMASTER, but the argument given above for doing it is bogus. Well that's true, that's a limitation of Postgres's reloading config files. Certainly I think it should be a goal to avoid any such guc variables where it's worth the effort. That doesn't mean you have to make the problem worse and go in a completely different direction. I would say it would be reasonable to print a warning if loading the new config file results in a different value for any guc variable that can't be changed. If that's too awkward then at least it would be nice to put a warning line in the initial default config file to mark any such guc variables. -- greg ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Proposed patch to getaddrinfo.c to support
Does this fix IPv6 on Win32? --- Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Context diff, please, diff -c. It needed dos2unix and pgindent as well. Here's a cleaned patch. Thanks to Chuck for doing this work. Applied, thanks. regards, tom lane -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Pre-allocated free space for row updating (like PCTFREE)
Satoshi, I've created a new patch which can be applied to the current cvs tree. http://dpsql.sourceforge.net/pctfree.cvs.diff Hmmm ... I don't see where I set the GUC. How am I supposed to vary the PCTFREE amount? -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Followup on the UnixWare Optimizer bug.
The following is from my SCO Internal contact about the bug. It's definitely their bug. Towards the end of the Exact diagnosis, is a suggested work-around for now, as well as a (possible) memory leak. - Dave and I were convinced that the CSE optimization was correct and manufactured data that we pushed through the interval_div() functions with and without the CSE optimization was producing the same results. It was only when we identified the exact input values from the interval regression test were we able to see the problem With span-month = 493 span-day = 11 factor = 10; The CSE optimization problemd occures with the following code from interval_div() and I am assuming also in interval_mul() /* Cascade fractions to lower units */ /* fractional months full days into days */ result-day += month_remainder * DAYS_PER_MONTH; /* fractional months partial days into time */ day_remainder += (month_remainder * DAYS_PER_MONTH) - (int)(month_remainder * DAYS_PER_MONTH); At the point of failure: month_remainder = 49.3 - 49 = .3 (INEXACT) and represented in the 80 bit FP register as .2 month_remainder * 30 = 8.7 (also inexact) That results in result-day = 8 + 1 = 9, but day_remainder is .997 + the .1 left from the earlier division. The later call to interval_justify_hours subtracts the 1 days worth of seconds from time ( day_mainder * SECS_PER_DAY + time portion).. and bumps result-day by 1 == 10. The FAILURE is because the compiler is trying to reduce the 3 FP multiples to 1 multiply; using the value 3 times. The problem occurs because the 8.997 is inexact and when the CSE values is stored as a double, it is rounded to 9.0. On the 2nd and 3rd uses of the value, the 9.0 (64-bit FP data) is used; but the 1st use is still using the 80-bit (8.9) value. So the inter truncation still gets 8, but the calculation day_remainder now is (9.0 - 9) + .1 (previous day_remainder contents). Our bug is that either: - the CSE value should have been preserved as an 80-bit long double since that is how the internal calculations are being done. This is the correct fix and will take us some time to make certain that we haven't broken anything. - the CSE value have been rounded (to 64-bit precision) before use in all 3 points in the code. This would have resulted in result-day = 9 + 1 = 10 and the resuilt-time would have been correctly less than 1 day. The interval_justify_hours() would make not adjustments and result would be identical - as expected. As I said, this will take us some time to work up the fix and revalidate the compiler. Since you have release coming up, I want to suggest the follow work-around for a Common Subexpression Elimination (CSE) bug in some compiler... For both interval_div() and interval_mul() double CSE; /* Cascade fractions to lower units */ /* fractional months full days into days */ CSE = month_remainder * DAYS_PER_MONTH; result-day += CSE; /* fractional months partial days into time */ day_remainder += (CSE) - (int)(CSE); Also note that there appears to be a memory leak in the interval_ routines. For example interval_div() allocates a result Interval. It eventually passes this result through to interval_justify_hours() which allocates another Interval result and that result is what gets passed back to caller on interval_div(). The 1st Interval allocated appears to be left around... -- I will get a pre-release copy of the compiler to test, but it will take a while, since they have to revalidate it. Comments? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 US ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] Proposed patch to getaddrinfo.c to support
Andrew Dunstan [EMAIL PROTECTED] writes: Context diff, please, diff -c. It needed dos2unix and pgindent as well. Here's a cleaned patch. Thanks to Chuck for doing this work. Applied, thanks. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Proposed patch to getaddrinfo.c to support
Bruce Momjian said: OK, we need text for the release notes. What would it be? How about this?: . Support for connections over IPv6 on Windows platforms capable of it. (Chuck McDevitt, Petr Jelinek, Magnus Hagander, Andrew Dunstan). cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] Proposed patch to getaddrinfo.c to support
OK, we need text for the release notes. What would it be? --- Andrew Dunstan wrote: I believe so, yes, although I think that we should remove the HAVE_GETADDRINFO compile time test that Tom built into initdb.c the other day, so that it can fall through to this code. cheers andrew Bruce Momjian said: Does this fix IPv6 on Win32? --- Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Context diff, please, diff -c. It needed dos2unix and pgindent as well. Here's a cleaned patch. Thanks to Chuck for doing this work. Applied, thanks. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] Proposed patch to getaddrinfo.c to support
I believe so, yes, although I think that we should remove the HAVE_GETADDRINFO compile time test that Tom built into initdb.c the other day, so that it can fall through to this code. cheers andrew Bruce Momjian said: Does this fix IPv6 on Win32? --- Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Context diff, please, diff -c. It needed dos2unix and pgindent as well. Here's a cleaned patch. Thanks to Chuck for doing this work. Applied, thanks. ---(end of broadcast)--- TIP 1: 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] Stuff running slooow
tom pointed it out to me a little while ago ... am looking into why, but I'm also just finishing putting together a new server to speed things up some more yet ... On Wed, 24 Aug 2005, Jim C. Nasby wrote: Don't know if anyone else has noticed, but cvsweb is a bit slow right now and mailing list response times have gotten really slow. Could we use more machines or bandwidth? -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Softwarehttp://pervasive.com512-569-9461 ---(end of broadcast)--- TIP 6: explain analyze is your friend Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] TODO list comments
I made a pass over the TODO list to see what was out of date. * Allow administrators to safely terminate individual sessions either via an SQL function or SIGTERM Currently SIGTERM of a backend can lead to lock table corruption. This comment may be out of date. Suggest Lock table corruption following SIGTERM of an individual backend has been reported in 8.0. A possible cause is fixed in 8.1, but it is unknown whether other trouble spots exist. This item is mainly a matter of doing adequate testing rather than of writing any new code. o Allow postgresql.conf values to be set so they can not be changed by the user Is that really a good idea? The ones that are unsafe are restricted already. * %Remove Money type, add money formatting for decimal type There's a fair-size contingent that doesn't want Money removed completely, but just reimplemented as an I/O wrapper around type numeric. Maybe that's even what you mean by the TODO item, but it's not clear. Please at least mention the alternative. o %Allow MIN()/MAX() on arrays This is done. o Modify array literal representation to handle array index lower bound of other than one This too. o Add security checking for large objects Currently large objects entries do not have owners. Permissions can only be set at the pg_largeobject table level. This comment is wrong: trying to set the permissions on pg_largeobject would have no effect whatsoever on the lo_xxx functions, so there is not even a partial solution available now. o Auto-delete large objects when referencing row is deleted This should note that contrib/lo already offers a solution. * %Have views on temporary tables exist in the temporary namespace * Allow temporary views on non-temporary tables Both of these are done in 8.1. * %Allow RULE recompilation Eh? Perhaps you meant automatically regenerate cached plans when needed, in which case it's redundant with the Dependency Checking entries. Whatever it means, this doesn't seem a particularly simple item. * %Allow TRUNCATE ... CASCADE/RESTRICT Huh? What would that do? * Make row-wise comparisons work per SQL spec This could probably be marked as a % item. o Currently the system uses the operating system COPY command to create a new database. Add ON COMMIT capability to CREATE TABLE AS SELECT This seems a bit garbled, and anyway the first part is done. o %Add ALTER DOMAIN TYPE To do what, exactly? This is unclear. o -Allow objects to be moved to different schemas This is only partly done --- the 8.1 patch didn't cover all object types. o %Disallow dropping of an inherited constraint ... o %Prevent child tables from altering constraints like CHECK that were inherited from the parent table These seem to be duplicates, or at least in need of merging. o Handle references to temporary tables that are created, destroyed, then recreated during a session, and EXECUTE is not used This requires the cached PL/PgSQL byte code to be invalidated when an object referenced in the function is changed. This is redundant with the Dependency Checking item about regenerating cached plans. o Add table function support to pltcl, plperl, plpython? Isn't this done for plperl? o Allow PL/pgSQL to name columns by ordinal position, e.g. rec.(3) This doesn't seem like an amazingly good idea; would prefer to see a way to get the column name list and use names dynamically. Numbers have all the same problems as SELECT * ... o Add MOVE to PL/pgSQL This should be generalized: upgrade plpgsql cursor support to have all the FETCH and MOVE options of the main language. o Add support for polymorphic arguments and return types to plperl I think all the PLs except plpgsql need this. Also, all the PLs except plpgsql are well behind the curve on supporting parameter names and OUT parameters. Please add TODO item(s) for these. * Allow libpq to access SQLSTATE so pg_ctl can test for connection failure This would be used for checking if the server is up. Huh? What has SQLSTATE got to do with connection failure checking? * Have initdb set DateStyle based on locale? Is this really a good idea? Being standardized on ISO format seems like a good thing to me, and encouraging people to adopt ambiguous formats as default a very bad thing. They can do it if they like, certainly, but having initdb do it for them just seems like not the direction we want. * Add a schema option to createlang This is superseded by events: createlang now puts the functions in pg_catalog, and there doesn't seem any particularly good reason to want to put them elsewhere. o Improve psql's handling of multi-line queries Uh, what's wrong with it? This item seems far too vague. o Add pg_dumpall
Re: [HACKERS] TODO list comments
On Wed, 24 Aug 2005, Tom Lane wrote: * Fetch heap pages matching index entries in sequential order Rather than randomly accessing heap pages based on index entries, mark heap pages needing access in a bitmap and do the lookups in sequential order. Another method would be to sort heap ctids matching the index before accessing the heap rows. This is done (see bitmap index scans). Will the optimizer ever choose this plan when dealing with only one index? Kris Jurka ---(end of broadcast)--- TIP 1: 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] TODO list comments
Kris Jurka [EMAIL PROTECTED] writes: On Wed, 24 Aug 2005, Tom Lane wrote: This is done (see bitmap index scans). Will the optimizer ever choose this plan when dealing with only one index? Certainly. It's actually likely to prefer a bitmap scan whenever the query is estimated to fetch more than one percent or so of the table (although if you are demanding ORDER BY the index order, the crossover point is higher, since a bitmap scan doesn't deliver sorted output). Something that probably ought to be on the Open Items list for 8.1 is whether the cost estimation for bitmap vs plain indexscan is OK. It's entirely likely that we need to do some tweaking to get the planner to make the right choice. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] Proposed patch to getaddrinfo.c to support
Thanks, added. --- Andrew Dunstan wrote: Bruce Momjian said: OK, we need text for the release notes. What would it be? How about this?: . Support for connections over IPv6 on Windows platforms capable of it. (Chuck McDevitt, Petr Jelinek, Magnus Hagander, Andrew Dunstan). cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] Proposed patch to getaddrinfo.c to support
Andrew Dunstan [EMAIL PROTECTED] writes: I believe so, yes, although I think that we should remove the HAVE_GETADDRINFO compile time test that Tom built into initdb.c the other day, so that it can fall through to this code. Will do. BTW, when we are using getaddrinfo.c, is the gai_strerror routine therein sufficient for Windows? regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Followup on the UnixWare Optimizer bug.
Larry Rosenman ler@lerctr.org forwards: Also note that there appears to be a memory leak in the interval_ routines. For example interval_div() allocates a result Interval. It eventually passes this result through to interval_justify_hours() which allocates another Interval result and that result is what gets passed back to caller on interval_div(). The 1st Interval allocated appears to be left around... Just to clarify my discussion with Bruce: this is a leak from the point of view of these specific routines, but we do not care, because the memory is leaked in a short-lived palloc context that will soon be reset (soon being the next tuple cycle in most cases). We rely on this behavior in a lot of places --- for example, detoasting a toasted input datum leaks memory that in most places isn't explicitly cleaned up. Cleaning up just a dozen or so bytes is really not worth the cycles needed to do it. Despite that, I wouldn't have objected to Bruce's patch if it hadn't made the code noticeably more obscure. As a general rule, datatype-specific functions only need to be paranoid about not leaking memory if they may be invoked by index operations; btree indexes, at least, call such functions in a query-lifespan memory context. (I think GIST was recently fixed to not do this, but btree still does.) regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] TODO questions
Joshua D. Drake wrote: ...when you comment something out, it should restore ...the contrary position is that a comment is a comment... ...If I comment out a parameter I expect... The most unambiguous behavior would be to not have commented out values in the config file at all. If someone wants to change a value and keep a reminder of what the old value was, he's welcome to comment out the original line himself. (assuming that was the thinking behind commenting them out in the first place) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Followup on the UnixWare Optimizer bug.
Larry Rosenman ler@lerctr.org forwards: As I said, this will take us some time to work up the fix and revalidate the compiler. Since you have release coming up, I want to suggest the follow work-around for a Common Subexpression Elimination (CSE) bug in some compiler... Done. I think the code is more legible this way anyway. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] TODO questions
On Wed, Aug 24, 2005 at 10:03:28PM -0700, Ron Mayer wrote: Joshua D. Drake wrote: ...when you comment something out, it should restore ...the contrary position is that a comment is a comment... ...If I comment out a parameter I expect... The most unambiguous behavior would be to not have commented out values in the config file at all. If someone wants to change a value and keep a reminder of what the old value was, he's welcome to comment out the original line himself. (assuming that was the thinking behind commenting them out in the first place) That only makes sense if you also remove the concept of default values; something I don't think we want to do. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Softwarehttp://pervasive.com512-569-9461 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Stuff running slooow
Well, if hardware or bandwidth becomes an issue I suspect we could easily get donations to improve things. On Wed, Aug 24, 2005 at 10:39:23PM -0300, Marc G. Fournier wrote: tom pointed it out to me a little while ago ... am looking into why, but I'm also just finishing putting together a new server to speed things up some more yet ... On Wed, 24 Aug 2005, Jim C. Nasby wrote: Don't know if anyone else has noticed, but cvsweb is a bit slow right now and mailing list response times have gotten really slow. Could we use more machines or bandwidth? -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Softwarehttp://pervasive.com512-569-9461 ---(end of broadcast)--- TIP 6: explain analyze is your friend Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Softwarehttp://pervasive.com512-569-9461 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] TODO questions
Ron Mayer [EMAIL PROTECTED] writes: The most unambiguous behavior would be to not have commented out values in the config file at all. Yeah, Robert Treat suggested that upthread, and I think it's been pushed by others too. The only argument I can see against it is that it'll take longer for the system to process such a file; but do we really care about a few more microseconds to respond to SIGHUP? This does not address the problem that changing PGC_POSTMASTER values in the file won't do anything without a postmaster restart. Greg Stark's suggestion of marking each PGC_POSTMASTER variable with a warning comment in postgresql.conf seems reasonable to me, though. So, the low-tech solution to these gripes seems to be: * uncomment all the entries in postgresql.conf * add comments to flag the values that can't be changed by SIGHUP Can we agree on taking these measures? regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
