[Pkg-postgresql-public] Bug#887940: Bug#887940: libpq-dev: changed version format in pg_config causes other packages to FTBFS

On 1/21/18 16:07, Adrian Bunk wrote: > Package: libpq-dev > Version: 10.1-3 > Severity: serious > Control: affects -1 src:libpreludedb > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libpreludedb.html > > ... > checking for ... checking for pg_config... /usr/bin/pg_config >

[Pkg-postgresql-public] Bug#865020: Bug#865020: postgresql-9.6: FTBFS with Perl 5.26: hstore_plperlu differences

On 6/18/17 15:15, Niko Tyni wrote: > Package: postgresql-9.6 > Version: 9.6.3-3 > Severity: important > User: debian-p...@lists.debian.org > Usertags: perl-5.26-transition > > This package fails to build with Perl 5.26 (currently in experimental.) This will be fixed in upstream 9.6.4, expected in

Re: [Pkg-postgresql-public] Wheezy update of postgresql-9.1?

On 5/21/17 08:10, Ola Lundqvist wrote: > The Debian LTS team would like to fix the security issues which are > currently open in the Wheezy version of postgresql-9.1: > https://security-tracker.debian.org/tracker/CVE-2017-7484 This issue cannot be backported to postgresql-9.1 (because 9.1 does not

[Pkg-postgresql-public] move some programs from contrib

of using an old version of pgbench. Comments? >From 9550aa33b95e9a0a42d09cf8502f91b11bd89f81 Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Tue, 9 Aug 2016 22:54:23 + Subject: [PATCH] Move some programs from contrib to server and client packages, reflecting upstream chan

[Pkg-postgresql-public] Bug#255208: Bug#255208: obsolete?

On 8/8/16 10:46 AM, Christoph Berg wrote: >> I haven't tested this in detail for local socket connections, but for >> TCP/IP, the backend carries on if the client disappears. The >> server-side TCP keepalive settings are there to control this to some extent. > > I mean... why? If PG receives SIGP

[Pkg-postgresql-public] Bug#255208: obsolete?

Since PostgreSQL 9.2, an unprivileged user can cancel their own queries using pg_cancel_backend(). So I think the original reason behind this complaint is obsolete. I propose to close this bug. ___ Pkg-postgresql-public mailing list Pkg-postgresql-publ

[Pkg-postgresql-public] Bug#795984: Bug#795984: postgresql-plproxy: please make the build reproducible

On 8/23/15 2:48 PM, Jérémy Bobbio wrote: > Hi Peter, > > Peter Eisentraut: >> On 8/18/15 9:15 AM, Dhole wrote: >>> The attached patch sets the timezone to UTC before calling asciidoc to >>> avoid timezone differences in the generated docs. Once applied, &g

[Pkg-postgresql-public] Bug#795984: Bug#795984: postgresql-plproxy: please make the build reproducible

On 8/18/15 9:15 AM, Dhole wrote: > The attached patch sets the timezone to UTC before calling asciidoc to > avoid timezone differences in the generated docs. Once applied, > postgresql-plproxy can be built reproducibly in our current experimental > framework. Stupid question: Couldn't dpkg-buildpa

[Pkg-postgresql-public] Bug#787468: Bug#787468: postgresql-9.4: FTBFS with perl 5.22 (test failures)

On 8/20/15 6:10 AM, Dominic Hargreaves wrote: > On Sat, Jun 06, 2015 at 09:05:54PM -0400, Peter Eisentraut wrote: >> Upstream will come up with a fix for this pretty soon, at which time we >> could either incorporate the patch or wait for the next minor releases. > > Hi, >

[Pkg-postgresql-public] Bug#794103: please support cross compilation using libpq-dev as a build-dependency

On 7/30/15 10:31 AM, Helmut Grohne wrote: > * Do not use pg_config at all. Use pkg-config instead. >+ pkg-config nicely supports cross compilation (for autotools based > projects) out of the box (assuming that #759556 gets fixed). >- pkg-config does not work for Windows and thus does

[Pkg-postgresql-public] Bug#787468: Bug#787468: postgresql-9.4: FTBFS with perl 5.22 (test failures)

Upstream will come up with a fix for this pretty soon, at which time we could either incorporate the patch or wait for the next minor releases. ___ Pkg-postgresql-public mailing list Pkg-postgresql-public@lists.alioth.debian.org http://lists.alioth.debia

[Pkg-postgresql-public] Bug#777623: pg_wrapper can fail before picking latest version

Package: postgresql-client-common pg_wrapper is supposed to pick the latest version of psql and other tools, but it can fail with Error: No existing local cluster is suitable as a default target. Please see man pg_wrapper(1) how to specify one. before it gets to that point. This will happen if

[Pkg-postgresql-public] Bug#750163: postgresql-plproxy: Conflicting declarations of function plproxy_yy_scan_bytes to cause undefined behaviour

The flex documentation has Function: YY_BUFFER_STATE yy_scan_bytes ( const char *bytes, int len) which is what plproxy abides by. The actual flex implementation uses yy_size_t, which is really size_t. Reported upstream as . Ideally, flex --header-f

[Pkg-postgresql-public] Bug#772202: pg_upgradecluster should not restrict upgrading tablespaces

Package: postgresql-common pg_upgradecluster --method=dump refuses to upgrade tablespaces because of bug #523574, but that check is no longer necessary as of PostgreSQL 9.0, because tablespaces can be upgraded in place (postgresql commit 22817041). ___

[Pkg-postgresql-public] Bug#764705: Bug#764705: Bug#764705: Bug#764705: Bug#764705: Bug#764705: postgresql-9.4: ERROR: The database format changed between beta 2 and 3. Please dump, but how?

On 10/13/14 11:35 AM, Christoph Berg wrote: > Yeah, though it was pretty unexpected that there was another catalog > version bump after beta2 :-(. Possibly, but it's not unheard of. There could also be other issues such as WAL format changes or extension ABI changes that could affect the upgrade

[Pkg-postgresql-public] Bug#764705: Bug#764705: Bug#764705: postgresql-9.4: ERROR: The database format changed between beta 2 and 3. Please dump, but how?

On 10/10/14 6:17 PM, Thorsten Glaser wrote: > I’ve read in the archives that you did this > before, in 9.1 times. Please invest some time > into creating a proper fix for this scenario, > one which keeps cluster-wide settings (such > as locale, encoding, etc.) and configuration > files the way they

[Pkg-postgresql-public] test suite problems with pg_stat_tmp

When you run one of the test files manually, e.g., sudo prove -v t/050_encodings.t they now all fail with something like not ok 58 - No files in /var/lib/postgresql left behind not ok 59 - No files in /var/run/postgresql left behind ok 60 - No files in /var/log/postgresql left behind # Expec

[Pkg-postgresql-public] pg_archivecleanup in postgresql-common

Responding to bug #740593, a symlink from pg_archivecleanup to pg_wrapper was added to postgresql-common, but this seems like a mistake to me. pg_archivecleanup is a server-side program and does not respond to any connection parameters, which is what pg_wrapper uses to pick an implementation. (I

[Pkg-postgresql-public] Bug#723503: Bug#723503: postgresql-9.3 link with -L/usr/lib

On Tue, 2013-09-17 at 18:52 +0800, YunQiang Su wrote: > This package has one or more -L/usr/lib in its build system, > which will make it ftbfs if there is libraries under /usr/lib, > while is not the default architecture, mips* for example. The occurrence of -L/usr/lib that is making your build f

[Pkg-postgresql-public] Bug#728599: point pg_isready to latest version

Package: postgresql-common Version: 150 Severity: wishlist pg_isready should always be pointed to the latest version, same as psql is handled now. pg_isready does not depend on the server version. Also, since it is new in 9.3, running it against an older version sometimes gets complaints from pg

[Pkg-postgresql-public] Bug#723847: Bug#723847: Bug#723847: Bug#723847: Bug#723847: postgresql-9.3: server - pg_upgradecluster - initdb: --data-checksums ?

On 10/19/13, 5:35 PM, Karsten Hilbert wrote: > On Sat, Oct 19, 2013 at 02:05:34PM +0200, Christoph Berg wrote: > >> What we could do is to add this as an example (comment) to the default >> version we ship for createcluster.conf. > > I would say that's better than the current situation. > > Also

[Pkg-postgresql-public] Bug#723847: Bug#723847: Bug#723847: postgresql-9.3: server - pg_upgradecluster - initdb: --data-checksums ?

On Sat, 2013-10-12 at 11:09 +0200, Karsten Hilbert wrote: > So, to rephrase the question: I wonder whether --data-checksums > can be pre-set in /etc/postgresql-common/createcluster.conf's > "initdb_options" ? It doesn't matter where you attach the option, the answer is the same: Upstream has decid

[Pkg-postgresql-public] Bug#723847: Bug#723847: postgresql-9.3: server - pg_upgradecluster - initdb: --data-checksums ?

On 9/20/13 8:51 AM, Karsten Hilbert wrote: > Package: postgresql-9.3 > Version: 9.3~rc1-2 > Severity: wishlist > > I wonder whether --data-checksums / -k can be made the default for > creating new clusters starting with PG 9.3. It's an upstream decision, and it's not our place to override that.

[Pkg-postgresql-public] Bug#719282: installing dictionary package restarts postgresql servers

On Mon, 2013-08-12 at 10:53 +0200, Christoph Berg wrote: > It might be smarter just to do nothing with the servers here, or just > invoke "reload", if necessary. (Or at least show a less frightening > output on the console.) I think we could just call exit 0 after pg_updatedicts in postinst. ___

[Pkg-postgresql-public] Bug#719282: installing dictionary package restarts postgresql servers

Package: postgresql-common Version: 147.pgdg70+1 Severity: normal Installing a dictionary package, for example apt-get install hunspell-de-de, ends up restarting all PostgreSQL servers on the machine, because the dictionary trigger calls postinst, which restarts everything because of the way debhe

Re: [Pkg-postgresql-public] Bug#717073: Bug#717073: The libpq-dev package misses some dependencies

On 7/16/13 10:15 AM, Evgeni Golov wrote: > Nope, the real issue is that pg_config is not pkg-config :) > > pg_config --help says > --libsshow LIBS value used when PostgreSQL was built > > So it has nothing in common with pkg-config --libs pq (if that would > exist) which will t

[Pkg-postgresql-public] postgresql-common calling external programs with full path

pg_createcluster calls pg_ctlcluster as '/usr/bin/pg_ctlcluster', whereas pg_dropcluster calls only 'pg_ctlcluster'. On the other hand, pg_dropcluster calls '/bin/rm', but nothing else calls basic system utilities with the full path. I think specifying the full directory is unnecessary and should

[Pkg-postgresql-public] Bug#714725: Bug#714725: Consider setting APT::NeverAutoRemove::"postgresql-*" in apt.conf

On Tue, 2013-07-02 at 15:42 +0200, Christoph Berg wrote: > Re: Peter Eisentraut 2013-07-02 <51d2bd16.6020...@debian.org> > > > 3) would be needed if we decide that we also need to care about > > > extension modules that should not be removed on dist-upgrade. > >

[Pkg-postgresql-public] Bug#714725: Bug#714725: Consider setting APT::NeverAutoRemove::"postgresql-*" in apt.conf

On 7/2/13 4:26 AM, Christoph Berg wrote: > The question now is which package(s) should be marked as > NeverAutoRemove. > > 1) The postgresql-x.y package of the (old)stable release 2) > ^postgresql-[0-9]+-[0-9]$ 3) ^postgresql-.* > > 2) is probably equivalent to 1), as there's only one version in

[Pkg-postgresql-public] Bug#701339: known upstream bug

This issue is discussed here: http://www.postgresql.org/message-id/14242.1365200...@sss.pgh.pa.us Currently, there is no fixed upstream release for the older branches, but 9.2 is OK. So for jessie, the fix is to move to 9.2 or 9.3, and remove 9.1 and whatever may be left of 8.4. For compiling o