Schedule for 8.1 feature freeze

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Bruce Momjian
Sent: 21 June 2005 05:04
To: PostgreSQL-development
Subject: [HACKERS] Schedule for 8.1 feature freeze

We have addressed all the open issues for 8.1 except for auto-vacuum,
which Alvaro is working on, so I think we are ready for a
feature freeze
on July 1.

What about Andreas' instrumentation stuff? This has been going on since
before 8.0 and it would good to get it in 8.1 given the amount of extra
functionality it allows us to offer users that prefer a GUI interface.

I realise there probably won't be time to fix pg_terminate_backend, or
convince people that it offers the admin the lesser of two evils (my
limited understanding being that there is a chance of it not clearing
some locks, vs, having to shut down the whole server to kill a single
connection) - can we at least get the other functions applied?

Thanks, Dave.

We have addressed all the open issues for 8.1 except for
auto-vacuum, which Alvaro is working on, so I think we are
ready for a feature freeze on July 1.

I don't beleive we have :-(

The server instrumentation patch is not yet addressed. Last I checked
there was the objections to pg_terminate_backend (which are certainly
valid,though I and many other still claim this is in daily use at *a
lot* of installations), and nothing substantial to the rest of the
patch. yet it hasn't even made it to the queue (the patch would still be
very useful with just the parts except pg_terminate_backend). I beleive
Andreas is working on separating out the pg_terminate_backend part to a
separate patch to make it easier for whomever would apply it.

There is also the ICU patch. this is *very* much needed for win32, and
from how I read it it's also needed for other platforms. Last I heard
Palle planned to have it fixed up before feature freeze (I'm not sure
exactly what more needed to be fixed). If not then we have to do
something else about unicode on win32 (perhaps under the flag of
"bugfix", but I'm sure it will be more invasive than most would like).
But I realy think a cross-platform thing like ICU is much better.

And there's a pending patch that redoes signal handling on win32. I
haven't had the time to check it through myself, as I've been
unexpectedly-out-of-town several times lately, but it was posted some
time ago and shoudl probalby be at least considered. (I'm not 100% sure
it's a worthwhile simplification myself, but I'll have to look into it
muc more careful before I can form an actual opinion on it)

Finally a heads-up: I'm looking at an updated patch to remove the
Kerberos V4 support. I posted to both hackers and general a month ago
asking for people who use it for exactly zero responses. It's not quite
done yet, but I plan to have it done before July 1st. But it's definitly
not something to hold up a freeze date for if I'm not.

Is there an "Open Issues" list yet, as you usually prepare for releases?
If so, can you please put these items up on it?

//Magnus

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Bruce Momjian
Sent: 21 June 2005 05:04
To: PostgreSQL-development
Subject: [HACKERS] Schedule for 8.1 feature freeze

We have addressed all the open issues for 8.1 except for auto-vacuum,
which Alvaro is working on, so I think we are ready for a
feature freeze
on July 1.

Bruce, we're working on GiST concurrency which is based on GiST recovery
code already submitted. Hopefully, we'll submit patch before July 1.
There is also one problem we already discussed - we have no gist opclasses
in core we could use for regression tests ! Probably, it's a time we need
to add some opclasses from intarray or rtree_gist to core ?

btw, there was a noise about funding of our work, but I've contacted only
with PostGis guys about real contribution. I'm just wondered if any
commercial clones do really understand the importance of our work. Should
I write some explanation what're recovery and concurrency for GiST ?

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

* Bruce Momjian (pgman@candle.pha.pa.us) wrote:

We have addressed all the open issues for 8.1 except for auto-vacuum,
which Alvaro is working on, so I think we are ready for a feature freeze
on July 1.

Bruce,

I'd really like to see role support added into 8.1. I've sent Alvaro
and Tom versions of the patch in the past and I was planning on
submitting it to -patches soon. There's a few remaining issue but I
don't think they'll take very long to clean up; I've just been
unfortunately pretty busy lately. I'm hopeful that I'll be able to
spend some time on it this week and next week to hopefully address at
least the remaining issues on my list.

Lookups need to do multi-level role resolution (for owner and other
ACL areas)
(Not very hard, and mostly isolated to the acl code)
Need to implement per-backend role-member cacheing
(Not very hard, basically same kind of way pg_namespace does
schema_path)
Support 'grant <role> to <role>'
(Shouldn't be too difficult, mainly just parser work)
Support 'with admin option'
(Somewhat difficult, but not necessary for the same functionality we
have today)
Support 'granted by'
(Not very hard, just parser work really)
Fix other parsers (ecpg, etc) based on updates to backend/parser.
(Worked on this some already, should be done real soon now)
Distinguish 'create role' permissions from 'superuser'?
(Not sure if this makes sense)

Modify \du, \dg to use new tables
(They work already using the backwards-compat views, just would be
nice to update them to the new schema).
? Add \dr, \dm
(Should be easy and would be nice I think, though perhaps not
required)

Add documentation for CREATE ROLE/etc
Document new system catalogs (pg_authid, pg_auth_members)
(Documentation updates)

There are views for pg_shadow/pg_group and things seem to be happy
with them. CREATE USER/CREATE GROUP work more-or-less as expected.
An interesting side-effect is that if you do 'create group' and then
look in the 'group' table you don't see the group till you actually
put users in it. Not entirely sure if anything actually depends on
that (You can, after all, still grant rights to the role which was
created by CREATE GROUP, and do ALTER GROUP on it, etc).

Thanks,

Stephen

I realise there probably won't be time to fix pg_terminate_backend, or
convince people that it offers the admin the lesser of two evils (my
limited understanding being that there is a chance of it not clearing
some locks, vs, having to shut down the whole server to kill a single
connection) - can we at least get the other functions applied?

Not clearing those locks frequently results in a "Lock Table corruption"
message and panic at some unknown point in the future, and is probably
not something we want to encourage.

It looks really bad when it happens hours or days after the connection
was killed because the user isn't going to associate those two actions.

This is a feature I'm really looking forward too, but it's not ready for
general consumption yet.

--

Stephen Frost <sfrost@snowman.net> writes:

I'd really like to see role support added into 8.1. I've sent Alvaro
and Tom versions of the patch in the past and I was planning on
submitting it to -patches soon. There's a few remaining issue but I
don't think they'll take very long to clean up; I've just been
unfortunately pretty busy lately. I'm hopeful that I'll be able to
spend some time on it this week and next week to hopefully address at
least the remaining issues on my list.

Stephen, it is not going to be acceptable to sit on that patch until
June 30 --- there are other things depending on it. If you don't have
time for it now, send in what you have so that someone else can pick up
the ball.

regards, tom lane

* Tom Lane (tgl@sss.pgh.pa.us) wrote:

Stephen Frost <sfrost@snowman.net> writes:

I'd really like to see role support added into 8.1. I've sent Alvaro
and Tom versions of the patch in the past and I was planning on
submitting it to -patches soon. There's a few remaining issue but I
don't think they'll take very long to clean up; I've just been
unfortunately pretty busy lately. I'm hopeful that I'll be able to
spend some time on it this week and next week to hopefully address at
least the remaining issues on my list.

Stephen, it is not going to be acceptable to sit on that patch until
June 30 --- there are other things depending on it. If you don't have
time for it now, send in what you have so that someone else can pick up
the ball.

Sorry, I thought that's what I had been doing when sending to
you/Alvaro/-hackers earlier.. I'll send in what I've got and I guess
see what happens. I'm planning on still working on it when I have time
available so if someone else picks it up to work on it, please let me
know so we can coordinate.

Thanks,

Stephen

Bruce Momjian <pgman@candle.pha.pa.us> writes:

We have addressed all the open issues for 8.1 except for auto-vacuum,

Aside from the other stuff people mentioned, I have these things on
my to-look-at list:

* Fix pg_dump to be able to dump large objects in text dumps

* Fix inherited constraints (per discussion around 5/20)

* Fix reporting of table/column numbers for cursors (per DeSoi, 4/9)

* statement_timeout does not behave very reasonably for V3 messages

And I'd really like to see pg_role and shared dependencies get in...

regards, tom lane

Bruce Momjian wrote:

We have addressed all the open issues for 8.1 except for auto-vacuum,
which Alvaro is working on, so I think we are ready for a feature freeze
on July 1.

FYI - plperl status.

I am trying to get the following 2 items done by feature freeze:
. convert returned perl array to pg array (see patch recently sent for
discussion)
. validator function

The remaining memory issue we have is where plperl does a huge select
via SPI. Abhijit Menon-Sen was working on this but is stumped on how to
proceed (see his previous message). We have a patch from CommandPrompt
which apparently improves the situation, although it doesn't solve the
basic problem. If we don't make progress with Abhijit's work, I will
look at working that up by July 1.

There is also the tiny patch to trap lexical warnings I submitted not
long ago still outstanding.

cheers

andrew

I'll do my best to submit bitmap index AM patch next week for your review.

--

Victor Y. Yegorov

Dave Page wrote:

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Bruce Momjian
Sent: 21 June 2005 05:04
To: PostgreSQL-development
Subject: [HACKERS] Schedule for 8.1 feature freeze

We have addressed all the open issues for 8.1 except for auto-vacuum,
which Alvaro is working on, so I think we are ready for a
feature freeze
on July 1.

What about Andreas' instrumentation stuff? This has been going on since
before 8.0 and it would good to get it in 8.1 given the amount of extra
functionality it allows us to offer users that prefer a GUI interface.

I realise there probably won't be time to fix pg_terminate_backend, or
convince people that it offers the admin the lesser of two evils (my
limited understanding being that there is a chance of it not clearing
some locks, vs, having to shut down the whole server to kill a single
connection) - can we at least get the other functions applied?

[ CC to Andreas.]

OK, let me address this, but you might not like what I have to say. ;-)

Basically, Andreas' approach for 8.0 was to develop a patch (without
posting a proposal or interface), and then argue why pgadmin needs it,
but without addressing the real concerns about the patch. Saying
pgadmin needs it just isn't enough to get a patch in. There are the
issues of security and maintainability that have to be addressed, and
in the limited time we had to do this in 8.0, it was clear the patch
should not be applied.

Now, in 8.1, the same thing has happened. Two weeks before feature
freeze, with no discussion, the patch appears, and makes no reference to
concerns raised during the 8.0 discussion. pg_terminate_backend is even
in the patch, and there is no mention or attempt to address concerns we
had in 8.0.

The move of dbsize into the backend is similar. He moves the parts of
dbsize the pgadmin needs into the backend, but makes no mention or
change to /contrib/dbsize to adjust it to the movement of the code. He
has since posted and updated version that fixes this, I think, but
again, we have to discuss how this is to be done --- do we move all the
dbsize functions into the backend, some, or none? Do the other dbsize
functions stay in /contrib or get deleted?

This needs discussion, not a patch. And because there are so many
assumptions made in the patch, the patch committers look unreasonable
asking for X changes to his patch, when in fact he made X assumptions in
the patch and never asked anyone before developing the patch about those
assumptions.

Basically, I think this is a great example of how _not_ to do things in
the community:

o don't post your proposal for discussion
o don't mention controversial issues in your patch
o don't fully address code migrations in your patch

It seems like the goal is to throw in the patch on the hopes that no one
will remember or realize the problems before it gets into CVS.

What has to happen now is that we need to restart the server
instrumentation discussion with a proposal of what needs to be added to
the server, and why, and then we can deal with any concerns raised. The
same is true with the dbsize patch.

Bad news, yea, but I think it is the only way to move forward.

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

Andrew Dunstan wrote:

There is also the tiny patch to trap lexical warnings I submitted not
long ago still outstanding.

OK, I missed that one. I see it at:

http://archives.postgresql.org/pgsql-patches/2005-06/msg00280.php

However, I don't see the new regession files attached to that URL.
Would you repost please?

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

Magnus Hagander wrote:

Is there an "Open Issues" list yet, as you usually prepare for releases?
If so, can you please put these items up on it?

Yes, it is at:

This item has been added to the 7.4 open items list:

http://candle.pha.pa.us/cgi-bin/pgopenitems

It did contain only pgautovacuum, but has been updated with the new
items.

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We have addressed all the open issues for 8.1 except for auto-vacuum,
which Alvaro is working on, so I think we are ready for a feature freeze
on July 1.

FWIW, I'm still working on column-level triggers, but the July 1st deadline
should not be a problem.

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200506211841
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iD8DBQFCuJe+vJuQZxSWSsgRAkSnAKDhwsRXoupe1DhHGgCYrquimK9CJQCgz1K5
/nHRvPxNs+41vxs7G9ngvW4=
=C+M3
-----END PGP SIGNATURE-----

On Jun 21, 2005, at 1:03 PM, Bruce Momjian wrote:

We have addressed all the open issues for 8.1 except for auto-vacuum,
which Alvaro is working on, so I think we are ready for a feature
freeze
on July 1.

I'm hoping to add documentation and regression tests for interval-

day over the next couple of days and have that ready for 8.1 as well.

Michael Glaesemann
grzm myrealbox com

On Jun 21, 2005, at 1:03 PM, Bruce Momjian wrote:

We have addressed all the open issues for 8.1 except for auto-vacuum,
which Alvaro is working on, so I think we are ready for a feature
freeze
on July 1.

I'm hoping to add documentation and regression tests for interval-

day over the next couple of days and have that ready for 8.1 as well.

Michael Glaesemann
grzm myrealbox com

People:

Oh, and in implementing the COPY stuff we realized that there weren't any
regression tests for encodings. If we can figure out how to do them,
we'll add those. Are new regression tests permitted during beta?

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

Bruce Momjian wrote:

Dave Page wrote:

Basically, Andreas' approach for 8.0 was to develop a patch (without
posting a proposal or interface), and then argue why pgadmin needs it,
but without addressing the real concerns about the patch.

Extending the logging was to get a means of reading the log file without
console access, with *any* client.
The proposal to develop the generic file functions came from a Mr Bruce
Momjian.

Saying
pgadmin needs it just isn't enough to get a patch in.

Never said that. It's needed by dbadmins without console access.

There are the
issues of security and maintainability that have to be addressed,

All issues were discussed and solved.

and
in the limited time we had to do this in 8.0, it was clear the patch
should not be applied.

Now, in 8.1, the same thing has happened. Two weeks before feature
freeze,

I posted it on June 1st.

with no discussion, the patch appears, and makes no reference to

concerns raised during the 8.0 discussion.

RTFM. The lengthy original discussion which addressed _all_ issues is
referenced.

pg_terminate_backend is even

in the patch, and there is no mention or attempt to address concerns we
had in 8.0.

I never intended to address the issues, I wanted to address the every
day problem to kill a backend without killing the server. Drop it, for
god's sake.

The move of dbsize into the backend is similar. He moves the parts of
dbsize the pgadmin needs into the backend, but makes no mention or
change to /contrib/dbsize to adjust it to the movement of the code. He
has since posted and updated version that fixes this, I think, but
again, we have to discuss how this is to be done --- do we move all the
dbsize functions into the backend, some, or none? Do the other dbsize
functions stay in /contrib or get deleted?
This needs discussion, not a patch. And because there are so many
assumptions made in the patch, the patch committers look unreasonable
asking for X changes to his patch, when in fact he made X assumptions in
the patch and never asked anyone before developing the patch about those
assumptions.

This was discussed lengthy starting May 11th, except for the broken
dbsize functions. My post is the result from that.

Regards,
Andreas

On Tue, 21 Jun 2005, Josh Berkus wrote:

People:

Oh, and in implementing the COPY stuff we realized that there weren't any
regression tests for encodings. If we can figure out how to do them,
we'll add those. Are new regression tests permitted during beta?

Yes, most definitely ... especially if they happen to pick up a bug at the
same time :)

Anything that improves *testing* or *documentation* should be no-brainers
for addition during the release process, since they both improve the end
product without affecting the backend code itself ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

Josh Berkus <josh@agliodbs.com> writes:

Oh, and in implementing the COPY stuff we realized that there weren't any
regression tests for encodings. If we can figure out how to do them,
we'll add those. Are new regression tests permitted during beta?

Certainly. Feature freeze is about features, not correctness ...

regards, tom lane

Andreas Pflug wrote:

Bruce Momjian wrote:

Dave Page wrote:

Basically, Andreas' approach for 8.0 was to develop a patch (without
posting a proposal or interface), and then argue why pgadmin needs it,
but without addressing the real concerns about the patch.

Extending the logging was to get a means of reading the log file without
console access, with *any* client.
The proposal to develop the generic file functions came from a Mr Bruce
Momjian.

Yes, you are right I helped with the initial file stuff, but not with
the terminate nor the dbsize. I can't remember if I got involved before
or after the initial patch, so you are right.

Saying
pgadmin needs it just isn't enough to get a patch in.

Never said that. It's needed by dbadmins without console access.

Needed and having it added are different issues. As I remember there
were security concerns about having the backend able to read/write
random files.

There are the
issues of security and maintainability that have to be addressed,

All issues were discussed and solved.

I am not aware they were all addressed, and if you had terminate in
there, which was clearly not addressed, I question whether the others
issues are addressed too. I think we need to re-discuss the idea of
these functions.

and
in the limited time we had to do this in 8.0, it was clear the patch
should not be applied.

Now, in 8.1, the same thing has happened. Two weeks before feature
freeze,

I posted it on June 1st.

Uh, you are right it wasn't June 22, but it was June 10, not June 1:

http://archives.postgresql.org/pgsql-patches/2005-06/msg00226.php

with no discussion, the patch appears, and makes no reference to

concerns raised during the 8.0 discussion.

RTFM. The lengthy original discussion which addressed _all_ issues is
referenced.

Is that true? I don't remember that conclusion myself. Do others?

pg_terminate_backend is even

in the patch, and there is no mention or attempt to address concerns we
had in 8.0.

I never intended to address the issues, I wanted to address the every
day problem to kill a backend without killing the server. Drop it, for
god's sake.

Well, here you are saying you didn't address concerns about terminate,
and just posted it because it was needed. That is my point.

The move of dbsize into the backend is similar. He moves the parts of
dbsize the pgadmin needs into the backend, but makes no mention or
change to /contrib/dbsize to adjust it to the movement of the code. He
has since posted and updated version that fixes this, I think, but
again, we have to discuss how this is to be done --- do we move all the
dbsize functions into the backend, some, or none? Do the other dbsize
functions stay in /contrib or get deleted?
This needs discussion, not a patch. And because there are so many
assumptions made in the patch, the patch committers look unreasonable
asking for X changes to his patch, when in fact he made X assumptions in
the patch and never asked anyone before developing the patch about those
assumptions.

This was discussed lengthy starting May 11th, except for the broken
dbsize functions. My post is the result from that.

Really? Where? I don't remember anything about it.

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

On Tue, 21 Jun 2005, Bruce Momjian wrote:

I am not aware they were all addressed, and if you had terminate in
there, which was clearly not addressed, I question whether the others
issues are addressed too. I think we need to re-discuss the idea of
these functions.

Just curious, but if 'all issues were discussed', maybe instead of
're-discussing' it, why not just read through the archives that should be
available of that discussion ... ?

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

Bruce Momjian wrote:

We have addressed all the open issues for 8.1 except for auto-vacuum,
which Alvaro is working on, so I think we are ready for a feature freeze
on July 1.

It would be nice to upgrade to autoconf 2.59 before the freeze (although
it would probably be okay to do this post-freeze but pre-beta).

-Neil

Dear Stephen,

I'd really like to see role support added into 8.1.

I'm also pretty interested in this, and was planing loosely to think about
implementing roles someday. It is even better if it is done by someone
else;-)

I've sent Alvaro and Tom versions of the patch in the past and I was
planning on submitting it to -patches soon. There's a few remaining
issue but I don't think they'll take very long to clean up; I've just
been unfortunately pretty busy lately. I'm hopeful that I'll be able to
spend some time on it this week and next week to hopefully address at
least the remaining issues on my list.

I could not find this patch, although I wanted to have a look. After some
thinking on the subjet, ISTM that there are 4 key issues for roles to be
really interesting in postgresql, and I just wanted to state them:

(1) the role rights should *supercede* group/user rights.
E.g. if an admin chose to act in the role "readonly-client",
then it should be restricted to what this role allows.

(2) roles should be per *catalog* (database), not per cluster
(installation) as "user" and "group".

(3) role management should be a natural privilege of the database *owner*.

(4) user/group/role will make "permission denied" errors even harder to
comprehend and solve as they are already, so instead of
"permission denied on table foo", give a more precise form such as
"permission denied on table foo, cannot perform update in role bla".

Otherwise ISTM that role would not be an improvement over the current
"group" concept in postgresql.

Maybe it is already what was submitted, but as I could not check...

Thanks for working on this useful feature, have a nice day,

--
Fabien.

-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: 21 June 2005 18:06
To: Dave Page
Cc: PostgreSQL-development; Andreas Pflug
Subject: Server instrumentation patch

OK, let me address this, but you might not like what I have
to say. ;-)

Basically, Andreas' approach for 8.0 was to develop a patch (without
posting a proposal or interface), and then argue why pgadmin needs it,
but without addressing the real concerns about the patch. Saying
pgadmin needs it just isn't enough to get a patch in. There are the
issues of security and maintainability that have to be addressed, and
in the limited time we had to do this in 8.0, it was clear the patch
should not be applied.

The reason it happen that way was because we already had the code as a
contrib-style module for pgAdmin. It was posted because we recognised
that it was becoming a PITA for pgAdmin users to compile a new
server-side component and the functions seemed like they would be useful
to other tools similar to pgAdmin.

Yes, this is not the normal way to proprose new features, but I'm sure
you appreciate that as picture speaks a thousand words, posting the
*existing* code with minor changes to properly integrate it shows
exactly what is being proposed, both in functional and impelmentation
detail.

Now, in 8.1, the same thing has happened. Two weeks before feature
freeze, with no discussion, the patch appears, and makes no
reference to
concerns raised during the 8.0 discussion.

OK, first it was the 10th of June which is a little more than two weeks,
however, Andreas clearly did reference previous discussions on the
subject - see his message
http://archives.postgresql.org/pgsql-patches/2005-06/msg00226.php in
which he points out that 2 functions are from the logger suprocess patch
from 07/2004, that the file related stuff is based on discussions
starting at
http://archives.postgresql.org/pgsql-patches/2004-07/msg00287.php,
including comments from yourself!!

pg_terminate_backend is even
in the patch, and there is no mention or attempt to address
concerns we
had in 8.0.

No. I cannot argue with that, and for that reason I suggested that
Andreas repost the patch without that function so it can be properly
discussed and implemented in a safe way in the future. I'm sure you have
see the reposted patch.

The move of dbsize into the backend is similar. He moves the parts of
dbsize the pgadmin needs into the backend, but makes no mention or
change to /contrib/dbsize to adjust it to the movement of the code. He
has since posted and updated version that fixes this, I think, but
again, we have to discuss how this is to be done --- do we
move all the
dbsize functions into the backend, some, or none? Do the other dbsize
functions stay in /contrib or get deleted?

Well as far as I can see, Andreas did respond to all queries about it,
and then posted his updated patch after it became apparent noone else
was going to discuss the issue further -
http://archives.postgresql.org/pgsql-patches/2005-06/msg00309.php. From
what I can see, no-one has argued or disagreed with his opinion given a
few days to do so, therefore there was nothing further to discuss.

Unfortunately sometimes people don't respond - either because they don't
care, or because they agree. Either way, *we* cannot force a discussion,
and in this sort of development model we have no choice than to assume
that if discussion of a issue stops and there are no outstanding
queries, concerns or objections, it's because it's everyone is happy for
the result of those discussions to be accepted into the project.

This needs discussion, not a patch. And because there are so many
assumptions made in the patch, the patch committers look unreasonable
asking for X changes to his patch, when in fact he made X
assumptions in
the patch and never asked anyone before developing the patch
about those
assumptions.

With the exception of the now removed pg_terminate_backend, I am unaware
of any issues that are outstanding. If the committers have issues they
*must* raise them for *any* submitted patch otherwise developers will
lose faith in the process when their hard work gets ignored.

Now, to try to get this ball rolling again - do the committers or anyone
else have any outstanding issues with the instrumentation or dbsize
patches that haven't been answered in public discussion and addressed in
the patches already?

Regards, Dave.

-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: 22 June 2005 04:08
To: Andreas Pflug
Cc: Dave Page; PostgreSQL-development
Subject: Re: Server instrumentation patch

The move of dbsize into the backend is similar. He moves

the parts of

dbsize the pgadmin needs into the backend, but makes no mention or
change to /contrib/dbsize to adjust it to the movement of

the code. He

has since posted and updated version that fixes this, I think, but
again, we have to discuss how this is to be done --- do

we move all the

dbsize functions into the backend, some, or none? Do the

other dbsize

functions stay in /contrib or get deleted?
This needs discussion, not a patch. And because there are so many
assumptions made in the patch, the patch committers look

unreasonable

asking for X changes to his patch, when in fact he made X

assumptions in

the patch and never asked anyone before developing the

patch about those

assumptions.

This was discussed lengthy starting May 11th, except for the broken
dbsize functions. My post is the result from that.

Really? Where? I don't remember anything about it.

I imagine that would be this lengthy thread:
http://archives.postgresql.org/pgsql-hackers/2005-05/msg00837.php

Regards, Dave.

Dave Page wrote:

The reason it happen that way was because we already had the code as a
contrib-style module for pgAdmin. It was posted because we recognised
that it was becoming a PITA for pgAdmin users to compile a new
server-side component and the functions seemed like they would be useful
to other tools similar to pgAdmin.

Yes, this is not the normal way to proprose new features, but I'm sure
you appreciate that as picture speaks a thousand words, posting the
*existing* code with minor changes to properly integrate it shows
exactly what is being proposed, both in functional and impelmentation
detail.

Sure.

Now, in 8.1, the same thing has happened. Two weeks before feature
freeze, with no discussion, the patch appears, and makes no
reference to
concerns raised during the 8.0 discussion.

OK, first it was the 10th of June which is a little more than two weeks,
however, Andreas clearly did reference previous discussions on the
subject - see his message
http://archives.postgresql.org/pgsql-patches/2005-06/msg00226.php in
which he points out that 2 functions are from the logger suprocess patch
from 07/2004, that the file related stuff is based on discussions
starting at
http://archives.postgresql.org/pgsql-patches/2004-07/msg00287.php,
including comments from yourself!!

pg_terminate_backend is even
in the patch, and there is no mention or attempt to address
concerns we
had in 8.0.

No. I cannot argue with that, and for that reason I suggested that
Andreas repost the patch without that function so it can be properly
discussed and implemented in a safe way in the future. I'm sure you have
see the reposted patch.

OK.

The move of dbsize into the backend is similar. He moves the parts of
dbsize the pgadmin needs into the backend, but makes no mention or
change to /contrib/dbsize to adjust it to the movement of the code. He
has since posted and updated version that fixes this, I think, but
again, we have to discuss how this is to be done --- do we
move all the
dbsize functions into the backend, some, or none? Do the other dbsize
functions stay in /contrib or get deleted?

Well as far as I can see, Andreas did respond to all queries about it,
and then posted his updated patch after it became apparent noone else
was going to discuss the issue further -
http://archives.postgresql.org/pgsql-patches/2005-06/msg00309.php. From
what I can see, no-one has argued or disagreed with his opinion given a
few days to do so, therefore there was nothing further to discuss.

Well, I see Marc replying that dbsize should be moved completely from
contrib:

http://archives.postgresql.org/pgsql-patches/2005-06/msg00409.php

The current version of the patch only moves those functions he wants.
Marc says he wants them all moved, and I agree.

With the exception of the now removed pg_terminate_backend, I am unaware
of any issues that are outstanding. If the committers have issues they
*must* raise them for *any* submitted patch otherwise developers will
lose faith in the process when their hard work gets ignored.

Well, from the May, 2005 discussion URL you posted, I see a clear reply
to the idea of adding the I/O functions to the backend:

http://archives.postgresql.org/pgsql-hackers/2005-05/msg00874.php

Now, you can agree or disagree that there are issues with the I/O
functions, but the concern was raised in May, and not addressed at all,
either via email or the patch.

Now, to try to get this ball rolling again - do the committers or anyone
else have any outstanding issues with the instrumentation or dbsize
patches that haven't been answered in public discussion and addressed in
the patches already?

OK, agreed, how can we move forward? The patch has three parts:

o file I/O
o move dbsize from contrib
o backend terminate

For the first, we need to re-discuss this on hackers. I found this as
the conclusion from July of 2004 as it relates to the I/O functions:

http://archives.postgresql.org/pgsql-patches/2004-07/msg00561.php

However, the TODO items still exist so we can discuss it and hopefully
resolve it by feature freeze.

For the second, please supply a patch that moves _all_ of dbsize into
the main server. I think we have agreement on that.

For backend terminate, I agree with Tom that we have to get SIGTERM
working, and then the function can just send a SIGTERM signal. Unless
it is working 100%, we will not add a terminate function to SQL. I will
post separately on this topic.

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

Dave Page wrote:

The reason it happen that way was because we already had the code as a
contrib-style module for pgAdmin. It was posted because we recognised
that it was becoming a PITA for pgAdmin users to compile a new
server-side component and the functions seemed like they would be useful
to other tools similar to pgAdmin.

Yes, this is not the normal way to proprose new features, but I'm sure
you appreciate that as picture speaks a thousand words, posting the
*existing* code with minor changes to properly integrate it shows
exactly what is being proposed, both in functional and impelmentation
detail.

Sure.

Now, in 8.1, the same thing has happened. Two weeks before feature
freeze, with no discussion, the patch appears, and makes no
reference to
concerns raised during the 8.0 discussion.

OK, first it was the 10th of June which is a little more than two weeks,
however, Andreas clearly did reference previous discussions on the
subject - see his message
http://archives.postgresql.org/pgsql-patches/2005-06/msg00226.php in
which he points out that 2 functions are from the logger suprocess patch
from 07/2004, that the file related stuff is based on discussions
starting at
http://archives.postgresql.org/pgsql-patches/2004-07/msg00287.php,
including comments from yourself!!

pg_terminate_backend is even
in the patch, and there is no mention or attempt to address
concerns we
had in 8.0.

No. I cannot argue with that, and for that reason I suggested that
Andreas repost the patch without that function so it can be properly
discussed and implemented in a safe way in the future. I'm sure you have
see the reposted patch.

OK.

The move of dbsize into the backend is similar. He moves the parts of
dbsize the pgadmin needs into the backend, but makes no mention or
change to /contrib/dbsize to adjust it to the movement of the code. He
has since posted and updated version that fixes this, I think, but
again, we have to discuss how this is to be done --- do we
move all the
dbsize functions into the backend, some, or none? Do the other dbsize
functions stay in /contrib or get deleted?

Well as far as I can see, Andreas did respond to all queries about it,
and then posted his updated patch after it became apparent noone else
was going to discuss the issue further -
http://archives.postgresql.org/pgsql-patches/2005-06/msg00309.php. From
what I can see, no-one has argued or disagreed with his opinion given a
few days to do so, therefore there was nothing further to discuss.

Well, I see Marc replying that dbsize should be moved completely from
contrib:

http://archives.postgresql.org/pgsql-patches/2005-06/msg00409.php

The current version of the patch only moves those functions he wants.
Marc says he wants them all moved, and I agree.

With the exception of the now removed pg_terminate_backend, I am unaware
of any issues that are outstanding. If the committers have issues they
*must* raise them for *any* submitted patch otherwise developers will
lose faith in the process when their hard work gets ignored.

Well, from the May, 2005 discussion URL you posted, I see a clear reply
to the idea of adding the I/O functions to the backend:

http://archives.postgresql.org/pgsql-hackers/2005-05/msg00874.php

Now, you can agree or disagree that there are issues with the I/O
functions, but the concern was raised in May, and not addressed at all,
either via email or the patch.

Now, to try to get this ball rolling again - do the committers or anyone
else have any outstanding issues with the instrumentation or dbsize
patches that haven't been answered in public discussion and addressed in
the patches already?

OK, agreed, how can we move forward? The patch has three parts:

o file I/O
o move dbsize from contrib
o backend terminate

For the first, we need to re-discuss this on hackers. I found this as
the conclusion from July of 2004 as it relates to the I/O functions:

http://archives.postgresql.org/pgsql-patches/2004-07/msg00561.php

However, the TODO items still exist so we can discuss it and hopefully
resolve it by feature freeze.

For the second, please supply a patch that moves _all_ of dbsize into
the main server. I think we have agreement on that.

I don't think so. As I mentioned, those views are broken. Do you want
them to be in core anyway?

Regards,
Andreas

-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: 24 June 2005 14:00
To: Dave Page
Cc: PostgreSQL-development; Andreas Pflug
Subject: Re: Server instrumentation patch

Well, I see Marc replying that dbsize should be moved completely from
contrib:

http://archives.postgresql.org/pgsql-patches/2005-06/msg00409.php

The current version of the patch only moves those functions he wants.
Marc says he wants them all moved, and I agree.

OK - did you see Andreas' response to why he hadn't done that (it was
actually posted in response to your original query, not Marcs)? In a
nutshell, the functions that had not been moved returned values that
were easily derived from the other functions, and thus could be
considered bloat?

The functions included in the patch were:

int8 pg_tablespace_size(oid) - Return the size of the tablespace in
bytes
int8 pg_database_size(oid) - Return the size of the database in
bytes
int8 pg_relation_size(oid) - Return the size of the relation in
bytes
text pg_size_pretty(int8) - Pretty-print the byte value

The ones left out were:

int8 database_size(name) - Return the size of the database in
bytes (by name)
int8 relation_size(text) - Return the size of the relation in
bytes (by name)
int8 indexes_size(text) - Return the size of the indexes on the
named relation
int8 total_relation_size(text) - Return relation_size(text) +
indexes_size(text) + relation_size(text->toast tables)
setof record relation_size_components(text) - return a pretty-print set
of values from above.

I don't feel particularly strongly either way, but given the normal
desire not to bloat the backend necessarily, I have to question the need
to include the latter functions.

With the exception of the now removed pg_terminate_backend,

I am unaware

of any issues that are outstanding. If the committers have

issues they

*must* raise them for *any* submitted patch otherwise

developers will

lose faith in the process when their hard work gets ignored.

Well, from the May, 2005 discussion URL you posted, I see a
clear reply
to the idea of adding the I/O functions to the backend:

http://archives.postgresql.org/pgsql-hackers/2005-05/msg00874.php

Now, you can agree or disagree that there are issues with the I/O
functions, but the concern was raised in May, and not
addressed at all,
either via email or the patch.

Maybe that's the wrong URL, but all I see there is a vague recollection
from Tom that there were security issues. In the next message, Andreas
recalls how you and he worked out the issues that were raised - I
believe this is the thread
http://archives.postgresql.org/pgsql-hackers/2004-07/msg00793.php.
Mhonarc has made a mess of the thread so it does seem to break in a few
places, and it is possible I've missed part.

Now, to try to get this ball rolling again - do the

committers or anyone

else have any outstanding issues with the instrumentation or dbsize
patches that haven't been answered in public discussion and

addressed in

the patches already?

OK, agreed, how can we move forward? The patch has three parts:

o file I/O
o move dbsize from contrib
o backend terminate

For the first, we need to re-discuss this on hackers. I found this as
the conclusion from July of 2004 as it relates to the I/O functions:

http://archives.postgresql.org/pgsql-patches/2004-07/msg00561.php

I've just read through that thread, and the only mention of security
concerns I can spot is one where you say yourself that they are a
non-issue!!

What are the actual outstanding concerns with these functions?

For the second, please supply a patch that moves _all_ of dbsize into
the main server. I think we have agreement on that.

If that remains the case having seen my comments above echoing Andreas'
concerns then sure, if that's what it takes to get them in, so be it.
Please confirm either way.

For backend terminate, I agree with Tom that we have to get SIGTERM
working, and then the function can just send a SIGTERM signal. Unless
it is working 100%, we will not add a terminate function to
SQL. I will
post separately on this topic.

Agreed.

Regards, Dave.

Andreas Pflug wrote:

For the second, please supply a patch that moves _all_ of dbsize into
the main server. I think we have agreement on that.

I don't think so. As I mentioned, those views are broken. Do you want them
to be in core anyway?

Why is e.g. this one broken:
int8 database_size(name) - Return the size of the database in
bytes (by name)

It should do the same as the one with the oid except that it will resolve
the name first, no? If not it should be fixed, not dropped. I understand
you'd like to have those functions for the GUI frontends, but what about
psql users? For many people it will be hard work to type the subquery to get
the database oid.

I vote for all (possibly corrected) functions to be moved into core.

Best Regards,
Michael Paesold

Michael Paesold wrote:

Andreas Pflug wrote:

For the second, please supply a patch that moves _all_ of dbsize into
the main server. I think we have agreement on that.

I don't think so. As I mentioned, those views are broken. Do you want
them to be in core anyway?

Why is e.g. this one broken:
int8 database_size(name) - Return the size of the database in
bytes (by name)

It should do the same as the one with the oid except that it will
resolve the name first, no? If not it should be fixed, not dropped. I
understand you'd like to have those functions for the GUI frontends,
but what about psql users? For many people it will be hard work to
type the subquery to get the database oid.

I vote for all (possibly corrected) functions to be moved into core.

You're correct about the functions, but I was talking about the views.
"WHERE name = $1" won't respect the schema, contrary to the current doc.

Regards,
Andreas

-----Original Message-----
From: Michael Paesold [mailto:mpaesold@gmx.at]
Sent: 24 June 2005 16:48
To: Andreas Pflug
Cc: Dave Page; PostgreSQL-development
Subject: Re: [HACKERS] Server instrumentation patch

Andreas Pflug wrote:

For the second, please supply a patch that moves _all_ of

dbsize into

the main server. I think we have agreement on that.

I don't think so. As I mentioned, those views are broken.

Do you want them

to be in core anyway?

Why is e.g. this one broken:
int8 database_size(name) - Return the size of the database in
bytes (by name)

It should do the same as the one with the oid except that it
will resolve
the name first, no? If not it should be fixed, not dropped. I
understand
you'd like to have those functions for the GUI frontends, but
what about
psql users? For many people it will be hard work to type the
subquery to get
the database oid.

I vote for all (possibly corrected) functions to be moved into core.

You have pg_database_size(oid) and database_size(name). Afaict, the
latter is equivalent to:

SELECT pg_database_size((SELECT oid FROM pg_database WHERE datname =
'foo'))

My main concern is that the names are inconsistent for no obvious
reason. I also questioned whether or not the bloat of an additional
function is worthwhile for what is probably a very small number of psql
users that might use it (probably quite rarely), however if people say
they would use it and that it's wothwhile, I wouldn't argue with it's
inclusion.

Regards, Dave

On Fri, Jun 24, 2005 at 05:10:15PM +0100, Dave Page wrote:

You have pg_database_size(oid) and database_size(name). Afaict, the
latter is equivalent to:

SELECT pg_database_size((SELECT oid FROM pg_database WHERE datname =
'foo'))

My main concern is that the names are inconsistent for no obvious
reason. I also questioned whether or not the bloat of an additional
function is worthwhile for what is probably a very small number of psql
users that might use it (probably quite rarely), however if people say
they would use it and that it's wothwhile, I wouldn't argue with it's
inclusion.

ISTM it would be better to just add this info into newsysviews. Anyone
who regularly queries against the catalog from psql is going to want to
have them installed anyway. We could either add exact size info to
pg_*_table_storage (http://lnk.nu/cvs.pgfoundry.org/39q.sql) or create a
new view with the file sizes.
--
Jim C. Nasby, Database Consultant decibel@decibel.org
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?"

Andreas Pflug wrote:

Michael Paesold wrote:

Andreas Pflug wrote:

For the second, please supply a patch that moves _all_ of dbsize into
the main server. I think we have agreement on that.

I don't think so. As I mentioned, those views are broken. Do you want
them to be in core anyway?

Why is e.g. this one broken:
int8 database_size(name) - Return the size of the database in
bytes (by name)

It should do the same as the one with the oid except that it will resolve
the name first, no? If not it should be fixed, not dropped. I understand
you'd like to have those functions for the GUI frontends, but what about
psql users? For many people it will be hard work to type the subquery to
get the database oid.

I vote for all (possibly corrected) functions to be moved into core.

You're correct about the functions, but I was talking about the views.
"WHERE name = $1" won't respect the schema, contrary to the current doc.

Oh, I am sorry for not reading carefully enough. Didn't know there were
views at all. So if they are broken and cannot be fixed, well...

Best Regards,
Michael Paesold

Dave Page wrote:

You have pg_database_size(oid) and database_size(name). Afaict, the
latter is equivalent to:

SELECT pg_database_size((SELECT oid FROM pg_database WHERE datname =
'foo'))

The typing is even more e.g. for tables or indexes, though. Of course you
can use the raw form, but why do we have pg_tables if there is pg_class
anyway.

My main concern is that the names are inconsistent for no obvious
reason.

That could be fixed by having:
pg_database_size(name)
pg_database_size(oid)

The original idea was probably to name "internal" functions with pg_ and
more user friendly ones without pg_. That does not mean it's a good idea.

I also questioned whether or not the bloat of an additional
function is worthwhile for what is probably a very small number of psql
users that might use it (probably quite rarely), however if people say
they would use it and that it's wothwhile, I wouldn't argue with it's
inclusion.

Well, I don't feel this is really bloat. I have been using them since the
creation of the contrib module and have found them quite useful.

Best Regards,
Michael Paesold

Dave Page wrote:

I vote for all (possibly corrected) functions to be moved into core.

You have pg_database_size(oid) and database_size(name). Afaict, the
latter is equivalent to:

SELECT pg_database_size((SELECT oid FROM pg_database WHERE datname =
'foo'))

My main concern is that the names are inconsistent for no obvious
reason. I also questioned whether or not the bloat of an additional
function is worthwhile for what is probably a very small number of psql
users that might use it (probably quite rarely), however if people say
they would use it and that it's wothwhile, I wouldn't argue with it's
inclusion.

Well, this is a good time to figure out exactly what we want in the
backend (perhaps with renaming), and which ones we want to keep in
/contrib, or delete entirely. The point is that we have to discuss this
item by item, _then_ we can look at a patch.

A patch with assumptions is just confusing to me.

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

Dave Page wrote:

The current version of the patch only moves those functions he wants.
Marc says he wants them all moved, and I agree.

OK - did you see Andreas' response to why he hadn't done that (it was
actually posted in response to your original query, not Marcs)? In a
nutshell, the functions that had not been moved returned values that
were easily derived from the other functions, and thus could be
considered bloat?

The functions included in the patch were:

int8 pg_tablespace_size(oid) - Return the size of the tablespace in
bytes
int8 pg_database_size(oid) - Return the size of the database in
bytes
int8 pg_relation_size(oid) - Return the size of the relation in
bytes
text pg_size_pretty(int8) - Pretty-print the byte value

The ones left out were:

int8 database_size(name) - Return the size of the database in
bytes (by name)
int8 relation_size(text) - Return the size of the relation in
bytes (by name)
int8 indexes_size(text) - Return the size of the indexes on the
named relation
int8 total_relation_size(text) - Return relation_size(text) +
indexes_size(text) + relation_size(text->toast tables)
setof record relation_size_components(text) - return a pretty-print set
of values from above.

I don't feel particularly strongly either way, but given the normal
desire not to bloat the backend necessarily, I have to question the need
to include the latter functions.

OK, well, let's talk about what we want done, then someone can work up a
patch. Does someone want to make a proposal here on what to do?

Well, from the May, 2005 discussion URL you posted, I see a
clear reply
to the idea of adding the I/O functions to the backend:

http://archives.postgresql.org/pgsql-hackers/2005-05/msg00874.php

Now, you can agree or disagree that there are issues with the I/O
functions, but the concern was raised in May, and not
addressed at all,
either via email or the patch.

Maybe that's the wrong URL, but all I see there is a vague recollection
from Tom that there were security issues. In the next message, Andreas
recalls how you and he worked out the issues that were raised - I
believe this is the thread
http://archives.postgresql.org/pgsql-hackers/2004-07/msg00793.php.
Mhonarc has made a mess of the thread so it does seem to break in a few
places, and it is possible I've missed part.

The security issue is that we didn't want the backend to be able to
read/write outside of /pgdata, and I think we have that working, except
that I have no idea how it will handle config files outside /pgdata.
Maybe that was in the patch --- I don't know.

I think we need to see a new patch with just the i/o functions so we can
review it. I personally think the I/O functions are a good idea, but I
need to be considerate of others in the community who have concerns.

For the second, please supply a patch that moves _all_ of dbsize into
the main server. I think we have agreement on that.

If that remains the case having seen my comments above echoing Andreas'
concerns then sure, if that's what it takes to get them in, so be it.
Please confirm either way.

Let's discuss what to move/delete/keep in contrib.

-- 
  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: Michael Paesold [mailto:mpaesold@gmx.at]
Sent: 24 June 2005 17:53
To: Dave Page; Andreas Pflug
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Server instrumentation patch

My main concern is that the names are inconsistent for no obvious
reason.

That could be fixed by having:
pg_database_size(name)
pg_database_size(oid)

The original idea was probably to name "internal" functions
with pg_ and
more user friendly ones without pg_. That does not mean it's
a good idea.

Yes, agreed - it could be fixed that way easily. If the inclusion of
/all/ functions is for backwards compatibility though, then that change
is somewhat more of a problem.

Well, I don't feel this is really bloat. I have been using
them since the
creation of the contrib module and have found them quite useful.

Fair enough.

Regards, Dave.

Dave Page wrote:

-----Original Message-----
From: Michael Paesold [mailto:mpaesold@gmx.at]
Sent: 24 June 2005 17:53
To: Dave Page; Andreas Pflug
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Server instrumentation patch

My main concern is that the names are inconsistent for no obvious
reason.

That could be fixed by having:
pg_database_size(name)
pg_database_size(oid)

The original idea was probably to name "internal" functions
with pg_ and
more user friendly ones without pg_. That does not mean it's
a good idea.

Yes, agreed - it could be fixed that way easily. If the inclusion of
/all/ functions is for backwards compatibility though, then that change
is somewhat more of a problem.

We are moving the functions into the backend so if we are going to make
them more consistent, now is the time. People are already going to not
have to load them from /contrib, so a more consistent API change is fine
at this stage --- it will be much harder later.

-- 
  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: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: 24 June 2005 18:47
To: Dave Page
Cc: PostgreSQL-development; Andreas Pflug
Subject: Re: [HACKERS] Server instrumentation patch

The security issue is that we didn't want the backend to be able to
read/write outside of /pgdata, and I think we have that
working, except

Andreas does indeed appear to be checking to ensure that only files
under $PGDATA can be accessed, by disallowing any paths containing '..'.

that I have no idea how it will handle config files outside /pgdata.
Maybe that was in the patch --- I don't know.

My reading of the code is that it should work OK if they are symlinked
from other locations of course, however if hba_file or ident_file are
set to locations outside $PGDATA, then that will not work. The log
directory can be accessed if it is outside $PGDATA.

I'm sure Andreas can confirm this.

I think we need to see a new patch with just the i/o
functions so we can
review it.

Andreas, can you (re)post this please?

I personally think the I/O functions are a good
idea, but I
need to be considerate of others in the community who have concerns.

Of course. I know we're pushing hard to get these included, but it's not
to try to force in a sub-standard solution, it just seems to us like
we're revisiting issues that we thought were resolved.

We'll get there in the end :-)

/D

Bruce Momjian wrote:

Andrew Dunstan wrote:

There is also the tiny patch to trap lexical warnings I submitted not
long ago still outstanding.

OK, I missed that one. I see it at:

http://archives.postgresql.org/pgsql-patches/2005-06/msg00280.php

I applied the attached patch from the following URL. The URL does not
have separate file names for the regression tests so I did not add
those.

Thanks.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

Bruce Momjian wrote:

Andrew Dunstan wrote:

There is also the tiny patch to trap lexical warnings I submitted not
long ago still outstanding.

OK, I missed that one. I see it at:

http://archives.postgresql.org/pgsql-patches/2005-06/msg00280.php

I applied the attached patch from the following URL. The URL does not
have separate file names for the regression tests so I did not add
those.

Never mind, I found the right patch. Will add regressions.

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