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: 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] 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

[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] [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

[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] 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

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] 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: 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] synchronous_commit = remote_flush

Re: Thomas Munro 2016-08-21 > Right, we could just add it to guc.c after "on", so that you can "SET > synchronous_commit TO remote_flush", but then "SHOW > synchronous_commit" returns "on". > > The problem I was thinking about was this: if you add "remote_flush" > before "on" in guc.c, then "SHO

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 > and scripts. Symlinks might actually be worse than removing the direct

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 wondering also whether a timestamp since the server

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 "/root/secret.csv" for reading: Permission denied > > or whatever,

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 future, so we > wouldn't really want the word "file" in there. IMHO "sett

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. > > ... but I think that's actually less helpful for the users who'll need

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 wr

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 the patch wouldn't apply as is. It > > wouldn't be difficult to back-patch further if

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: 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 > s

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 that we can't do > > better than what we've got now. +1 for trying. >

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 > pg

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 the rest out of it? I t

[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 th

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 "\set" a bunch of lengthy SQL commands in there,

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 means intending to stop your pgbench patch from

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 file

Re: [HACKERS] Renaming of pg_xlog and pg_clog

Re: Michael Paquier 2016-09-30 "pg_trans" is used in two places: > -pg_clog records the commit status for each transaction that has been assigned > +pg_trans records the commit status for each transaction that has been > assigned > - /* copy old commit logs to new data dir */ > - copy

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 sets fixed DH > parameters with SSL_CTX_set_tmp_d

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 f

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. > > Pa

Re: [HACKERS] Non-empty default log_line_prefix

Re: Jeff Janes 2016-10-12 > Do you think the pushback will come from people who just accept the > defaults? I'm concerned about readability. "2016-10-12 20:14:30.449 CEST" is a lot of digits. My eyes can parse "20:14:30" as a timestamp, but "20:14:30.449" looks more like an IP address. (Admitted

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 < SizeO

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] 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 > w

Re: [HACKERS] process type escape for log_line_prefix

Re: Michael Paquier 2016-02-10 > On Mon, Feb 8, 2016 at 11:32 PM, Andres Freund wrote: > > Frequently when reading postgres logs to do some post mortem analysis > > I'm left wondering what process emitted an error/log message. After the > > fact it's often hard to know wether an error message wa

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 trying

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 intern

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] process type escape for log_line_prefix

Re: Jeff Janes 2016-10-14 > I don't know why you would have to change %q though. I assume you would > just stick %a in from of %q, if that is what you wanted to do. But I've > never used %q myself. I got it the wrong way round - the change will be that %a will be available in non-session conte

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] 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 is > not defined. We can also have a parametrer to

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 pg_ea

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 fa

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 pg_log/postgresql-2016-10-27_185100.log > csvlog pg_log/postgre

[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: https://buildd.debian.org/status/fetch.p

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

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 binary

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] 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] Shared memory changes in 9.4?

[redirecting to -hackers] Re: Robert Haas 2014-05-28 > On Tue, May 27, 2014 at 8:22 PM, Maciek Sakrejda wrote: > > On Mon, May 26, 2014 at 12:24 AM, Andres Freund > > wrote: > >> Any chance you're using a 9.3 configuration file instead of the one > >> generated by initdb? > >> dynamic_shared_m

Re: [HACKERS] Shared memory changes in 9.4?

Re: Andres Freund 2014-06-12 <20140612094112.gz8...@alap3.anarazel.de> > > * Make initdb determine the best shm type for this platform and write > > it into postgresql.conf as it does now. > > * If no dynamic_shared_memory_type is found in the config, default to > > "none". > > * Modify the thr

Re: [HACKERS] postgresql.auto.conf read from wrong directory

Re: Amit Kapila 2014-06-13 > Agreed, I had mentioned in Notes section of document. Apart from that > I had disallowed parameters that are excluded from postgresql.conf by > initdb (Developer options) and they are recommended in user manual > to be not used in production. Excluding developer opt

Re: [HACKERS] postgresql.auto.conf read from wrong directory

Re: Amit Kapila 2014-06-16 > Developer options are mainly for debugging information or might help in one > of the situations, so I thought somebody might not want them to be part of > server configuration once they are set. We already disallow parameters like > config_file, transaction_isolation

[HACKERS] Is analyze_new_cluster.sh still useful?

Hi, now that we have vacuumdb --all --analyze-in-stages in 9.4, wouldn't it make sense to get rid of the analyze_new_cluster.sh file which pg_upgrade writes? The net content is a single line which could as well be printed by pg_upgrade itself. Instead of an lengthy explanation how to invoke that m

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

Re: Tom Lane 2014-06-18 <21034.1403110...@sss.pgh.pa.us> > Christoph Berg writes: > > now that we have vacuumdb --all --analyze-in-stages in 9.4, wouldn't > > it make sense to get rid of the analyze_new_cluster.sh file which > > pg_upgrade writes? The net content

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

Re: Jeff Janes 2014-06-20 > On Wed, Jun 18, 2014 at 8:41 AM, Christoph Berg > wrote: > > Hi, > > > > now that we have vacuumdb --all --analyze-in-stages in 9.4, wouldn't > > it make sense to get rid of the analyze_new_cluster.sh file which > > pg_upgrade

[HACKERS] postgresql.auto.conf and reload

I've just run into this: $ psql -p 5433 (that port is configured in postgresql.conf) # alter system set port = 5494; ... restart the server $ psql -p 5494 # select pg_reload_conf(); 2014-06-25 14:22:07 CEST [11297-4] LOG: received SIGHUP, reloading configuration files 2014-06-25 14:22:07 CE

[HACKERS] ALTER SYSTEM RESET?

Hi, is there a reason there's no ALTER SYSTEM RESET? The natural idiom to reset SET statements is "RESET guc;", I don't think "SET guc = default;" is in use much, so "ALTER SYSTEM RESET guc;" would be the natural way to try. Also, ALTER SYSTEM SET/RESET seems to be what oracle does: http://docs.

Re: [HACKERS] postgresql.auto.conf and reload

Re: Amit Kapila 2014-06-25 > On Wed, Jun 25, 2014 at 6:11 PM, Christoph Berg wrote: > > > > I've just run into this: > > > > $ psql -p 5433 (that port is configured in postgresql.conf) > > # alter system set port = 5494; > > > > ... rest

Re: [HACKERS] postgresql.auto.conf and reload

Re: Amit Kapila 2014-06-25 > The main reason behind such such a behaviour after restart is > that there are duplicate entries, one in postgresql.conf and > another in postgresql.conf. It always first read postgresql.conf > and then .auto file and applies the changed parameters one by one, > so w

[HACKERS] [PATCH] log_{directory,filename} doc fixes

Hi, The defaults for log_directory and log_filename were undocumented, and the log_filename docs still refered to a config example that was removed with 8.4 deprecation of epoch-based logfilenames. Christoph -- c...@df7cb.de | http://www.df7cb.de/ diff --git a/doc/src/sgml/config.sgml b/doc/src/

Re: [HACKERS] ALTER SYSTEM RESET?

Re: Amit Kapila 2014-06-26 > On Wed, Jun 25, 2014 at 9:56 PM, Vik Fearing wrote: > > On 06/25/2014 03:04 PM, Amit Kapila wrote: > > > Currently you can achieve that by > > > "ALTER SYSTEM RESET guc = Default;". > > > However it will be good to have support for RESET as well. I think it > > > sh

Re: [HACKERS] postgresql.auto.conf and reload

Re: Amit Kapila 2014-06-26 > On Wed, Jun 25, 2014 at 7:52 PM, Christoph Berg wrote: > > Re: Amit Kapila 2014-06-25 < > caa4ek1+f9ztogvvw-wyj2+vt0k8_jxtziqhp8ivb7wdo1w1...@mail.gmail.com> > > > > > I think maintaining values both in postgresql.conf and by Al

Re: [HACKERS] ALTER SYSTEM RESET?

Re: Vik Fearing 2014-06-27 <53ad15f7.2060...@dalibo.com> > On 06/27/2014 08:49 AM, Vik Fearing wrote: > > This third patch reformats the documentation in the way I expected it to > > be committed. > > Amit, > > I added this to the next commitfest with your name as reviewer. > > https://commitfes

Re: [HACKERS] NUMA packaging and patch

Re: Kevin Grittner 2014-06-09 <1402267501.4.yahoomail...@web122304.mail.ne1.yahoo.com> > @@ -536,6 +539,24 @@ PGSharedMemoryCreate(Size size, bool makePrivate, int > port, >*/ > } > > +#ifdef USE_LIBNUMA > + /* > + * If this is not a private segment and we are

Re: [HACKERS] NUMA packaging and patch

Re: Kevin Grittner 2014-07-01 <1404213492.98740.yahoomail...@web122306.mail.ne1.yahoo.com> > Andres Freund wrote: > > On 2014-07-01 11:01:04 +0200, Christoph Berg wrote: > > >> How much difference would it make if numactl --interleave=all > >> was used ins

Re: [HACKERS] /proc/self/oom_adj is deprecated in newer Linux kernels

Re: Tom Lane 2014-06-23 <17054.1403542...@sss.pgh.pa.us> > > While I'd love to reduce the number of future installations without > > this fix in place, I respect the decision to honor project policy. At > > the same time, this change does not break anything. It introduces new > > environment variab

Re: [HACKERS] /proc/self/oom_adj is deprecated in newer Linux kernels

Re: Tom Lane 2014-07-01 <20654.1404247...@sss.pgh.pa.us> > Yeah, I'm unexcited about this proposal. In any case, given the two > existing APIs we have to deal with, allowing PG_OOM_ADJUST_VALUE to > default to "0" is sane in both APIs but a default for the file name > can work for only one. Nod.

Re: [HACKERS] buildfarm and "rolling release" distros

Re: Craig Ringer 2014-07-02 <53b39638.9010...@2ndquadrant.com> > > +1. The buildfarm has one such member already, anchovy, and I recall it > > having given at least one helpful forewarning. It shows as "Arch Linux > > testing [updated daily]", which is sufficient annotation for me. Its > > fail

Re: [HACKERS] postgresql.auto.conf and reload

Re: Amit Kapila 2014-07-06 > Another could be that during initdb all the uncommented settings be > written to postgresql.auto.conf file rather than to postgresql.conf. > I think we can do this by changing code in initdb.c->setup_config(). > This will ensure that unless user is changing settings i

Re: [HACKERS] Securing "make check" (CVE-2014-0067)

Re: Noah Misch 2014-06-08 <20140608135713.ga525...@tornado.leadboat.com> > Here's an update that places the socket in a temporary subdirectory of /tmp. > The first attached patch adds NetBSD mkdtemp() to libpgport. The second, > principal, patch uses mkdtemp() to implement this design in pg_regres

Re: [HACKERS] Securing "make check" (CVE-2014-0067)

Re: Noah Misch 2014-07-08 <20140708174125.ga1884...@tornado.leadboat.com> > On Tue, Jul 08, 2014 at 07:02:04PM +0200, Christoph Berg wrote: > > Re: Noah Misch 2014-06-08 <20140608135713.ga525...@tornado.leadboat.com> > > > Here's an update that places the so

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

Hi, here's my review for this patch. Generally, the patch addresses a real need, tables often only turn out to be desired as unlogged if there are performance problems in practice, and the other way round changing an unlogged table to logged is way more involved manually than it could be with thi

Re: [HACKERS] postgresql.auto.conf and reload

Re: Tom Lane 2014-07-08 <28635.1404844...@sss.pgh.pa.us> > > Sounds like a 9.5 feature, though. > > No, ALTER SYSTEM is there now and it needs to work right in its first > release. I will go fix this if nobody else does. I'd like to throw in again that imho this should include ALTER SYSTEM RESET

Re: [HACKERS] Securing "make check" (CVE-2014-0067)

Re: Bruce Momjian 2014-07-08 <20140708202114.gd9...@momjian.us> > > > > I believe pg_upgrade itself still needs a fix. While it's not a > > > > security problem to put the socket in $CWD while upgrading (it is > > > > using -c unix_socket_permissions=0700), this behavior is pretty > > > > unexpecte

Re: [HACKERS] Securing "make check" (CVE-2014-0067)

Re: To Bruce Momjian 2014-07-11 <20140711093923.ga3...@msg.df7cb.de> > Re: Bruce Momjian 2014-07-08 <20140708202114.gd9...@momjian.us> > > > > > I believe pg_upgrade itself still needs a fix. While it's not a > > > > > security problem to put the socket in $CWD while upgrading (it is > > > > > usin

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

Re: Fabrízio de Royes Mello 2014-07-12 > > ... that being the non-WAL-logging with wal_level=minimal, or more? > > This is the first of additional goals, but we have others. Please see [1]. Oh I wasn't aware of the wiki page, I had just read the old thread. Thanks for the pointer. > > > diff

Re: [HACKERS] Securing "make check" (CVE-2014-0067)

Re: Noah Misch 2014-07-12 <20140712170151.ga1985...@tornado.leadboat.com> > Thanks. Preliminary questions: > > > +#ifdef HAVE_UNIX_SOCKETS > > +/* make_temp_sockdir() is invoked at most twice from pg_upgrade.c via > > get_sock_dir() */ > > +#define MAX_TEMPDIRS 2 > > +static int n_tempdirs = 0;

Re: [HACKERS] tab completion for setting search_path

Re: Andres Freund 2014-07-12 <20140712135128.gd3...@awork2.anarazel.de> > I'm also not really happy with the fact that we only complete a single > search_path item. But it's not easy to do better and when looking around > other places (e.g. DROP TABLE) don't support it either. The difference is th

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

Hi Fabrízio, thanks for the speedy new version. Re: Fabrízio de Royes Mello 2014-07-15 > > > > > + > > > > > + if (pass == AT_PASS_SET_LOGGED_UNLOGGED) > > > > > + > > > ATPostAlterSetLoggedUnlogged(RelationGetRelid(rel)); > > > > > > > > This must be done before relation_cl

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

Re: Fabrízio de Royes Mello 2014-07-15 > > What about the wqueue mechanism, though? Isn't that made exactly for > > the kind of catalog updates you are doing? > > > > Works, but this mechanism create a new entry in pg_class for toast, so it's > a little different than use the cluster_rel that ge

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

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] [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] 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] [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] [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] 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] 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] 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 late

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 it

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 an older version somewhere? > > > > Well crake is a Fedora box - and

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 th

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

Re: Tom Lane 2017-07-28 <3254.1501276...@sss.pgh.pa.us> > Christoph Berg 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.GC704%40msgid.df7cb.

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) > > ... which is unchanged from the beta2 output. > > > I am not able t

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

Re: Tom Lane 2017-07-31 <30582.1501508...@sss.pgh.pa.us> > Christoph Berg 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 > >>> key

[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&arch=mips64el&ver=9.6.4-1&stamp=1502374949&raw=0 https://buildd.debian.org/status/fetch.php?pkg=postgresql-10&arch=mips64el&ver=10%7Ebeta3-1&stamp=15

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&arch=mips64el&ver=9.6.4-1&stamp=1502374949&raw=0 > https

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 problem on kfreebsd. Is there anything I could dump so we understand the

  1   2   3   4   >