Thread: 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,
Pennsylvania19073
> /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/
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, Pennsylvania19073
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/
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, Pennsylvania19073
"Joshua D. Drake" <jd@commandprompt.com> 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:
adddependdbasedbmirrorfulltextindexmSQL-interfacemacoracletips
regards, tom lane
Andrew Dunstan <andrew@dunslane.net> 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
Tom Lane wrote: >"Joshua D. Drake" <jd@commandprompt.com> 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
> 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
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
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, Pennsylvania19073
> > > 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
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,
Pennsylvania19073
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,
Pennsylvania19073
Bruce Momjian wrote: > bump major library version number? Were there any incompatible interface changes? -- Peter Eisentraut http://developer.postgresql.org/~petere/
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 libpqjust because# libpq uses those functions too. This makes applications less# dependent on changes in libpq's usage ofpgport. To do this we link to# pgport before libpq. This does cause duplicate -lpgport's to appear# on client link lines.ifdefPGXSlibpq_pgport = -L$(libdir) -lpgport $(libpq)elselibpq_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, Pennsylvania19073
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
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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, Pennsylvania19073
> -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org] 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
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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
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, Pennsylvania19073
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
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 jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
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
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, Pennsylvania19073
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 jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461