Re: Magnus Hagander 2017-04-06 <CABUevEzkTLFSFZvCVsk07oEVgSZmWo9kPaGiJtrONYjQrH5PLw@xxxxxxxxxxxxxx> > On Thu, Apr 6, 2017 at 3:46 PM, Stephen Frost <sfrost@xxxxxxxxxxx> wrote: > > > * Tom Lane (tgl@xxxxxxxxxxxxx) 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. https://anonscm.debian.org/cgit/pkg-postgresql/postgresql.git/tree/debian/patches/51-default-sockets-in-var.patch?h=10 > 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.GT9812@xxxxxxxxxxxxxxxxxxx> > 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. https://anonscm.debian.org/cgit/pkg-postgresql/postgresql.git/tree/debian/patches/50-per-version-dirs.patch?h=10 > 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. https://anonscm.debian.org/cgit/pkg-postgresql/postgresql.git/tree/debian/patches/54-debian-alternatives-for-external-tools.patch?h=10 > 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. https://anonscm.debian.org/cgit/pkg-postgresql/postgresql.git/tree/debian/patches/64-pg_upgrade-sockdir?h=10 > 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 https://anonscm.debian.org/cgit/pkg-postgresql/postgresql.git/tree/debian/patches/filter-debug-prefix-map?h=10 > 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
