On Wed, May 18, 2011 at 3:37 PM, Magnus Hagander mag...@hagander.net wrote:
On Wed, May 18, 2011 at 15:29, Marko Kreen mark...@gmail.com wrote:
On Wed, May 18, 2011 at 2:57 PM, Magnus Hagander mag...@hagander.net wrote:
On Wed, May 18, 2011 at 10:25, Greg Smith g...@2ndquadrant.com wrote:
Some
Greg Smith wrote:
Attached is a second patch to move a number of extensions from
contrib/ to src/test/. Extensions there are built by the default
built target, making installation of the postgresql-XX-contrib package
unnecessary for them to be available.
That was supposed to be contrib/ to
On Wed, May 18, 2011 at 10:25, Greg Smith g...@2ndquadrant.com wrote:
Attached is a second patch to move a number of extensions from contrib/ to
src/test/. Extensions there are built by the default built target, making
installation of the postgresql-XX-contrib package unnecessary for them to
On Wed, May 18, 2011 at 2:57 PM, Magnus Hagander mag...@hagander.net wrote:
On Wed, May 18, 2011 at 10:25, Greg Smith g...@2ndquadrant.com wrote:
Some of my personal discussions of this topic have suggested that some other
popular extensions like pgcrypto and hstore get converted too. I think
On Wed, May 18, 2011 at 15:29, Marko Kreen mark...@gmail.com wrote:
On Wed, May 18, 2011 at 2:57 PM, Magnus Hagander mag...@hagander.net wrote:
On Wed, May 18, 2011 at 10:25, Greg Smith g...@2ndquadrant.com wrote:
Some of my personal discussions of this topic have suggested that some other
Greg Smith wrote:
Any packager who grabs the shared/postgresql/extension directory in
9.1, which I expect to be all of them, shouldn't need any changes to
pick up this adjustment. For example, pgstattuple installs these files:
share/postgresql/extension/pgstattuple--1.0.sql
On Thu, 2011-05-12 at 19:37 -0400, Tom Lane wrote:
It should be okay to move, since the -devel subpackage requires the
main one. Therefore there is no configuration in which pg_config
would be present before and missing after the change.
Thanks Tom. I can make this change in next build
On Sat, 2011-05-07 at 21:47 -0400, Greg Smith wrote:
On 05/06/2011 04:06 PM, Tom Lane wrote:
FWIW, I did move pg_config from -devel to the main (really client)
postgresql package in Fedora, as of 9.0. That will ensure it's
present
in either client or server installations. Eventually that
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= dev...@gunduz.org writes:
I'm not sure that I can move it to main package in 9.0 package set, I
need to make sure that I won't break anything. But it is pretty doable
for 9.1.
It should be okay to move, since the -devel subpackage requires the main
one.
Tom Lane wrote:
Christopher Browne cbbro...@gmail.com writes:
But people are evidently still setting packaging policies based on how
things were back in 7.3, even though that perhaps isn't necessary
anymore.
FWIW, once you get past the client versus server distinction, I think
most
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
here are the sizes of the built RPMs from my last build for Fedora:
-rw-r--r--. 1 tgl tgl 3839458 Apr 18 10:50
postgresql-9.0.4-1.fc13.x86_64.rpm
-rw-r--r--. 1 tgl tgl 490788 Apr 18 10:50
postgresql-contrib-9.0.4-1.fc13.x86_64.rpm
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
here are the sizes of the built RPMs from my last build for Fedora:
-rw-r--r--. 1 tgl tgl 3839458 Apr 18 10:50
postgresql-9.0.4-1.fc13.x86_64.rpm
-rw-r--r--. 1 tgl tgl 490788 Apr 18 10:50
On Sun, May 8, 2011 at 12:02 AM, Greg Smith g...@2ndquadrant.com wrote:
Attached patch is a first cut at what moving one contrib module (in this
case pg_buffercache) to a new directory structure might look like. The idea
is that src/extension could become a place for first-class extensions to
On Mon, May 9, 2011 at 1:14 PM, Greg Smith g...@2ndquadrant.com wrote:
On 05/09/2011 10:53 AM, Robert Haas wrote:
I would really like to see us try to group things by topic, and not
just by whether or not we can all agree that the extension is
important enough to be first-class (which is
Excerpts from Robert Haas's message of lun may 09 14:31:33 -0400 2011:
I'm happy enough with that set of guidelines: namely, that we'd use
src/extension only for things that don't require additional
dependencies, and not for things that build standalone executables.
If we're going to move
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Robert Haas's message of lun may 09 14:31:33 -0400 2011:
I'm happy enough with that set of guidelines: namely, that we'd use
src/extension only for things that don't require additional
dependencies, and not for things that build
Tom Lane t...@sss.pgh.pa.us writes:
Sure, but that's a documentation issue, which again is not going to be
helped by a source-tree rearrangement.
So we have several problem to solve here, and I agree that source code
rearrangement is fixing none of them. Maybe it would ease maintaining
down
On 05/09/2011 03:31 PM, Alvaro Herrera wrote:
For executables we already have src/bin. Do we really need a separate
place for, say, pg_standby or pg_upgrade?
There's really no executables in contrib that I find myself regularly
desperate for/angry at because they're not installed as an
On 05/09/2011 02:31 PM, Robert Haas wrote:
I don't think we should be too obstinate about trying to twist the arm
of packagers who (as Tom points out) will do whatever they want in
spite of us, but the current state of contrib, with all sorts of
things of varying type, complexity, and value
On lör, 2011-05-07 at 17:38 -0400, Andrew Dunstan wrote:
On 05/07/2011 05:26 PM, Peter Eisentraut wrote:
On lör, 2011-05-07 at 17:16 -0400, Andrew Dunstan wrote:
pg_config is useful quite apart from its use in building things, as was
discussed upthread.
Link please.
On 05/08/2011 05:24 AM, Peter Eisentraut wrote:
On lör, 2011-05-07 at 17:38 -0400, Andrew Dunstan wrote:
On 05/07/2011 05:26 PM, Peter Eisentraut wrote:
On lör, 2011-05-07 at 17:16 -0400, Andrew Dunstan wrote:
pg_config is useful quite apart from its use in building things, as was
discussed
On sön, 2011-05-08 at 07:21 -0400, Andrew Dunstan wrote:
As I said there: to see how the libraries are configured, for example.
Just the other day I wanted to know what compilation options had been
used for a particular installation. pg_config wasn't installed because
the -devel package
My example is of doing self-discovery to see if all needful database
components seem to be properly installed.
E.g. - the app needs pgcrypto, intarray, and a custom data type. The
install script can consequently inform the production folk either looks
good, or, alternately, seems problematic!
Christopher Browne cbbro...@gmail.com writes:
I don't expect the extension system to help with any of this, since if
production folk try to install minimal sets of packages, they're
liable to consciously exclude extension support. The improvement
would come from drawing contrib a bit closer
On Sat, May 7, 2011 at 8:54 AM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
We've been talking about renaming contrib for a long time, but that will
not cut it. Classifying it and agreeing to maintain some parts of it
the same way we maintain the core is what's asked here. Is there a will
On Fri, 06 May 2011 20:06:04 -, Tom Lane t...@sss.pgh.pa.us wrote:
Bundling pg_config into a -libs package is probably not going to happen,
at least not on Red Hat systems, because it would create multilib issues
(ie, you're supposed to be able to install 32-bit and 64-bit libraries
Greg Stark gsst...@mit.edu writes:
On Fri, May 6, 2011 at 11:32 PM, Greg Smith g...@2ndquadrant.com wrote:
I use pgstattuple, pageinspect, pg_freespacemap, and pg_buffercache
regularly enough that I wish they were more common. Throw in pgrowlocks and
you've got the whole group Robert put into
On fre, 2011-05-06 at 14:32 -0400, Greg Smith wrote:
Given the other improvements in being able to build extensions in 9.1,
we really should push packagers to move pg_config from the PostgreSQL
development package into the main one starting in that version. I've
gotten bit by this plenty of
Em 07-05-2011 13:42, Peter Eisentraut escreveu:
Do you need pg_config to install extensions?
No. But we need it to build other extensions.
--
Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
--
Sent
On lör, 2011-05-07 at 17:35 -0300, Euler Taveira de Oliveira wrote:
Em 07-05-2011 13:42, Peter Eisentraut escreveu:
Do you need pg_config to install extensions?
No. But we need it to build other extensions.
But for that you need the -dev[el] package anyway, so there would be no
point in
On 05/07/2011 12:42 PM, Peter Eisentraut wrote:
On fre, 2011-05-06 at 14:32 -0400, Greg Smith wrote:
Given the other improvements in being able to build extensions in 9.1,
we really should push packagers to move pg_config from the PostgreSQL
development package into the main one starting in
On 05/07/2011 04:43 PM, Peter Eisentraut wrote:
On lör, 2011-05-07 at 17:35 -0300, Euler Taveira de Oliveira wrote:
Em 07-05-2011 13:42, Peter Eisentraut escreveu:
Do you need pg_config to install extensions?
No. But we need it to build other extensions.
But for that you need the -dev[el]
On lör, 2011-05-07 at 17:16 -0400, Andrew Dunstan wrote:
pg_config is useful quite apart from its use in building things, as was
discussed upthread.
Link please.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On lör, 2011-05-07 at 17:06 -0400, Greg Smith wrote:
The repmgr program we distribute has the same problem, so I've been
getting first-hand reports of just how many people are likely to run
into this recently. You have to install postgresql-devel with RPM and
on Debian, the very non-obvious
On 05/07/2011 05:26 PM, Peter Eisentraut wrote:
On lör, 2011-05-07 at 17:16 -0400, Andrew Dunstan wrote:
pg_config is useful quite apart from its use in building things, as was
discussed upthread.
Link please.
http://archives.postgresql.org/pgsql-hackers/2011-05/msg00275.php
cheers
On 05/06/2011 04:06 PM, Tom Lane wrote:
FWIW, I did move pg_config from -devel to the main (really client)
postgresql package in Fedora, as of 9.0. That will ensure it's present
in either client or server installations. Eventually that packaging
will reach RHEL ...
We should make sure
Attached patch is a first cut at what moving one contrib module (in this
case pg_buffercache) to a new directory structure might look like. The
idea is that src/extension could become a place for first-class
extensions to live. Those are ones community is committed to providing
in core, but
On Fri, May 6, 2011 at 00:34, Josh Berkus josh.ber...@pgexperts.com wrote:
Hackers,
I've run into a couple of occasions lately where I really wanted
pgstattuple on a production server in order to check table/index bloat.
However, in the production environment at a large site installing a
Em 06-05-2011 05:06, Magnus Hagander escreveu:
On Fri, May 6, 2011 at 00:34, Josh Berkusjosh.ber...@pgexperts.com wrote:
Hackers,
I've run into a couple of occasions lately where I really wanted
pgstattuple on a production server in order to check table/index bloat.
However, in the
On Fri, May 6, 2011 at 18:22, Euler Taveira de Oliveira
eu...@timbira.com wrote:
Em 06-05-2011 05:06, Magnus Hagander escreveu:
On Fri, May 6, 2011 at 00:34, Josh Berkusjosh.ber...@pgexperts.com
wrote:
Hackers,
I've run into a couple of occasions lately where I really wanted
pgstattuple
On Fri, May 6, 2011 at 1:32 PM, Magnus Hagander mag...@hagander.net wrote:
On Fri, May 6, 2011 at 18:22, Euler Taveira de Oliveira
eu...@timbira.com wrote:
Em 06-05-2011 05:06, Magnus Hagander escreveu:
On Fri, May 6, 2011 at 00:34, Josh Berkusjosh.ber...@pgexperts.com
wrote:
Hackers,
On 05/06/2011 01:55 PM, Christopher Browne wrote:
Once we got AIX running a buildfarm node, that led to getting *ALL* of
contrib working there, and I'm pretty sure that similar happened with
other platforms at around the same time (I'm thinking this was 7.4,
but it might have been 8.0)
FYI,
Em 06-05-2011 14:55, Christopher Browne escreveu:
The improvement
would come from drawing contrib a bit closer to core, and encouraging
packagers (dpkg, rpm, ports) to fold contrib into base rather than
separating it. I'm sure that would get some pushback, though.
I'm in favor of find out
Christopher Browne wrote:
I'm getting paper cuts quite a bit these days over the differences
between what different packaging systems decide to install. The one
*I* get notably bit on, of late, is that I have written code that
expects to have pg_config to do some degree of self-discovery, only
On Fri, May 6, 2011 at 2:32 PM, Greg Smith g...@2ndquadrant.com wrote:
Christopher Browne wrote:
I'm getting paper cuts quite a bit these days over the differences
between what different packaging systems decide to install. The one
*I* get notably bit on, of late, is that I have written code
On 05/06/2011 03:14 PM, Christopher Browne wrote:
On Fri, May 6, 2011 at 2:32 PM, Greg Smithg...@2ndquadrant.com wrote:
Christopher Browne wrote:
I'm getting paper cuts quite a bit these days over the differences
between what different packaging systems decide to install. The one
*I* get
On Fri, May 6, 2011 at 21:19, Andrew Dunstan and...@dunslane.net wrote:
On 05/06/2011 03:14 PM, Christopher Browne wrote:
On Fri, May 6, 2011 at 2:32 PM, Greg Smithg...@2ndquadrant.com wrote:
Christopher Browne wrote:
I'm getting paper cuts quite a bit these days over the differences
Magnus Hagander mag...@hagander.net writes:
On Fri, May 6, 2011 at 21:19, Andrew Dunstan and...@dunslane.net wrote:
On 05/06/2011 03:14 PM, Christopher Browne wrote:
If there's a server package and a client package, it likely only
fits with the server package. On a host where only the client
On 05/06/2011 04:06 PM, Tom Lane wrote:
Magnus Hagandermag...@hagander.net writes:
On Fri, May 6, 2011 at 21:19, Andrew Dunstanand...@dunslane.net wrote:
On 05/06/2011 03:14 PM, Christopher Browne wrote:
If there's a server package and a client package, it likely only
fits with the server
Christopher Browne cbbro...@gmail.com writes:
But people are evidently still setting packaging policies based on how
things were back in 7.3, even though that perhaps isn't necessary
anymore.
FWIW, once you get past the client versus server distinction, I think
most subpackaging decisions are
All,
We might get somewhere by trying to identify a small set of particularly
popular contrib modules that don't add any extra dependencies, and then
recommending to packagers that those ones get bundled into the main
server package.
Yeah, I wasn't thinking of including all of contrib.
On Fri, May 6, 2011 at 5:58 PM, Josh Berkus j...@agliodbs.com wrote:
Yeah, I wasn't thinking of including all of contrib. There's a lot of
reasons not to do that.
Slightly off-topic, but I really think we would benefit from trying to
divide up contrib. Right now it's a mixture of (a)
On 05/06/2011 05:58 PM, Josh Berkus wrote:
Yeah, I wasn't thinking of including all of contrib. There's a lot of
reasons not to do that. I was asking about pgstattuple in particular,
since it's:
(a) small
(b) has no external dependancies
(c) adds no stability risk or performance overhead
(d) is
Robert Haas robertmh...@gmail.com writes:
On Fri, May 6, 2011 at 5:58 PM, Josh Berkus j...@agliodbs.com wrote:
Yeah, I wasn't thinking of including all of contrib. There's a lot of
reasons not to do that.
Slightly off-topic, but I really think we would benefit from trying to
divide up
On 5/6/11 3:19 PM, Robert Haas wrote:
Slightly off-topic, but I really think we would benefit from trying to
divide up contrib.
I don't agree, unless by divide up you mean move several things to
extensions.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via
These are the only ones I'd care about moving into a more likely place.
The rest of the contrib modules are the sort where if you need them, you
realize that early and get them installed. These are different by
virtue of their need popping up most often during emergencies. The fact
that I
On Fri, May 6, 2011 at 11:32 PM, Greg Smith g...@2ndquadrant.com wrote:
I use pgstattuple, pageinspect, pg_freespacemap, and pg_buffercache
regularly enough that I wish they were more common. Throw in pgrowlocks and
you've got the whole group Robert put into the debug set. It makes me sad
On Fri, May 6, 2011 at 6:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
As a packager, what I'd really want to see from a division into
recommended and not-so-recommended packages is that they get installed
into different subdirectories by make install. Then I could just
point RPM at those
Robert Haas robertmh...@gmail.com writes:
On Fri, May 6, 2011 at 6:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
As a packager, what I'd really want to see from a division into
recommended and not-so-recommended packages is that they get installed
into different subdirectories by make install.
On Fri, May 6, 2011 at 9:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, May 6, 2011 at 6:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
As a packager, what I'd really want to see from a division into
recommended and not-so-recommended packages is that
60 matches
Mail list logo
