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/

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

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, Pennsylvania 19073

"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:

adddepend
dbase
dbmirror
fulltextindex
mSQL-interface
mac
oracle
tips

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

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:

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

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

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

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, Pennsylvania 19073

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

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 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

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, Pennsylvania 19073

-----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