[HACKERS] OpenSSL 1.1 breaks configure and more

Hi, as reported by Debian's OpenSSL maintainers, PostgreSQL is failing to build against a snapshot of the upcoming 1.1.0 version. The report was for 9.5.3, but I can reproduce it in HEAD as well: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828510 > OpenSSL 1.1.0 is about to released. Durin

Re: [HACKERS] Login into PostgreSQL without password

Re: Murtuza Zabuawala 2016-05-26 > Hi, > > I have created a role using below sql, then I disconnected & try to login > into postgres db with newly created user "test_role", It prompt for > password and I pressed Enter key because I did not provided any password > when I created role so it throw

Re: [HACKERS] LSN as a recovery target

Re: Michael Paquier 2016-05-24 > Yeah, that's really something that covers only a narrow case, though > if we don't have it when we need it we're limited to some hacks. > Perhaps people who have the advanced level to use such a thing have > the level to use hacks anyway.. I'd think recovery_targ

Re: [HACKERS] 10.0

Re: Álvaro Hernández Tortosa 2016-05-14 <5736f966.3040...@8kdata.com> > Having said that, I believe having a single major number is a more > effective marketing. Non major-major versions may make the release look like > a "probably not worth" upgrade. People may hold their breath until a > majo

Re: [HACKERS] Rename max_parallel_degree?

Re: Robert Haas 2016-05-02 > max_parallel_degree -> max_parallel_workers > parallel_degree -> parallel_workers > > I would prefer to keep it as "degree". It's a reasonable term of art, > and it also improves grep-ability. But I'm willing to go do the above > renaming if there is a clear consen

Re: [HACKERS] relocation truncated to fit: citus build failure on s390x

Re: To Andres Freund 2016-04-28 <20160428080824.ga22...@msg.df7cb.de> > I'm not an expert in compiler flags, but it seems to me CFLAGS_SL is > wrong on s390(x) in Makefile.port, it should use -fPIC like sparc. > > (The m68k build has yet to happen, I'd guess it would exhibit the same > problem.)

[HACKERS] relocation truncated to fit: citus build failure on s390x

[Cc'ing -hackers] I said: > That said, there's a build failure on s390x: > > https://buildd.debian.org/status/fetch.php?pkg=citus&arch=s390x&ver=5.0.1-1&stamp=1461670278 > > gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement > -Wendif-labels -Wmissing-format-attribute

Re: [HACKERS] \crosstabview fixes

Re: Daniel Verite 2016-04-14 > I don't quite see how to work around that, short of simply > removing the possibility of addressing columns by their > numbers. Which maybe is a bit sad for the end user, I'm not > sure, but ISTM that's a logical consequence of abandoning > the dedicated parser for c

Re: [HACKERS] \crosstabview fixes

Re: Tom Lane 2016-04-14 <15673.1460592...@sss.pgh.pa.us> > Here's a patch along those lines. Any objections? > \crosstabview [ > colV > ! [ colH > ! [ colD > ! [ scolH > ! ] ] ] ] Maybe use "sortcolH" to make it immediately

Re: [HACKERS] [patch] \crosstabview documentation

Re: Tom Lane 2016-04-13 <1854.1460562...@sss.pgh.pa.us> > Hm, we do not have entries attached to any other psql > meta-commands. Maybe they all should have one, or maybe not, but > I'm unconvinced about adding one for just this command. What I did > instead was to make a link target (which there

Re: [HACKERS] [patch] \crosstabview documentation

Re: To PostgreSQL Hackers 2016-04-13 <20160413092312.ga21...@msg.df7cb.de> > Re: Alvaro Herrera 2016-04-09 <20160408232553.GA721890@alvherre.pgsql> > > It's useful, no doubt. > > It's cool :) > > > I pushed it. > > Here's a small doc patch that removes the bogus space in "colH [:scolH]" > (other

[HACKERS] [patch] \crosstabview documentation

Re: Alvaro Herrera 2016-04-09 <20160408232553.GA721890@alvherre.pgsql> > It's useful, no doubt. It's cool :) > I pushed it. Here's a small doc patch that removes the bogus space in "colH [:scolH]" (otherwise psql complains that it is ignoring the 4th parameter. It also adds an index entry and a

[HACKERS] pg_upgrade 9.6->9.6: column "amtype" does not exist

Hi, I'm not sure this is a bug, but before it bites back too late, I'm reporting it now. On pg_upgrading my catversion 201603111 9.6 cluster to 201603301, I got the following error: - pg_upgrade run on Fri Apr 1 22:50:07 2016 ---

[HACKERS] pg_filedump 9.5.0

Re: To Pavel Raiskup 2016-03-19 <20160319170614.gb8...@msg.df7cb.de> > thanks for the patches, I've pushed them to the git repo. > > http://git.postgresql.org/gitweb/?p=pg_filedump.git We don't have any place to put releases, so I'm posting the tar ball here... Christoph pg_filedump-9.5.0.tar.

Re: [HACKERS] pg_filedump patch for 9.5

Re: Pavel Raiskup 2016-02-26 <8883822.6jzmttx...@nb.usersys.redhat.com> > On Saturday 08 of August 2015 20:38:38 Satoshi Nagayasu wrote: > > I have created a patch for pg_filedump to work with 9.5. > > Here is a list of changes. > > > > * Fix to rename CRC32 macros to work with 9.5. > > * Fix to

Re: [HACKERS] Relaxing SSL key permission checks

Re: Peter Eisentraut 2016-03-16 <56e8c221.1050...@gmx.net> > >> * it failed to check for S_IXUSR, so permissions 0700 were okay, in > >> contradiction with what the error message indicates. This is a > >> preexisting bug actually. Do we want to fix it by preventing a > >> user-executable file (po

Re: [HACKERS] Relaxing SSL key permission checks

Re: Alvaro Herrera 2016-03-04 <20160304205521.GA735336@alvherre.pgsql> > For the sake of cleanliness, I propose splitting out the checks for > regular file and for owned-by-root-or-us from the actual chmod-level > checks at the same time. That way we can provide more specific error > messages for

Re: [HACKERS] Relaxing SSL key permission checks

Re: Tom Lane 2016-02-22 <21507.1456099...@sss.pgh.pa.us> > Stephen Frost writes: > > Just to be clear, I'm not really against this patch as-is, but it > > shouldn't be a precedent or limit us from supporting more permissive > > permissions in other areas (or even here) if there are sensible > > us

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

Re: David Fetter 2016-01-26 <20160126180011.ga16...@fetter.org> > +1 for back-patching. There's literally no case where an infinite > input could be correct as the start or end of an interval for > generate_series. select * from generate_series(now(), 'infinity', '1 day') limit 10; ... seems pre

Re: [HACKERS] Relaxing SSL key permission checks

Re: To Tom Lane 2016-02-19 <20160219115334.gb26...@msg.df7cb.de> > Updated patch attached. *Blush* I though I had compile-tested the patch, but without --enable-openssl it wasn't built :(. The attached patch has successfully been included in the 9.6 Debian package, passed the regression tests the

Re: [HACKERS] Relaxing SSL key permission checks

Re: Tom Lane 2016-02-18 <27423.1455809...@sss.pgh.pa.us> > I did have a thought though: could we allow two distinct permissions > configurations? That is, allow either: > > * file is owned by us, mode 0600 or less > > * file is owned by root, mode 0640 or less > > The first case is what we allo

[HACKERS] Relaxing SSL key permission checks

Hi, Currently the server insists on ssl_key_file's permissions to be 0600 or less, and be owned by the database user. Debian has been patching be-secure.c since forever (the git history goes back to 8.2beta1) to relax that to 0640 or less, and owned by root or the database user. The reason for th

Re: [HACKERS] [PATCH] better systemd integration

Hi Peter, thanks for working on this, I'm looking forward to make Debian's pg_*cluster tools work with that (and hopefully be able to remove tons of legacy code). If a cluster is configured for non-hot-standby replication, the READY=1 seems to never happen. Did you check if that doesn't trigger a

Re: [HACKERS] Building pg_xlogdump reproducibly

perl/Makefile |2 !! contrib/hstore_plpython/Makefile |4 contrib/ltree_plpython/Makefile |4 src/bin/pg_xlogdump/Makefile |2 !! 4 files changed, 12 modifications(!) Mit freundlichen Grüßen, Christoph Berg -- Senior Berater, Tel.: +49 (0)21 61 / 46 43-187 c

Re: [HACKERS] Building pg_xlogdump reproducibly

Re: Andres Freund 2016-01-04 <20160104155125.gd28...@awork2.anarazel.de> > That's probably not the only non-deterministic rule in postgres, given > nobody paid attention tot that so far? At least transform modules added > in 9.5 (hstore_plpython et al) look like they might similar issues. I was wo

[HACKERS] Building pg_xlogdump reproducibly

The list of objects used to link pg_xlogdump is coming from $(wildcard *desc.c) which returns them in filesystem order. This makes the build result depend on this ordering, yielding different compilation results. This patch fixes the reproducibility issue: --- a/src/bin/pg_xlogdump/Makefile +++ b

Re: [HACKERS] 9.3.9 and pg_multixact corruption

Re: Andreas Seltenreich 2015-09-13 <87si6i1875@credativ.de> > I managed disassemble RecordNewMultiXact from the core dump using a > cross-binutils, and it reveals that the compiler[1] appears to have > indeed generated a signed division here. I'm attaching a piece of C > code that does the sam

Re: [HACKERS] Building storage/lwlocknames.h?

Re: Andres Freund 2015-09-16 <20150916201955.gj2...@alap3.anarazel.de> > On 2015-09-16 22:10:00 +0200, Christoph Berg wrote: > > Can we have a "submake-lwlocknames" build target like there already is > > for submake-errcodes? Reading the Makefile I could not see h

[HACKERS] Building storage/lwlocknames.h?

Hi, the Debian package build compiles plpython twice, once for python 2 in the main build, and then for python 3 in an extra run. In order not to waste too much time, we have this recipe in there: stamp/build-py3: stamp/configure-build-py3 $(MAKE) -C build-py3/src/backend/ submake-errcode

Re: [HACKERS] 9.3.9 and pg_multixact corruption

Re: Bernd Helmle 2015-09-10 <7E3C7F8D210AC9A423E96F3A@eje.local> > 2015-09-08 11:40:59 CEST [27047] DETAIL: Could not seek in file > "pg_multixact/members/5FC4" to offset 4294950912: Invalid argument. > 2015-09-08 11:40:59 CEST [27047] CONTEXT: xlog redo create mxid 1068235595 > offset 214748

Re: [HACKERS] datestyle=postgres broken with timezone=UTC+N

Re: Tom Lane 2015-08-30 <20976.1440946...@sss.pgh.pa.us> > Christoph Berg writes: > > postgres =# set timezone = 'Etc/UTC+1'; > > SET > > postgres =# set datestyle = 'postgres'; > > SET > > postgres =# select '2015-01-01 01:

Re: [HACKERS] 9.4 broken on alpha

Re: Michael Cree 2015-08-26 <20150826052530.GA4256@tower> > I reported the failure to build on Alpha, with an explanation and a > patch to fix it, to the Debian package maintainers over a year ago, > and within about of a month of version 9.4 being uploaded to Debian. > > My recollection is that p

[HACKERS] datestyle=postgres broken with timezone=UTC+N

Discovered when debugging libpqtypes test failures: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795729 postgres =# set timezone = 'Etc/UTC+1'; SET postgres =# set datestyle = 'postgres'; SET postgres =# select '2015-01-01 01:00:00 +0100'::timestamptz; Wed 31 Dec 23:00:00 2014 ETC/UTC post

Re: [HACKERS] 9.4 broken on alpha

Re: Andrew Dunstan 2015-08-25 <55dc5f9e.60...@dunslane.net> > >gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement > >-Wendif-labels -Wmissing-format-attribute -Wformat-security > >-fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -g -O2 -Wformat > >-Werror=for

[HACKERS] 9.4 broken on alpha

25 internal error, aborting at ../../gas/write.c line 603 in size_seg as: Please report this bug. : recipe for target 'bgworker.o' failed make[5]: *** [bgworker.o] Error 1 There's a proposed patch: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;msg=5;bug=756368;filename=alpha-

[HACKERS] Using contrib modules in check (Re: pgsql: Fix BRIN to use SnapshotAny during summarization)

Re: Tom Lane 2015-08-07 <928.1438900...@sss.pgh.pa.us> > Alvaro Herrera writes: > > Fix BRIN to use SnapshotAny during summarization > > This patch added an isolation test that fails unless contrib/pageinspect > has been built and installed. I do not find that acceptable. It causes > "make chec

Re: [HACKERS] pg_rewind tap test unstable

Re: Michael Paquier 2015-07-28 > On Tue, Jul 28, 2015 at 5:57 PM, Christoph Berg wrote: > > for something between 10% and 20% of the devel builds for apt.postgresql.org > > (which happen every 6h if there's a git change, so it happens every few > > days), > > I&

[HACKERS] pg_rewind tap test unstable

Hi, for something between 10% and 20% of the devel builds for apt.postgresql.org (which happen every 6h if there's a git change, so it happens every few days), I'm seeing this: make[2]: Entering directory '/tmp/buildd/postgresql-9.6-9.6~~devel~20150728.0405/build/src/bin/pg_rewind' rm -rf /tmp/

[HACKERS] [patch] typo in brin.sql

There was a stray "s" in "classes implement*s*". I've also added a "the" to make the sentence more readable (at least for me). Christoph -- c...@df7cb.de | http://www.df7cb.de/ diff --git a/doc/src/sgml/brin.sgml b/doc/src/sgml/brin.sgml new file mode 100644 index e25f09c..894c269 *** a/doc/src/s

Re: [HACKERS] why does txid_current() assign new transaction-id?

Re: Michael Paquier 2015-05-28 > Attached is a doc patch among those lines. > diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml > index 89a609f..6485b42 100644 > --- a/doc/src/sgml/func.sgml > +++ b/doc/src/sgml/func.sgml > @@ -16233,7 +16233,7 @@ SELECT collation for ('foo' COLLATE "

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

Re: Tom Lane 2015-05-29 <13871.1432921...@sss.pgh.pa.us> > Why can't the user stop it? We won't be bleating about the case of a > symlink to a non-writable file someplace else, which is the Debian use > case. I don't see a very good excuse to have a non-writable file right > in the data directory

Re: [HACKERS] Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1

Re: Robert Haas 2015-05-29 > > FTR: Robert, you have been a Samurai on this issue. Our many thanks. > > Thanks! I really appreciate the kind words. I'm still watching with admiration. This list of steps-to-reproduce is the longest and at the same time best I've ever seen. If anyone ever asks

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

Re: Tom Lane 2015-05-28 <5740.1432849...@sss.pgh.pa.us> > Abhijit Menon-Sen writes: > > Here's an updated patch for the fsync problem(s). > > I've committed this after some mostly-cosmetic rearrangements. Fwiw, I can confirm that the problem is fixed for 9.5. The regression tests I've added to p

Re: [HACKERS] pg_upgrade resets timeline to 1

Re: Noah Misch 2015-05-28 <20150528150234.ga4111...@tornado.leadboat.com> > On Thu, May 28, 2015 at 10:20:58AM -0400, Bruce Momjian wrote: > > On Thu, May 28, 2015 at 08:47:07AM +0100, Simon Riggs wrote: > > > What we should be saying is that the last timeline doesn't need a history > > > file. >

Re: [HACKERS] pg_upgrade resets timeline to 1

Re: Noah Misch 2015-05-28 <20150528072721.ga4102...@tornado.leadboat.com> > > I've just had trouble getting barman to work again after a 9.1->9.4.2 > > upgrade, and I think part of the problem was that the WAL for this > > cluster got reset from timeline 2 to 1, which made barman's incoming > > WAL

Re: [HACKERS] pg_upgrade resets timeline to 1

Re: Simon Riggs 2015-05-28 > Hmm, it looks like the change to TimeLine 1 is just a kludge anyway. The > rule that TimeLine 1 doesn't need a history file is itself a hack. > > What we should be saying is that the last timeline doesn't need a history > file. Then no change is needed here. IMHO it

Re: [HACKERS] pg_upgrade resets timeline to 1

Re: Bruce Momjian 2015-05-28 <20150527221607.ga7...@momjian.us> > Well, if you used pg_dump/pg_restore, you would have had even larger > problems as the file names would have matched. True, but even here it's possible that files get overwritten. If you had a server running on TL 1 for files 000100

Re: [HACKERS] pg_upgrade resets timeline to 1

Re: Bruce Momjian 2015-05-27 <20150527174244.gb31...@momjian.us> > > In fact, I'm wondering if pg_upgrade shouldn't rather *increase* the > > timeline to make sure the archive_command doesn't clobber any files > > from the old cluster when reused in the new cluster? > > > > https://bugs.debian.org

[HACKERS] pg_upgrade resets timeline to 1

commit 4c5e060049a3714dd27b7f4732fe922090edea69 Author: Bruce Momjian Date: Sat May 16 00:40:18 2015 -0400 pg_upgrade: force timeline 1 in the new cluster Previously, this prevented promoted standby servers from being upgraded because of a missing WAL history file. (Timeline 1 do

Re: [HACKERS] Why does txid_current() assign new transaction-id?

Re: Tom Lane 2015-05-26 <18863.1432661...@sss.pgh.pa.us> > Christoph Berg writes: > > Still, exposing GetStableLatestTransactionId() on the SQL level would > > make sense for monitoring transaction throughput. > > Perhaps, though I wonder why we should expose t

Re: [HACKERS] Why does txid_current() assign new transaction-id?

Re: Tom Lane 2015-05-26 <14207.1432650...@sss.pgh.pa.us> > Naoya Anzai writes: > > I have a question about txid_current(). > > it is "Why does txid_current() assign new transaction-id?". > > Consider > > begin; > select txid_current(); > insert into my_table ...; > commit

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

Re: To Andres Freund 2015-05-24 <20150524075244.gb27...@msg.df7cb.de> > Re: Andres Freund 2015-05-24 <20150524005245.gd32...@alap3.anarazel.de> > > How about, to avoid masking actual problems, we have a more > > differentiated logic for the toplevel data directory? I think we could > > just skip al

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

Re: Andres Freund 2015-05-24 <20150524005245.gd32...@alap3.anarazel.de> > How about, to avoid masking actual problems, we have a more > differentiated logic for the toplevel data directory? I think we could > just skip all non-directory files in there data_directory itself. None > of the files in t

Re: [HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

Re: Tom Lane 2015-05-23 <2284.1432413...@sss.pgh.pa.us> > Christoph Berg writes: > > the new fsync-pgdata-on-recovery code tries to open all files using > > O_RDWR. At least on 9.1, this can make recovery fail: > > Hm. I wonder whether it would be all right to just sk

[HACKERS] Re: fsync-pgdata-on-recovery tries to write to more files than previously

Re: To PostgreSQL Hackers 2015-05-23 <20150523172627.ga24...@msg.df7cb.de> > Hi, > > the new fsync-pgdata-on-recovery code tries to open all files using > O_RDWR. At least on 9.1, this can make recovery fail: > > * launch postgres, hit ^\ (or otherwise shut down uncleanly) > * touch foo; chmod 44

[HACKERS] fsync-pgdata-on-recovery tries to write to more files than previously

Hi, the new fsync-pgdata-on-recovery code tries to open all files using O_RDWR. At least on 9.1, this can make recovery fail: * launch postgres, hit ^\ (or otherwise shut down uncleanly) * touch foo; chmod 444 foo * launch postgres LOG: database system was interrupted; last known up at 2015-05-

Re: [HACKERS] Re: [pgsql-pkg-debian] Updated libpq5 packages cause connection errors on postgresql 9.2

Re: Bruce Momjian 2015-04-01 <20150401160907.gj4...@momjian.us> > On Sat, Dec 20, 2014 at 12:27:05PM +0100, Magnus Hagander wrote: > > I haven't seen a specific number, it might depend on exactly which cipher is > > negotiated. See for example http://openssl.6102.n7.nabble.com/ > > What-is-the-reas

Re: [HACKERS] PITR failing to stop before DROP DATABASE

Re: Bruce Momjian 2015-03-20 <20150320223549.gz6...@momjian.us> > > > >So my suggestion for a simple fix would be to make DROP DATABASE > > > >execute a short fake transaction before it starts deleting files and > > > >then continue as before. This would serve as a stopping point for > > > >recover

Re: [HACKERS] gcc5: initdb produces gigabytes of _fsm files

Re: Tom Lane 2015-02-15 <21030.1424022...@sss.pgh.pa.us> > Christoph Berg writes: > > gcc5 is lurking in Debian experimental, and it's breaking initdb. > > FYI, this is now fixed in Red Hat's rawhide version: > https://bugzilla.redhat.com/show_bug.cgi?id=11909

[HACKERS] gcc5: initdb produces gigabytes of _fsm files

Hi, gcc5 is lurking in Debian experimental, and it's breaking initdb. There's bug reports for 9.1 and 9.4: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778070 (9.1) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778071 (9.4) but I could reproduce it with 9.5devel (from last week) as well:

Re: [HACKERS] libpq 9.4 requires /etc/passwd?

Re: Tom Lane 2015-01-11 <13609.1420998...@sss.pgh.pa.us> > > The problem isn't present in 9.3 and earlier (at least with > > postfix-pgsql), so there's no need to go back further. > > I've committed a fix for this in HEAD and 9.4. I've just tested with the HEAD libpq and the issue is fixed. Thank

Re: [HACKERS] libpq 9.4 requires /etc/passwd?

Re: Tom Lane 2015-01-10 <22432.1420915...@sss.pgh.pa.us> > So what I propose we do with this is patch HEAD and 9.4 only. > We need to do *something* in 9.4 to address Christoph's complaint, and > that branch is new enough that we can probably get away with changing > officially-unsupported APIs. T

[HACKERS] libpq 9.4 requires /etc/passwd?

Hi, I've got several reports that postfix's pgsql lookup tables are broken with 9.4's libpq5, while 9.3's libpq5 works just fine. The error message looks like this: Jan 10 00:11:40 lehmann postfix/trivial-rewrite[29960]: warning: connect to pgsql server localhost:5432: out of memory? Jan 10 00:1

[HACKERS] pg_upgrade needs postmaster [sic]

Hi, I've played with trying to find out which minimal set of files I need from the old version to make pg_upgrade work. Interestingly, this includes the good old postmaster binary: $ sudo -u postgres pgsql/bin/pg_upgrade -b /var/tmp/pgsql/bin/ -B /usr/lib/postgresql/9.5/bin/ -d /etc/postgresql/9

Re: [HACKERS] TAP test breakage on MacOS X

Re: Peter Eisentraut 2014-11-03 <5457f54e.4020...@gmx.net> > On 11/2/14 2:00 PM, Noah Misch wrote: > >> Ick; I concur with your judgment on those aspects of the IPC::Cmd design. > >> Thanks for investigating. So, surviving options include: > >> > >> 1. Require IPC::Run. > >> 2. Write our own run()

Re: [HACKERS] Proposal "VACUUM SCHEMA"

Re: Alvaro Herrera 2014-12-22 <20141222165157.gd1...@alvh.no-ip.org> > Multi-table CLUSTER uses multiple transactions, so this should not be an > issue. That said, I don't think there's much point in CLUSTER SCHEMA, > much less TRUNCATE SCHEMA. Do you normally organize your schemas so > that ther

[HACKERS] Re: [pgsql-pkg-debian] Updated libpq5 packages cause connection errors on postgresql 9.2

Re: Chris Butler 2014-12-19 <1155204201.65430.1418975376728.javamail.zim...@zedcore.com> > One of our servers is currently running on postgres 9.2 using the > 9.2.9-1.pgdg70+1 packages from pgdg. > > After an apt update this morning which brought in the libpq5 package version > 9.4.0-1.pgdg70+1

Re: [HACKERS] Minor binary-search int overflow in timezone code

Re: Tom Lane 2014-12-16 <14615.1418694...@sss.pgh.pa.us> > Jim Nasby writes: > > On 12/15/14, 1:39 PM, Christoph Berg wrote: > >> Well, if it's not interesting, let's just forget it. Sorry. > > > At the risk of sticking my head in the lions mouth... th

Re: [HACKERS] Minor binary-search int overflow in timezone code

Re: Tom Lane 2014-12-15 <21813.1418655...@sss.pgh.pa.us> > This is totally silly. The timecnt couldn't be anywhere near INT_MAX (in > fact, it is not allowed to exceed TZ_MAX_TIMES, which is currently just > 1200). And there are bunches of other instances of similar code in PG; > shall we put equ

[HACKERS] Minor binary-search int overflow in timezone code

Hi, a fellow Debian Developer found a minor glitch in src/timezone/localtime.c, where binary search is used. Now I don't think there is an actual problem (unless there's > 2^30 timezones), but it would at least make sense to mark the code as okayish so that people running code scanners won't stumb

Re: [HACKERS] moving from contrib to bin

Re: Alvaro Herrera 2014-12-12 <20141212203700.gb1...@alvh.no-ip.org> > > Pardon me for not knowing much about Debian packages, but how would > > that work exactly? Is it possible to do make install-client, then > > package the installed files, then rm -rf the install tree, then > > repeat for inst

Re: [HACKERS] moving from contrib to bin

Re: Andres Freund 2014-12-12 <20141212152723.go31...@awork2.anarazel.de> > On 2014-12-12 10:20:58 -0500, Tom Lane wrote: > > Peter Eisentraut writes: > > > On 12/12/14 8:13 AM, Andres Freund wrote: > > >> Wouldn't a make install-server/client targets or something similar > > >> actually achieve th

Re: [HACKERS] test_shm_mq failing on mips*

Re: Robert Haas 2014-12-02 > I can't tell from this exactly what's going wrong. Questions: > > 1. Are there any background worker processes running at the same time? > If so, how many? We'd expect to see 3. > 2. Can we printout of the following variables in stack frame 3 > (test_shm_mq_pipeli

Re: [HACKERS] PITR failing to stop before DROP DATABASE

Re: Heikki Linnakangas 2014-11-26 <54759bc0.4070...@vmware.com> > >Oh ok. So this is an artifact of the non-transactionality (is this a > >word?) of CREATE DATABASE. > > DROP DATABASE. CREATE DATABASE is a different story. It does similar > non-transactional tricks and has similar issues, but it's

Re: [HACKERS] Add shutdown_at_recovery_target option to recovery.conf

Re: Petr Jelinek 2014-11-25 <5474efea.2040...@2ndquadrant.com> > >Patch committed. > > Thanks! I'm a bit late to the party, but wouldn't recovery_target_action = ... have been a better name for this? It'd be in line with the other recovery_target_* parameters, and also a bit shorter than the im

Re: [HACKERS] PITR failing to stop before DROP DATABASE

Re: Heikki Linnakangas 2014-11-25 <5474b848.3060...@vmware.com> > >db1 is registered in pg_database, but the directory is missing on > >disk. > > Yeah, DROP DATABASE cheats. It deletes all the files first, and commits the > transaction only after that. There's this comment at the end of dropdb() >

[HACKERS] PITR failing to stop before DROP DATABASE

In 9.3.5, if I set up archiving, create a database, pull a base backup, look at the clock, drop database, stop the server, rm -rf datadir, put back the backup, edit recovery.conf: cd /tmp; initdb foo edit postgresql.conf with archive_mode = on, archive_command, max_wal_senders = 1, wal_level = hot

Re: [HACKERS] test_shm_mq failing on mips*

Re: To Robert Haas 2014-11-24 <20141124200824.ga22...@msg.df7cb.de> > > Does it fail every time when run on a machine where it fails sometimes? > > So far there's a consistent host -> fail-or-not mapping, but most > mips/mipsel build hosts have seen only one attempt so far which > actually came so

Re: [HACKERS] Use of recent Russian TZ changes in regression tests

Re: Tom Lane 2014-11-18 <23920.1416350...@sss.pgh.pa.us> > That doesn't make any sense as it stands, but I take your point, and > indeed that's more or less the reasoning that led me to write the test > as it is: we *should* complain if you've got TZ data that's more than > 6 months old. However,

Re: [HACKERS] test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?)

Re: Robert Haas 2014-11-24 > > https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.4&arch=mipsel&ver=9.4~rc1-1&stamp=1416547779 > > > > mips had the problem as well in the past (9.4 beta3): > > > > https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.4&arch=mips&ver=9.4~beta3-3&sta

Re: [HACKERS] test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?)

Hi, I'm still seeing trouble with test_shm_mq on mipsel (9.4 rc1): https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.4&arch=mipsel&ver=9.4~rc1-1&stamp=1416547779 mips had the problem as well in the past (9.4 beta3): https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.4&arch=mi

Re: [HACKERS] [BUGS] ltree::text not immutable?

Re: Tom Lane 2014-11-17 <6903.1416241...@sss.pgh.pa.us> > Christoph Berg writes: > > In HEAD, there's this WARNING now: > > WARNING: type input function chkpass_in should not be volatile > > Yeah, that's intentional. > > > IMHO built-in functions

Re: [HACKERS] [BUGS] ltree::text not immutable?

Re: Tom Lane 2014-11-05 <29132.1415144...@sss.pgh.pa.us> > I wrote: > > An alternative that just occurred to me is to put the no-volatile- > > I/O-functions check into CREATE TYPE, but make it just WARNING not > > ERROR. That would be nearly as good as an ERROR in terms of nudging > > people who'd

Re: [HACKERS] Hide 'Execution time' in EXPLAIN (COSTS OFF)

Re: Tom Lane 2014-10-12 <19766.1413129...@sss.pgh.pa.us> > Another possibility, which would introduce less non-orthogonality into > the switch design, is to remove the connection to COSTS OFF but say that > planning time is only printed when execution time is also printed (ie, > only in EXPLAIN ANA

Re: [HACKERS] Is analyze_new_cluster.sh still useful?

t; ./delete_old_cluster.sh I like this, thanks! Mit freundlichen Grüßen, Christoph Berg -- Senior Berater, Tel.: +49 (0)21 61 / 46 43-187 credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209 Hohenzollernstr. 133, 41061 Mönchengladbach Geschäftsführung: Dr. Michael Meskes

[HACKERS] libpq-dev: pg_config_manual.h redefines CACHE_LINE_SIZE

Hi, there's a #define clash between pg_config_manual.h and FreeBSD's /usr/include/machine-amd64/param.h which also defines CACHE_LINE_SIZE. It's probably not really a PostgreSQL bug, but it seems easy enough to rename that definition now as it's only present in 9.4+. It's only used in one file, x

Re: [HACKERS] Hide 'Execution time' in EXPLAIN (COSTS OFF)

Re: Tom Lane 2014-09-23 <15155.1411493...@sss.pgh.pa.us> > Robert Haas writes: > > On Sat, Sep 20, 2014 at 4:13 PM, Christoph Berg wrote: > >> Can we have "EXPLAIN (timing off)" in 9.4+ hide the "Planning time" > >> line? That would even be b

Re: [HACKERS] Hide 'Execution time' in EXPLAIN (COSTS OFF)

Re: Andres Freund 2014-06-04 <20140604194544.gb...@awork2.anarazel.de> > > I'm unconvinced that this'd add much to our regression testing capability, > > though. The standard thing is to do an EXPLAIN to check the plan shape > > and then run the query to see if it gets the right answer. Checking

Re: [HACKERS] ALTER SYSTEM RESET?

Re: Vik Fearing 2014-09-02 <5405d2d9.9050...@dalibo.com> > > Uhm, are we agreed on the decision on not to backpatch this? I would > > think this should have been part of the initial ALTER SYSTEM SET patch > > and thus should be backpatched to 9.4. > > I think it belongs in 9.4 as well, especially

Re: [HACKERS] pg_filedump for 9.4?

Re: Fabrízio de Royes Mello 2014-06-25 > On Wed, Jun 25, 2014 at 3:52 PM, Tom Lane wrote: > > Would like that, but I'm not sure what pgindent will do with the // > > comments. It's been on my to-do list to switch all the comments to C89 > > style and then pgindent it, but I don't see myself get

Re: [HACKERS] [TODO] Process pg_hba.conf keywords as case-insensitive

Re: Heikki Linnakangas 2014-08-21 <53f5a2d6.2050...@vmware.com> > >1) database and role names behave similar to SQL identifiers (case-sensitive > >/ case-folding). > > > >2) users and user-groups only requires special handling and behavior as > >follows > > Normal user : > > A. unquoted

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

Re: Thom Brown 2014-08-20 > "ERROR: table test is not permanent" > > Perhaps this would be better as "table test is unlogged" as "permanent" > doesn't match the term used in the DDL syntax. I was also wondering that, but then figured that when ALTER TABLE SET UNLOGGED is invoked on temp tables

Re: [HACKERS] Hokey wrong versions of libpq in apt.postgresql.org

Re: Joshua D. Drake 2014-08-11 <53e83e9c.6030...@commandprompt.com> > The issue that I specifically ran into is that by using apt.postgresql.org > in its default configuration, I can't add certain extensions (without > jumping through hoops). Simple: > > Assume a running 9.2.9 from apt.postgresql.

Re: [HACKERS] Is analyze_new_cluster.sh still useful?

Re: Bruce Momjian 2014-07-29 <20140729094234.gc13...@momjian.us> > On Fri, Jun 20, 2014 at 05:15:05PM +0200, Christoph Berg wrote: > > Another nitpick here: What pg_upgrade outputs doesn't even work on > > most systems, you need to ./analyze_new_cluster.sh or &quo

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

Re: Fabrízio de Royes Mello 2014-07-28 > There are something that should I do on this patch yet? I haven't got around to have a look at the newest incarnation yet, but I plan to do that soonish. (Of course that shouldn't stop others from doing that as well if they wish.) Christoph -- c...@df7c

Re: [HACKERS] [TODO] Process pg_hba.conf keywords as case-insensitive

Re: Viswanatham kirankumar 2014-07-23 > 3) Host name is not a SQL object so it will be treated as case-sensitive >except for all, samehost, samenet are considered as keywords. >For these user need to use quotes to differentiate between hostname and > keywords. DNS is case-insensitive,

Re: [HACKERS] Portability issues in TAP tests

Re: Noah Misch 2014-07-18 <20140718052625.ga2231...@tornado.leadboat.com> > Installing a new version of one Perl module is well within the capabilities of > buildfarm owners. Saving them the trouble, which in turn means more of them > actually activating the TAP tests, might justify the loss. I'd

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

Re: Fabrízio de Royes Mello 2014-07-16 > Anyway I think all is ok now. Is this ok for you? Hi Fabrízio, it's ok for me now, though Andres' concerns seem valid. > > > +SET TABLESPACE class="PARAMETER">new_tablespace > > > RESET ( class="PARAMETER">storage_parameter [, ... ] ) > > >

Re: [HACKERS] [TODO] Process pg_hba.conf keywords as case-insensitive

Re: Tom Lane 2014-07-16 <30956.1405532...@sss.pgh.pa.us> > Christoph Berg writes: > > Re: Viswanatham kirankumar 2014-07-16 > > > >> Attached patch is implementing following TODO item > >> Process pg_hba.conf keywords as case-insensitive > > &

Re: [HACKERS] [TODO] Process pg_hba.conf keywords as case-insensitive

Re: Viswanatham kirankumar 2014-07-16 > Attached patch is implementing following TODO item > Process pg_hba.conf keywords as case-insensitive > > * More robust pg_hba.conf parsing/error > logging Hmm. I see a case for accep

<    1   2   3   4   >