From: | Christoph Berg <myon(at)debian(dot)org> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net>, Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, rob stone <floriparob(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: A change in the Debian install |
Date: | 2017-04-07 13:38:23 |
Message-ID: | 20170407133823.i2pahcfqxyjlsanf@msg.df7cb.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Re: Magnus Hagander 2017-04-06 <CABUevEzkTLFSFZvCVsk07oEVgSZmWo9kPaGiJtrONYjQrH5PLw(at)mail(dot)gmail(dot)com>
> On Thu, Apr 6, 2017 at 3:46 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>
> > * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> > > (But ... these statements are based on an assumption of out-of-the-
> > > box Postgres behavior. I would not exactly put it past the Debian
> > > packagers to have decided to change this for reasons of their own,
> > > and their track record of telling us about such decisions is many
> > > miles south of abysmal. So you might look at whatever patches
> > > are in the Debian package to see if there's anything touching
> > > pgstat.c's socket-setup logic.)
> >
> > I don't believe this is really a fair assessment. Maybe at some point
> > in the distant past, but not today. Christoph is regularly on this list
> > contributing to threads regarding packaging, submitting patches of his
> > own for improvements to PG, and the patches currently included in the
> > Debian distribution, at least mostly, are for things which really should
> > be possible to do with configure options, but which we don't provide
> > today, or things we should just be handling already.
> >
>
> +1. While this may have been true in a *very* distant past, it's certainly
> not anymore. So let's try to avoid spreading disinformation about that.
>
> And FWIW, the RPM distributions have about the same number of patches...
Thanks Stephen and Magnus. I don't think the way Martin and I have
been handling the Debian packages over the last year deserves being
bashed that loudly. At least I would expect a Cc on such matters, Tom
should know very well whom to address here.
> > 51-default-sockets-in-var.patch
> > Use /var/run/postgresql/ for the DEFAULT_PGSOCKET_DIR. We really
> > should allow this to be changed in configure.
>
> This looks exactly like something the RPMs want as well, so we should
> definitely look at providing that upstream.
That one is touching src/include/pg_config_manual.h only, i.e.
something that is actually meant to be altered.
> I'll start a discussion with Christoph on if we might, already, be able
> > to remove some of these, and where we might be able to make upstream
> > changes to remove the need for others.
>
> That'd be useful. I think you should also include Devrim to figure out what
> things would actually make *both* sides happier.
Aye.
Re: Stephen Frost 2017-04-06 <20170406134629(dot)GT9812(at)tamriel(dot)snowman(dot)net>
> The non-comment/documentation patches include for the Debian PG 9.6
> packages are:
>
> 50-per-version-dirs.patch
> Use version specific installation directories so that several major
> versions can be installed in parallel. This includes changing
> pkglibdir and includedir_server. Those might be able to be set
> through existing configure flags and that's probably something we
> could work with Christoph to do.
Nod. If someone figures how to translate that to configure (or
possibly make) arguments, I'd be happy to move to using that.
> There's also a change to pg_config
> which might be a bit more difficult to handle in upstream (related to
> how pg_config ends up in /usr/bin, but that isn't the "right" BINDIR).
pg_config is special there, because we ship it twice, once in
/usr/bin/ libpq-dev, and then again in
/usr/lib/postgresql/$version/bin/ from postgresql-server-dev-version.
Not sure if there's a saner approach that still allows co-installation
of multiple versions, while still supplying a pg_config from libpq-dev
that allows using --includedir and other version-independent queries.
> 54-debian-alternatives-for-external-tools.patch
> Use 'sensible-editor' for DEFAULT_EDITOR, and 'pager' for
> DEFAULT_PAGER. These could also be done through configure switches, I
> would think.
> 64-pg_upgrade-sockdir
> This is a bit of a curious one, the description is:
> Fix for: connection to database failed: Unix-domain socket path
> "/build/buildd-postgresql-9.3_9.3~beta1-1-i386-mHjRUH/postgresql-9.3-9.3~beta1/build/contrib/pg_upgrade/.s.PGSQL.50432"
> is too long (maximum 107 bytes)
>
> See also: http://lists.debian.org/debian-wb-team/2013/05/msg00015.html
>
> This basically adds a mechanism to fall back to using /tmp if the
> socket path is too long. Would probably be good to figure out a
> better way.
That one is actually on my TODO list:
https://www.postgresql.org/message-id/20140711094009.GB3115%40msg.df7cb.de
I'll need to restart working on it.
> filter-debug-prefix-map
> Description: Remove -fdebug-prefix-map=/p/w/d=. from CFLAGS and
> CONFIGURE in pg_config. The embedded path makes the build
> non-reproducible, and the flag is useless for building extensions
> anyway.
> Not sure there's much we can do about this one, but it's also just for
> pg_config.
I hope to be able to drop this one again. There is a patch for gcc in
preparation that will allow using a constant -fdebug-prefix-map=
compile flag that doesn't embed the current build directory:
https://tests.reproducible-builds.org/debian/issues/unstable/captures_build_path_issue.html
> hurd-sem_init
> Adds -pthread to LIBS and forces POSIX semaphores on hurd. I'm not
> sure if this is all still required, but if so, it'd probably be ideal
> if we could figure out a way to handle it automatically instead of
> making the Debian packagers have to do it.
This one is already gone again for the 10 packaging. The 9.6 version
is:
https://anonscm.debian.org/cgit/pkg-postgresql/postgresql.git/tree/debian/patches/hurd-sem_init
> In short, there's certainly nothing that touches pgstat.c's socket-setup
> logic and almost all of the changes are just changes to #define's to
> specify alternative paths or external tools.
I don't have an answer the OP's question. My bet would be on
"localhost" resolving to something weird.
Christoph
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2017-04-07 13:57:37 | Re: keeping WAL after dropping replication slots |
Previous Message | Günce Kaya | 2017-04-07 07:11:54 | Re: calculating table and index size |