Re: [HACKERS] Add Roman numeral conversion to to_number

Re: Peter Eisentraut 2017-08-14 > There are probably a bunch of Perl or Python modules that can be > employed for this. https://github.com/ChristophBerg/postgresql-numeral Christoph -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Surjective functional indexes

Re: Konstantin Knizhnik 2017-09-13 <2393c4b3-2ec4-dc68-4ea9-670597b56...@postgrespro.ru> > > > On 13.09.2017 10:51, Christoph Berg wrote: > > Re: Konstantin Knizhnik 2017-09-01 > > <f530ede0-1bf6-879c-c362-34325514f...@postgrespro.ru> > > > +

Re: [HACKERS] Surjective functional indexes

Re: Konstantin Knizhnik 2017-09-01 > + Functional index is based on on projection function: function which > extract subset of its argument. > + In mathematic such functions are called non-injective. For injective > function if

Re: [HACKERS] mysql_fdw + PG10: unrecognized node type: 217

Re: To Andres Freund 2017-09-11 <20170911095338.mqkiinkpk7gko...@msg.df7cb.de> > Re: Andres Freund 2017-09-11 > <20170911090306.s7sj4uyr4t72w...@alap3.anarazel.de> > > Could you pprint() the expression that's being initialized? > (gdb) p pprint(node) Andres helped me to produce a correct dump,

Re: [HACKERS] mysql_fdw + PG10: unrecognized node type: 217

Re: Andres Freund 2017-09-11 <20170911090306.s7sj4uyr4t72w...@alap3.anarazel.de> > Could you pprint() the expression that's being initialized? (gdb) f 4 #4 0x5604ecedd124 in ExecInitNode (node=node@entry=0x5604ee884f80, estate=estate@entry=0x5604ee8c78a0, eflags=eflags@entry=16) at

Re: [HACKERS] mysql_fdw + PG10: unrecognized node type: 217

Re: To Tom Lane 2017-09-11 <20170911083136.stdnc4w52wk3o...@msg.df7cb.de> > postgres=# select test_param_where(); > FEHLER: XX000: unrecognized node type: 217 > KONTEXT: SQL-Anweisung »select bfrom numbers where a=x« > PL/pgSQL-Funktion test_param_where() Zeile 6 bei SQL-Anweisung > ORT:

Re: [HACKERS] mysql_fdw + PG10: unrecognized node type: 217

Re: Tom Lane 2017-09-10 <13662.1505077...@sss.pgh.pa.us> > Christoph Berg <m...@debian.org> writes: > > I'm not sure if this is a bug in mysql_fdw, or in PG10: > > > ! ERROR: unrecognized node type: 217 > > Hm, nodetag 217 is T_List according to gdb. Wouldn'

[HACKERS] mysql_fdw + PG10: unrecognized node type: 217

Hi, I'm not sure if this is a bug in mysql_fdw, or in PG10: == running regression test queries== test mysql_fdw... FAILED *** 345,359 NOTICE: Found number Three NOTICE: Found number Four NOTICE: Found number Five ! NOTICE: Found

Re: [HACKERS] initdb failure on Debian sid/mips64el in EventTriggerEndCompleteQuery

Re: Tom Lane 2017-08-13 <14677.1502638...@sss.pgh.pa.us> > Christoph Berg <m...@debian.org> writes: > > Seems to be a gcc-7 problem affecting several packages on mips64el: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871514 > > Hm, unless th

Re: [HACKERS] obsolete code in pg_upgrade

Re: Peter Eisentraut 2017-08-24 <8aa00f15-144e-e793-750e-d1d6876d6...@2ndquadrant.com> > On 8/23/17 09:36, Robert Haas wrote: > > I think I agree. It seems to me that the version of pg_upgrade > > shipped with release N only needs to support upgrades to release N, > > not older releases.

Re: [HACKERS] initdb failure on Debian sid/mips64el in EventTriggerEndCompleteQuery

Re: Tom Lane 2017-08-13 <14517.1502638...@sss.pgh.pa.us> > I suspect you could work around this with > > boolisCompleteQuery = (context <= PROCESS_UTILITY_QUERY); > - boolneedCleanup; > + volatile bool needCleanup; > boolcommandCollected =

Re: [HACKERS] Log LDAP "diagnostic messages"?

Re: Thomas Munro 2017-08-10

Re: [HACKERS] pl/perl extension fails on Windows

Re: Sandeep Thakkar 2017-08-08 > Hi > > An update from beta3 build: We are no longer seeing this issue (handshake > failure) on Windows 64bit, but on Windows 32bit it still persists. HEAD as of 5a5c2feca still has the same

Re: [HACKERS] initdb failure on Debian sid/mips64el in EventTriggerEndCompleteQuery

Re: To PostgreSQL Hackers 2017-08-13 <20170813130127.g3tcyzzvuvlpz...@msg.df7cb.de> > 10beta3 and 9.6.4 are both failing during initdb on mips64el on > Debian/sid (unstable): > > https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.6=mips64el=9.6.4-1=1502374949=0 >

[HACKERS] initdb failure on Debian sid/mips64el in EventTriggerEndCompleteQuery

10beta3 and 9.6.4 are both failing during initdb on mips64el on Debian/sid (unstable): https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.6=mips64el=9.6.4-1=1502374949=0 https://buildd.debian.org/status/fetch.php?pkg=postgresql-10=mips64el=10%7Ebeta3-1=1502535836=0 All other

Re: [HACKERS] pl/perl extension fails on Windows

Re: Tom Lane 2017-07-31 <30582.1501508...@sss.pgh.pa.us> > Christoph Berg <m...@debian.org> writes: > >>> The only interesting line in log/postmaster.log is a log_line_prefix-less > >>> Util.c: loadable library and perl binaries are mismatched (got handshake

Re: [HACKERS] pl/perl extension fails on Windows

Re: Ashutosh Sharma 2017-07-31 > > The only interesting line in log/postmaster.log is a log_line_prefix-less > > Util.c: loadable library and perl binaries are mismatched (got handshake > > key 0xd500080, needed 0xd600080) > >

Re: [HACKERS] pl/perl extension fails on Windows

Re: Tom Lane 2017-07-28 <3254.1501276...@sss.pgh.pa.us> > Christoph Berg <m...@debian.org> writes: > > The plperl segfault on Debian's kfreebsd port I reported back in 2013 > > is also still present: > > https://www.postgresql.org/message-id/20130515064201

Re: [HACKERS] 10beta1/m68k: static assertion failed: "MAXALIGN too small to fit int32"

Re: Heikki Linnakangas 2017-05-18 <5b9085c2-2c18-e5e3-c340-c07d11a9c...@iki.fi> > > Please go ahead, I don't think I have online access to a m68k machine. > > (It got demoted to an unofficial port some time ago and the old Debian > > porter machines got taken down). > > Ok, pushed, let's see if

Re: [HACKERS] pl/perl extension fails on Windows

Re: Dave Page 2017-07-12 > > Well, we have various buildfarm machines running perls newer than that, > > eg, crake, with 5.24.1. So I'd say there is something busted about your > > perl installation. Perhaps leftover bits of

Re: [HACKERS] PostgreSQL - Weak DH group

Re: Alvaro Herrera 2017-07-13 <20170713170402.74uuoivrgd3c6tnw@alvherre.pgsql> > > > Objections to committing this now, instead of waiting for v11? > > > > But I am -1 for the sneak part. It is not the time to have a new > > feature in 10, the focus is to stabilize. > > But if we were treating

Re: [HACKERS] 10beta1 sequence regression failure on sparc64

Re: To Andres Freund 2017-05-24 <20170524170921.7pykzbt54dlfk...@msg.df7cb.de> > > > If we had a typo or something in that code, the build farm should have > > > caught it by now. > > > > > > I would try compiling with lower -O and see what happens. > > > > Trying -O0 now. > > Sorry for the

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

Re: Tom Lane 2017-05-31 <28752.1496238...@sss.pgh.pa.us> > OK, this looks good to me. Just to make sure everyone's on the > same page, what I propose to do is simplify all our platform-specific > Makefiles that use either -fpic or -fPIC to use -fPIC unconditionally. > This affects the netbsd,

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

Re: Tom Lane 2017-05-30 <1564.1496176...@sss.pgh.pa.us> > It'd be interesting if people could gather similar numbers on other > platforms of more real-world relevance, such as ppc64. But based on > this small sample, I wouldn't object to just going to -fPIC across > the board. ppc64el, Debian

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

Re: Tom Lane 2017-05-30 <25131.1496163...@sss.pgh.pa.us> > Christoph Berg <m...@debian.org> writes: > > My main point here would be that we are already setting this for all > > extensions for sparc and sparc64, so s390(x) would just follow suit. > > For some

Re: [HACKERS] Surjective functional indexes

Re: Konstantin Knizhnik 2017-05-30 <f97118e3-821c-10a8-85ec-0af3f1dfd...@postgrespro.ru> > > > On 29.05.2017 20:21, Christoph Berg wrote: > > > > I think the term you were looking for is "projection". > > > > https://en.wikipedia.org/wiki/Pr

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

Re: Andres Freund 2017-05-30 <20170530161541.koj5xbvvovrrt...@alap3.anarazel.de> > I think we can fix this easily enough in Citus, postgis, and whatever. > But it's not a particularly good user/developer experience, and > presumably is going to become more and more common. On x86 there > shouldn't

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

Re: Tom Lane 2017-05-29 <28291.1496087...@sss.pgh.pa.us> > Andres Freund writes: > > On May 29, 2017 12:15:37 PM PDT, Alvaro Herrera > > wrote: > >> I think it'd be smart to support the use case directly, because there's > >> interest in it being

Re: [HACKERS] psql: Activate pager only for height, not width

Re: Jeff Janes 2017-05-29

Re: [HACKERS] Surjective functional indexes

Re: Konstantin Knizhnik 2017-05-29 <592bbd90.3060...@postgrespro.ru> > On 05/27/2017 09:50 PM, Peter Eisentraut wrote: > > On 5/25/17 12:30, Konstantin Knizhnik wrote: > > > Functions like (info->>'name') are named "surjective" ni mathematics. > > A surjective function is one where each value in

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

Re: To Andres Freund 2016-04-28 <20160428080824.ga22...@msg.df7cb.de> > > I'm not clear why citus triggers this, when other extensions don't? > > Maybe it's simply because citus.so is bigger than all the other > extension .so files: > >-fpic > Generate position-independent code

Re: [HACKERS] 10beta1 sequence regression failure on sparc64

Re: To Andres Freund 2017-05-18 <20170518192924.jkrzevlencp3g...@msg.df7cb.de> > > If we had a typo or something in that code, the build farm should have > > caught it by now. > > > > I would try compiling with lower -O and see what happens. > > Trying -O0 now. Sorry for the late reply, I was

Re: [HACKERS] 10beta1 sequence regression failure on sparc64

Re: Peter Eisentraut 2017-05-18 <7a4d3b0f-78da-2a5b-7f3b-8b3509c1e...@2ndquadrant.com> > If we had a typo or something in that code, the build farm should have > caught it by now. > > I would try compiling with lower -O and see what happens. Trying -O0 now. Re: Andres Freund 2017-05-18

Re: [HACKERS] 10beta1/m68k: static assertion failed: "MAXALIGN too small to fit int32"

Re: Heikki Linnakangas 2017-05-18 > I'll commit that, barring objections. If you can verify that it fixes the > problem before that, that'd be great, otherwise I guess we'll find out some > time after the commit. Please go ahead, I don't think I have

Re: [HACKERS] 10beta1 sequence regression failure on sparc64

Re: Tom Lane 2017-05-17 <30016.1495041...@sss.pgh.pa.us> > Christoph Berg <m...@debian.org> writes: > > The sequence regression tests are failing on Debian/sparc64: > > ... > > (This is only the last 100 lines of regression.diffs, if it helps I > > can tr

[HACKERS] 10beta1/m68k: static assertion failed: "MAXALIGN too small to fit int32"

Not sure if a lot of people still care about m68k, but it's still one of the unofficial Debian ports (it used to be the first non-x86 port done decades ago): gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security

[HACKERS] 10beta1 sequence regression failure on sparc64

The sequence regression tests are failing on Debian/sparc64: sequence ... FAILED polymorphism ... ok rowtypes ... ok returning... ok largeobject ... ok with ... ok xml

[HACKERS] Re: [Pkg-postgresql-public] Debian "postgresql-common" config check issue with pg10

Re: Fabien COELHO 2017-05-08 > Thus I naïvely added: > > password_encryption = scram-sha-256 Hmm. Naïvely I would have assumed this would be missing quotes :) > The result is: > > Error: Invalid line 88 in /etc/postgresql/10/main/postgresql.conf:

Re: [HACKERS] One-shot expanded output in psql using \gx

Re: Daniel Verite 2017-03-03 <4d84079e-325b-48c5-83e6-bb54bb567...@manitou-mail.org> > - tab-completion: works but the list in tab-complete.c:backslash_commands[] > is sorted alphabetically so "\\gx" should come after "\\gset" Good catch, it was still in that place from when it was named \G. In

Re: [HACKERS] powerpc(32) point/polygon regression failures on Debian Jessie

Re: To Tom Lane 2017-02-20 <20170220161556.5ukosuj5o572b...@msg.credativ.de> > I was compiling the program on jessie and on sid, and running the > jessie binary on sid made it output the same as the sid binary, so the > difference isn't in the binary, but in some system library. Fwiw, the problem

Re: [HACKERS] powerpc(32) point/polygon regression failures on Debian Jessie

Re: Tom Lane 2017-02-20 <13825.1487607...@sss.pgh.pa.us> > Still, it'd be worth comparing the assembly code for your test program. I was compiling the program on jessie and on sid, and running the jessie binary on sid made it output the same as the sid binary, so the difference isn't in the

Re: [HACKERS] powerpc(32) point/polygon regression failures on Debian Jessie

Re: Tom Lane 2017-02-20 <30737.1487598...@sss.pgh.pa.us> > Hmph. We haven't touched that code in awhile, and certainly not in the > 9.4.x branch. I'd have to agree that this must be a toolchain change. FYI, in the meantime we could indeed trace it back to an libc issue on Jessie: $ cat sqrt.c

[HACKERS] powerpc(32) point/polygon regression failures on Debian Jessie

The point/polygon regression tests have started to fail on 32-bit powerpc on Debian Jessie. So far I could reproduce the problem with PostgreSQL 9.4.10+11 and 9.6.1, on several different machines. Debian unstable is unaffected. The failure looks like this:

Re: [HACKERS] One-shot expanded output in psql using \gx

ion starts at line 398 in master. I think that ship has sailed, given there's already \gset. Supporting \g[optionset] next to it *now*, given no one knows how "optionset" is going to evolve seems like premature optimization. Mit freundlichen Grüßen, Christoph Berg -- Senior Berater, Tel.

Re: [HACKERS] One-shot expanded output in psql using \gx

Re: David Fetter 2017-02-07 <20170207051659.gc3...@fetter.org> > On Mon, Feb 06, 2017 at 08:54:13PM +0100, Christoph Berg wrote: > > The majority of voices here was in favor of using \gx, so here is > > another version of the same patch which implements that. > >

Re: [HACKERS] One-shot expanded output in psql using \gx

The majority of voices here was in favor of using \gx, so here is another version of the same patch which implements that. Christoph diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml new file mode 100644 index ae58708..e0302ea *** a/doc/src/sgml/ref/psql-ref.sgml ---

Re: [HACKERS] One-shot expanded output in psql using \G

port a filename argument. (It will instead stuff the argument into the next query buffer.) (The \G patch already supports the filename argument.) Mit freundlichen Grüßen, Christoph Berg -- Senior Berater, Tel.: +49 2166 9901 187 credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209 Tro

Re: [HACKERS] One-shot expanded output in psql using \G

Re: Daniel Verite 2017-01-28 <74e7fd23-f5a9-488d-a8c4-1e0da674b...@manitou-mail.org> > > Mysql's CLI client is using \G for this purpose, and adding the very > > same functionality to psql fits nicely into the set of existing > > backslash commands: \g sends the query buffer, \G will do exactly

Re: [HACKERS] One-shot expanded output in psql using \G

Re: Stephen Frost 2017-01-27 <20170127160544.gi9...@tamriel.snowman.net> > > > Uh, I figured it was more like \g, which just re-runs the last query.. > > > As in, you'd do: > > > > > > table pg_proc; % blargh, I can't read it like this > > > \G % ahh, much nicer > > > > Sure, that's exactly the

Re: [HACKERS] One-shot expanded output in psql using \G

people in the thread seem to > have agreed back then. I forgot to add the archive URL here: https://www.postgresql.org/message-id/758d5e7f0804030023j659d72e6nd66a9d6b93b30886%40mail.gmail.com Mit freundlichen Grüßen, Christoph Berg -- Senior Berater, Tel.: +49 2166 9901 187 credativ GmbH, HRB M

[HACKERS] One-shot expanded output in psql using \G

al people in the thread seem to have agreed back then. Patch attached, I'll add it to the next commit fest. Mit freundlichen Grüßen, Christoph Berg -- Senior Berater, Tel.: +49 2166 9901 187 credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchenglad

Re: [HACKERS] Use EVP API pgcrypto encryption, dropping support for OpenSSL 0.9.6 and older

Re: Heikki Linnakangas 2016-10-17 <07ebd878-ff09-72d5-7df7-f7fde7b83...@iki.fi> > Committed this patch now. Hi, I've just taken up work again on PG 10 on Debian unstable. With openssl 1.1.0c-2, pgcrypto errors out with: gcc -Wall -Wmissing-prototypes -Wpointer-arith

Re: [HACKERS] Patch to implement pg_current_logfile() function

Re: Gilles Darold 2016-10-27 > > I'm partial to "format path" over just line number, because > > it's more explicit. Either way works. > > This is the format used. Ex: > > ~$ cat /usr/local/postgresql/data/current_logfile > stderr

Re: [HACKERS] Patch to implement pg_current_logfile() function

Re: Karl O. Pinc 2016-10-27 <20161026222513.74cd3...@slate.meme.com> > Since it now can contain multiple pathnames perhaps the name of the > file should be "current_logfiles"? Seems more descriptive. Not sure about that, most often it would contain one logfile only, and catering for that seems

Re: [HACKERS] Renaming of pg_xlog and pg_clog

Re: Bruce Momjian 2016-10-19 <20161018220909.ga11...@momjian.us> > > There's actually another instance of "rename so people shoot their > > feet less often" here: pg_resetxlog, which is a user-facing tool. > > Folks on #postgresql have repeatedly been joking that it should rather > > be named

Re: [HACKERS] Patch to implement pg_current_logfile() function

Re: Gilles Darold 2016-10-14 > Agree, the usability of the current version is really a pain. What I've > thought is that the function could return the csv log in all case when > csvlog is set in log_destination and the stderr log file when csvlog

Re: [HACKERS] Renaming of pg_xlog and pg_clog

Re: Stephen Frost 2016-10-14 <20161014113523.gz13...@tamriel.snowman.net> > > We have a tool called pg_xlogdump in the standard installation. initdb > > has an option --xlogdir, pg_basebackup has --xlog and others. Renaming > > the xlog directory would make this all a bit confusing, unless we're

Re: [HACKERS] process type escape for log_line_prefix

Re: Jeff Janes 2016-10-14

Re: [HACKERS] Patch to implement pg_current_logfile() function

Re: To Gilles Darold 2016-10-14 <20161014125406.albrfj3qldiwj...@msg.df7cb.de> > A better design might be to return two columns instead: > > postgres=# select * from pg_current_logfile(); > stderr| csvlog >

Re: [HACKERS] Renaming of pg_xlog and pg_clog

Re: Stephen Frost 2016-10-14 <20161014113523.gz13...@tamriel.snowman.net> > > I think it would help if we moved it to something like > > "internal/pg_xlog" and "internal/pg_clog". Keep the name but move it > > out of sight. > > I disagree that this will materially help with the issue. And

Re: [HACKERS] Patch to implement pg_current_logfile() function

Hi Gilles, Re: Gilles Darold 2016-10-07 <0731a353-8d2f-0f2f-fcd5-fde77114c...@dalibo.com> > > What bugs me is the new file "pg_log_file" in PGDATA. It clutters the > > directory listing. I wouldn't know where else to put it, but you might > > want to cross-check that with the thread that is

Re: [HACKERS] process type escape for log_line_prefix

Re: Michael Paquier 2016-02-10

Re: [HACKERS] Non-empty default log_line_prefix

Re: Stephen Frost 2016-10-12 <20161012190732.gj13...@tamriel.snowman.net> > For my 2c, I'd rather have %m, but I definitely agree with Robert that > we need to do *something* here and if the only thing holding us back is > %t vs. %m, then let's just pick one and move on. I'll just hold my nose >

Re: [HACKERS] [PATCH] pg_filedump is broken

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:not tested pg_filedump is a separate git repo, so the commitfest app won't let me mark

Re: [HACKERS] [PATCH] pg_filedump is broken

Re: Aleksander Alekseev 2016-10-12 <20161012111527.GA17916@e733.localdomain> > Hello. > > First patch fixes: > > ``` > pg_filedump.c: In function ‘FormatItem’: > pg_filedump.c:994:18: error: ‘SizeOfIptrData’ undeclared (first use in > this function) >if (numBytes <

Re: [HACKERS] Non-empty default log_line_prefix

Re: Jeff Janes 2016-10-12

Re: [HACKERS] Non-empty default log_line_prefix

Re: Peter Eisentraut 2016-10-12 <0caa6d7f-deb6-9a43-2b38-60e63af93...@2ndquadrant.com> > >> > is going to do more to raise peoples' awareness than anything we > >> > could do in the documentation. But perhaps an example along these > >> > lines would be useful for showing proper use of %q. > >

Re: [HACKERS] Switch to unnamed POSIX semaphores as our preferred sema code?

Re: Tom Lane 2016-10-08 <29244.1475959...@sss.pgh.pa.us> > So I'm still of the opinion that there's not likely to be any meaningful > performance difference in practice, at least not on reasonably recent > Linux machines. But this does indicate that if there is any difference, > it will probably

Re: [HACKERS] PostgreSQL - Weak DH group

Re: Heikki Linnakangas 2016-10-06 > I propose the attached patch. It gives up on trying to deal with multiple > key lengths (as noted earlier, OpenSSL just always passed keylength=1024, so > that was useless). Instead of using the callback, it just

Re: [HACKERS] Renaming of pg_xlog and pg_clog

Re: Michael Paquier 2016-09-30

Re: [HACKERS] Patch to implement pg_current_logfile() function

Hi Gilles, I've just tried v4 of the patch. The OID you picked for pg_current_logfile doesn't work anymore, but after increasing it randomly by 1, it compiles. I like the added functionality, especially that "select pg_read_file(pg_current_logfile());" just works. What bugs me is the new

Re: [HACKERS] pgbench - allow backslash continuations in \set expressions

Re: Fabien COELHO 2016-10-03 > > I "\set" a bunch of lengthy SQL commands in there, e.g. > > I agree that this looks like a desirable feature, however I would tend to > see that as material for another independent patch. Sure, my question was by no

Re: [HACKERS] pgbench - allow backslash continuations in \set expressions

Re: Fabien COELHO 2016-10-03 > > Attached patch does what is described in the title, hopefully. Continuations > in other pgbench backslash-commands should be dealt with elsewhere... Would (a similar version of) that patch also apply to .psqlrc? I

[HACKERS] Non-empty default log_line_prefix

Re: Tom Lane 2016-09-29 <18642.1475159...@sss.pgh.pa.us> > > Possibly the longer version could be added as an example in the > > documentation. > > I suspect that simply having a nonempty default in the first place > is going to do more to raise peoples' awareness than anything we > could do in

Re: [HACKERS] Set log_line_prefix and application name in test drivers

Re: Tom Lane 2016-09-29 <16946.1475157...@sss.pgh.pa.us> > Robert Haas writes: > > As long as we get %t and %p in there we're going to be way ahead, really. > > Could we get consensus on just changing the default to > > log_line_prefix = '%t [%p] ' > > and leaving

Re: [HACKERS] Set log_line_prefix and application name in test drivers

Re: Peter Eisentraut 2016-09-29 <21d2719f-36ff-06d2-5856-25ed48b96...@2ndquadrant.com> > > Christoph/Debian: > > log_line_prefix = '%t [%p-%l] %q%u@%d ' > > Peter: > > log_line_prefix = '%t [%p]: [%l] %qapp=%a ' > > I'm aware of two existing guidelines on log line formats: syslog and >

Re: [HACKERS] Set log_line_prefix and application name in test drivers

Re: Robert Haas 2016-09-28 > > Well, practically anything that includes a PID and the timestamp is > > going to be an improvement over the status quo. Just because we can't > > all agree on what would be perfect does not mean

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

Re: To Heikki Linnakangas 2016-09-15 <20160915213406.2mjlhcg7px3sa...@msg.df7cb.de> > > Can you elaborate? Are you saying that Debian 9 (strect) will not ship > > OpenSSL 1.0.2 anymore, and will require using OpenSSL 1.1.0? > > I thought that was the plan, but upon asking on #debian-devel, it >

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

Re: Heikki Linnakangas 2016-09-15 <7e4991a9-410f-5e1f-2a3a-e918e4a4b...@iki.fi> > > I'm afraid it's not that easy - Debian 9 (stretch) will release at the > > beginning of next year, and apt.postgresql.org will want to build > > 9.2/9.3/9.4 for that distribution. I guess yum.postgresql.org will >

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

Re: Michael Paquier 2016-09-15 > On Thu, Sep 15, 2016 at 8:57 PM, Heikki Linnakangas wrote: > > I backpatched this to 9.5, but not further than that. The functions this > > modified were moved around in 9.5, so

Re: [HACKERS] [PATCH] COPY vs \copy HINT

Re: Tom Lane 2016-09-06 <17637.1473192...@sss.pgh.pa.us> > Christoph's idea isn't bad. We could tweak it to: > > COPY TO instructs the PostgreSQL server process to write a file. > > COPY FROM instructs the PostgreSQL server process to read a file. > > This seems to cover both the

Re: [HACKERS] [PATCH] COPY vs \copy HINT

Re: Craig Ringer 2016-09-05 > To cover the same-host case we could try something like: > >COPY runs on the PostgreSQL server, using the PostgreSQL server's > directories and permissions, it doesn't run on the client. > >

Re: [HACKERS] pg_hba_file_settings view patch

Re: Simon Riggs 2016-09-03 > pg_hba_file_settings seems a clumsy name. I'd prefer pg_hba_settings, > since that name could live longer than the concept of pg_hba.conf, > which seems likely to become part of ALTER SYSTEM in

Re: [HACKERS] [PATCH] COPY vs \copy HINT

Re: Craig Ringer 2016-09-02 > I thought about that but figured it didn't really matter too much, > when thinking about examples like > > # COPY batch_demo FROM '/root/secret.csv' WITH (FORMAT CSV); > ERROR: could not open file

Re: [HACKERS] Set log_line_prefix and application name in test drivers

Re: Fabien COELHO 2016-08-26 > So I would suggest something like the following, which is also a little bit > more compact: > > log_line_prefix = '%m [%p:%l] %q%a ' > > If you want to keep something with %a, maybe parentheses? > > Finally I'm

Re: [HACKERS] Renaming of pg_xlog and pg_clog

Re: Fujii Masao 2016-08-26 > > I agree on a hard break, unless we get pushback from users, and even > > then, they can create the symlinks themselves. > > I strongly prefer symlink approach not to break many existing tools >

Re: [HACKERS] synchronous_commit = remote_flush

Re: Thomas Munro 2016-08-21

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

Re: To Tom Lane 2016-08-15 <20160815111057.v2mqqjp4aabvw...@msg.df7cb.de> > Re: Tom Lane 2016-07-30 <1184.1469890...@sss.pgh.pa.us> > > In short, I think that the way to make something like this work is to > > figure out how to have "virtual" catalog rows describing a temp table. > > Or maybe to

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

Re: Tom Lane 2016-07-30 <1184.1469890...@sss.pgh.pa.us> > In short, I think that the way to make something like this work is to > figure out how to have "virtual" catalog rows describing a temp table. > Or maybe to partition the catalogs so that vacuuming away temp-table > rows is easier/cheaper

Re: [HACKERS] [PATCH] COPY vs \copy HINT

Re: Craig Ringer 2016-08-12 > I think we should emit a HINT here, something like: > > ERROR: could not open file "D:\CBS_woningcijfers_2014.csv" for reading: No > such file or directory' > HINT: Paths for COPY are on the

Re: [HACKERS] pg_size_pretty, SHOW, and spaces

Re: Peter Eisentraut 2016-08-01 > > PostgreSQL uses the spaces inconsistently, though. pg_size_pretty uses > > spaces: > > > > # select pg_size_pretty((2^20)::bigint); > > pg_size_pretty > > > > 1024 kB > > because it's

[HACKERS] pg_size_pretty, SHOW, and spaces

Re: Bruce Momjian 2016-07-30 <20160730181643.gd22...@momjian.us> > I also just applied a doc patch that increases case and spacing > consistency in the use of kB/MB/GB/TB. Hi, PostgreSQL uses the spaces inconsistently, though. pg_size_pretty uses spaces: # select pg_size_pretty((2^20)::bigint);

Re: [HACKERS] sslmode=require fallback

Makes sense. Is this something that should be implemented in postgresql, or via pg_createcluster? Am 19. Juli 2016 16:00:05 MESZ, schrieb Magnus Hagander <mag...@hagander.net>: >On Sun, Jul 17, 2016 at 10:07 PM, Christoph Berg <m...@debian.org> >wrote: > >> Re:

Re: [HACKERS] sslmode=require fallback

Re: Peter Eisentraut 2016-07-17 > On 7/15/16 3:07 PM, Andrew Dunstan wrote: > > Do those packagers who install dummy certificates and turn SSL on also > > change their pg_hba.conf.sample files to use hostssl?. That could go a > > long way

Re: [HACKERS] 9.6beta2: query failure with 'cache lookup failed for type 0'

Re: Stefan Huehner 2016-07-02 <20160702160042.ga11...@huehner.biz> > No data at all needed in table. > In fact just create database + create 3 those objects is enough to reproduce > it. Confirmed here on Debian unstable amd64, beta2. FEHLER: XX000: cache lookup failed for type 0 ORT:

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

Re: Andreas Karlsson 2016-07-02 <a5f4b79e-a9ea-200d-e17e-2da3ad187...@proxel.se> > On 07/01/2016 11:41 AM, Christoph Berg wrote: > > thanks for the patches. I applied all there patches on top of HEAD > > (10c0558f). The server builds and passes "make check", pgcryp

Re: [HACKERS] Broken handling of lwlocknames.h

Re: Tom Lane 2016-07-01 <26357.1467400...@sss.pgh.pa.us> > I made some mostly-cosmetic changes to this and pushed it. I confirm that Debian's out-of-tree python3 build works now when invoked directly in the relevant plpython/hstore_plpython subdirectories. Thanks! Christoph -- Sent via

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

Re: Andreas Karlsson 2016-07-01 <688a438c-ccc2-0431-7100-26e418fc3...@proxel.se> > Hi, > > Here is an initial set of patches related to OpenSSL 1.1. Everything should > still build fine on older OpenSSL versions (and did when I tested with > 1.0.2h). Hi Andreas, thanks for the patches. I

Re: [HACKERS] Broken handling of lwlocknames.h

Re: Tom Lane 2016-06-27 <31398.1467036...@sss.pgh.pa.us> > Bjorn Munch reported off-list that this sequence: > > unpack tarball, cd into it > ./configure ... > cd src/test/regress > make > > no longer works in 9.6beta2, where it did work in previous releases. > I have confirmed both statements.

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

Re: Andreas Karlsson 2016-06-27 <8a0a5959-0b83-3dc8-d9e7-66ce8c1c5...@proxel.se> > > The errors you report make it sound like they broke API compatibility > > wholesale. Was that really their intent? If so, where are the changes > > documented? > > I do not see that they have documented the

  1   2   3   4   >