[HACKERS] open items list cleanup
I spent much of today going through here: https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items Here's what I did: * Committed patches for four of the items, hopefully resolving those items. * Moved three items from open to either resolved or a new section don't need fixing. * Added several new items based on recent posts to pgsql-hackers. * Split up the remaining open items into sections. * Added a comment with current status to many, but not all, of the items. (I would have done them all, but I'm pretty much out of time to work on this for today.) There are a sizeable number of items on that list for which no patches exist yet. It would be great if the people involved in those issues could work on producing those patches. There are a few issues on that list that require a committer's attention to a patch that has already been produced. I believe that the onus is on the committers who committed those features to look at those patches - or if not, they should be up-front about the fact that they no longer have time to work on the features they committed, so that other committers know that they need to and should step in. Further improvements to the wiki page itself are also welcome and will be appreciated, at least, by me. Thanks, -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] open items list cleanup
On Fri, Jun 26, 2015 at 04:23:28PM -0400, Robert Haas wrote: https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items Here's what I did: * Split up the remaining open items into sections. * Added a comment with current status to many, but not all, of the items. (I would have done them all, but I'm pretty much out of time to work on this for today.) I like these changes. It's now much easier to see trends and to see which items are ready for which kinds of actions. Thanks. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] open items for 9.4
On 09/30/2014 09:10 PM, Gregory Smith wrote: On 9/29/14, 2:30 PM, Andres Freund wrote: Can we explain those reasons in the form of documentation? Yes. Try and benchmark it. It'll be hardware and workload dependant. I missed this whole thing, and eventually I have to circle back to it. I could do it this week. Ah, that would be great! Could you (or someone else familiar with the useful benchmarks) give me more detail on how to replicate one case where things should improve? I can do that, and I have a lab full of hardware if it's easier to spot on one type of server. That exercise will probably lead to a useful opinion on the feature in its final form, any associated GUC, tunables, and necessary level of associated documentation in a day or two. To see the most improvement from the patch, try a workload that's otherwise bottlenecked on XLogInsert. For example, with pgbench: psql postgres -c create table foo (id int4) pgbench postgres -n -f fooinsert.sql -c 4 -T10 and in the test script: insert into foo select g from generate_series(1, 1) g; - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] open items for 9.4
On 09/30/2014 04:56 AM, Heikki Linnakangas wrote: There seems to be no decisive consensus here. I'm going to put my foot on the ground and go remove it, as I'm leaning towards that option, and we need to get the release out. But if someone objects loudly enough to actually write the documentation and commit it that way, I'm happy with that too. I'm also in favor of removing it. We really don't need more GUCs which nobody has any clear idea how to change or why. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] open items for 9.4
On 9/29/14, 2:30 PM, Andres Freund wrote: Can we explain those reasons in the form of documentation? Yes. Try and benchmark it. It'll be hardware and workload dependant. I missed this whole thing, and eventually I have to circle back to it. I could do it this week. Could you (or someone else familiar with the useful benchmarks) give me more detail on how to replicate one case where things should improve? I can do that, and I have a lab full of hardware if it's easier to spot on one type of server. That exercise will probably lead to a useful opinion on the feature in its final form, any associated GUC, tunables, and necessary level of associated documentation in a day or two. This is a pretty low bar, right? Examples and documentation sufficient for just me to catch up is not asking for very much. If it isn't possible to do that in a very short period of time, it would not bode well for broader consumption. -- Greg Smith greg.sm...@crunchydatasolutions.com Chief PostgreSQL Evangelist - http://crunchydatasolutions.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] open items for 9.4
On Sun, Sep 28, 2014 at 11:36 PM, Tom Lane t...@sss.pgh.pa.us wrote: Josh Berkus j...@agliodbs.com writes: So, can we get Beta3 out now? If nobody else steps up and says they want to do some performance testing, I'll push the latest lengths+offsets patch tomorrow. Are any of the other open items listed at https://wiki.postgresql.org/wiki/PostgreSQL_9.4_Open_Items things that we must-fix-before-beta3? The items I see are: - Remove xloginsert_slots/xloginsert_locks GUC - Not yet!! The text seems to indicate that there's some disagreement on this point. I don't have a strong opinion on whether or not to keep the GUC, but if we're going to remove it it should probably happen before beta3. It's going to be impossible to remove once we've released with it, I suspect. - TAP tests still have some pretty severe problems Some of these issues have been fixed; but maybe not all. - psql output change in 9.4 I'm still happy with what's committed, but if somebody else wants to tweak it, it should get done soon. - autovacuum scheduling starvation and frenzy This doesn't seem to be a new problem, so I don't think we should consider it a stop-ship issue. - jsonb data format doesn't work well with toast compression Sounds like we are near to resolving this. - pg_dump fails with --if-exists and blobs This looks like a 9.4 regression. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] open items for 9.4
On Mon, Sep 29, 2014 at 5:53 PM, Andres Freund and...@2ndquadrant.com wrote: On 2014-09-29 11:50:19 -0400, Robert Haas wrote: The items I see are: - Remove xloginsert_slots/xloginsert_locks GUC - Not yet!! The text seems to indicate that there's some disagreement on this point. I don't have a strong opinion on whether or not to keep the GUC, but if we're going to remove it it should probably happen before beta3. It's going to be impossible to remove once we've released with it, I suspect. I vote for keeping it. No real preference. But ISTM that if we're uncertain, it's probably a good idea to keep them. - TAP tests still have some pretty severe problems Some of these issues have been fixed; but maybe not all. If there are, they don't seem blockers to me personally. +1. Good to have, but not release blockers. - autovacuum scheduling starvation and frenzy This doesn't seem to be a new problem, so I don't think we should consider it a stop-ship issue. +1. +1. - pg_dump fails with --if-exists and blobs This looks like a 9.4 regression. Alvaro, IIRC you were looking at this one? This does seem to be the major release stopper, other than the json stuff. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] open items for 9.4
On 2014-09-29 11:50:19 -0400, Robert Haas wrote: The items I see are: - Remove xloginsert_slots/xloginsert_locks GUC - Not yet!! The text seems to indicate that there's some disagreement on this point. I don't have a strong opinion on whether or not to keep the GUC, but if we're going to remove it it should probably happen before beta3. It's going to be impossible to remove once we've released with it, I suspect. I vote for keeping it. - TAP tests still have some pretty severe problems Some of these issues have been fixed; but maybe not all. If there are, they don't seem blockers to me personally. - autovacuum scheduling starvation and frenzy This doesn't seem to be a new problem, so I don't think we should consider it a stop-ship issue. +1. - pg_dump fails with --if-exists and blobs This looks like a 9.4 regression. Alvaro, IIRC you were looking at this one? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] open items for 9.4
Andres Freund wrote: On 2014-09-29 11:50:19 -0400, Robert Haas wrote: - pg_dump fails with --if-exists and blobs This looks like a 9.4 regression. Alvaro, IIRC you were looking at this one? I am. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] open items for 9.4
Dne 29.9.2014 18:00 Magnus Hagander mag...@hagander.net napsal(a): On Mon, Sep 29, 2014 at 5:53 PM, Andres Freund and...@2ndquadrant.com wrote: On 2014-09-29 11:50:19 -0400, Robert Haas wrote: The items I see are: - Remove xloginsert_slots/xloginsert_locks GUC - Not yet!! The text seems to indicate that there's some disagreement on this point. I don't have a strong opinion on whether or not to keep the GUC, but if we're going to remove it it should probably happen before beta3. It's going to be impossible to remove once we've released with it, I suspect. I vote for keeping it. No real preference. But ISTM that if we're uncertain, it's probably a good idea to keep them. - TAP tests still have some pretty severe problems Some of these issues have been fixed; but maybe not all. If there are, they don't seem blockers to me personally. +1. Good to have, but not release blockers. - autovacuum scheduling starvation and frenzy This doesn't seem to be a new problem, so I don't think we should consider it a stop-ship issue. +1. +1. - pg_dump fails with --if-exists and blobs This looks like a 9.4 regression. Alvaro, IIRC you were looking at this one? This does seem to be the major release stopper, other than the json stuff. I sent two variants of fix month ago. It should be somewhere in mailing list archive -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] open items for 9.4
On 2014-09-29 11:28:07 -0700, Josh Berkus wrote: On 09/29/2014 08:53 AM, Andres Freund wrote: - Remove xloginsert_slots/xloginsert_locks GUC - Not yet!! The text seems to indicate that there's some disagreement on this point. I don't have a strong opinion on whether or not to keep the GUC, but if we're going to remove it it should probably happen before beta3. It's going to be impossible to remove once we've released with it, I suspect. I vote for keeping it. Time for me to put on my we have too many darned GUCs curmudgeon hat. 1. What does it do? Change scalability in write heavy loads. 2. Are there reasons why users would want to change it from the default? Yes, to improve scalability. 3. Can we explain those reasons in the form of documentation? Yes. Try and benchmark it. It'll be hardware and workload dependant. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] open items for 9.4
Robert Haas robertmh...@gmail.com writes: The items I see are: - Remove xloginsert_slots/xloginsert_locks GUC - Not yet!! The text seems to indicate that there's some disagreement on this point. I don't have a strong opinion on whether or not to keep the GUC, but if we're going to remove it it should probably happen before beta3. It's going to be impossible to remove once we've released with it, I suspect. The lack of any documentation for the GUC (neither in config.sgml or postgresql.conf.sample) suggests very very strongly that it was not meant to be shipped. If we don't remove it I will certainly insist that it be documented adequately. Personally I think a hardwired #define should be plenty. What's the argument that users will need to tune this at runtime? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] open items for 9.4
Andres Freund and...@2ndquadrant.com writes: On 2014-09-29 14:44:42 -0400, Tom Lane wrote: Personally I think a hardwired #define should be plenty. What's the argument that users will need to tune this at runtime? That right now it can make quite noticeable differences in scalability. And we have not much data to justify 8 as the default. And that's surely not going to change if we require recompiles. I wonder why it's a fixed constant at all, and not something like wal_buffers / 8. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] open items for 9.4
On 2014-09-29 16:35:12 -0400, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: On 2014-09-29 16:16:38 -0400, Tom Lane wrote: I wonder why it's a fixed constant at all, and not something like wal_buffers / 8. Because that'd be horrible performancewise on a system with many wal_buffers. There's several operations where all locks are checked in sequence (to see whether there's any stragglers that need to finish inserting) and even some where they're acquired concurrently (e.g. for xlog switch, checkpoint and such). Hm. Well, if there are countervailing considerations as to how large is a good value, that makes it even less likely that it's sensible to expose it as a user tunable. Aren't there such considerations for most of the performance critical gucs? A relevant analogy is that we don't expose a way to adjust the number of lock table partitions at runtime. Which has worked out badly for e.g. the number of buffer partitions... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] open items for 9.4
On Tue, Sep 30, 2014 at 3:44 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: The items I see are: - Remove xloginsert_slots/xloginsert_locks GUC - Not yet!! The text seems to indicate that there's some disagreement on this point. I don't have a strong opinion on whether or not to keep the GUC, but if we're going to remove it it should probably happen before beta3. It's going to be impossible to remove once we've released with it, I suspect. The lack of any documentation for the GUC (neither in config.sgml or postgresql.conf.sample) suggests very very strongly that it was not meant to be shipped. If we don't remove it I will certainly insist that it be documented adequately. Personally I think a hardwired #define should be plenty. What's the argument that users will need to tune this at runtime? I tend to go in this direction too. It is unclear how it is really able to improve scalability, or at least some documentation should be here to help users to set it. An additional thought as well: set it with a configure switch at compilation instead of a GUC. -- Michael
[HACKERS] Open items related to SR
Hi, Many open items related to SR are listed on the wiki again. http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items I clarify the status of those items. Smart shutdown gets stuck - patch to fix from Fuji Masao Robert is reviewing and testing the patch I submitted. I believe that the patch will be applied soon :) Where should wal_level description and location be in postgresql.conf I don't think this should be addressed. Patch for distinguishing normal shutdown from unexpected exit Robert is reviewing the patch I submitted. keep_mumble or min_wal_segments naming Nobody has proposed a parameter name which everyone accepts. This seems not to be worth further discussion, so how about removing this from open items? xlog timeline 0 pg_xlogfile_name_offset This subject doesn't match the linked discussion. The subject represents the same problem as that of another item Streaming replication and pg_xlogfile_name(). In the linked discussion, I submitted the patch which adds new function useful for truncating the unnecessary archived files. But, after that, restartpoint_command was committed for that purpose, so we don't need to apply the patch right now. Remove the item? Streaming replication and pg_xlogfile_name() As the result of the discussion, Heikki and I decided not to address the root cause, but to just throw an error in pg_xlogfile_name() if called during recovery. http://archives.postgresql.org/pgsql-committers/2010-04/msg00075.php We need to do nothing anymore for 9.0. How about moving the item to 9.1 or later? Assertion failure in walreceiver Already fixed. http://archives.postgresql.org/pgsql-committers/2010-02/msg00356.php HS/SR and smart shutdown Already fixed. http://archives.postgresql.org/pgsql-committers/2010-04/msg00081.php Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Open items for 8.3
Bruce Momjian wrote: In an attempt to move us toward 8.3 RC1 I have put all open item emails into the patches queue: http://momjian.postgresql.org/cgi-bin/pgpatches FWIW it seems the only remaining issue is the ltree bug #3720: http://archives.postgresql.org/pgsql-bugs/2007-11/msg00044.php I am still seeing it with fresh HEAD: alvherre=# SELECT '5.0.1.0'::ltree ~ '5.!0.!0.0'::lquery; ?column? -- t (1 ligne) Is anyone working on this? -- Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J Hay que recordar que la existencia en el cosmos, y particularmente la elaboración de civilizaciones dentro de él no son, por desgracia, nada idílicas (Ijon Tichy) ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Open items for 8.3
On Wed, 5 Dec 2007, Alvaro Herrera wrote: Bruce Momjian wrote: In an attempt to move us toward 8.3 RC1 I have put all open item emails into the patches queue: http://momjian.postgresql.org/cgi-bin/pgpatches FWIW it seems the only remaining issue is the ltree bug #3720: http://archives.postgresql.org/pgsql-bugs/2007-11/msg00044.php I am still seeing it with fresh HEAD: alvherre=# SELECT '5.0.1.0'::ltree ~ '5.!0.!0.0'::lquery; ?column? -- t (1 ligne) Is anyone working on this? The problem is clear, Teodor probably will fix it. Regards, Oleg _ Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru), Sternberg Astronomical Institute, Moscow University, Russia Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(495)939-16-83, +007(495)939-23-83 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] Open items for 8.3
In an attempt to move us toward 8.3 RC1 I have put all open item emails into the patches queue: http://momjian.postgresql.org/cgi-bin/pgpatches -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open items for 8.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 5 Nov 2007 12:47:10 -0500 (EST) Bruce Momjian [EMAIL PROTECTED] wrote: In an attempt to move us toward 8.3 RC1 I have put all open item emails into the patches queue: http://momjian.postgresql.org/cgi-bin/pgpatches It would be great if this would push to the wiki. That has been working really well through the cycle. Joshua D. Drake - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHL1jNATb/zqfZUUQRAmI0AJ9HtxqXM52c9p999mkQ4CfZWQMeQQCfYMh2 arqwrUGX8YJkw5l4K/hkRM4= =cmdZ -END PGP SIGNATURE- ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Open items for 8.3
Joshua D. Drake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 5 Nov 2007 12:47:10 -0500 (EST) Bruce Momjian [EMAIL PROTECTED] wrote: In an attempt to move us toward 8.3 RC1 I have put all open item emails into the patches queue: http://momjian.postgresql.org/cgi-bin/pgpatches It would be great if this would push to the wiki. That has been working really well through the cycle. The wiki has a nice summary and links to the discussion. I don't have time to do that much work on this, and maintain it. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Open items for 8.3
Joshua D. Drake [EMAIL PROTECTED] writes: On Mon, 5 Nov 2007 12:47:10 -0500 (EST) Bruce Momjian [EMAIL PROTECTED] wrote: In an attempt to move us toward 8.3 RC1 I have put all open item emails into the patches queue: http://momjian.postgresql.org/cgi-bin/pgpatches It would be great if this would push to the wiki. That has been working really well through the cycle. How many developers have even jumped through the hoops to get wiki accounts? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Open items for 8.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 05 Nov 2007 18:57:39 + Gregory Stark [EMAIL PROTECTED] wrote: Joshua D. Drake [EMAIL PROTECTED] writes: On Mon, 5 Nov 2007 12:47:10 -0500 (EST) Bruce Momjian [EMAIL PROTECTED] wrote: In an attempt to move us toward 8.3 RC1 I have put all open item emails into the patches queue: http://momjian.postgresql.org/cgi-bin/pgpatches It would be great if this would push to the wiki. That has been working really well through the cycle. How many developers have even jumped through the hoops to get wiki accounts? You don't need a wiki account to view. - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHL4+NATb/zqfZUUQRAn4KAJ9AsHQODMrle5yRmxz8rGbG4upsXwCbBjLH 1FeUN3lIPZGw/RUF4MIY59Q= =nGLR -END PGP SIGNATURE- ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Open items for 8.3
On Mon, 5 Nov 2007, Gregory Stark wrote: How many developers have even jumped through the hoops to get wiki accounts? According to http://developer.postgresql.org/index.php?title=Special:Listusersgroup=pgdevlimit=500 there are currently 51 members of the group pgdev on the wiki. -- Spare no expense to save money on this one. -- Samuel Goldwyn ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open items for 8.3
How many developers have even jumped through the hoops to get wiki accounts? According to http://developer.postgresql.org/index.php?title=Special:Listusersgroup=pgdevlimit=500 there are currently 51 members of the group pgdev on the wiki. Well, a lot of those people aren't actually developers, which was the question. But a lot of them are. More interesting would be how many has ever edited anything past just signing up... /Magnus ---(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] Open items for 8.2
--On Montag, September 04, 2006 23:58:35 -0400 Tom Lane [EMAIL PROTECTED] wrote: Updatable views are likewise dead --- we don't have a credible patch or any short-term path to get one. I hope to see both of these items land early in the 8.3 devel cycle, but for 8.2, nyet. Yeah, i don't had the time to get to it the last days and to fix all outstanding issues, sorry for that. Regarding to the complexity of all required work that needs to be done, 8.3 is the better choice, indeed. -- Thanks Bernd ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Open items for 8.2
Am Dienstag, 5. September 2006 05:58 schrieb Tom Lane: A couple of recently discussed FE/BE protocol issues are: not storing a plan at all for unnamed-statement cases, and thus allowing bind parameters to be treated as constants; allowing parameter types to go unresolved rather than throwing an error. Perhaps it's too late to consider these for 8.2, but they seem no more invasive than some other items on the open-issues list. Do we have a patch for that today? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Open items for 8.2
Am Dienstag, 5. September 2006 03:07 schrieb Bruce Momjian: Here are the open items for 8.2: http://momjian.postgresql.org/cgi-bin/pgopenitems This host seems to be offline. What about using the wiki? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] Open items for 8.2
Hello, On Wed, 2006-09-06 at 13:04 +0200, Peter Eisentraut wrote: http://momjian.postgresql.org/cgi-bin/pgopenitems This host seems to be offline. It is suffering from a DNS problem. What about using the wiki? Wiki has the same problem, too. Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Open items for 8.2
Here are the open items for 8.2: http://momjian.postgresql.org/cgi-bin/pgopenitems This host seems to be offline. What about using the wiki? The problem is with the postgresql.org DNS servers. Something weird is afoot around the hub.org nameservers, from what I can tell. Servers seem to be dropping off one by one as TTLs expire. //Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Open items for 8.2
Martha Stewart called it a Good Thing when [EMAIL PROTECTED] (Magnus Hagander) wrote: Here are the open items for 8.2: http://momjian.postgresql.org/cgi-bin/pgopenitems This host seems to be offline. What about using the wiki? The problem is with the postgresql.org DNS servers. Something weird is afoot around the hub.org nameservers, from what I can tell. Servers seem to be dropping off one by one as TTLs expire. Apparently Marc is back; he recently had a question about reordering IP addresses on pgsql.sql, which suggests some sort of DNS maintenance being up. Hopefully this is a matter of things getting a little worse before they get more comprehensively fixed. I hope... -- let name=cbbrowne and tld=gmail.com in name ^ @ ^ tld;; http://linuxdatabases.info/info/spreadsheets.html Look, would it save you all this bother if I just gave up and went mad now? -- Arthur Dent ---(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] Open items for 8.2
Peter Eisentraut [EMAIL PROTECTED] writes: Am Dienstag, 5. September 2006 05:58 schrieb Tom Lane: A couple of recently discussed FE/BE protocol issues are: not storing a plan at all for unnamed-statement cases, and thus allowing bind parameters to be treated as constants; allowing parameter types to go unresolved rather than throwing an error. Perhaps it's too late to consider these for 8.2, but they seem no more invasive than some other items on the open-issues list. Do we have a patch for that today? We could have a patch for the first one today --- I was thinking about it last night and intending to code it today. The second one is merely a matter of removing an error check that exists now; the question really is do people want that behavior. (I asked that on the jdbc list and got zero response, so actually I was thinking that it was a dead issue; but as long as it's on the open-items list we ought to discuss it.) regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open items for 8.2
Peter Eisentraut wrote: Am Dienstag, 5. September 2006 03:07 schrieb Bruce Momjian: Here are the open items for 8.2: http://momjian.postgresql.org/cgi-bin/pgopenitems This host seems to be offline. What about using the wiki? The host is fine. postgresql.org DNS is broken. Reference the host directly: http://momjian.us/cgi-bin/pgopenitems -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Open items for 8.2
Bruce Momjian wrote: Tom Lane wrote: Had a bitmap-index patch arrived in my inbox this morning, as had been promised to me for three weekends running, I might have been willing to drop all else and review it. But, no patch. This item is dead for 8.2. Do not even think of suggesting otherwise. Well, we have to use some objective criteria, rather than one person's decision. I would say we are one month past feature freeze, and have not received a patch to review, and you have asked repeatedly. That is enough of a basis to reject this feature for 8.2. Removed from open items list. This may be too little too late, but I have time to work on the bitmap index patch and fix the API issues. I'm familiar with the index am API and I can see the issues with the patch as it stands. If it's definitely too late for 8.2, I'd like to get it into CVS as soon as possible after the 8.2 release. Jie and/or Gavin, could you send the latest version of the patch to the list in any case? Do you want help with the patch, or would I be stepping on your toes? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open items for 8.2
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Am Dienstag, 5. September 2006 05:58 schrieb Tom Lane: A couple of recently discussed FE/BE protocol issues are: not storing a plan at all for unnamed-statement cases, and thus allowing bind parameters to be treated as constants; allowing parameter types to go unresolved rather than throwing an error. Perhaps it's too late to consider these for 8.2, but they seem no more invasive than some other items on the open-issues list. Do we have a patch for that today? We could have a patch for the first one today --- I was thinking about it last night and intending to code it today. The second one is merely a matter of removing an error check that exists now; the question really is do people want that behavior. (I asked that on the jdbc list and got zero response, so actually I was thinking that it was a dead issue; but as long as it's on the open-items list we ought to discuss it.) I personally think it's a good idea to do it, as it should improve the plans for one-shot queries. Unfortunately I don't certainly know how the JDBC driver issues queries when called through a PreparedStatement but without a prepare-threshold[*] set. If it uses the unnamed-statement, then I guess the proposed change would be a win. Best Regards Michael Paesold [*] This option determines, after how many executes of a prepared statement, the driver will switch to server-side prepares. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Open items for 8.2
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: A quickie: this item Store only active XIDs in subtransaction cache was already done: I think Bruce is referring to the idea that you and I each arrived at recently, ie removing subcommitted subxact XIDs from the PGPROC cache if they hadn't stored any tuples. That certainly wasn't done by my commit you mention ... did you do it when I wasn't looking? Ah, true -- no, I didn't do it, sorry :-) -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Open items for 8.2
Bruce Momjian wrote: Here are the open items for 8.2: http://momjian.postgresql.org/cgi-bin/pgopenitems This list will be continually updated until we release 8.2. Emacs code example not submitted Gregory Stark [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] This one is actually on my list, and will be done in a day or two. I have Greg's suggestion, which will be included. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open items for 8.2
On Mon, Sep 04, 2006 at 11:58:35PM -0400, Tom Lane wrote: timezone changes: appendix B is out of date, and do we need a list at all rather than telling people to look at the config file + system view? Since I did the initial patch I also volunteer to submit documentation for it. As far as the table is concerned, I think we agreed on removing the list (that has been inaccurate since long anyway) and tell people to check out the system view. Joachim -- Joachim Wieland [EMAIL PROTECTED] GPG key available ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Open items for 8.2
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Here are the open items for 8.2: http://momjian.postgresql.org/cgi-bin/pgopenitems Had a bitmap-index patch arrived in my inbox this morning, as had been promised to me for three weekends running, I might have been willing to drop all else and review it. But, no patch. This item is dead for 8.2. Do not even think of suggesting otherwise. Well, we have to use some objective criteria, rather than one person's decision. I would say we are one month past feature freeze, and have not received a patch to review, and you have asked repeatedly. That is enough of a basis to reject this feature for 8.2. Removed from open items list. Updatable views are likewise dead --- we don't have a credible patch or any short-term path to get one. I hope to see both of these items land early in the 8.3 devel cycle, but for 8.2, nyet. OK, same criteria. Removed. The list is missing the issue of removing the long-since-agreed-on-to-remove contrib modules. Added. A couple of recently discussed FE/BE protocol issues are: not storing a plan at all for unnamed-statement cases, and thus allowing bind parameters to be treated as constants; allowing parameter types to go unresolved rather than throwing an error. Perhaps it's too late to consider these for 8.2, but they seem no more invasive than some other items on the open-issues list. Well, I think the difference is that they are new items, rather than something pre-August 1 (or bugs), but I figure we could throw them in if it wasn't risky. Added to list. Other docs issues: VALUES-list syntax --- not real clear where to put it timezone changes: appendix B is out of date, and do we need a list at all rather than telling people to look at the config file + system view? Both added. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Open items for 8.2
Andrew Dunstan wrote: Bruce Momjian wrote: Here are the open items for 8.2: http://momjian.postgresql.org/cgi-bin/pgopenitems This list will be continually updated until we release 8.2. Emacs code examplenot submitted Gregory Stark [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] This one is actually on my list, and will be done in a day or two. I have Greg's suggestion, which will be included. OK. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Open items for 8.2
We made pretty good progress today on the open-items list: ISBN/EAN: I've reviewed this and fixed a couple small issues, it's ready to commit as soon as the author indicates his assent to license statement. I'll remove isbn_issn at the same time. Altering view ownership doesn't work: fixed Remove pgcrypto deprecated functions: done Intel compiler fails for GIN build: I think Teodor did something with this Add /contrib/hstore: done by Teodor plpgsql, return can contains any expression: actually, this is bounced back to author for rework. Dunno if you intend reviewing to include that state. Remove contrib stuff: done regards, tom lane ---(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] Open items for 8.2
Joachim Wieland wrote: On Mon, Sep 04, 2006 at 11:58:35PM -0400, Tom Lane wrote: timezone changes: appendix B is out of date, and do we need a list at all rather than telling people to look at the config file + system view? Since I did the initial patch I also volunteer to submit documentation for it. As far as the table is concerned, I think we agreed on removing the list (that has been inaccurate since long anyway) and tell people to check out the system view. OK, added. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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] Open items for 8.2
Tom Lane wrote: We made pretty good progress today on the open-items list: ISBN/EAN: I've reviewed this and fixed a couple small issues, it's ready to commit as soon as the author indicates his assent to license statement. I'll remove isbn_issn at the same time. Altering view ownership doesn't work: fixed Remove pgcrypto deprecated functions: done Intel compiler fails for GIN build: I think Teodor did something with this Add /contrib/hstore: done by Teodor plpgsql, return can contains any expression: actually, this is bounced back to author for rework. Dunno if you intend reviewing to include that state. Yes, it does, but I changed it to resubmit. Remove contrib stuff: done Other stuff all updated/removed. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open items for 8.2
[EMAIL PROTECTED] (Bruce Momjian) writes: Here are the open items for 8.2: http://momjian.postgresql.org/cgi-bin/pgopenitems This list will be continually updated until we release 8.2. I've got suggested patches for my item (e.g. - --with-openssl causing contrib stuff to break on AIX); a couple of instances of: SHLIB_LINK = $(libpq) $(LIBS) in contrib/dblink/Makefile and contrib/sslinfo seem to do the trick. I'm not sure of adverse effects for others, so that's only speculative at this point... -- output = (cbbrowne @ linuxfinances.info) http://linuxdatabases.info/info/postgresql.html Is A.I. Possible? Some ask Can humans create intelligent machines? In fact, humans do it all the time. The question needs to be Since it's possible in the bedroom, why shouldn't it be possible in the laboratory? -- Mark Miller ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open items for 8.2
Chris Browne wrote: [EMAIL PROTECTED] (Bruce Momjian) writes: Here are the open items for 8.2: http://momjian.postgresql.org/cgi-bin/pgopenitems This list will be continually updated until we release 8.2. I've got suggested patches for my item (e.g. - --with-openssl causing contrib stuff to break on AIX); a couple of instances of: SHLIB_LINK = $(libpq) $(LIBS) in contrib/dblink/Makefile and contrib/sslinfo seem to do the trick. I'm not sure of adverse effects for others, so that's only speculative at this point... My guess is that sslinfo needs it because of the use of the SSL libraries. I would guess any of the other /contrib modules would need similar changes. Can you do a 'make' at the top of the contrib tree and see what fails? -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Open items for 8.2
Bruce Momjian [EMAIL PROTECTED] writes: Chris Browne wrote: I've got suggested patches for my item (e.g. - --with-openssl causing contrib stuff to break on AIX); a couple of instances of: SHLIB_LINK = $(libpq) $(LIBS) in contrib/dblink/Makefile and contrib/sslinfo seem to do the trick. I'm not sure of adverse effects for others, so that's only speculative at this point... My guess is that sslinfo needs it because of the use of the SSL libraries. I just added $(LIBS) to sslinfo's Makefile to fix its build failure on Darwin. (I see no reason why libpq should be involved there, though.) I'm unclear on why AIX would need more than Darwin does to get dblink to build. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Open items for 8.2
Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] (Tom Lane) would
write:
Bruce Momjian [EMAIL PROTECTED] writes:
Chris Browne wrote:
I've got suggested patches for my item (e.g. - --with-openssl causing
contrib stuff to break on AIX); a couple of instances of:
SHLIB_LINK = $(libpq) $(LIBS)
in contrib/dblink/Makefile and contrib/sslinfo seem to do the trick.
I'm not sure of adverse effects for others, so that's only speculative
at this point...
My guess is that sslinfo needs it because of the use of the SSL
libraries.
I just added $(LIBS) to sslinfo's Makefile to fix its build failure on
Darwin. (I see no reason why libpq should be involved there,
though.)
I'm unclear on why AIX would need more than Darwin does to get dblink
to build.
In the case of dblink/Makefile, it started as
SHLIB_LINK = $(libpq)
which need to be augmented to:
SHLIB_LINK = $(libpq) $(LIBS)
When I saw the same errors pop up with sslinfo, there was no
SHLIB_LINK definition, so went to:
SHLIB_LINK = $(libpq) $(LIBS)
It's entirely possible that
SHLIB_LINK = $(LIBS)
is sufficient.
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','gmail.com').
http://linuxfinances.info/info/spreadsheets.html
We defeated the enemy with teamwork and the hammer of not bickering.
-- The Shoveller, Mystery Men
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Open items
I should have a list of open items for 8.2 within 24 hours. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Open items for 8.2
Here are the open items for 8.2: http://momjian.postgresql.org/cgi-bin/pgopenitems This list will be continually updated until we release 8.2. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open items for 8.2
Bruce Momjian wrote: Here are the open items for 8.2: http://momjian.postgresql.org/cgi-bin/pgopenitems This list will be continually updated until we release 8.2. Thanks for the effort. A quickie: this item Store only active XIDs in subtransaction cache was already done: http://archives.postgresql.org/pgsql-committers/2006-09/msg00048.php -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Open items for 8.2
Bruce Momjian [EMAIL PROTECTED] writes: Here are the open items for 8.2: http://momjian.postgresql.org/cgi-bin/pgopenitems Had a bitmap-index patch arrived in my inbox this morning, as had been promised to me for three weekends running, I might have been willing to drop all else and review it. But, no patch. This item is dead for 8.2. Do not even think of suggesting otherwise. Updatable views are likewise dead --- we don't have a credible patch or any short-term path to get one. I hope to see both of these items land early in the 8.3 devel cycle, but for 8.2, nyet. The list is missing the issue of removing the long-since-agreed-on-to-remove contrib modules. A couple of recently discussed FE/BE protocol issues are: not storing a plan at all for unnamed-statement cases, and thus allowing bind parameters to be treated as constants; allowing parameter types to go unresolved rather than throwing an error. Perhaps it's too late to consider these for 8.2, but they seem no more invasive than some other items on the open-issues list. Other docs issues: VALUES-list syntax --- not real clear where to put it timezone changes: appendix B is out of date, and do we need a list at all rather than telling people to look at the config file + system view? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Open items for 8.2
Alvaro Herrera [EMAIL PROTECTED] writes: A quickie: this item Store only active XIDs in subtransaction cache was already done: I think Bruce is referring to the idea that you and I each arrived at recently, ie removing subcommitted subxact XIDs from the PGPROC cache if they hadn't stored any tuples. That certainly wasn't done by my commit you mention ... did you do it when I wasn't looking? 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] Open items
Here are the open items. The only big one left is the handling of a foreign key problem we have had for a while. We also have issues with MSVC builds crashing and pg_config --pgxs on Win32 but they are being actively discussed. I also have a dblink patch on hold. I think it is time to start looking at the finalizing stages. I am thinking I should run pgindent tonight, US Eastern time. I am heading to EuroOSCON in Amsterdam on Saturday night and return on Thursday. We should also start compiling the ports list. Who is doing that? Are the manual pages ready to be built? Has the interactive documentation been scanned and merged into the SGML? Are the error message translations being worked on? Completion date? --- PostgreSQL 8.1 Open Items = Current version at http://candle.pha.pa.us/cgi-bin/pgopenitems or from http://www.postgresql.org/developer/beta. Bugs fix foreign trigger timing issue Questions - cosider O_SYNC as default when O_DIRECT exists /contrib move to pgfoundry pgindent? make sure bitmap scan optimizer settings are reasonable Documentation - scan interactive documentation ports list manual pages -- 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] Open items
Oh, let me add that this release has gone very smoothly. We are right on schedule in release timing. I sometimes think the beta period is not as productive as the development period, but going through it, I am always reminded how much more polished our final product is because of the hard work we do during the beta period --- it isn't exciting, but it is very valuable. --- Bruce Momjian wrote: Here are the open items. The only big one left is the handling of a foreign key problem we have had for a while. We also have issues with MSVC builds crashing and pg_config --pgxs on Win32 but they are being actively discussed. I also have a dblink patch on hold. I think it is time to start looking at the finalizing stages. I am thinking I should run pgindent tonight, US Eastern time. I am heading to EuroOSCON in Amsterdam on Saturday night and return on Thursday. We should also start compiling the ports list. Who is doing that? Are the manual pages ready to be built? Has the interactive documentation been scanned and merged into the SGML? Are the error message translations being worked on? Completion date? --- PostgreSQL 8.1 Open Items = Current version at http://candle.pha.pa.us/cgi-bin/pgopenitems or from http://www.postgresql.org/developer/beta. Bugs fix foreign trigger timing issue Questions - cosider O_SYNC as default when O_DIRECT exists /contrib move to pgfoundry pgindent? make sure bitmap scan optimizer settings are reasonable Documentation - scan interactive documentation ports list manual pages -- 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 -- 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 6: explain analyze is your friend
Re: [HACKERS] Open items
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian Sent: 14 October 2005 12:57 To: PostgreSQL-development Subject: [HACKERS] Open items Has the interactive documentation been scanned and merged into the SGML? Note that when we moderate this we now hide away most of the comments that may suggest improvements for the docs and only leave the ones that are actually helpful in their own right visible. All of the garbage is deleted now so there should be little wading through junk to do, just reviewing which suggestions should be acted upon. If someone wants access to these to review, please let me know. Regards, Dave. ---(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] Open items
On Fri, 2005-14-10 at 13:08 +0100, Dave Page wrote: Note that when we moderate this we now hide away most of the comments that may suggest improvements for the docs and only leave the ones that are actually helpful in their own right visible. If someone wants access to these to review, please let me know. I'd be interested in taking a look. -Neil ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Open items
pgindent run and committed. --- Bruce Momjian wrote: Here are the open items. The only big one left is the handling of a foreign key problem we have had for a while. We also have issues with MSVC builds crashing and pg_config --pgxs on Win32 but they are being actively discussed. I also have a dblink patch on hold. I think it is time to start looking at the finalizing stages. I am thinking I should run pgindent tonight, US Eastern time. I am heading to EuroOSCON in Amsterdam on Saturday night and return on Thursday. We should also start compiling the ports list. Who is doing that? Are the manual pages ready to be built? Has the interactive documentation been scanned and merged into the SGML? Are the error message translations being worked on? Completion date? --- PostgreSQL 8.1 Open Items = Current version at http://candle.pha.pa.us/cgi-bin/pgopenitems or from http://www.postgresql.org/developer/beta. Bugs fix foreign trigger timing issue Questions - cosider O_SYNC as default when O_DIRECT exists /contrib move to pgfoundry pgindent? make sure bitmap scan optimizer settings are reasonable Documentation - scan interactive documentation ports list manual pages -- 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 -- 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] Open items list for 8.1
On Wed, Sep 28, 2005 at 06:07:02PM -0400, Neil Conway wrote: On Wed, 2005-28-09 at 18:35 -0300, Marc G. Fournier wrote: The problem isn't whether or not they should be changed, the problem is that they were changed *during* beta AND *against* the direction that discussion on these changes went I'm not sure what you mean: what is the direction that discusson on these changes went? (If you're referring to complete vs. total, that hardly constitutes a change in direction.) ... pre-beta would have been more acceptable, but pre-feature freeze would have been much preferred I think there is an argument to be made for reverting pg_cancel_backend, since that function was released with 8.0. Personally I'm sceptical that there are very many people using that function in scripts (particularly using it in such a way that their scripts will break if the return type is changed). Since we've already made the change, I don't really see the point in reverting it, but I don't mind if someone wants to do it. I think it's just as important to work towards keeping interfaces clean as it is not to break old code. What's wrong with adding pg_cancel_backend(...) RETURNS int as an alias for the one that returns boolean, and document that it's deprecated and will be removed in the future. The same goes for Tom's timeofday() RETURNS text example. As for the other changes, I think there is absolutely no reason to revert them. Since when is making changes to the signatures of new functions forbidden during the beta period? AFAIK we don't make guarantees of backward compatibility during the beta period, nor would it be sensible to do so. We had the opportunity to fix some poor API choices, and since an initdb was already required I think making these changes for beta2 was quite reasonable. Agreed. Not making API changes now means we get to live with them for years and years. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-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] Open items list for 8.1
On Fri, 2005-30-09 at 17:47 -0500, Jim C. Nasby wrote: What's wrong with adding pg_cancel_backend(...) RETURNS int as an alias for the one that returns boolean, and document that it's deprecated and will be removed in the future. You can't overload functions based on their return type alone. -Neil ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Open items list for 8.1
Jim C. Nasby wrote: On Wed, Sep 28, 2005 at 06:07:02PM -0400, Neil Conway wrote: On Wed, 2005-28-09 at 18:35 -0300, Marc G. Fournier wrote: The problem isn't whether or not they should be changed, the problem is that they were changed *during* beta AND *against* the direction that discussion on these changes went I'm not sure what you mean: what is the direction that discusson on these changes went? (If you're referring to complete vs. total, that hardly constitutes a change in direction.) ... pre-beta would have been more acceptable, but pre-feature freeze would have been much preferred I think there is an argument to be made for reverting pg_cancel_backend, since that function was released with 8.0. Personally I'm sceptical that there are very many people using that function in scripts (particularly using it in such a way that their scripts will break if the return type is changed). Since we've already made the change, I don't really see the point in reverting it, but I don't mind if someone wants to do it. I think it's just as important to work towards keeping interfaces clean as it is not to break old code. What's wrong with adding pg_cancel_backend(...) RETURNS int as an alias for the one that returns boolean, and document that it's deprecated and will be removed in the future. The same goes for Tom's timeofday() RETURNS text example. We don't have the ability to have to functions that take the same parameters and return different results because there is no facility to decide which function to call based on what return value is expected, because a simple query doesn't have a return value restriction: SELECT pg_cancel_backend(); -- 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] Open items list for 8.1
On Fri, Sep 30, 2005 at 06:58:05PM -0400, Bruce Momjian wrote: We don't have the ability to have to functions that take the same parameters and return different results because there is no facility to decide which function to call based on what return value is expected, because a simple query doesn't have a return value restriction: SELECT pg_cancel_backend(); Duh, I keep forgetting that. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-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] Open items list
We are basically on hold until we can resolve these items. We need a beta3, but some of these items might require an initdb (ALTER SCHEMA RENAME and ROLES), so until we resolve them, we can't go for beta3 and can't get to an RC candidate. I know Tom is busy right now, but I know we will get there, so I am just reporting where we are. --- pgman wrote: Here is the open item list: PostgreSQL 8.1 Open Items = Current version at http://candle.pha.pa.us/cgi-bin/pgopenitems or from http://www.postgresql.org/developer/beta. Bugs fix pg_dump --clean for roles Is there a way to fix this or do we remove --clean? foreign trigger timing issue Who is working on this? fix ALTER SCHEMA RENAME for sequence dependency, or remove In discussion currently. improve spinlock performance What is the timeframe for completion of this? fix semantic issues of granted permissions in roles Same as above. fix pgxs for spaces in file names I assume we have found a solution and are just waiting for a patch to be applied. Questions - consider O_SYNC as default when O_DIRECT exists /contrib move to pgfoundry pgindent? make sure bitmap scan optimizer settings are reasonable Documentation - -- 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 -- 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] Open items list for 8.1
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marc G. Fournier Sent: 28 September 2005 00:50 To: Tom Lane Cc: Bruce Momjian; PostgreSQL-development; Neil Conway Subject: Re: [HACKERS] Open items list for 8.1 IMHO, changes like this *should not* have been allowed during beta, period ... even during feature freeze, it would have been questionable :( Agreed. It's not like they weren't discussed to death prior to then as well. Whilst I'm not so wed to the changes to the others, pg_cancel_backend() should certainly not be changed on whim - I know for a fact there are people for whom this will cause problems. Regards, Dave ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Open items list for 8.1
On Tue, 27 Sep 2005, Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: fix ALTER SCHEMA RENAME for sequence dependency, or remove feature I've posted a proposed patch to fix this. The patch requires an initdb (to add new sequence functions), so if we do that we may as well also fix the 32/64bit risk mentioned here: http://archives.postgresql.org/pgsql-hackers/2005-09/msg01241.php Also, the floor seems open to discuss whether or not to revert the file access functions to their pre-beta2 APIs. I've got mixed feelings about that myself, but you can certainly make a case that the current definitions are not enough cleaner than what was there before to justify changing. This seems particularly true for pg_cancel_backend(), which already was in the core in 8.0. I am thinking we should keep things as they are now. The problem isn't whether or not they should be changed, the problem is that they were changed *during* beta AND *against* the direction that discussion on these changes went ... pre-beta would have been more acceptable, but pre-feature freeze would have been much preferred ... but *post-beta*, this should never have happened unless it created a critical bug, which I have seen no arguments that it did ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Open items list for 8.1
On Wed, 2005-28-09 at 18:35 -0300, Marc G. Fournier wrote: The problem isn't whether or not they should be changed, the problem is that they were changed *during* beta AND *against* the direction that discussion on these changes went I'm not sure what you mean: what is the direction that discusson on these changes went? (If you're referring to complete vs. total, that hardly constitutes a change in direction.) ... pre-beta would have been more acceptable, but pre-feature freeze would have been much preferred I think there is an argument to be made for reverting pg_cancel_backend, since that function was released with 8.0. Personally I'm sceptical that there are very many people using that function in scripts (particularly using it in such a way that their scripts will break if the return type is changed). Since we've already made the change, I don't really see the point in reverting it, but I don't mind if someone wants to do it. As for the other changes, I think there is absolutely no reason to revert them. Since when is making changes to the signatures of new functions forbidden during the beta period? AFAIK we don't make guarantees of backward compatibility during the beta period, nor would it be sensible to do so. We had the opportunity to fix some poor API choices, and since an initdb was already required I think making these changes for beta2 was quite reasonable. -Neil ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Open items list for 8.1
Marc G. Fournier wrote: On Tue, 27 Sep 2005, Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: fix ALTER SCHEMA RENAME for sequence dependency, or remove feature I've posted a proposed patch to fix this. The patch requires an initdb (to add new sequence functions), so if we do that we may as well also fix the 32/64bit risk mentioned here: http://archives.postgresql.org/pgsql-hackers/2005-09/msg01241.php Also, the floor seems open to discuss whether or not to revert the file access functions to their pre-beta2 APIs. I've got mixed feelings about that myself, but you can certainly make a case that the current definitions are not enough cleaner than what was there before to justify changing. This seems particularly true for pg_cancel_backend(), which already was in the core in 8.0. I am thinking we should keep things as they are now. The problem isn't whether or not they should be changed, the problem is that they were changed *during* beta AND *against* the direction that discussion on these changes went ... pre-beta would have been more acceptable, but pre-feature freeze would have been much preferred ... but *post-beta*, this should never have happened unless it created a critical bug, which I have seen no arguments that it did ... It was done quickly to complete it for beta2. Neil talked to Tom and me about it before he made the change. Obviously we all guessed wrong on this one. -- 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] Open items list for 8.1
Bruce Momjian pgman@candle.pha.pa.us writes: It was done quickly to complete it for beta2. Neil talked to Tom and me about it before he made the change. Obviously we all guessed wrong on this one. Personally I had forgotten that pg_cancel_backend was in the previous release and so there was a backwards-compatibility issue to consider. There's no doubt that a boolean return value is cleaner than an int return value, but we don't ordinarily make non-backward-compatible changes just because they're cleaner. Comparable case: timeofday() is still returning text not timestamptz after all these years, even though that is *obviously* the wrong API, and even though we could probably change it without a huge risk of breaking things. As for the total-vs-complete function name business, I do personally like total better, but the time to have been making that argument was back during the original discussion, which itself went on way too long. Renaming it now with relatively little discussion was definitely a violation of our normal development process. I'll take my fair share of the blame for this, because I encouraged Neil to do it without stopping to think that the names had already been hashed over extensively. But it was the wrong way to proceed. In short, yeah, I think we should revert. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Open items list
Here is the open item list: PostgreSQL 8.1 Open Items = Current version at http://candle.pha.pa.us/cgi-bin/pgopenitems or from http://www.postgresql.org/developer/beta. Bugs fix pg_dump --clean for roles Is there a way to fix this or do we remove --clean? foreign trigger timing issue Who is working on this? fix ALTER SCHEMA RENAME for sequence dependency, or remove In discussion currently. improve spinlock performance What is the timeframe for completion of this? fix semantic issues of granted permissions in roles Same as above. fix pgxs for spaces in file names I assume we have found a solution and are just waiting for a patch to be applied. Questions - consider O_SYNC as default when O_DIRECT exists /contrib move to pgfoundry pgindent? make sure bitmap scan optimizer settings are reasonable Documentation - -- 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] Open items list for 8.1
Magnus Hagander wrote: Changes --- Win32 signal handling patch (Magnus) Unless someone else steps up to doing this one, please remove it from the list. I will not have time to dig into this patch before 8.1. OK, what should the TODO item be? -- 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] Open items list for 8.1
Changes --- Win32 signal handling patch (Magnus) Unless someone else steps up to doing this one, please remove it from the list. I will not have time to dig into this patch before 8.1. OK, what should the TODO item be? A link to the mail should be there, I guess (it's somewhere in the archives). Investigate different way of handling signals on win32 with a link perhaps. Note - we need to investigate, I'm not convinced that doing it is worth it at all (I asked for opinions on that earlier, but no other win32 hacker was available for comment). And then if it is, the patch itself should be reviewed. //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Open items list for 8.1
Magnus Hagander wrote: Changes --- Win32 signal handling patch (Magnus) Unless someone else steps up to doing this one, please remove it from the list. I will not have time to dig into this patch before 8.1. OK, what should the TODO item be? A link to the mail should be there, I guess (it's somewhere in the archives). Investigate different way of handling signals on win32 with a link perhaps. Note - we need to investigate, I'm not convinced that doing it is worth it at all (I asked for opinions on that earlier, but no other win32 hacker was available for comment). And then if it is, the patch itself should be reviewed. Added to TODO: o Improve signal handling, http://archives.postgresql.org/pgsql-patches/2005-06/msg00027.php -- 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] Open items list for 8.1
The open items list has been reduced nicely: PostgreSQL 8.1 Open Items = Current version at http://candle.pha.pa.us/cgi-bin/pgopenitems or from http://www.postgresql.org/developer/beta. Changes --- fix pg_dump --clean for roles foreign trigger timing issue fix ALTER SCHEMA RENAME for sequence dependency, or remove feature spinlock performance fix semantic issues of granted permissions in roles fix pgxs for Win32 paths Questions - cosider O_SYNC as default when O_DIRECT exists /contrib move to pgfoundry bump major library version number? pgindent, when? make sure bitmap scan optimizer settings are reasonable Documentation - document control over partial page writes Fixed Since Last Beta - -- 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] Open items list for 8.1
Bruce Momjian wrote: bump major library version number? Were there any incompatible interface changes? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open items list for 8.1
Peter Eisentraut wrote: Bruce Momjian wrote: bump major library version number? Were there any incompatible interface changes? No, I don't _think_ so, but we have been bitten by this before, not because of API change but because of use of libpgport functions called by libpq in one release but not in a later one. What happened was that apps pulled pgport functions from libpq and not from libpgport, and when the calls were removed from libpq, the old apps didn't work anymore. This hit us in 8.0.X. Makefile.global has this now: # Force clients to pull symbols from the non-shared library libpgport # rather than pulling some libpgport symbols from libpq just because # libpq uses those functions too. This makes applications less # dependent on changes in libpq's usage of pgport. To do this we link to # pgport before libpq. This does cause duplicate -lpgport's to appear # on client link lines. ifdef PGXS libpq_pgport = -L$(libdir) -lpgport $(libpq) else libpq_pgport = -L$(top_builddir)/src/port -lpgport $(libpq) endif so I think we are OK going forward, but it something I wanted to keep an eye out for. In older releases we actually had reports of failures, and just told people to recompile, not realizing the magnitude of the problem (it was assume to be more old CVS build issue than a backward-compatible issue.) I am going to remove the open item about this because I think if we had a problem, we would have heard about it by now. It is an interesting story because it does highlight that the libpq API is not the only cause of a major bump. -- 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] Open items list for 8.1
Bruce Momjian pgman@candle.pha.pa.us writes: fix ALTER SCHEMA RENAME for sequence dependency, or remove feature I've posted a proposed patch to fix this. The patch requires an initdb (to add new sequence functions), so if we do that we may as well also fix the 32/64bit risk mentioned here: http://archives.postgresql.org/pgsql-hackers/2005-09/msg01241.php Also, the floor seems open to discuss whether or not to revert the file access functions to their pre-beta2 APIs. I've got mixed feelings about that myself, but you can certainly make a case that the current definitions are not enough cleaner than what was there before to justify changing. This seems particularly true for pg_cancel_backend(), which already was in the core in 8.0. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Open items list for 8.1
On Tue, 27 Sep 2005, Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: fix ALTER SCHEMA RENAME for sequence dependency, or remove feature I've posted a proposed patch to fix this. The patch requires an initdb (to add new sequence functions), so if we do that we may as well also fix the 32/64bit risk mentioned here: http://archives.postgresql.org/pgsql-hackers/2005-09/msg01241.php Also, the floor seems open to discuss whether or not to revert the file access functions to their pre-beta2 APIs. I've got mixed feelings about that myself, but you can certainly make a case that the current definitions are not enough cleaner than what was there before to justify changing. This seems particularly true for pg_cancel_backend(), which already was in the core in 8.0. IMHO, changes like this *should not* have been allowed during beta, period ... even during feature freeze, it would have been questionable :( Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Open items list for 8.1
Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: fix ALTER SCHEMA RENAME for sequence dependency, or remove feature I've posted a proposed patch to fix this. The patch requires an initdb (to add new sequence functions), so if we do that we may as well also fix the 32/64bit risk mentioned here: http://archives.postgresql.org/pgsql-hackers/2005-09/msg01241.php Also, the floor seems open to discuss whether or not to revert the file access functions to their pre-beta2 APIs. I've got mixed feelings about that myself, but you can certainly make a case that the current definitions are not enough cleaner than what was there before to justify changing. This seems particularly true for pg_cancel_backend(), which already was in the core in 8.0. I am thinking we should keep things as they are now. I remember two changes of significance. First, pg_cancel_backend()'s return value was change to boolean. I think the compelling argument here is that we are adding other functions that _should_ return boolean, and to keep pg_cancel_backend() as 1/0 was kind of strange. Also, I assume pg_cancel_backend() is not a general use function and therefore is more of an admin function that we can adjust as needed to improve the API. We have always allowed rare/admin functions to be improved without as much concern for backward compatibility as a more mainstream feature. The other change was the rename of pg_complete_relation_size() to pg_total_relation_size(). While there was a huge (exhausting) discussion that finalized on pg_complete_relation_size(), a number of people felt pg_total_relation_size() was better. -- 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
[HACKERS] Open items list for 8.1
Here are the open items for 8.1: PostgreSQL 8.1 Open Items = Current version at http://candle.pha.pa.us/cgi-bin/pgopenitems or from http://www.postgresql.org/developer/beta. Changes --- Win32 signal handling patch (Magnus) fix pg_dump --clean for roles cosider O_SYNC as default when O_DIRECT exists test terminate_backend()? /contrib move to pgfoundry bump major library version number? foreign trigger timing issue pgindent make sure bitmap scan optimizer settings are reasonable fix ALTER SCHEMA RENAME for sequence dependency, or remove feature spinlock performance fix semantic issues of granted permissions in roles fix pgxs for Win32 paths Documentation - document control over partial page writes Fixed Since Last Beta - -- 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] Open items list for 8.1
/contrib move to pgfoundry Is this actually happening? -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Open items list for 8.1
Joshua D. Drake wrote: /contrib move to pgfoundry Is this actually happening? Josh has talked about it, but not sure where he is. -- 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] Open items list for 8.1
Bruce Momjian wrote: Joshua D. Drake wrote: /contrib move to pgfoundry Is this actually happening? Josh has talked about it, but not sure where he is. Well pgFoundry isn't ready to have a load of code that is that actively maintained put on it. It still needs to be moved to its new servers. Also we should probably seriously consider which contrib modules get moved. IMHO shipping PostgreSQL without TSearch2 and pgcrypto (of course I think those should be core anyway) is a non-starter. Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Open items list for 8.1
Joshua D. Drake wrote: Bruce Momjian wrote: Joshua D. Drake wrote: /contrib move to pgfoundry Is this actually happening? Josh has talked about it, but not sure where he is. Well pgFoundry isn't ready to have a load of code that is that actively maintained put on it. It still needs to be moved to its new servers. Also we should probably seriously consider which contrib modules get moved. IMHO shipping PostgreSQL without TSearch2 and pgcrypto (of course I think those should be core anyway) is a non-starter. Agreed. The idea was to move _some_ /contrib to pgfoundry. -- 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] Open items list for 8.1
Joshua D. Drake [EMAIL PROTECTED] writes: /contrib move to pgfoundry Well pgFoundry isn't ready to have a load of code that is that actively maintained put on it. It still needs to be moved to its new servers. The modules proposed to be moved out aren't actively maintained now; if they were we'd probably be keeping them in core. Also we should probably seriously consider which contrib modules get moved. You seem to have forgotten the discussion entirely. These are the modules proposed to be moved: adddepend dbase dbmirror fulltextindex mSQL-interface mac oracle tips regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Open items list for 8.1
Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: /contrib move to pgfoundry Well pgFoundry isn't ready to have a load of code that is that actively maintained put on it. It still needs to be moved to its new servers. The modules proposed to be moved out aren't actively maintained now; if they were we'd probably be keeping them in core. Speaking as a pgFoundry admin, I would say if they aren't actively maintained we don't want them either. pgFoundry is not a dumping ground for modules that are dying. If they are not maintained then drop them. They can always be recovered from the CVS archive. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Open items list for 8.1
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: The modules proposed to be moved out aren't actively maintained now; if they were we'd probably be keeping them in core. Speaking as a pgFoundry admin, I would say if they aren't actively maintained we don't want them either. pgFoundry is not a dumping ground for modules that are dying. I didn't say they were dying --- the ones we thought were dead, we already dropped. I was responding to Joshua's concern that they might get enough update traffic to pose a noticeable load on the pgfoundry server. Most of them seem to have been touched only once or twice in the past year. That does not indicate that they don't have user communities, though. There was already very extensive discussion about this in this thread: http://archives.postgresql.org/pgsql-hackers/2005-06/msg00302.php and no one objected to the summary proposal I posted here: http://archives.postgresql.org/pgsql-hackers/2005-06/msg00976.php so I'm not inclined to think that the floor is still open for debate about what to move. It's just a matter of someone getting it done. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open items list for 8.1
Changes --- Win32 signal handling patch (Magnus) Unless someone else steps up to doing this one, please remove it from the list. I will not have time to dig into this patch before 8.1. //Magnus ---(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] Open items list for 8.1
Tom Lane wrote: Speaking as a pgFoundry admin, I would say if they aren't actively maintained we don't want them either. pgFoundry is not a dumping ground for modules that are dying. I didn't say they were dying --- the ones we thought were dead, we already dropped. I was responding to Joshua's concern that they might get enough update traffic to pose a noticeable load on the pgfoundry server. Most of them seem to have been touched only once or twice in the past year. That does not indicate that they don't have user communities, though. OK. I agree that we do not need to wait, any more than we are waiting now on other newly registered projects. What we do need is an owner in each case. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] enable/disable trigger (Re: Fwd: [HACKERS] Open items)
Satoshi Nagayasu wrote: Bruce Momjian wrote: I am not sure what to do with this patch. It is missing dump capability, there is no clause to disable all triggers on a table, and it uses a table owner check when a super user check is required (because of referential integrity). Satoshi, are you still working on it? If not does someone else want to complete it? I realized you just started on it but the deadline is soon. I've already implemented 'ENABLE/DISABLE TRIGGER ALL', and the superuser check has been added. Please check it. And, I'm going to have a business trip to Sydney this weekend, so I'll complete pg_dump stuffs while my flight. There are several issues with disabling triggers, and I thought I would outline them before we add something to 8.1. The functionality that has been discussed is: o disable a single trigger (in patch) o disable all user-defined triggers o disable all referential integrity constraint triggers o disable all triggers on a table (in patch) o disable triggers on all tables The first four are via ALTER TABLE ENABLE/DISABLE TRIGGER, and the last would be via SET. (Some think the last item is too powerful.) There is also the issue of whether table owners can perform these operations, or just super-users. There is general agreement that table owners should be able to disable user-defined triggers, but not referential integrity triggers, because they might not own the referenced table. The current patch makes no disinction between user-defined triggers and referential integrity triggers. It allows either a single trigger to be disabled, or all triggers on a table, and it can be done only by the super-user, via ALTER TABLE. The big question is what functionality we want in 8.1, and whether enhancements in later releases will conflict with our chosen syntax. The current super-user only behavior can be relaxed in later releases as appropriate. The ALL keyword applying to all triggers is probably good. We might add a USER later (or in 8.1) like this: ALTER TABLE ENABLE/DISABLE TRIGGER USER as distinct from ALTER TABLE ENABLE/DISABLE TRIGGER ALL Oh, and one trick for disabling triggers in a single session is to do this: BEGIN WORK; ALTER TABLE xx DISABLE TRIGGER ALL ... ALTER TABLE xx ENABLE TRIGGER ALL COMMIT WORK; In this case, the triggers are disabled just for that session. I think this usage should be documented in our manual. -- 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 6: explain analyze is your friend
Re: [PATCHES] enable/disable trigger (Re: Fwd: [HACKERS] Open items)
Bruce Momjian pgman@candle.pha.pa.us writes: Oh, and one trick for disabling triggers in a single session is to do this: BEGIN WORK; ALTER TABLE xx DISABLE TRIGGER ALL ... ALTER TABLE xx ENABLE TRIGGER ALL COMMIT WORK; In this case, the triggers are disabled just for that session. ... but everybody else is locked out completely, because the ALTER takes an exclusive lock on the table. It's a bit misleading to describe that as a local change. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] enable/disable trigger (Re: Fwd: [HACKERS] Open items)
Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: Oh, and one trick for disabling triggers in a single session is to do this: BEGIN WORK; ALTER TABLE xx DISABLE TRIGGER ALL ... ALTER TABLE xx ENABLE TRIGGER ALL COMMIT WORK; In this case, the triggers are disabled just for that session. ... but everybody else is locked out completely, because the ALTER takes an exclusive lock on the table. It's a bit misleading to describe that as a local change. Oh, I had not considered that. -- 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: [PATCHES] enable/disable trigger (Re: Fwd: [HACKERS] Open items)
Bruce Momjian pgman@candle.pha.pa.us writes: Tom Lane wrote: ... but everybody else is locked out completely, because the ALTER takes an exclusive lock on the table. It's a bit misleading to describe that as a local change. The pre-8.1 method was to UPDATE pg_class.reltriggers = 0. Would that allow concurrent access? It did not lock the table per se. (Whether that was a safe behavior at all, I'm too tired to work out at the moment.) regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Open items
On Thu, Jun 30, 2005 at 10:11:56AM -0400, Rod Taylor wrote: On Thu, 2005-06-30 at 23:02 +0900, Satoshi Nagayasu wrote: The TODO item is about counting all temporary files, not sorts in particular. Or at least that's what I thought it meant. If the DBA have to improve the performance, DBA will need to know about: - Which SQL generate a disk sort? Good point. An EXPLAIN ANALYZE note about the disk usage for the sort would be really nice. Even nicer would be a way to log queries that generate on-disk sorts. -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open items
Tom Lane wrote: My patch counts inittapes(), tuplesort_begin_heap() and tuplesort_begin_index(), and collect them, and sum them through the stat collector. Hm, that doesn't seem like quite the right level to be counting at. Shouldn't you be hacking fd.c to count operations on FD_XACT_TEMPORARY files? Why do you think so? I don't see tuplesort.c is good or not. But all code of sort operations are in tuplesort.c. So I thought it is a good place to count them up. Of course, I can move my code to fd.c if it will be reasonable. -- NAGAYASU Satoshi [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Open items
Satoshi Nagayasu [EMAIL PROTECTED] writes: Tom Lane wrote: Hm, that doesn't seem like quite the right level to be counting at. Shouldn't you be hacking fd.c to count operations on FD_XACT_TEMPORARY files? Why do you think so? I don't see tuplesort.c is good or not. But all code of sort operations are in tuplesort.c. So I thought it is a good place to count them up. The TODO item is about counting all temporary files, not sorts in particular. Or at least that's what I thought it meant. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open items
The TODO item is about counting all temporary files, not sorts in particular. Or at least that's what I thought it meant. If the DBA have to improve the performance, DBA will need to know about: - Which SQL generate a disk sort? - Size of sorts. - Changing 'work_mem' value can reduce disk sorts? So, sometime DBA want to know about 'sorts', not temp files. However, I understand DBA must also care about temp files usage. I think both are required. DBA need to know about 'sorts' and 'temp files'. -- NAGAYASU Satoshi [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Open items
On Thu, 2005-06-30 at 23:02 +0900, Satoshi Nagayasu wrote: The TODO item is about counting all temporary files, not sorts in particular. Or at least that's what I thought it meant. If the DBA have to improve the performance, DBA will need to know about: - Which SQL generate a disk sort? Good point. An EXPLAIN ANALYZE note about the disk usage for the sort would be really nice. -- ---(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] Open items
* Rod Taylor ([EMAIL PROTECTED]) wrote: On Thu, 2005-06-30 at 23:02 +0900, Satoshi Nagayasu wrote: The TODO item is about counting all temporary files, not sorts in particular. Or at least that's what I thought it meant. If the DBA have to improve the performance, DBA will need to know about: - Which SQL generate a disk sort? Good point. An EXPLAIN ANALYZE note about the disk usage for the sort would be really nice. I agree with this. It'd also be really nice to know when a sort is going to be done on the disk vs. when the planner thinks there's enough memory to do it in memory (or does that always turn it into a hash join from a merge join?). Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Open items
Euler Taveira de Oliveira [EMAIL PROTECTED] writes: I think that moving rtree_gist, reindexdb, and/or userlock into core would have to happen before feature freeze, [snip] Are you think in putting reindex at core? I was about to submit a replacement of it but if it goes to bin/scripts (for example) I can rearrange the patch. Could I? The redefinition of REINDEX DATABASE is already in. A direct replacement for reindexdb would basically need to apply this across all DBs in the cluster, which is definitely a job for bin/scripts. I was speculating that maybe it'd make more sense to handle it as an option to vacuumdb or clusterdb instead of a whole new program, but it's up to you if you're doing the work. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Open items
Hi Tom, I think that moving rtree_gist, reindexdb, and/or userlock into core would have to happen before feature freeze, [snip] Are you think in putting reindex at core? I was about to submit a replacement of it but if it goes to bin/scripts (for example) I can rearrange the patch. Could I? Euler Taveira de Oliveira euler[at]yahoo_com_br __ Converse com seus amigos em tempo real com o Yahoo! Messenger http://br.download.yahoo.com/messenger/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open items
Changes --- integrated auto-vacuum (Alvaro) ICU locale patch? That would be Palle, and he's said he thinks he can have it in place in time. I'll have to update it for win32 build specifics after that, but that should be ok after the freeze, right? Please consider removing the question mark ;-) The latest version of the patch is at http://people.freebsd.org/~girgen/postgresql-icu/readme.html. It needs to be updated for 8.1. //Magnus ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
