from:"Christoph Berg"

Re: [HACKERS] Add Roman numeral conversion to to_number

2017-09-17 Thread Christoph Berg

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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Surjective functional indexes

2017-09-13 Thread Christoph Berg

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>
> > > +   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 any attribute used in the indexed
> > > +   expression is changed, then value of index expression is also 
> > > changed.
> > This is Just Wrong. I still think what you are doing here doesn't have
> > anything to do with the function being injective or not.
> 
> Sorry, can you please explain what is wrong?

I don't get why you are reasoning about "projection" ->
"non-injective" -> "injective". Can't you try to explain what this
functionality is about without abusing math terms that just mean
something else in the rest of the world?

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Surjective functional indexes

2017-09-13 Thread Christoph Berg

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 any attribute used in the indexed
> +   expression is changed, then value of index expression is also changed.

This is Just Wrong. I still think what you are doing here doesn't have
anything to do with the function being injective or not.

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-09-11 Thread Christoph Berg

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, my error was that the
breakpoint should have been one line earlier because of elog()
internals.

The outcome is that Andres diagnosed it as a bug in mysql_fdw;
ExecInitExpr() should never get toplevel lists anymore.

Bug filed: https://github.com/EnterpriseDB/mysql_fdw/issues/147

Thanks,
Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-09-11 Thread Christoph Berg

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 
./build/../src/backend/executor/execProcnode.c:164
164 ./build/../src/backend/executor/execProcnode.c: Datei oder Verzeichnis 
nicht gefunden.
(gdb) p pprint(node)
$1 = void


2017-09-11 11:27:53.268 CEST [31066] postgres@postgres ANWEISUNG:  SELECT 
test_param_where();
   {RESULT 
   :startup_cost 0.00 
   :total_cost 0.26 
   :plan_rows 1 
   :plan_width 4 
   :parallel_aware false 
   :parallel_safe false 
   :plan_node_id 0 
   :targetlist (
  {TARGETENTRY 
  :expr 
 {FUNCEXPR 
 :funcid 16402 
 :funcresulttype 2278 
 :funcretset false 
 :funcvariadic false 
 :funcformat 0 
 :funccollid 0 
 :inputcollid 0 
 :args <> 
 :location 7
 }
  :resno 1 
  :resname test_param_where 
  :ressortgroupref 0 
  :resorigtbl 0 
  :resorigcol 0 
  :resjunk false
  }
   )
   :qual <> 
   :lefttree <> 
   :righttree <> 
   :initPlan <> 
   :extParam (b)
   :allParam (b)
   :resconstantqual <>
   }


Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-09-11 Thread Christoph Berg

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:  ExecInitExprRec, execExpr.c:2031

The problem happens on the 6th iteration of this loop:

CREATE FOREIGN TABLE numbers(a int, b varchar(255)) SERVER mysql_svr OPTIONS 
(dbname 'testdb', table_name 'numbers');

create or replace function test_param_where() returns void as $$
DECLARE
  n varchar;
BEGIN
  FOR x IN 1..9 LOOP
select b into n from numbers where a=x;
raise notice 'Found number %', n;
  end loop;
  return;
END
$$ LANGUAGE plpgsql;

SELECT test_param_where();

***
*** 345,368 
  NOTICE:  Found number Three
  NOTICE:  Found number Four
  NOTICE:  Found number Five
! NOTICE:  Found number Six
! NOTICE:  Found number Seven
! NOTICE:  Found number Eight
! NOTICE:  Found number Nine
!  test_param_where 
! --
!  
! (1 row)
! 
  DELETE FROM employee;
...
--- 344,365 
  NOTICE:  Found number Three
  NOTICE:  Found number Four
  NOTICE:  Found number Five
! ERROR:  unrecognized node type: 217
! CONTEXT:  SQL statement "select bfrom numbers where a=x"
! PL/pgSQL function test_param_where() line 6 at SQL statement
! /*
  DELETE FROM employee;
...

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-09-11 Thread Christoph Berg

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't expect that
> failure in very many places.  If you could get a stack trace from
> the errfinish call, it might help narrow things down.
> 
> Offhand my bet is on mysql_fdw needing an update for some PG10
> change, but that's just a guess.

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:  ExecInitExprRec, execExpr.c:2031

(gdb) b execExpr.c:2031
Breakpoint 2 at 0x55d5a728e530: file 
./build/../src/backend/executor/execExpr.c, line 2031.
(gdb) c
Continuing.

Breakpoint 2, ExecInitExprRec (node=, 
parent=parent@entry=0x55d5a8766368, 
state=state@entry=0x55d5a87667d0, resv=resv@entry=0x55d5a87667d8, 
resnull=resnull@entry=0x55d5a87667d5 "")
at ./build/../src/backend/executor/execExpr.c:2034
2034./build/../src/backend/executor/execExpr.c: Datei oder Verzeichnis 
nicht gefunden.
(gdb) bt f
#0  ExecInitExprRec (node=, parent=parent@entry=0x55d5a8766368, 
state=state@entry=0x55d5a87667d0, 
resv=resv@entry=0x55d5a87667d8, resnull=resnull@entry=0x55d5a87667d5 "")
at ./build/../src/backend/executor/execExpr.c:2034
scratch = {opcode = 20, resvalue = 0x55d5a87667d8, resnull = 
0x55d5a87667d5 "", d = {fetch = {
  last_var = -1468635040}, var = {attnum = -1468635040, vartype = 
21973}, wholerow = {
  var = 0x55d5a8766860, first = -72 '\270', slow = 104 'h', 
  tupdesc = 0x7f9e21220140 , junkFilter = 
0x55d5}, assign_var = {
  resultnum = -1468635040, attnum = 21973}, assign_tmp = {resultnum 
= -1468635040}, constval = {
  value = 94376142727264, isnull = -72 '\270'}, func = {finfo = 
0x55d5a8766860, 
  fcinfo_data = 0x55d5a87668b8, fn_addr = 0x7f9e21220140 
, nargs = 0}, boolexpr = {
  anynull = 0x55d5a8766860 "@\001\"!\236\177", jumpdone = 
-1468634952}, qualexpr = {
  jumpdone = -1468635040}, jump = {jumpdone = -1468635040}, 
nulltest_row = {argdesc = 0x55d5a8766860}, 
param = {paramid = -1468635040, paramtype = 21973}, casetest = 
{value = 0x55d5a8766860, 
  isnull = 0x55d5a87668b8 "`hv\250\325U"}, make_readonly = {value = 
0x55d5a8766860, 
  isnull = 0x55d5a87668b8 "`hv\250\325U"}, iocoerce = {finfo_out = 
0x55d5a8766860, 
  fcinfo_data_out = 0x55d5a87668b8, finfo_in = 0x7f9e21220140 
, 
  fcinfo_data_in = 0x55d5}, sqlvaluefunction = {svf = 
0x55d5a8766860}, nextvalueexpr = {
  seqid = 2826332256, seqtypid = 21973}, arrayexpr = {elemvalues = 
0x55d5a8766860, 
  elemnulls = 0x55d5a87668b8 "`hv\250\325U", nelems = 555876672, 
elemtype = 32670, elemlength = 0, 
  elembyval = 0 '\000', elemalign = 0 '\000', multidims = -43 
'\325'}, arraycoerce = {
  coerceexpr = 0x55d5a8766860, resultelemtype = 2826332344, 
  elemfunc = 0x7f9e21220140 , amstate = 
0x55d5}, row = {
  tupdesc = 0x55d5a8766860, elemvalues = 0x55d5a87668b8, 
  elemnulls = 0x7f9e21220140  
"UH\211\345ATSH\201", }, 
rowcompare_step = {finfo = 0x55d5a8766860, fcinfo_data = 
0x55d5a87668b8, 
  fn_addr = 0x7f9e21220140 , jumpnull = 0, 
jumpdone = 21973}, rowcompare_final = {
  rctype = 2826332256}, minmax = {values = 0x55d5a8766860, nulls = 
0x55d5a87668b8 "`hv\250\325U", 
  nelems = 555876672, op = (unknown: 32670), finfo = 
0x55d5, fcinfo_data = 0x55d5a86d5df8}, 
fieldselect = {fieldnum = 26720, resulttype = 21973, argdesc = 
0x55d5a87668b8}, fieldstore = {
  fstore = 0x55d5a8766860, argdesc = 0x55d5a87668b8, values = 
0x7f9e21220140 , 
  nulls = 0x55d5 , 
  ncolumns = -1469227528}, arrayref_subscript = {state = 
0x55d5a8766860, off = -1468634952, 
  isupper = -43 '\325', jumpdone = 555876672}, arrayref = {state = 
0x55d5a8766860}, domaincheck = {
  constraintname = 0x55d5a8766860 "@\001\"!\236\177", checkvalue = 
0x55d5a87668b8, 
  checknull = 0x7f9e21220140  
"UH\211\345ATSH\201", , 
  resulttype = 0}, convert_rowtype = {convert = 0x55d5a8766860, 
indesc = 0x55d5a87668b8, 
  outdesc = 0x7f9e21220140 , map = 
0x55d5, initialized = -8 '\370'}, 
scalararrayop = {element_type = 2826332256, useOr = -43 '\325', 
typlen = 0, typbyval = -72 '\270', 
  typalign = 104

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

2017-09-10 Thread Christoph Berg

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 number Six
! NOTICE:  Found number Seven
! NOTICE:  Found number Eight
! NOTICE:  Found number Nine
!  test_param_where 
! --
!  
! (1 row)
! 
  DELETE FROM employee;
  DELETE FROM department;
  DELETE FROM empdata;
--- 344,352 
  NOTICE:  Found number Three
  NOTICE:  Found number Four
  NOTICE:  Found number Five
! ERROR:  unrecognized node type: 217
! CONTEXT:  SQL statement "select bfrom numbers where a=x"
! PL/pgSQL function test_param_where() line 6 at SQL statement
  DELETE FROM employee;
  DELETE FROM department;
  DELETE FROM empdata;

mysql_fdw master at 7d084c59, PG10 at 6913d066.


The testsuite was running against this mysql schema:

CREATE DATABASE testdb;
USE testdb;

CREATE USER 'foo'@'127.0.0.1' IDENTIFIED BY 'bar';
GRANT ALL PRIVILEGES ON testdb.* TO 'foo'@'127.0.0.1';

CREATE TABLE department(department_id int, department_name text, PRIMARY KEY 
(department_id));
CREATE TABLE employee(emp_id int, emp_name text, emp_dept_id int, PRIMARY KEY 
(emp_id));
CREATE TABLE empdata (emp_id int, emp_dat blob, PRIMARY KEY (emp_id));
CREATE TABLE numbers(a int PRIMARY KEY, b varchar(255));

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-09-04 Thread Christoph Berg

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 there is a use of sigsetjmp earlier in that clamav
> routine, I would not assume that that's the same issue.  The bug
> I suspect we are looking at here is very specific to sigsetjmp
> callers: it usually amounts to the compiler unsafely trying to
> use the same temporary location for multiple purposes.

It appears to have been the same issue - non-long ints spilled on the
stack and loaded back as long int:

Changes:
 gcc-7 (7.2.0-3) unstable; urgency=high
 .
   * Update to SVN 20170901 (r251583) from the gcc-7-branch.
 - Fix PR target/81504 (PPC), PR c++/82040.
   * Apply proposed patch for PR target/81803 (James Cowgill), conditionally
 for mips* targets. Closes: #871514.

The package built successfully on mips64el now.

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] obsolete code in pg_upgrade

2017-08-25 Thread Christoph Berg

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.  There's probably room for debate about whether a
> > pg_upgrade needs to support direct upgrades FROM very old releases,
> > but we need not decide anything about that right now.
> > 
> > I think you could go ahead and rip out this code, but as it seems like
> > a non-critical change, -1 for back-patching it.
> 
> committed to PG10 and master

This #define seems to be obsolete now as well:
src/bin/pg_upgrade/pg_upgrade.h:#define TABLE_SPACE_SUBDIRS_CAT_VER 20100

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-08-22 Thread Christoph Berg

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 = false;
> 
> If that fixes it, it's definitely a compiler bug.  That function does
> not change needCleanup after the sigsetjmp call, so per POSIX it
> should not have to label the variable volatile.  This is far from
> being the first such bug we've seen though.

In the meantime, gcc-7 is at version 7.2.0-1, so I gave 9.6 on
mips64el a new try. It's still failing at initdb time, and indeed
adding "volatile" makes initdb proceed, but then the rest of the
testsuite fails in various ways:

DETAIL:  Failed process was running: CREATE TABLE enumtest_child (parent 
rainbow REFERENCES enumtest_parent);
DETAIL:  Failed process was running: create table trigtest2 (i int references 
trigtest(i) on delete cascade);
DETAIL:  Failed process was running: CREATE TABLE trunc_b (a int REFERENCES 
truncate_a);
DETAIL:  Failed process was running: CREATE SCHEMA evttrig
CREATE TABLE one (col_a SERIAL PRIMARY KEY, col_b text DEFAULT 
'forty two')
CREATE INDEX one_idx ON one (col_b)
CREATE TABLE two (col_c INTEGER CHECK (col_c > 0) REFERENCES 
one DEFAULT 42);

Hopefully the compiler gets fixed soonish on mips64el...

Thanks for the analysis,
Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-08-15 Thread Christoph Berg

Re: Thomas Munro 2017-08-10

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

2017-08-14 Thread Christoph Berg

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 problem better?

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-08-13 Thread Christoph Berg

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
> https://buildd.debian.org/status/fetch.php?pkg=postgresql-10=mips64el=10%7Ebeta3-1=1502535836=0
> 
> All other architectures have succeeded, as well as the 9.6.4 build for
> Debian/stretch (stable) on mips64el. The difference might be the
> compiler version (6.3.0 vs 7.1.0).

Seems to be a gcc-7 problem affecting several packages on mips64el:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871514

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-08-13 Thread Christoph Berg

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 architectures have succeeded, as well as the 9.6.4 build for
Debian/stretch (stable) on mips64el. The difference might be the
compiler version (6.3.0 vs 7.1.0).

Command was: "initdb" -D 
"/home/myon/postgresql-9.6/postgresql-9.6-9.6.3/build/src/t
est/regress/./tmp_check/data" --noclean --nosync > 
"/home/myon/postgresql-9.6/postgr
esql-9.6-9.6.3/build/src/test/regress/log/initdb.log" 2>&1

 build/src/test/regress/log/initdb.log 
Running in noclean mode.  Mistakes will not be cleaned up.
The files belonging to this database system will be owned by user "myon".
This user must also own the server process.

The database cluster will be initialized with locales
  COLLATE:  de_DE.utf8
  CTYPE:de_DE.utf8
  MESSAGES: C
  MONETARY: de_DE.utf8
  NUMERIC:  de_DE.utf8
  TIME: de_DE.utf8
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "german".

Data page checksums are disabled.

creating directory 
/home/myon/postgresql-9.6/postgresql-9.6-9.6.3/build/src/test/regress/./tmp_check/data
 ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... posix
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... Segmentation fault (core dumped)
child process exited with exit code 139


$ gdb build/tmp_install/usr/lib/postgresql/9.6/bin/postgres 
build/src/test/regress/tmp_check/data/core 
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mips64el-linux-gnuabi64".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from 
build/tmp_install/usr/lib/postgresql/9.6/bin/postgres...done.
[New LWP 24217]
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/mips64el-linux-gnuabi64/libthread_db.so.1".
Core was generated by 
`/home/myon/postgresql-9.6/postgresql-9.6-9.6.3/build/tmp_install/usr/lib/postgr'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00aababa6634 in EventTriggerEndCompleteQuery ()
at ./build/../src/backend/commands/event_trigger.c:1263
1263MemoryContextDelete(currentEventTriggerState->cxt);
(gdb) bt full
#0  0x00aababa6634 in EventTriggerEndCompleteQuery ()
at ./build/../src/backend/commands/event_trigger.c:1263
prevstate = 
#1  0x00aabad6d508 in ProcessUtilitySlow (
parsetree=parsetree@entry=0xaac3688428, 
queryString=queryString@entry=0xaac3687888 "REVOKE ALL on pg_authid FROM 
public;\n", context=context@entry=PROCESS_UTILITY_TOPLEVEL, 
params=params@entry=0x0, 
completionTag=completionTag@entry=0x985218 "", 
dest=0xaabb0a0378 ) at 
./build/../src/backend/tcop/utility.c:1582
isTopLevel = 1 '\001'
isCompleteQuery = 1 '\001'
needCleanup = 0 '\000'
commandCollected = 
address = {classId = 2, objectId = 0, objectSubId = 0}
secondaryObject = {classId = 0, objectId = 0, objectSubId = 0}
#2  0x00aabad6c6cc in standard_ProcessUtility (parsetree=0xaac3688428, 
queryString=0xaac3687888 "REVOKE ALL on pg_authid FROM public;\n", 
context=, params=0x0, dest=0xaabb0a0378 , 
completionTag=0x985218 "") at ./build/../src/backend/tcop/utility.c:907
isTopLevel = 1 '\001'
__func__ = "standard_ProcessUtility"
#3  0x00aabad6d33c in ProcessUtility (parsetree=, 
queryString=, context=, params=, 
dest=, completionTag=)
at ./build/../src/backend/tcop/utility.c:336
No locals.
#4  0x00aabad68e80 in PortalRunUtility (portal=portal@entry=0xaac368a8a8, 
utilityStmt=utilityStmt@entry=0xaac3688428, 
isTopLevel=isTopLevel@entry=1 '\001', 
setHoldSnapshot=setHoldSnapshot@entry=0 '\000', 
dest=0xaabb0a0378 , completionTag=0x985218 "")
at ./build/../src/backend/tcop/pquery.c:1193
snapshot = 0xaac368c8e8
__func__ = "PortalRunUtility"
#5  0x00aabad69d70 in PortalRunMulti (portal=portal@entry=0xaac368a8a8,

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

2017-07-31 Thread Christoph Berg

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 
> >>> key 0xd500080, needed 0xd600080)
> 
> Can we see the Perl-related output from configure, particularly the new
> lines about CFLAGS?

$ ./configure --with-perl

checking whether to build Perl modules... yes

checking for perl... /usr/bin/perl
configure: using perl 5.26.0
checking for Perl archlibexp... /usr/lib/x86_64-kfreebsd-gnu/perl/5.26
checking for Perl privlibexp... /usr/share/perl/5.26
checking for Perl useshrplib... true
checking for CFLAGS recommended by Perl... -D_REENTRANT -D_GNU_SOURCE -DDEBIAN 
-fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64
checking for CFLAGS to compile embedded Perl... -DDEBIAN
checking for flags to link embedded Perl...   -fstack-protector-strong 
-L/usr/local/lib  -L/usr/lib/x86_64-kfreebsd-gnu/perl/5.26/CORE -lperl -ldl -lm 
-lpthread -lc -lcrypt

checking for perl.h... yes
checking for libperl... yes

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-07-31 Thread Christoph Berg

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 to reproduce this issue on my Windows or Linux box. Have
> you deleted Util.c and SPI.c files before starting with the build?

That was from a git checkout which didn't contain the files.
Retrying anyway:

[127] 10:28 myon@experimental_k-a-dchroot.falla:~/po/po/src/pl/plperl $ make 
clean
rm -f plperl.so   libplperl.a  libplperl.pc
rm -f SPI.c Util.c plperl.o SPI.o Util.o  perlchunks.h plperl_opmask.h
rm -rf results/ regression.diffs regression.out tmp_check/ tmp_check_iso/ log/ 
output_iso/
[0] 10:29 myon@experimental_k-a-dchroot.falla:~/po/po/src/pl/plperl $ make
'/usr/bin/perl' ./text2macro.pl --strip='^(\#.*|\s*)$' plc_perlboot.pl 
plc_trusted.pl > perlchunks.h
'/usr/bin/perl' plperl_opmask.pl plperl_opmask.h
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement 
-Wendif-labels -Wmissing-format-attribute -Wformat-security 
-fno-strict-aliasing -fwrapv -fexcess-precision=standard -O2 -fPIC -I. -I. 
-I../../../src/include -D_GNU_SOURCE   
-I/usr/lib/x86_64-kfreebsd-gnu/perl/5.26/CORE  -c -o plperl.o plperl.c
'/usr/bin/perl' /usr/share/perl/5.26/ExtUtils/xsubpp -typemap 
/usr/share/perl/5.26/ExtUtils/typemap SPI.xs >SPI.c
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement 
-Wendif-labels -Wmissing-format-attribute -Wformat-security 
-fno-strict-aliasing -fwrapv -fexcess-precision=standard -O2 -fPIC -I. -I. 
-I../../../src/include -D_GNU_SOURCE   
-I/usr/lib/x86_64-kfreebsd-gnu/perl/5.26/CORE  -c -o SPI.o SPI.c
'/usr/bin/perl' /usr/share/perl/5.26/ExtUtils/xsubpp -typemap 
/usr/share/perl/5.26/ExtUtils/typemap Util.xs >Util.c
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement 
-Wendif-labels -Wmissing-format-attribute -Wformat-security 
-fno-strict-aliasing -fwrapv -fexcess-precision=standard -O2 -fPIC -I. -I. 
-I../../../src/include -D_GNU_SOURCE   
-I/usr/lib/x86_64-kfreebsd-gnu/perl/5.26/CORE  -c -o Util.o Util.c
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement 
-Wendif-labels -Wmissing-format-attribute -Wformat-security 
-fno-strict-aliasing -fwrapv -fexcess-precision=standard -O2 -fPIC -shared -o 
plperl.so plperl.o SPI.o Util.o  -L../../../src/port -L../../../src/common 
-Wl,--as-needed 
-Wl,-rpath,'/usr/lib/x86_64-kfreebsd-gnu/perl/5.26/CORE',--enable-new-dtags  
-fstack-protector-strong -L/usr/local/lib  
-L/usr/lib/x86_64-kfreebsd-gnu/perl/5.26/CORE -lperl -ldl -lm -lpthread -lc 
-lcrypt 
[0] 10:29 myon@experimental_k-a-dchroot.falla:~/po/po/src/pl/plperl $ make check
make -C ../../../src/test/regress pg_regress
make[1]: Verzeichnis 
„/home/myon/postgresql-10/postgresql-10-10~beta2/src/test/regress“ wird betreten
make -C ../../../src/port all
make[2]: Verzeichnis „/home/myon/postgresql-10/postgresql-10-10~beta2/src/port“ 
wird betreten
make -C ../backend submake-errcodes
make[3]: Verzeichnis 
„/home/myon/postgresql-10/postgresql-10-10~beta2/src/backend“ wird betreten
make[3]: Für das Ziel „submake-errcodes“ ist nichts zu tun.
make[3]: Verzeichnis 
„/home/myon/postgresql-10/postgresql-10-10~beta2/src/backend“ wird verlassen
make[2]: Verzeichnis „/home/myon/postgresql-10/postgresql-10-10~beta2/src/port“ 
wird verlassen
make -C ../../../src/common all
make[2]: Verzeichnis 
„/home/myon/postgresql-10/postgresql-10-10~beta2/src/common“ wird betreten
make -C ../backend submake-errcodes
make[3]: Verzeichnis 
„/home/myon/postgresql-10/postgresql-10-10~beta2/src/backend“ wird betreten
make[3]: Für das Ziel „submake-errcodes“ ist nichts zu tun.
make[3]: Verzeichnis 
„/home/myon/postgresql-10/postgresql-10-10~beta2/src/backend“ wird verlassen
make[2]: Verzeichnis 
„/home/myon/postgresql-10/postgresql-10-10~beta2/src/common“ wird verlassen
make[1]: Verzeichnis 
„/home/myon/postgresql-10/postgresql-10-10~beta2/src/test/regress“ wird 
verlassen
rm -rf '/home/myon/postgresql-10/postgresql-10-10~beta2'/tmp_install
/bin/mkdir -p '/home/myon/postgresql-10/postgresql-10-10~beta2'/tmp_install/log
make -C '../../..' 
DESTDIR='/home/myon/postgresql-10/postgresql-10-10~beta2'/tmp_install install 
>'/home/myon/postgresql-10/postgresql-10-10~beta2'/tmp_install/log/install.log 
2>&1
PATH="/home/myon/postgresql-10/postgresql-10-10~beta2/tmp_install/usr/local/pgsql/bin:$PATH"
 
LD_LIBRARY_PATH="/home/myon/postgresql-10/postgresql-10-10~beta2/tmp_install/usr/local/pgsql/lib"
 ../../../src/test/regress/pg_regress --temp-instance=./tmp_check --inputdir=. 
--bindir= --dbname=pl_regression --load-extension=plperl  
--load-extension=plperlu plperl plperl_lc plperl_trigger plperl_shared 
plperl_elog plperl_util plperl_init plperlu plperl_array plperl_plperlu

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

2017-07-30 Thread Christoph Berg

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.GC704%40msgid.df7cb.de
> > https://buildd.debian.org/status/fetch.php?pkg=postgresql-10=kfreebsd-amd64=10~beta2-1=1499947011=0
> 
> So it'd be interesting to know if it's any better with HEAD ...

Unfortunately not:

== creating database "pl_regression"  ==
CREATE DATABASE
ALTER DATABASE
== installing plperl  ==
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
connection to server was lost

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.

Christoph

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-07-17 Thread Christoph Berg

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 the port machine likes it.

The build works now, thanks!

https://people.debian.org/~glaubitz/postgresql-10_10~beta2-1+b2_m68k.build

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-07-13 Thread Christoph Berg

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 we have no problems on Linux, only on
> Windows.

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

https://buildd.debian.org/status/fetch.php?pkg=postgresql-10=kfreebsd-amd64=10~beta2-1=1499947011=0

(Arguably, this is a toy architecture, so we can just leave it unfixed
there without any harm...)

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PostgreSQL - Weak DH group

2017-07-13 Thread Christoph Berg

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 as a security issue, would we backpatch it?
> If we do, then it definitely makes sense to put something in pg10.  I'm
> not sure that this patch is it, though -- perhaps it makes sense to put
> a minimal fix in older branches, and let the new feature wait for pg11?

Making it user-configurable seems pretty minimal to me. Everything
else would probably require lengthy explanations about which file
could hold which contents, and this confusion seems to be part of the
problem.

Fwiw, wouldn't it make sense to recreate the default 2048 DH group as
well, maybe each time a new major is branched?

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-07-13 Thread Christoph Berg

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 reply, I was hoping to catch you on IRC, but then
> didn't manage to be around at a time that would fit the timezone
> shift.
> 
> The -O0 build passed the regression tests. Not sure what that means
> for our problem, though.

Fwiw, the problem is fixed with beta2, even with -O2:

https://buildd.debian.org/status/logs.php?pkg=postgresql-10=sparc64

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-05-31 Thread Christoph Berg

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, linux, and openbsd ports.  Looks like we should
> also change the example link commands in dfunc.sgml.

Ack.

> Next question: should we back-patch this change, or just do it in HEAD?

Debian "needs" it for 9.6, but I've already pushed the s390x patch in
the original posting, so I could just live with it being just in head.
But of course it would be nice to have everything in sync.

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-05-31 Thread Christoph Berg

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

textdata bss dec hex filename
-fpic: 79520 9281768   82216   14128 postgres_fdw.so
-fPIC: 79520 9281768   82216   14128 postgres_fdw.so
-> no change

s390x, Debian unstable:

textdata bss dec hex filename
-fpic: 807352552  48   83335   14587 postgres_fdw.so
-fPIC: 812472552  48   83847   14787 postgres_fdw.so
-> +0.61%

arm64, Debian unstable:

textdata bss dec hex filename
-fpic: 641302600  48   66778   104da postgres_fdw.so
-fPIC: 642742600  48   66922   1056a postgres_fdw.so
-> +0.22%

sparc64, Debian unstable:

textdata bss dec hex filename
-fpic: 758043296  48   79148   1352c postgres_fdw.so
-fPIC: 72748 920  48   73716   11ff4 postgres_fdw.so
-> 6.9% decrease (!)

9.6.3, gcc (Debian 6.3.0-18) 6.3.0 20170516, -O2, all objects unstripped
(sparc64 is gcc (Debian 6.3.0-17) 6.3.0 20170510)

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-05-30 Thread Christoph Berg

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 values of "we", sure ;-).

Afaict for all values of "we":

ifeq "$(findstring sparc,$(host_cpu))" "sparc"
CFLAGS_SL = -fPIC
else
CFLAGS_SL = -fpic
endif

https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/makefiles/Makefile.linux

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Surjective functional indexes

2017-05-30 Thread Christoph Berg

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/Projection_(set_theory)
> 
> I have already renamed parameter from "surjective" to "injective".
> But I am ok to do do one more renaming to "projection" if it will be
> considered as better alternative.
> From my point of view, "projection" seems to be clearer for people without
> mathematical background,
> but IMHO this term is overloaded in DBMS context.

With mathematical background, I don't see how your indexes would
exploit surjective or injective properties of the function used. What
you are using is that ->> projects a json value to one of its
components, i.e. the projection/function result does not depend on the
other attributes contained.

> The irony is that in Wikipedia "projection" is explained using
> "surjection" term:)

For the equivalence classes part, which isn't really connected to your
application.

Christoph

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-05-30 Thread Christoph Berg

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 be a difference in efficiency between the two, but some others
> will see some.  Given that most distributions switched to building the
> main executables with -fPIE anyway, to allow for ASLR, it seems unlikely
> that the intra extension overhead is going to be very meaningful in
> comparison.

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.

-fPIC is the default in Debian now, see the discussion starting at
https://lists.debian.org/debian-devel/2016/05/msg00028.html
including the Fedora: 
https://lists.debian.org/debian-devel/2016/05/msg00219.html
and Ubuntu: https://lists.debian.org/debian-devel/2016/05/msg00225.html
situation, which all do that.

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-05-30 Thread Christoph Berg

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 actually supported (unlike the statu quo).
> >> Something like restoring the tablespace to the empty state on boot, if
> >> it's known to need it.
> 
> > Has the danger of making recovery harder after a restart where somebody 
> > forgot to mount some subdirectory ...
> 
> Or even worse, the mount happens after PG starts (and creates directories
> on the root volume, not knowing they should go onto the mount instead).
> 
> I'm too lazy to search the archives right now, but there was some case
> years ago where somebody destroyed their database via an ill-thought-out
> combination of automatic-initdb-if-$PGDATA-isn't-there and slow mounting.
> We'd have to be very sure that any auto-directory-creation behavior didn't
> have a potential for that.  Perhaps doing it only for temp tablespaces
> alleviates some of the risk, but it still seems pretty scary.

stats_temp_directory has the same problem. In that case, the risk of
breaking something by calling mkdir() instead of aborting startup
seems pretty low to me.

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-05-29 Thread Christoph Berg

Re: Jeff Janes 2017-05-29

Re: [HACKERS] Surjective functional indexes

2017-05-29 Thread Christoph Berg

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 the output type can be
> > obtained by some input value.  That's not what you are after here.  The
> > behavior you are describing is a not-injective function.
> > 
> > I think you are right that in practice most functions are not injective.
> >   But I think there is still quite some difference between a function
> > like the one you showed that selects a component from a composite data
> > structure and, for example, round(), where in practice any update is
> > likely to change the result of the function.
> > 
> Thank you, I will rename "surjective" parameter to "injective" with "false" 
> as default value.

I think the term you were looking for is "projection".

https://en.wikipedia.org/wiki/Projection_(set_theory)

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-05-29 Thread Christoph Berg

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 (PIC) suitable for use
>  in a shared library, if supported for the target machine.
>  Such code accesses all constant addresses through a global
>  offset table (GOT).  The dynamic loader resolves the GOT
>  entries when the program starts (the dynamic loader is not
>  part of GCC; it is part of the operating system).  If the
>  GOT size for the linked executable exceeds a machine-
>  specific maximum size, you get an error message from the
>  linker indicating that -fpic does not work; in that case,
>  recompile with -fPIC instead.  (These maximums are 8k on
>  the SPARC and 32k on the m68k and RS/6000.  The 386 has no
>  such limit.)
> 
>  Position-independent code requires special support, and
>  therefore works only on certain machines.  For the 386, GCC
>  supports PIC for System V but not for the Sun 386i.  Code
>  generated for the IBM RS/6000 is always
>  position-independent.
> 
>  When this flag is set, the macros "__pic__" and "__PIC__"
>  are defined to 1.
> 
>-fPIC
>  If supported for the target machine, emit
>  position-independent code, suitable for dynamic linking and
>  avoiding any limit on the size of the global offset table.
>  This option makes a difference on the m68k, PowerPC and
>  SPARC.
> 
>  Position-independent code requires special support, and
>  therefore works only on certain machines.
> 
>  When this flag is set, the macros "__pic__" and "__PIC__"
>  are defined to 2.
> 
> This doesn't mention s390(x), but citus.so 382952 bytes (on amd64) is
> well beyond the 8k/32k limits mentioned above.
> 
> PostgreSQL itself links correctly on s390x:
> ... -I/usr/include/mit-krb5 -fPIC -pie -I../../../../src/include
> 
> 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.

After talking to a s390x Debian porter, -fPIC is the correct flag to
use. The quoted patch made the previously failing builds for citus and
pglogical (which have larger-than-average .so files) on s390x succeed
(and the sparc64 case still works):

--- a/src/makefiles/Makefile.linux
+++ b/src/makefiles/Makefile.linux
@@ -5,7 +5,8 @@ export_dynamic = -Wl,-E
 rpath = -Wl,-rpath,'$(rpathdir)',--enable-new-dtags
 DLSUFFIX = .so
 
-ifeq "$(findstring sparc,$(host_cpu))" "sparc"
+# Enable -fPIC to avoid "relocation truncated to fit" linker errors
+ifneq "$(filter sparc% s390%,$(host_cpu))" ""
 CFLAGS_SL = -fPIC
 else
 CFLAGS_SL = -fpic


The patch was made against 9.6; I'd opt to include it in master and
the back branches.

https://buildd.debian.org/status/logs.php?pkg=citus=s390x
https://buildd.debian.org/status/logs.php?pkg=pglogical=s390x

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-05-24 Thread Christoph Berg

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 hoping to catch you on IRC, but then
didn't manage to be around at a time that would fit the timezone
shift.

The -O0 build passed the regression tests. Not sure what that means
for our problem, though.

> Re: Andres Freund 2017-05-18 
> <20170518184811.7c44jcvwjvnzc...@alap3.anarazel.de>
> > Weird.  Christoph, IIRC you can help gaining access to a porter machine
> > to reproduce this?
> 
> I'll let the build run over night (the machine has 32 cores but is
> dead slow) and see what I can arrange tomorrow. (Peter will already
> have access, it's notker.debian.net.)

Will send you a separate mail for that.

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-05-18 Thread Christoph Berg

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 <20170518184811.7c44jcvwjvnzc...@alap3.anarazel.de>
> Weird.  Christoph, IIRC you can help gaining access to a porter machine
> to reproduce this?

I'll let the build run over night (the machine has 32 cores but is
dead slow) and see what I can arrange tomorrow. (Peter will already
have access, it's notker.debian.net.)

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-05-18 Thread Christoph Berg

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

Thanks,
Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-05-17 Thread Christoph Berg

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 try rebuilding and grabbing the full file.)
> 
> Yes please.  What we can see here looks to be just fallout from
> a failure earlier in the run.

*** 
/home/myon/postgresql-10-10~beta1/build/../src/test/regress/expected/sequence.out
   2017-05-15 23:20:59.0 +0200
--- 
/home/myon/postgresql-10-10~beta1/build/src/test/regress/results/sequence.out  
2017-05-17 22:27:28.834225769 +0200
***
*** 34,44 
--- 34,47 
  CREATE SEQUENCE sequence_test7 AS bigint;
  CREATE SEQUENCE sequence_test8 AS integer MAXVALUE 10;
  CREATE SEQUENCE sequence_test9 AS integer INCREMENT BY -1;
+ ERROR:  MINVALUE (-9223372036854775808) is out of range for sequence data 
type integer
  CREATE SEQUENCE sequence_test10 AS integer MINVALUE -10 START 1;
  CREATE SEQUENCE sequence_test11 AS smallint;
  CREATE SEQUENCE sequence_test12 AS smallint INCREMENT -1;
+ ERROR:  MINVALUE (-9223372036854775808) is out of range for sequence data 
type smallint
  CREATE SEQUENCE sequence_test13 AS smallint MINVALUE -32768;
  CREATE SEQUENCE sequence_test14 AS smallint MAXVALUE 32767 INCREMENT -1;
+ ERROR:  MINVALUE (-9223372036854775808) is out of range for sequence data 
type smallint
  CREATE SEQUENCE sequence_testx AS text;
  ERROR:  sequence type must be smallint, integer, or bigint
  CREATE SEQUENCE sequence_testx AS nosuchtype;
***
*** 54,66 
--- 57,73 
  ERROR:  MAXVALUE (10) is out of range for sequence data type smallint
  ALTER SEQUENCE sequence_test8 AS smallint MAXVALUE 2;  -- ok now
  ALTER SEQUENCE sequence_test9 AS smallint;  -- success, min will be adjusted
+ ERROR:  relation "sequence_test9" does not exist
  ALTER SEQUENCE sequence_test10 AS smallint;  -- fail, min has to be adjusted
  ERROR:  MINVALUE (-10) is out of range for sequence data type smallint
  ALTER SEQUENCE sequence_test10 AS smallint MINVALUE -2;  -- ok now
  ALTER SEQUENCE sequence_test11 AS int;  -- max will be adjusted
  ALTER SEQUENCE sequence_test12 AS int;  -- min will be adjusted
+ ERROR:  relation "sequence_test12" does not exist
  ALTER SEQUENCE sequence_test13 AS int;  -- min and max will be adjusted
+ ERROR:  MINVALUE (-9223372036854775808) is out of range for sequence data 
type integer
  ALTER SEQUENCE sequence_test14 AS int;  -- min and max will be adjusted
+ ERROR:  relation "sequence_test14" does not exist
  ---
  --- test creation of SERIAL column
  ---
***
*** 477,485 
  
--+-++---+---+-+---+-+--+-+---+--
   regression   | public  | sequence_test10| smallint  |
16 |   2 | 0 | 1   | -2 
  | 32767   | 1 | NO
   regression   | public  | sequence_test11| integer   |
32 |   2 | 0 | 1   | 1  
  | 2147483647  | 1 | NO
!  regression   | public  | sequence_test12| integer   |
32 |   2 | 0 | -1  | 
-2147483648  | -1  | -1| NO
!  regression   | public  | sequence_test13| integer   |
32 |   2 | 0 | -32768  | 
-2147483648  | 2147483647  | 1 | NO
!  regression   | public  | sequence_test14| integer   |
32 |   2 | 0 | 32767   | 
-2147483648  | 2147483647  | -1| NO
   regression   | public  | sequence_test2 | bigint|
64 |   2 | 0 | 32  | 5  
  | 36  | 4 | YES
   regression   | public  | sequence_test3 | bigint|
64 |   2 | 0 | 1   | 1  
  | 9223372036854775807 | 1 | NO
   regression   | public  | sequence_test4 | bigint|
64 |   2 | 0 | -1  | 
-9223372036854775808 | -1  | -1| NO
--- 484,490 
  
--+-++---+---+-+---+-+--+-+---+--
   regression   | public  | sequence_test10

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

2017-05-17 Thread Christoph Berg

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 
-fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -I/usr/include/mit-krb5 -no-pie 
-I../../../../src/include -I/<>/build/../src/include -Wdate-time 
-D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -I/usr/include/libxml2  -I/usr/include/tcl8.6 
  -c -o slab.o /<>/build/../src/backend/utils/mmgr/slab.c
In file included from /<>/build/../src/include/postgres.h:47:0,
 from 
/<>/build/../src/backend/utils/mmgr/slab.c:53:
/<>/build/../src/backend/utils/mmgr/slab.c: In function 
'SlabContextCreate':
/<>/build/../src/include/c.h:753:7: error: static assertion 
failed: "MAXALIGN too small to fit int32"
  do { _Static_assert(condition, errmessage); } while(0)
   ^
/<>/build/../src/backend/utils/mmgr/slab.c:198:2: note: in 
expansion of macro 'StaticAssertStmt'
  StaticAssertStmt(MAXIMUM_ALIGNOF >= sizeof(int),
  ^~~~
: recipe for target 'slab.o' failed
make[5]: *** [slab.o] Error 1


The code there is:

/*
 * SlabContextCreate
 *  Create a new Slab context.
 *
 * parent: parent context, or NULL if top-level context
 * name: name of context (for debugging --- string will be copied)
 * blockSize: allocation block size
 * chunkSize: allocation chunk size
 *
 * The chunkSize may not exceed:
 *  MAXALIGN_DOWN(SIZE_MAX) - MAXALIGN(sizeof(SlabBlock)) - SLAB_CHUNKHDRSZ
 *
 */
MemoryContext
SlabContextCreate(MemoryContext parent,
  const char *name,
  Size blockSize,
  Size chunkSize)
{
int chunksPerBlock;
SizefullChunkSize;
SizefreelistSize;
SlabContext *slab;

StaticAssertStmt(offsetof(SlabChunk, slab) +sizeof(MemoryContext) ==
 MAXALIGN(sizeof(SlabChunk)),
 "padding calculation in SlabChunk is wrong");

/* otherwise the linked list inside freed chunk isn't guaranteed to fit */
StaticAssertStmt(MAXIMUM_ALIGNOF >= sizeof(int),
 "MAXALIGN too small to fit int32");

/* chunk, including SLAB header (both addresses nicely aligned) */
fullChunkSize = MAXALIGN(sizeof(SlabChunk) + MAXALIGN(chunkSize));


I don't have the pg_config.h file at hand, but the 9.6 version has
this:

/* The normal alignment of `double', in bytes. */
#define ALIGNOF_DOUBLE 2

/* The normal alignment of `int', in bytes. */
#define ALIGNOF_INT 2

/* The normal alignment of `long', in bytes. */
#define ALIGNOF_LONG 2

/* The normal alignment of `long long int', in bytes. */
#define ALIGNOF_LONG_LONG_INT 2

/* The normal alignment of `short', in bytes. */
#define ALIGNOF_SHORT 2

/* Define as the maximum alignment requirement of any C data type. */
#define MAXIMUM_ALIGNOF 2


I don't think anyone is actually going to run a PG server on m68k, but
the same source package is building libpq5, which is not dispensable.

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] 10beta1 sequence regression failure on sparc64

2017-05-17 Thread Christoph Berg

The sequence regression tests are failing on Debian/sparc64:

 sequence ... FAILED
 polymorphism ... ok
 rowtypes ... ok
 returning... ok
 largeobject  ... ok
 with ... ok
 xml  ... ok
test identity ... ok
test event_trigger... ok
test stats... ok
== shutting down postmaster   ==


 1 of 178 tests failed. 


The differences that caused some tests to fail can be viewed in the
file "/<>/build/src/test/regress/regression.diffs".  A copy of the 
test summary that you see
above is saved in the file 
"/<>/build/src/test/regress/regression.out".

GNUmakefile:130: recipe for target 'check' failed
make[2]: *** [check] Error 1
make[2]: Leaving directory '/<>/build/src/test/regress'
Makefile:28: recipe for target 'check-regress-recurse' failed
make[1]: *** [check-regress-recurse] Error 2
make[1]: Leaving directory '/<>/build/src/test'
GNUmakefile:69: recipe for target 'check-world-src/test-recurse' failed
make: *** [check-world-src/test-recurse] Error 2
make: Leaving directory '/<>/build'
 build/src/test/regress/regression.diffs 
*** 477,485 
  
--+-++---+---+-+---+-+--+-+---+--
   regression   | public  | sequence_test10| smallint  |
16 |   2 | 0 | 1   | -2 
  | 32767   | 1 | NO
   regression   | public  | sequence_test11| integer   |
32 |   2 | 0 | 1   | 1  
  | 2147483647  | 1 | NO
!  regression   | public  | sequence_test12| integer   |
32 |   2 | 0 | -1  | 
-2147483648  | -1  | -1| NO
!  regression   | public  | sequence_test13| integer   |
32 |   2 | 0 | -32768  | 
-2147483648  | 2147483647  | 1 | NO
!  regression   | public  | sequence_test14| integer   |
32 |   2 | 0 | 32767   | 
-2147483648  | 2147483647  | -1| NO
   regression   | public  | sequence_test2 | bigint|
64 |   2 | 0 | 32  | 5  
  | 36  | 4 | YES
   regression   | public  | sequence_test3 | bigint|
64 |   2 | 0 | 1   | 1  
  | 9223372036854775807 | 1 | NO
   regression   | public  | sequence_test4 | bigint|
64 |   2 | 0 | -1  | 
-9223372036854775808 | -1  | -1| NO
--- 484,490 
  
--+-++---+---+-+---+-+--+-+---+--
   regression   | public  | sequence_test10| smallint  |
16 |   2 | 0 | 1   | -2 
  | 32767   | 1 | NO
   regression   | public  | sequence_test11| integer   |
32 |   2 | 0 | 1   | 1  
  | 2147483647  | 1 | NO
!  regression   | public  | sequence_test13| smallint  |
16 |   2 | 0 | -32768  | -32768 
  | 32767   | 1 | NO
   regression   | public  | sequence_test2 | bigint|
64 |   2 | 0 | 32  | 5  
  | 36  | 4 | YES
   regression   | public  | sequence_test3 | bigint|
64 |   2 | 0 | 1   | 1  
  | 9223372036854775807 | 1 | NO
   regression   | public  | sequence_test4 | bigint|
64 |   2 | 0 | -1  | 
-9223372036854775808 | -1  | -1| NO
***
*** 487,500 
   regression   | public  | sequence_test6 | smallint  |
16 |   2 | 0 | 1   | 1  
  | 32767   | 1 | NO

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

2017-05-08 Thread Christoph Berg

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:
> »password_encryption = scram-sha-256«
> 
> However, it works if I put 'scram-sha-256' (with simple quotes).
> 
> The underlying issue is that the '-' character breaks the config checker,
> ISTM that the simple value regex in function "read_conf_file" in module
> "PgCommon.pm" should be extended to allow more chars in unquoted strings, to
> be consistent with lexer definitions in "src/backend/utils/misc/guc-file.l".

I've relaxed the regexps there. It's still not exactly what the PG
parser accepts, but I think it's a superset now, so we should be safe.

https://anonscm.debian.org/cgit/pkg-postgresql/postgresql-common.git/commit/?id=93a2ec91ea83e427fc2e68789e572864e158a32e

> In passing, I would like to point out that the French quotation chevrons
> (guillemets) used on the wrong sides and without spacing is probably eye
> watering pain to any French reader, maybe like using ß in place of B in a
> text. Also utf8 chars might not work properly under some terminal encodings.
> Maybe using simple ascii ">>" and "<<" for the messages would also be more
> portable?

I think »« are used the other way round in German vs. French, that's
probably why it was like that ;). Anyway, we are not quoting output in
most of the error() calls, so I've simply dropped the quotes.

Thanks for spotting and reporting!

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-03-06 Thread Christoph Berg

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 the \? output I left it directly after \g because the help text
starts with "as \g ..." and it is IMHO more closely related to \g than
\gexec and \gset which differ more in functionality.

> unsigned short int expanded;/* expanded/vertical output (if supported
> by
>* output format); 0=no, 1=yes, 2=auto */
> Although there is still code that puts true/false in this variable
> (probably because it was a bool before?), I assume that for new
> code, assigning 0/1/2 should be preferred.

Right. I had seen both being used and went with "true", but "1" is
better style.

Both fixed, thanks for the review! Version 3 attached.

Christoph
-- 
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970  87C6 4C5A 6BAB 12D2 A7AE
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
--- b/doc/src/sgml/ref/psql-ref.sgml
*** Tue Oct 26 21:40:57 CEST 1999
*** 1891,1896 
--- 1891,1908 
  
  

+ \gx [ filename ]
+ \gx [ |command ]
+ 
+ 
+ \gx is equivalent to \g, but
+ forces expanded output mode for this query.
+ 
+ 
+   
+ 
+ 
+   
  \gexec
  
  
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
new file mode 100644
index a52adc8..07efc27
*** a/src/bin/psql/command.c
--- b/src/bin/psql/command.c
*** exec_command(const char *cmd,
*** 906,913 
  		free(fname);
  	}
  
! 	/* \g [filename] -- send query, optionally with output to file/pipe */
! 	else if (strcmp(cmd, "g") == 0)
  	{
  		char	   *fname = psql_scan_slash_option(scan_state,
     OT_FILEPIPE, NULL, false);
--- 906,916 
  		free(fname);
  	}
  
! 	/*
! 	 * \g [filename] -- send query, optionally with output to file/pipe
! 	 * \gx [filename] -- same as \g, with expanded mode forced
! 	 */
! 	else if (strcmp(cmd, "g") == 0 || strcmp(cmd, "gx") == 0)
  	{
  		char	   *fname = psql_scan_slash_option(scan_state,
     OT_FILEPIPE, NULL, false);
*** exec_command(const char *cmd,
*** 920,925 
--- 923,930 
  			pset.gfname = pg_strdup(fname);
  		}
  		free(fname);
+ 		if (strcmp(cmd, "gx") == 0)
+ 			pset.g_expanded = true;
  		status = PSQL_CMD_SEND;
  	}
  
diff --git a/src/bin/psql/common.c b/src/bin/psql/common.c
new file mode 100644
index 5349c39..1aa56ab
*** a/src/bin/psql/common.c
--- b/src/bin/psql/common.c
*** PrintQueryTuples(const PGresult *results
*** 770,775 
--- 770,779 
  {
  	printQueryOpt my_popt = pset.popt;
  
+ 	/* one-shot expanded output requested via \gx */
+ 	if (pset.g_expanded)
+ 		my_popt.topt.expanded = 1;
+ 
  	/* write output to \g argument, if any */
  	if (pset.gfname)
  	{
*** sendquery_cleanup:
*** 1410,1415 
--- 1414,1422 
  		pset.gfname = NULL;
  	}
  
+ 	/* reset \gx's expanded-mode flag */
+ 	pset.g_expanded = false;
+ 
  	/* reset \gset trigger */
  	if (pset.gset_prefix)
  	{
diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c
new file mode 100644
index 91cf0be..c390f87
*** a/src/bin/psql/help.c
--- b/src/bin/psql/help.c
*** slashUsage(unsigned short int pager)
*** 173,178 
--- 173,179 
  	fprintf(output, _("  \\copyright show PostgreSQL usage and distribution terms\n"));
  	fprintf(output, _("  \\errverboseshow most recent error message at maximum verbosity\n"));
  	fprintf(output, _("  \\g [FILE] or ; execute query (and send results to file or |pipe)\n"));
+ 	fprintf(output, _("  \\gx [FILE] as \\g, but force expanded output\n"));
  	fprintf(output, _("  \\gexec execute query, then execute each value in its result\n"));
  	fprintf(output, _("  \\gset [PREFIX] execute query and store results in psql variables\n"));
  	fprintf(output, _("  \\q quit psql\n"));
diff --git a/src/bin/psql/settings.h b/src/bin/psql/settings.h
new file mode 100644
index 195f5a1..70ff181
*** a/src/bin/psql/settings.h
--- b/src/bin/psql/settings.h
*** typedef struct _psqlSettings
*** 91,96 
--- 91,97 
  	printQueryOpt popt;
  
  	char	   *gfname;			/* one-shot file output argument for \g */
+ 	bool		g_expanded;		/* one-shot expanded output requested via \gx */
  	char	   *gset_prefix;	/* one-shot prefix argument for \gset */
  	bool		gexec_flag;		/* one-shot flag to

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

2017-02-21 Thread Christoph Berg

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 will be fixed in Jessie's glibc by backporting this update:

2015-02-12  Joseph Myers  

[BZ #17964]
* sysdeps/powerpc/fpu/e_sqrt.c (__slow_ieee754_sqrt): Use
__builtin_fma instead of relying on contraction of a * b + c.

https://anonscm.debian.org/cgit/pkg-glibc/glibc.git/commit/?h=jessie=b26c084f6eba0057b1cd93e0caf424a1d06bd97e

(Upstream it's probably one of these, didn't dig deeper:
https://sourceware.org/git/?p=glibc.git=search=HEAD=commit=__builtin_fma)

Thanks for the input,
Christoph
-- 
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970  87C6 4C5A 6BAB 12D2 A7AE


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-02-20 Thread Christoph Berg

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, but in some system library.

Christoph
-- 
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970  87C6 4C5A 6BAB 12D2 A7AE


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-02-20 Thread Christoph Berg

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 
#include 
#include 
#include 

double
pg_hypot(double x, double y)
{
double  yx;

/* Some PG-specific code deleted here */

/* Else, drop any minus signs */
x = fabs(x);
y = fabs(y);

/* Swap x and y if needed to make x the larger one */
if (x < y)
{
double  temp = x;

x = y;
y = temp;
}

/*
 * If y is zero, the hypotenuse is x.  This test saves a few cycles in
 * such cases, but more importantly it also protects against
 * divide-by-zero errors, since now x >= y.
 */
if (y == 0.0)
return x;

/* Determine the hypotenuse */
yx = y / x;
return x * sqrt(1.0 + (yx * yx));
}


int main ()
{
//fesetround(FE_TONEAREST);
printf("fegetround is %d\n", fegetround());
double r = pg_hypot(10.0, 10.0);
printf("14 %.14g\n", r);
printf("15 %.15g\n", r);
printf("16 %.16g\n", r);
printf("17 %.17g\n", r);
return 0;
}


Jessie output:
fegetround is 0
14 14.142135623731
15 14.1421356237309
16 14.14213562373095
17 14.142135623730949

Sid output:
fegetround is 0
14 14.142135623731
15 14.142135623731
16 14.14213562373095
17 14.142135623730951


The Sid output is what the point and polygon tests are expecting.

Possible culprit is this bug report from November:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843904
(Though that doesn't explain why it affects 32bit powerpc only.)

Christoph
-- 
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970  87C6 4C5A 6BAB 12D2 A7AE


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-02-20 Thread Christoph Berg

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.php?pkg=postgresql-9.6=powerpc=9.6.1-2~bpo8%2B1=1485184696=0

 build/src/test/regress/regression.diffs 
*** /«PKGBUILDDIR»/build/../src/test/regress/expected/point.out Mon Oct 24 
20:08:51 2016
--- /«PKGBUILDDIR»/build/src/test/regress/results/point.out Mon Jan 23 
15:17:51 2017
***
*** 125,131 
   | (-3,4) |5
   | (-10,0)|   10
   | (-5,-12)   |   13
!  | (10,10)|  14.142135623731
   | (5.1,34.5) | 34.8749193547455
  (6 rows)
  
--- 125,131 
   | (-3,4) |5
   | (-10,0)|   10
   | (-5,-12)   |   13
!  | (10,10)| 14.1421356237309
   | (5.1,34.5) | 34.8749193547455
  (6 rows)
  
***
*** 150,157 
 | (-5,-12)   | (-10,0)|   13
 | (-5,-12)   | (0,0)  |   13
 | (0,0)  | (-5,-12)   |   13
!| (0,0)  | (10,10)|  14.142135623731
!| (10,10)| (0,0)  |  14.142135623731
 | (-3,4) | (10,10)| 14.3178210632764
 | (10,10)| (-3,4) | 14.3178210632764
 | (-5,-12)   | (-3,4) | 16.1245154965971
--- 150,157 
 | (-5,-12)   | (-10,0)|   13
 | (-5,-12)   | (0,0)  |   13
 | (0,0)  | (-5,-12)   |   13
!| (0,0)  | (10,10)| 14.1421356237309
!| (10,10)| (0,0)  | 14.1421356237309
 | (-3,4) | (10,10)| 14.3178210632764
 | (10,10)| (-3,4) | 14.3178210632764
 | (-5,-12)   | (-3,4) | 16.1245154965971
***
*** 221,227 
   | (-10,0)| (0,0)  |   10
   | (-10,0)| (-5,-12)   |   13
   | (-5,-12)   | (0,0)  |   13
!  | (0,0)  | (10,10)|  14.142135623731
   | (-3,4) | (10,10)| 14.3178210632764
   | (-5,-12)   | (-3,4) | 16.1245154965971
   | (-10,0)| (10,10)| 22.3606797749979
--- 221,227 
   | (-10,0)| (0,0)  |   10
   | (-10,0)| (-5,-12)   |   13
   | (-5,-12)   | (0,0)  |   13
!  | (0,0)  | (10,10)| 14.1421356237309
   | (-3,4) | (10,10)| 14.3178210632764
   | (-5,-12)   | (-3,4) | 16.1245154965971
   | (-10,0)| (10,10)| 22.3606797749979

==

*** /«PKGBUILDDIR»/build/../src/test/regress/expected/polygon.out   Mon Oct 
24 20:08:51 2016
--- /«PKGBUILDDIR»/build/src/test/regress/results/polygon.out   Mon Jan 23 
15:17:51 2017
***
*** 222,229 
'(2,2)'::point <-> '((0,0),(1,4),(3,1))'::polygon as inside,
'(3,3)'::point <-> '((0,2),(2,0),(2,2))'::polygon as near_corner,
'(4,4)'::point <-> '((0,0),(0,3),(4,0))'::polygon as near_segment;
!  on_corner | on_segment | inside |   near_corner   | near_segment 
! ---+++-+--
!  0 |  0 |  0 | 1.4142135623731 |  3.2
  (1 row)
  
--- 222,229 
'(2,2)'::point <-> '((0,0),(1,4),(3,1))'::polygon as inside,
'(3,3)'::point <-> '((0,2),(2,0),(2,2))'::polygon as near_corner,
'(4,4)'::point <-> '((0,0),(0,3),(4,0))'::polygon as near_segment;
!  on_corner | on_segment | inside |   near_corner| near_segment 
! ---+++--+--
!  0 |  0 |  0 | 1.41421356237309 |  3.2
  (1 row)
  


The 9.4.11 log contains the same point.out diff, but not polygon.out:
https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.4=powerpc=9.4.11-0%2Bdeb8u1=1487517299=0

Does that ring any bell? As Debian unstable is unaffected, it's likely
the toolchain to be blamed, but it worked for Debian Jessie before.

Christoph
-- 
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970  87C6 4C5A 6BAB 12D2 A7AE


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-02-09 Thread Christoph Berg

Re: David Fetter 2017-02-08 <20170208151214.ga8...@fetter.org>
> Would you be open to saving the next person some work by doing
> something similar to how \d is done, namely looking for an 'x'
> modifier after g without regard to how far after?  As of this writing,
> the \d version 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.: +49 2166 9901 187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970  87C6 4C5A 6BAB 12D2 A7AE


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-02-08 Thread Christoph Berg

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.
> 
> Patch is useful, and works as documented.
> 
> Maybe it could get a test or two in src/test/regress/*/psql.*

Good point. The new version tests \g and \gx with a new query, and
re-running it on the last query buffer.

Christoph
-- 
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970  87C6 4C5A 6BAB 12D2 A7AE
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
--- b/doc/src/sgml/ref/psql-ref.sgml
*** Tue Oct 26 21:40:57 CEST 1999
*** 1891,1896 
--- 1891,1908 
  
  

+ \gx [ filename ]
+ \gx [ |command ]
+ 
+ 
+ \gx is equivalent to \g, but
+ forces expanded output mode for this query.
+ 
+ 
+   
+ 
+ 
+   
  \gexec
  
  
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
new file mode 100644
index f17f610..6e140fe
*** a/src/bin/psql/command.c
--- b/src/bin/psql/command.c
*** exec_command(const char *cmd,
*** 910,917 
  		free(fname);
  	}
  
! 	/* \g [filename] -- send query, optionally with output to file/pipe */
! 	else if (strcmp(cmd, "g") == 0)
  	{
  		char	   *fname = psql_scan_slash_option(scan_state,
     OT_FILEPIPE, NULL, false);
--- 910,920 
  		free(fname);
  	}
  
! 	/*
! 	 * \g [filename] -- send query, optionally with output to file/pipe
! 	 * \gx [filename] -- same as \g, with expanded mode forced
! 	 */
! 	else if (strcmp(cmd, "g") == 0 || strcmp(cmd, "gx") == 0)
  	{
  		char	   *fname = psql_scan_slash_option(scan_state,
     OT_FILEPIPE, NULL, false);
*** exec_command(const char *cmd,
*** 924,929 
--- 927,934 
  			pset.gfname = pg_strdup(fname);
  		}
  		free(fname);
+ 		if (strcmp(cmd, "gx") == 0)
+ 			pset.g_expanded = true;
  		status = PSQL_CMD_SEND;
  	}
  
diff --git a/src/bin/psql/common.c b/src/bin/psql/common.c
new file mode 100644
index 5349c39..4534bd9
*** a/src/bin/psql/common.c
--- b/src/bin/psql/common.c
*** PrintQueryTuples(const PGresult *results
*** 770,775 
--- 770,779 
  {
  	printQueryOpt my_popt = pset.popt;
  
+ 	/* one-shot expanded output requested via \gx */
+ 	if (pset.g_expanded)
+ 		my_popt.topt.expanded = true;
+ 
  	/* write output to \g argument, if any */
  	if (pset.gfname)
  	{
*** sendquery_cleanup:
*** 1410,1415 
--- 1414,1422 
  		pset.gfname = NULL;
  	}
  
+ 	/* reset \gx's expanded-mode flag */
+ 	pset.g_expanded = false;
+ 
  	/* reset \gset trigger */
  	if (pset.gset_prefix)
  	{
diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c
new file mode 100644
index 3e3cab4..2aece7e
*** a/src/bin/psql/help.c
--- b/src/bin/psql/help.c
*** slashUsage(unsigned short int pager)
*** 174,179 
--- 174,180 
  	fprintf(output, _("  \\copyright show PostgreSQL usage and distribution terms\n"));
  	fprintf(output, _("  \\errverboseshow most recent error message at maximum verbosity\n"));
  	fprintf(output, _("  \\g [FILE] or ; execute query (and send results to file or |pipe)\n"));
+ 	fprintf(output, _("  \\gx [FILE] as \\g, but force expanded output\n"));
  	fprintf(output, _("  \\gexec execute query, then execute each value in its result\n"));
  	fprintf(output, _("  \\gset [PREFIX] execute query and store results in psql variables\n"));
  	fprintf(output, _("  \\q quit psql\n"));
diff --git a/src/bin/psql/settings.h b/src/bin/psql/settings.h
new file mode 100644
index 195f5a1..70ff181
*** a/src/bin/psql/settings.h
--- b/src/bin/psql/settings.h
*** typedef struct _psqlSettings
*** 91,96 
--- 91,97 
  	printQueryOpt popt;
  
  	char	   *gfname;			/* one-shot file output argument for \g */
+ 	bool		g_expanded;		/* one-shot expanded output requested via \gx */
  	char	   *gset_prefix;	/* one-shot prefix argument for \gset */
  	bool		gexec_flag;		/* one-shot flag to execute query's results */
  	bool		crosstab_flag;	/* one-shot request to crosstab results */
diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
new file mode 100644
index 6e759d0..0bd2ae3
*** a/src/bin/psql/tab-complete.c
--- b/src/bin/psql/tab-complete.c
*** psql_completion(const char *text, int st
*** 13

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

2017-02-06 Thread Christoph Berg

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
--- b/doc/src/sgml/ref/psql-ref.sgml
*** Tue Oct 26 21:40:57 CEST 1999
*** 1891,1896 
--- 1891,1908 
  
  

+ \gx [ filename ]
+ \gx [ |command ]
+ 
+ 
+ \gx is equivalent to \g, but
+ forces expanded output mode for this query.
+ 
+ 
+   
+ 
+ 
+   
  \gexec
  
  
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
new file mode 100644
index f17f610..6e140fe
*** a/src/bin/psql/command.c
--- b/src/bin/psql/command.c
*** exec_command(const char *cmd,
*** 910,917 
  		free(fname);
  	}
  
! 	/* \g [filename] -- send query, optionally with output to file/pipe */
! 	else if (strcmp(cmd, "g") == 0)
  	{
  		char	   *fname = psql_scan_slash_option(scan_state,
     OT_FILEPIPE, NULL, false);
--- 910,920 
  		free(fname);
  	}
  
! 	/*
! 	 * \g [filename] -- send query, optionally with output to file/pipe
! 	 * \gx [filename] -- same as \g, with expanded mode forced
! 	 */
! 	else if (strcmp(cmd, "g") == 0 || strcmp(cmd, "gx") == 0)
  	{
  		char	   *fname = psql_scan_slash_option(scan_state,
     OT_FILEPIPE, NULL, false);
*** exec_command(const char *cmd,
*** 924,929 
--- 927,934 
  			pset.gfname = pg_strdup(fname);
  		}
  		free(fname);
+ 		if (strcmp(cmd, "gx") == 0)
+ 			pset.g_expanded = true;
  		status = PSQL_CMD_SEND;
  	}
  
diff --git a/src/bin/psql/common.c b/src/bin/psql/common.c
new file mode 100644
index 5349c39..4534bd9
*** a/src/bin/psql/common.c
--- b/src/bin/psql/common.c
*** PrintQueryTuples(const PGresult *results
*** 770,775 
--- 770,779 
  {
  	printQueryOpt my_popt = pset.popt;
  
+ 	/* one-shot expanded output requested via \gx */
+ 	if (pset.g_expanded)
+ 		my_popt.topt.expanded = true;
+ 
  	/* write output to \g argument, if any */
  	if (pset.gfname)
  	{
*** sendquery_cleanup:
*** 1410,1415 
--- 1414,1422 
  		pset.gfname = NULL;
  	}
  
+ 	/* reset \gx's expanded-mode flag */
+ 	pset.g_expanded = false;
+ 
  	/* reset \gset trigger */
  	if (pset.gset_prefix)
  	{
diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c
new file mode 100644
index 3e3cab4..2aece7e
*** a/src/bin/psql/help.c
--- b/src/bin/psql/help.c
*** slashUsage(unsigned short int pager)
*** 174,179 
--- 174,180 
  	fprintf(output, _("  \\copyright show PostgreSQL usage and distribution terms\n"));
  	fprintf(output, _("  \\errverboseshow most recent error message at maximum verbosity\n"));
  	fprintf(output, _("  \\g [FILE] or ; execute query (and send results to file or |pipe)\n"));
+ 	fprintf(output, _("  \\gx [FILE] as \\g, but force expanded output\n"));
  	fprintf(output, _("  \\gexec execute query, then execute each value in its result\n"));
  	fprintf(output, _("  \\gset [PREFIX] execute query and store results in psql variables\n"));
  	fprintf(output, _("  \\q quit psql\n"));
diff --git a/src/bin/psql/settings.h b/src/bin/psql/settings.h
new file mode 100644
index 195f5a1..70ff181
*** a/src/bin/psql/settings.h
--- b/src/bin/psql/settings.h
*** typedef struct _psqlSettings
*** 91,96 
--- 91,97 
  	printQueryOpt popt;
  
  	char	   *gfname;			/* one-shot file output argument for \g */
+ 	bool		g_expanded;		/* one-shot expanded output requested via \gx */
  	char	   *gset_prefix;	/* one-shot prefix argument for \gset */
  	bool		gexec_flag;		/* one-shot flag to execute query's results */
  	bool		crosstab_flag;	/* one-shot request to crosstab results */
diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
new file mode 100644
index 6e759d0..0bd2ae3
*** a/src/bin/psql/tab-complete.c
--- b/src/bin/psql/tab-complete.c
*** psql_completion(const char *text, int st
*** 1338,1344 
  		"\\dm", "\\dn", "\\do", "\\dO", "\\dp", "\\drds", "\\ds", "\\dS",
  		"\\dt", "\\dT", "\\dv", "\\du", "\\dx", "\\dy",
  		"\\e", "\\echo", "\\ef", "\\encoding", "\\errverbose", "\\ev",
! 		"\\f", "\\g", "\\gexec", "\\gset", "\\h", "\\help", "\\H", "\\i", "\\ir", "\\l",
  		"\\lo_import", "\\lo_export", "\\lo_list", "\\lo_unlink",
  		"\\o", "\\p", "\\password", "\\prompt", "\\pset", "\\q", "\\qecho", "\\r",
  		"\\s", "\\set", "\\setenv", "\\sf", "\\sv", "\\t", "\\T",
--- 1338,1344 
  		"\\dm", "\\dn", "\\do", "\\dO", "\\dp", "\\drds", "\\ds", "\\dS",
  		"\\dt", "\\dT", "\\dv", "\\du", "\\dx", "\\dy",
  		"\\e", "\\echo", "\\ef", "\\encoding", "\\errverbose", "\\ev",
! 		"\\f", "\\g", "\\gx", "\\gexec", "\\gset", "\\h", "\\help", "\\H", "\\i", "\\ir", "\\l",

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

2017-01-30 Thread Christoph Berg

Re: Tom Lane 2017-01-30 <23622.1485788...@sss.pgh.pa.us>
> FWIW, \gx makes sense to me as well, particularly if we make it a
> complete extension of \g and allow an optional target file name.
> Does that functionality exist in mysql's \G ?

MySQL's (5.5 here) \G does not support 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
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970  87C6 4C5A 6BAB 12D2 A7AE


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-01-30 Thread Christoph Berg

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 the
> > same as \g (including parameters), but forces expanded output just for
> > this query.
> 
> +1 for the functionality but should we choose to ignore the comparison
> to mysql, I'd suggest \gx for the name.

IMHO \G is a tad easier to type than \gx, though the difference isn't
huge, so I would be fine with either. But do we really want to choose
something different just because MySQL is using it? \G will be much
easier to explain to existing users (both people coming from MySQL to
PostgreSQL, and PostgreSQL users doing a detour into foreign
territory), and it would be one difference less to have to care about
when typing on the CLIs.

+1 on \G.

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-01-27 Thread Christoph Berg

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 same thing.  (You can omit the query in either
> > case which causes the previous query to be re-ran.  \crosstabview,
> > \gexec etc also work like that).
> 
> Right, I agree it's the same thing, but (clearly), not everyone
> discussing this realized that and, well, the \G-by-itself is a lot
> easier for me, at least.  I have a really hard time not ending things
> with a semi-colon. ;)

Heh, tbh even I as the patch other didn't realize that \G-by-itself
just works, my intention was that it replaces the semicolon. :)

So, to clarify, both ways work:

select * from pg_class where relname = 'pg_class';
-- dang, much too wide, press 
select * from pg_class where relname = 'pg_class' \G
-- ah nice!

select * from pg_class where relname = 'pg_class';
-- dang, much too wide
\G
-- ah nice!

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-01-27 Thread Christoph Berg

Re: To PostgreSQL Hackers 2017-01-27 
<20170127132737.6skslelaf4txs...@msg.credativ.de>
> The same idea was discussed back in 2008. Back then the outcome was
> that "\x auto" was implemented, but I still think that \G is a useful
> feature to have on its own, and several 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önchengladbach 12080, USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970  87C6 4C5A 6BAB 12D2 A7AE


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-01-27 Thread Christoph Berg

I frequently find myself in the situation that I want the "\x"
expanded output mode activated just for one query. There's little
wrong with typing "\x" and re-executing the query in that case, but
then I'm always annoyed that the expanded output is still active for
the next query after that.

"\x auto" is not a fix for the problem; I have set up the pager to use
"less -S" (non-wrapping) by default so I can scroll right/left through
the query result instead of having it spread over several terminal
lines.

A workaround is to submit queries using "\x\g\x", but that's ugly,
clutters the output with toggle messages, and will forget that "\x
auto" was set.

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 the
same as \g (including parameters), but forces expanded output just for
this query.

The same idea was discussed back in 2008. Back then the outcome was
that "\x auto" was implemented, but I still think that \G is a useful
feature to have on its own, and several 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önchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970  87C6 4C5A 6BAB 12D2 A7AE
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
new file mode 100644
index 640fe12..af85888
*** a/doc/src/sgml/ref/psql-ref.sgml
--- b/doc/src/sgml/ref/psql-ref.sgml
*** Tue Oct 26 21:40:57 CEST 1999
*** 1891,1896 
--- 1891,1908 
  
  

+ \G [ filename ]
+ \G [ |command ]
+ 
+ 
+ \G is equivalent to \g, but
+ forces expanded output mode for this query.
+ 
+ 
+   
+ 
+ 
+   
  \gexec
  
  
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
new file mode 100644
index 0c164a3..912f672
*** a/src/bin/psql/command.c
--- b/src/bin/psql/command.c
*** exec_command(const char *cmd,
*** 904,911 
  		free(fname);
  	}
  
! 	/* \g [filename] -- send query, optionally with output to file/pipe */
! 	else if (strcmp(cmd, "g") == 0)
  	{
  		char	   *fname = psql_scan_slash_option(scan_state,
     OT_FILEPIPE, NULL, false);
--- 904,914 
  		free(fname);
  	}
  
! 	/*
! 	 * \g [filename] -- send query, optionally with output to file/pipe
! 	 * \G [filename] -- same as \g, with expanded mode forced
! 	 */
! 	else if (strcasecmp(cmd, "g") == 0)
  	{
  		char	   *fname = psql_scan_slash_option(scan_state,
     OT_FILEPIPE, NULL, false);
*** exec_command(const char *cmd,
*** 918,923 
--- 921,928 
  			pset.gfname = pg_strdup(fname);
  		}
  		free(fname);
+ 		if (strcmp(cmd, "G") == 0)
+ 			pset.g_expanded = true;
  		status = PSQL_CMD_SEND;
  	}
  
diff --git a/src/bin/psql/common.c b/src/bin/psql/common.c
new file mode 100644
index e1b04de..4a75470
*** a/src/bin/psql/common.c
--- b/src/bin/psql/common.c
*** PrintQueryTuples(const PGresult *results
*** 770,775 
--- 770,779 
  {
  	printQueryOpt my_popt = pset.popt;
  
+ 	/* one-shot expanded output requested via \G */
+ 	if (pset.g_expanded)
+ 		my_popt.topt.expanded = true;
+ 
  	/* write output to \g argument, if any */
  	if (pset.gfname)
  	{
*** sendquery_cleanup:
*** 1411,1416 
--- 1415,1423 
  		pset.gfname = NULL;
  	}
  
+ 	/* reset \G's expanded-mode flag */
+ 	pset.g_expanded = false;
+ 
  	/* reset \gset trigger */
  	if (pset.gset_prefix)
  	{
diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c
new file mode 100644
index 5365629..5e9c249
*** a/src/bin/psql/help.c
--- b/src/bin/psql/help.c
*** slashUsage(unsigned short int pager)
*** 174,179 
--- 174,180 
  	fprintf(output, _("  \\copyright show PostgreSQL usage and distribution terms\n"));
  	fprintf(output, _("  \\errverboseshow most recent error message at maximum verbosity\n"));
  	fprintf(output, _("  \\g [FILE] or ; execute query (and send results to file or |pipe)\n"));
+ 	fprintf(output, _("  \\G [FILE]  as \\g, but force expanded output\n"));
  	fprintf(output, _("  \\gexec execute query, then execute each value in its result\n"));
  	fprintf(output, _("  \\gset [PREFIX] execute query and store results in psql variables\n"));
  	fprintf(output, _("  \\q quit psql\n"));
diff --git a/src/bin/psql/settings.h b/src/bin/psql/settings.h
new

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

2016-12-08 Thread Christoph Berg

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 -Wdeclaration-after-statement 
-Wendif-labels -Wmissing-format-attribute -Wformat-security 
-fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -g -O2 
-fdebug-prefix-map=/<>=. 
-specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -I/usr/include/mit-krb5 -fPIC -pie 
-fno-omit-frame-pointer -fpic -I. -I/<>/build/../contrib/pgcrypto 
-I../../src/include -I/<>/build/../src/include -Wdate-time 
-D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -I/usr/include/libxml2  -I/usr/include/tcl8.6 
 -c -o openssl.o /<>/build/../contrib/pgcrypto/openssl.c
/<>/build/../contrib/pgcrypto/openssl.c:253:17: error: field 
'evp_ctx' has incomplete type
  EVP_CIPHER_CTX evp_ctx;
 ^~~
/<>/build/../contrib/pgcrypto/openssl.c: In function 
'bf_check_supported_key_len':
/<>/build/../contrib/pgcrypto/openssl.c:373:17: error: storage 
size of 'evp_ctx' isn't known
  EVP_CIPHER_CTX evp_ctx;
 ^~~
/<>/build/../contrib/pgcrypto/openssl.c:373:17: warning: unused 
variable 'evp_ctx' [-Wunused-variable]
: recipe for target 'openssl.o' failed

Reverting 5ff4a67f63fd6d3eb01ff9707d4674ed54a89f3b fixes compilation.
(9.6 is fine.)

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2016-10-27 Thread Christoph Berg

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/postgresql-2016-10-27_185100.csv

On a closer look, I like this better than my "always two lines"
suggestion. +1.

> -1, SHOW is used to display run-time parameters values in our case this
> is log_destination + log_directory + log_filename. current_logfile is a
> filename not a parameter name.

I'm not sure if it's even possible to put non-GUC information in
there. It might also be a performance problem, if pg_current_logfiles
had to read-in for every "select * from pg_settings".

Re: Karl O. Pinc 2016-10-27 <20161027121141.6bd95...@slate.meme.com>
> Another interface to consider might be a system catalog:
> 
> SELECT * from postgres.pg_current_logfile;
> 
> format | path
> ---+---
> syslog | /some/where/log
> cvslog | /some/where/log.csv
> 
> (2 rows)
> 
> Maybe good if the goal is "interactive use".  Seems like
> overkill to me, but thought I'd present the idea
> anyway.

We were discussing exactly that idea upthread before concluding that a
function with a single return value is much easier to use.

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2016-10-27 Thread Christoph Berg

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 fair to me. (But see the next comment below)

> But what if current_logfile contains only a single line?  What
> sort of file format does the logfile have?  If you don't know
> you can't process the logfile content.
> 
> When there's multiple lines in current_logfile your script might
> be looking for a logfile in a particular format.  How is the
> script supposed to know the file format of each logfile listed?

My idea here would be to always write out two lines, the first for
stderr, the second for csvlog, and leave the unused one empty. That's
easy to parse from shell scripts.

> Regards the data structure to use to expose the file format
> I can't vouch that "format path" is most future-proof.
> It's what I came up with on the spur of the moment.
> Something like: "format : path ",
> where ":" is the field separator and each data element is
> tagged, would still be parseable by the shell "read" built-in
> so long as the path comes last. I don't really care about 
> the exact data structure but I do think the file format
> meta-information should be included.

I guess that depends on how likely we think new log formats would be
added in the future. My guess would be that it's rather unlikely, so
going with simple file format makes sense.

> Why not just: SELECT pg_log_format(); since you only ever need to
> know what log format is returned by pg_current_logfile() when called
> without arguments?  Otherwise you already know the log format because
> you asked for something specific.

That function already exists: "show log_destination;"

> Therefore pg_current_logfile() without any arguments is, in the sense
> of any sort of automated processing of the logfile content, useless.

The function without arguments is very useful for interactive use,
which is the primary point of this patch in my opinion.

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Renaming of pg_xlog and pg_clog

2016-10-19 Thread Christoph Berg

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_eatmydata, given the number of "howtos" on the web that
> > make use of it. Maybe this is the chance to find a less
> > innocent-sounding name. (Or add a mandatory --rewind-my-data switch.)
> 
> I wonder how many of the uses of pg_resetxlog were caused by mistakenly
> removing the pg_xlog directory.   My point is renaming pg_xlog might
> reduce mistake use of pg_resetxlog.

I don't think there's much of a connection. There are people who
clean up disk space by removing everything that sounds like log files.
For those people renaming the directories makes sense so they don't
have that idea.

There are other people who have random database startup problems, ask
google, and end up with applying some pg_resetxlog advice (that
doesn't necessarily fit their problem). For those people renaming
pg_resetxlog to something that sounds more like "it will break your
data, use as last resort only" might make sense. (Though I don't have
a good suggestion, and the cost of renaming utilities is higher than
renaming some internal directory names.)

The question would now be if there's people who used pg_resetxlog
because they thought it freed up disk space, and if renaming either
would have prevented that. I'm less sure about that.

(tl;dr: rename pg_xlog yes, rename pg_resetxlog only if we have a good
alternative.)

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2016-10-14 Thread Christoph Berg

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 ask for a specific log
> format, like pg_current_logfile('csv') or pg_current_logfile('stderr').

Good idea to add an optional parameter.

pg_current_logfile(type text DEFAULT 'auto')

pg_current_logfile()
pg_current_logfile('stderr')
pg_current_logfile('csvlog')
pg_current_logfile('auto')

I think I'd prefer the stderr variant by default when both variants
are configured.

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Renaming of pg_xlog and pg_clog

2016-10-14 Thread Christoph Berg

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
> > prepared to rename the programs and options as well.
> 
> pg_xlogdump is not a user-facing tool, frankly, so I don't believe we
> should be terribly concerned about either leaving it named as-is or
> renaming it.  I agree that we should consider adding alternative names
> to the options for initdb and pg_basebackup.

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_eatmydata, given the number of "howtos" on the web that
make use of it. Maybe this is the chance to find a less
innocent-sounding name. (Or add a mandatory --rewind-my-data switch.)

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] process type escape for log_line_prefix

2016-10-14 Thread Christoph Berg

Re: Jeff Janes 2016-10-14

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

2016-10-14 Thread Christoph Berg

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
> ---+---
>  pg_log/postgresql-2016-10-07_1646.log | pg_log/postgresql-2016-10-07_1646.csv

> (The alternative could be to return an extra column:
> 
> postgres=# select * from pg_current_logfile();
>   type  | logfile
> ---
>  stderr | pg_log/postgresql-2016-10-07_1646.log
>  csvlog | pg_log/postgresql-2016-10-07_1646.csv

Usability-wise it might be better to have pg_current_logfile() just
return the name of the text log (and possibly a HINT that there's a
csv log if stderr is disabled), and have a second function
pg_current_csvlog() return the csv log name.

The choice which design is better will probably depend on if we think
these functions are meant for interactive use (-> 2 functions), or for
automated use (-> 2 columns). My guess would be that interactive use
is more important here.

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Renaming of pg_xlog and pg_clog

2016-10-14 Thread Christoph Berg

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 internal/base and internal/global and internal/pg_... because
these shouldn't be touched by the users either.

I don't think this would lead anywhere.

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2016-10-14 Thread Christoph Berg

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 to reshuffle
> > the directory layout to make it easier to exclude files from backups.
> > (Should this file be part of backups?)
> >
> > It's probably correct to leave the file around on shutdown (given it's
> > still a correct pointer). But there might be a case for removing it on
> > startup if logging_collector isn't active anymore.
> 
> The file has been renamed into current_logfile and is now removed at
> startup if logging_collector is not active. The file can be excluded
> from a backup but otherwise if it is restored it will be removed or
> overridden at startup. Perhaps the file can give a useful information in
> a backup to know the last log file active at backup time, but not sure
> it has any interest.
> 
> I'm not sure which thread is talking about reshuffling the directory
> layout, please give me a pointer if this is not the thread talking about
> renaming of pg_xlog and pg_clog. In the future if we have a directory to
> store files that must be excluded from backup or status files, it will
> be easy to move this file here. I will follow such a change.

I meant "exclude from backup", but let's not worry here because it
will be very easy to move the file to this location once it exists.

Thanks for renaming the file, the new name makes the purpose of the
file very clear.

I'm still not very happy about the file being in PGDATA (modulo the
move mentioned above) - how about the idea of putting it into global/?
That location isn't ideal either, but maybe a better place for now?
(pg_control is a similar write-by-rename file in there as well, so
we'd only be constantly rewriting one subdirectory instead of two.)

> > # select pg_read_file(pg_current_logfile());
> >  pg_read_file  
> > ───
> >  LOG:  ending log output to stderr↵
> >  HINT:  Future log output will go to log destination "csvlog".↵
> >
> > -rw---  1 cbe staff 1011 Okt  3 15:06 postgresql-2016-10-03_150602.csv
> > -rw---  1 cbe staff   96 Okt  3 15:06 postgresql-2016-10-03_150602.log
> >
> > ... though it's unclear what to do if both stderr and csvlog are
> > selected.
> >
> > Possibly NULL should be returned if only "syslog" is selected.
> > (Maybe remove pg_log_file once 'HINT:  Future log output will go to
> > log destination "syslog".' is logged?)
> 
> I've totally missed that we can have log_destination set to stderr and
> csvlog at the same time, so pg_current_logfile() might return two
> filenames in this case. I've changed the function to return a setof
> record to report the last stderr or csv log file or both. One another
> major change is that the current log filename list is also updated after
> a configuration reload and not just after a startup or a log rotation.
> So in the case of you are switching from stderr to  csvlog or both you
> will see immediately the change in current_logfile instead of waiting
> for the next log rotation.

I'm unsure if having two lines of output there is helpful. In the case
where both log destinations are active, pg_read_file(pg_current_logfile())
prints the log contents twice. If I want a specific format, I'll have
to use limit and/or offset which seems fragile.

A better design might be to return two columns instead:

postgres=# select * from pg_current_logfile();
 stderr|  csvlog
---+---
 pg_log/postgresql-2016-10-07_1646.log | pg_log/postgresql-2016-10-07_1646.csv

("stderr" is not a nice column name, but it would at least match the
log_destination setting.)

The on-disk format in current_logfile could then be to always write
two lines, and leave the first or second line empty for the disabled
format.

The downside of that idea is that "pg_read_file(pg_current_logfile())"
won't work, so I'm not sure this change is an improvement in
usability.

(The alternative could be to return an extra column:

postgres=# select * from pg_current_logfile();
  type  | logfile
---
 stderr | pg_log/postgresql-2016-10-07_1646.log
 csvlog | pg_log/postgresql-2016-10-07_1646.csv

... but this makes (interactive) querying even harder, though it
would scale better to any future added log formats/channels.)

> I can change the return type to a single text[] if that's looks better.

Arrays would be worse, I think.


There's a bug in the SRF code, on rm'ing current_logfile, invoking
pg_current_logfile() crashes the server.

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes

Re: [HACKERS] process type escape for log_line_prefix

2016-10-14 Thread Christoph Berg

Re: Michael Paquier 2016-02-10

Re: [HACKERS] Non-empty default log_line_prefix

2016-10-14 Thread Christoph Berg

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
> when I see the default and change it to %m.

Here's the very same patch with %m instead of %t. Pick one :)

(Fwiw, I'm still leaning towards %t, but my eyes are becoming more and
more accustomed to %m as well. I'd be fine with it as well. (I'd
rather want to try to get rid of the timezone identifier there...))

Christoph
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
new file mode 100644
index e826c19..bec9483
*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
*** local0.*/var/log/postgresql
*** 5004,5010 
   value will pad on the left. Padding can be useful to aid human
   readability in log files.
   This parameter can only be set in the postgresql.conf
!  file or on the server command line. The default is an empty string.
  
   

--- 5004,5011 
   value will pad on the left. Padding can be useful to aid human
   readability in log files.
   This parameter can only be set in the postgresql.conf
!  file or on the server command line. The default is
!  %m [%p]  which logs a time stamp and the process ID.
  
   

*** FROM pg_stat_activity;
*** 5142,5147 
--- 5143,5159 
   include those escapes if you are logging to syslog.
  
 
+ 
+
+ 
+  The %q escape is useful when including information that 
is
+  only available in session (backend) context like user or database
+  name. An example would be:
+ 
+ log_line_prefix = '%m [%p] %q%u@%d/%a '
+ 
+ 
+

   
  
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
new file mode 100644
index 622279b..65660c1
*** a/src/backend/utils/misc/guc.c
--- b/src/backend/utils/misc/guc.c
*** static struct config_string ConfigureNam
*** 3014,3020 
gettext_noop("If blank, no prefix is used.")
},
_line_prefix,
!   "",
NULL, NULL, NULL
},
  
--- 3014,3020 
gettext_noop("If blank, no prefix is used.")
},
_line_prefix,
!   "%m [%p] ",
NULL, NULL, NULL
},
  
diff --git a/src/backend/utils/misc/postgresql.conf.sample 
b/src/backend/utils/misc/postgresql.conf.sample
new file mode 100644
index 05b1373..159ada3
*** a/src/backend/utils/misc/postgresql.conf.sample
--- b/src/backend/utils/misc/postgresql.conf.sample
***
*** 430,436 
  #log_duration = off
  #log_error_verbosity = default# terse, default, or verbose 
messages
  #log_hostname = off
! #log_line_prefix = '' # special values:
#   %a = application name
#   %u = user name
#   %d = database name
--- 430,436 
  #log_duration = off
  #log_error_verbosity = default# terse, default, or verbose 
messages
  #log_hostname = off
! #log_line_prefix = '%m [%p] ' # special values:
#   %a = application name
#   %u = user name
#   %d = database name

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] pg_filedump is broken

2016-10-14 Thread Christoph Berg

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 
this as commited by me. I'll mark it as "returned with feedback". Thanks!

The new status of this patch is: Ready for Committer

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] pg_filedump is broken

2016-10-14 Thread Christoph Berg

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 < SizeOfIptrData)
> ```
> 
> After 8023b582 there is no more SizeOfIptrData macro.

Thanks, pushed to filedump git.

> Second patch fixes Makefile. On some systems (notably FreeBSD) there is
> no `gcc` by default. Using `cc` is a more crossplatform way to compile a
> project.

I think we just shouldn't set CC at all. Pushed along with some more
usage of pg_config.

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Non-empty default log_line_prefix

2016-10-12 Thread Christoph Berg

Re: Jeff Janes 2016-10-12

Re: [HACKERS] Non-empty default log_line_prefix

2016-10-12 Thread Christoph Berg

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.
> > Patch attached. (Still using %t, I don't think %m makes sense for the
> > default.)
> 
> That still doesn't address what to do about syslog and eventlog users.
> We would need either a separate prefix setting for those, or maybe
> something like %q that says, skip to here if using syslog.  (I don't
> know eventlog, so I don't know if a common setting for syslog and
> eventlog would work.)

This patch simply tries to fix the default (stderr + '') which wasn't
useful for anyone. Note that there is already a hint in the
documentation that says timestamps and PID are not useful for syslog.

(Yes, the '' default might be fine for syslog, but I don't think
that's a good argument for sticking with it for default installs. I've
seen way too many useless log files out there, and at worst we'll have
syslogs with two timestamps.)

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2016-10-09 Thread Christoph Berg

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 favor switching.

Another data point that's admittedly much more of a footnote than
serious input to the original question is the following: Debian has a
(so far mostly toy) port "hurd-i386" which is using the GNU hurd
kernel along with the usual GNU userland that's also in use on Linux.

This OS doesn't implement any semaphores yet (PG compiles, but initdb
dies with ENOSYS immediately). On talking to the porters, they advised
that POSIX semaphores would have the best chances to get implemented
first, so I added USE_UNNAMED_POSIX_SEMAPHORES=1 to the architecture
template to be prepared for that.

Christoph


(The patch quoted below is obviously Debian-specific and not meant for
inclusion upstream.)


hurd doesn't support sysv semaphores (semget), and needs -pthread to find
sem_init. POSIX semaphores shared between processes (sem_init(pshared = 1))
aren't supported yet either, but have the best chance to get implemented, so be
prepared.

FATAL:  could not create semaphores: Function not implemented
DETAIL:  Failed system call was semget(1, 17, 03600).

undefined reference to symbol 'sem_init@@GLIBC_2.12'

--- a/src/backend/Makefile
+++ b/src/backend/Makefile
@@ -109,6 +109,10 @@ endif
 
 endif # aix
 
+ifeq ($(shell dpkg-architecture -qDEB_HOST_ARCH_OS), hurd)
+LIBS += -pthread
+endif # hurd
+
 # Update the commonly used headers before building the subdirectories
 $(SUBDIRS:%=%-recursive): | generated-headers
 
--- a/src/template/linux
+++ b/src/template/linux
@@ -28,3 +28,10 @@ if test "$SUN_STUDIO_CC" = "yes" ; then
 ;;
   esac
 fi
+
+# force use of POSIX instead of SysV semaphores on hurd-i386
+case $(dpkg-architecture -qDEB_HOST_ARCH) in
+   hurd*)
+   USE_UNNAMED_POSIX_SEMAPHORES=1
+   ;;
+esac



signature.asc
Description: PGP signature

Re: [HACKERS] PostgreSQL - Weak DH group

2016-10-06 Thread Christoph Berg

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_dh(), like we do for the ECDH curve. The DH
> parameters are loaded from a file called "dh_params.pem" (instead of
> "dh1024.pem"), if present, otherwise the built-in 2048 bit parameters are
> used.

Shouldn't this be a GUC pointing to a configurable location like
ssl_cert_file? This way, people reading the security section of the
default postgresql.conf would notice that there's something (new) to
configure. (And I wouldn't want to start creating symlinks from PGDATA
to /etc/ssl/something again...)

Thanks,
Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Renaming of pg_xlog and pg_clog

2016-10-03 Thread Christoph Berg

Re: Michael Paquier 2016-09-30

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

2016-10-03 Thread Christoph Berg

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 "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 to reshuffle
the directory layout to make it easier to exclude files from backups.
(Should this file be part of backups?)

It's probably correct to leave the file around on shutdown (given it's
still a correct pointer). But there might be a case for removing it on
startup if logging_collector isn't active anymore.

Also, pg_log_file is tab-completion-unfriendly, it conflicts with
pg_log/. Maybe name it current_logfile?

Another thing that might possibly be improved is csv logging:

# select pg_read_file(pg_current_logfile());
 pg_read_file  
───
 LOG:  ending log output to stderr↵
 HINT:  Future log output will go to log destination "csvlog".↵

-rw---  1 cbe staff 1011 Okt  3 15:06 postgresql-2016-10-03_150602.csv
-rw---  1 cbe staff   96 Okt  3 15:06 postgresql-2016-10-03_150602.log

... though it's unclear what to do if both stderr and csvlog are
selected.

Possibly NULL should be returned if only "syslog" is selected.
(Maybe remove pg_log_file once 'HINT:  Future log output will go to
log destination "syslog".' is logged?)

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2016-10-03 Thread Christoph Berg

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 going forward by adding extra requirements.

> Hmmm. I'm not sure how this is parsed. If this is considered a string '...',
> then maybe \set should wait for the end of the string instead of the end of
> the line, i.e. no continuation would be needed...
> 
>  \set config '
> SELECT name, ...
>CASE ... END
> FROM pg_settings
> WHERE ...;'

I guess that would be the sane solution here, yes. Not adding any \
chars at the end of the line would also mean cut-and-paste of the RHS
content would work.

Thanks for the feedback!

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2016-10-03 Thread Christoph Berg

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, e.g.

\set config 'SELECT name, current_setting(name), CASE source WHEN 
$$configuration file$$ THEN sourcefile||$$:$$||sourceline ELSE source END FROM 
pg_settings WHERE source <> $$default$$;'

Being able to split that over several lines would greatly improve
maintainability. (Though I do realize this would also require a notion
for splitting/continuing strings.)

Christoph


signature.asc
Description: PGP signature

[HACKERS] Non-empty default log_line_prefix

2016-10-02 Thread Christoph Berg

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 the documentation.  But perhaps an example along these
> lines would be useful for showing proper use of %q.

Patch attached. (Still using %t, I don't think %m makes sense for the
default.)

Christoph
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
new file mode 100644
index e826c19..a4d8b74
*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
*** local0.*/var/log/postgresql
*** 5004,5010 
   value will pad on the left. Padding can be useful to aid human
   readability in log files.
   This parameter can only be set in the postgresql.conf
!  file or on the server command line. The default is an empty string.
  
   

--- 5004,5011 
   value will pad on the left. Padding can be useful to aid human
   readability in log files.
   This parameter can only be set in the postgresql.conf
!  file or on the server command line. The default is
!  %t [%p]  which logs a time stamp and the process ID.
  
   

*** FROM pg_stat_activity;
*** 5142,5147 
--- 5143,5159 
   include those escapes if you are logging to syslog.
  
 
+ 
+
+ 
+  The %q escape is useful when including information that 
is
+  only available in session (backend) context like user or database
+  name. An example would be:
+ 
+ log_line_prefix = '%t [%p] %q%u@%d/%a '
+ 
+ 
+

   
  
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
new file mode 100644
index cced814..b71fa93
*** a/src/backend/utils/misc/guc.c
--- b/src/backend/utils/misc/guc.c
*** static struct config_string ConfigureNam
*** 3014,3020 
gettext_noop("If blank, no prefix is used.")
},
_line_prefix,
!   "",
NULL, NULL, NULL
},
  
--- 3014,3020 
gettext_noop("If blank, no prefix is used.")
},
_line_prefix,
!   "%t [%p] ",
NULL, NULL, NULL
},
  
diff --git a/src/backend/utils/misc/postgresql.conf.sample 
b/src/backend/utils/misc/postgresql.conf.sample
new file mode 100644
index 05b1373..9eaa23e
*** a/src/backend/utils/misc/postgresql.conf.sample
--- b/src/backend/utils/misc/postgresql.conf.sample
***
*** 430,436 
  #log_duration = off
  #log_error_verbosity = default# terse, default, or verbose 
messages
  #log_hostname = off
! #log_line_prefix = '' # special values:
#   %a = application name
#   %u = user name
#   %d = database name
--- 430,436 
  #log_duration = off
  #log_error_verbosity = default# terse, default, or verbose 
messages
  #log_hostname = off
! #log_line_prefix = '%t [%p] ' # special values:
#   %a = application name
#   %u = user name
#   %d = database name

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2016-09-29 Thread Christoph Berg

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 think pretty much everybody agrees
> that those fields are useful, whereas the rest of it is a lot more
> context-dependent.  (For example, there are a whole lot of real
> installations where neither %u nor %d would be worth the log space.)

Nod. In many installations %u and %d will be effectively constants.

> Personally I'm also on board with using this for regression testing:
> 
>   log_line_prefix = '%t [%p] %q%a '
> 
> but I doubt it can be sold as a general-purpose default.

I don't think it makes much sense to log only %a unconditionally,
except maybe for making more applications actually set it.

If we were to add more fields I'd go for

log_line_prefix = '%t [%p] %q%u@%d/%a '

but the above-proposed '%t [%p] ' is already fixing 95% of the problem
(and the remaining 5% are unclear).

Possibly the longer version could be added as an example in the
documentation.

So, in short, +1.

Christoph

signature.asc
Description: PGP signature

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

2016-09-29 Thread Christoph Berg

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
> pgbadger.  Syslog output looks like this:
> 
> Sep 28 00:58:56 hostname syslogd[46]: some text here
> 
> pgbadger by default asks for this:
> 
> log_line_prefix = '%t [%p]: [%l-1] user=%u,db=%d,app=%a,client=%h '
> 
> I don't know why it wants that "-1" there, and I'm actually not sure
> what the point of %l is in practice.  Those are separate issues that are
> having their own lively discussions at times.  I could drop the [%l]
> from my proposal if that causes concerns.

[%l-1] is originally from pgfouine, and I vaguely remember that it
used to be something like [%l-%c] where %c was some extra line
numbering removed in later (7.something?) PG versions. In any case,
the -1 isn't useful.

I'm happy to remove %l as well. Log lines won't be out of order
anyway, and one needs to look at %p anyway to correlate them. %l
doesn't help there.

Christoph


signature.asc
Description: PGP signature

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

2016-09-28 Thread Christoph Berg

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.
> 
> Is there any chance we can move forward here, or is this effort doomed for 
> now?

IMHO it would make sense. Maybe we should collect a few suggestions,
and then take a poll?

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

2016-09-16 Thread Christoph Berg

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
> seems it's not set yet. I'll ask the maintainers directly and report
> back.

The plan is to ship only OpenSSL 1.1 in Stretch. (The list of packages
not yet ported is enormous, though, so I'm not yet sure it will really
happen.)

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827061


Re: Tom Lane 2016-09-16 <17025.1473977...@sss.pgh.pa.us>
> > Here is the result of backporting the sum of the two patches on top of 
> > REL9_4_STABLE. Not sure if we need this, but if we do we can apply this 
> > patch.
> 
> If someone's done the legwork, I think we would be well advised to
> back-patch.  Maybe not bother with 9.1 though.

Thanks for the patch!

I just tried to apply it to 9.2. There was a conflict in configure.in which was
trivial to resolve.

Another conflict in contrib/pgcrypto/pgcrypto.c was not applicable
because the code doesn't seem to exist (didn't try very hard though).

Ignoring the contrib conflict, it still didn't compile:

/home/cbe/projects/postgresql/debian/9.2/build/../src/backend/libpq/be-secure.c:
 In function ‘secure_write’:
/home/cbe/projects/postgresql/debian/9.2/build/../src/backend/libpq/be-secure.c:342:17:
 error: dereferencing pointer to incomplete type ‘SSL {aka struct ssl_st}’
if (port->ssl->state != SSL_ST_OK)
 ^~
/home/cbe/projects/postgresql/debian/9.2/build/../src/backend/libpq/be-secure.c:342:28:
 error: ‘SSL_ST_OK’ undeclared (first use in this function)
if (port->ssl->state != SSL_ST_OK)
^

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

2016-09-15 Thread Christoph Berg

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
> > have the same problem with the next Fedora release.
> 
> 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
seems it's not set yet. I'll ask the maintainers directly and report
back.

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

2016-09-15 Thread Christoph Berg

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 there's demand, but I'm not
> > eager to do that until someone complains.
> 
> Not going older than 9.5 may be fine:
> https://www.openssl.org/blog/blog/2014/12/23/the-new-release-strategy/
> https://wiki.freebsd.org/OpenSSL
> As far as I can see 1.0.2 would be supported until Dec 2019, so that
> would just overlap with 9.4's EOL.

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
have the same problem with the next Fedora release.

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2016-09-06 Thread Christoph Berg

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 wrong-machine and wrong-process-identity
> cases, and as a bonus it might help if you've had a brain fade about
> which COPY direction is write vs. read.
> 
> (I think we're all in agreement that the second sentence of the hint
> is fine, so leaving that out of it.)
> 
> Comments?

I like your new version, it's crisp and transports the right message.

Christoph


signature.asc
Description: PGP signature

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

2016-09-05 Thread Christoph Berg

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

The part about the server permissions might be useful to hint at.

> > I don't suppose there's any easy way for COPY to distinguish local
> > from remote connections
> 
> Not that I see, since "local" can be unix socket or tcp to localhost.
> Not cleanly anyway.
> 
> I don't think it matters. Many hosts have enough paths in common that
> in practice the hint on EACCES will be useful anyway. It'd be nice to
> work in something about running with the permissions of the PostgreSQL
> server, but I don't see a way to do that without making it all more
> complex.
> 
> I don't think it's worth tons of time anyway. This will be better than
> what we have, lets do it.

It's probably not helpful trying to distinguish local and remote
connections, the set of possible problems is diverse and this is just
one of them.

> I'm fairly happy with the wording you came up with:
> 
> "COPY copies to a file on the PostgreSQL server, not on the client. "
> "You may want a client-side facility such as psql's \\copy."

What about

 "COPY TO instructs the PostgreSQL server to write to a file on the server. 
"
 "You may want a client-side facility such as psql's \\copy."

 "COPY FROM instructs the PostgreSQL server to read from a file on the 
server. "
 "You may want a client-side facility such as psql's \\copy."

This stresses more explicitly that the file is opened by the server
process. (I'm not particularly happy that it says "server" in there
twice, but couldn't think of anything else.)

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_hba_file_settings view patch

2016-09-04 Thread Christoph Berg

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 "settings" is wrong here. "pg_file_settings" means "settings in
config file (that might not been applied yet)". The contents of
pg_hba.conf are not config settings, but there doesn't appear to be a
standard name for them - 19.1 calls them "records".

Given that the patch seems to report what's on disk, "pg_hba_file"
seems a good name to me. Even if ALTER SYSTEM should become able to
update the file, it'd still be a file. (If it were the actual running
config, I'd go for "pg_hba_rules".)

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2016-09-02 Thread Christoph Berg

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, where the user doesn't understand why they can't read the
> file given that their local client has permission to do so.
> 
> I don't feel strongly about this and think that the error on ENOENT is
> by far the most important, so I'll adjust it per your recommendation.

Couldn't you just add EACCESS to the check as well?

> > 3. As for the wording, maybe you could do it like this:
> >
> > HINT:  COPY copies to[from] a file on the PostgreSQL server, not on the
> > client.  You may want a client-side facility such as psql's \copy.
> >
> > That avoids trying to invent a name for other implementations.
> 
> I like that wording a lot more, thanks. Adopted.

Same here, thanks!

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2016-08-27 Thread Christoph Berg

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 has started
> (which does not exists) would be more useful for a "make check", or at
> default maybe %n?

I've always been wondering why we don't set a log_line_prefix by
default. Logs without timestamps and (pid or session id or equivalent)
are useless. Of course in practise the log_line_prefix needs to be
different depending on the log_destination (syslog adds its own
timestamps, ...), but the current default of '' doesn't help anyone.

The above looks quite similar to what the Debian packages have been
setting as their default for some time, with standard stderr logging:

log_line_prefix = '%t [%p-%l] %q%u@%d '

People who want a different log channel need to touch the config
anyway and can update log_line_prefix as they go.

The concrete value to be used needs to be discussed, but I think we'd
end up with something like '%m [%p:%l] ' plus maybe some suffix.

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Renaming of pg_xlog and pg_clog

2016-08-26 Thread Christoph Berg

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 directories
altogether. If your backup tool fails because the pg_xlog directory is
gone, you'll hopefully notice, but if you end up with a backup that
consists merely of a copy of a symlink named pg_xlog, you might not
notice.

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] synchronous_commit = remote_flush

2016-08-21 Thread Christoph Berg

Re: Thomas Munro 2016-08-21

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

2016-08-15 Thread Christoph Berg

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 partition the catalogs so that vacuuming away temp-table
> > rows is easier/cheaper than today.
> 
> We should also be thinking about how the opposite idea of "global"
> temp tables

(Obviously I should catch up on the rest of the thread when postponing
a message for an hour or two. Sorry for the duplicated idea here...)

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2016-08-15 Thread Christoph Berg

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 than today.

We should also be thinking about how the opposite idea of "global"
temp tables (I believe that's what Oracle calls them) would work.
These have a persistent structure in the catalogs, just the data is
private to every session (or transaction); every connection starts
with an empty temp table and for their use.

I'd guess that type of global temp tables would fix the bloat problem
also very efficiently. (Ad-hoc temp tables shouldn't occur that often
so the bloat caused by them wouldn't matter that much. If they do,
their structure is likely always the same, and they could be made
"global" in the schema.)

The bit that needs to be thought out here would be how to maintain
statistics for these tables. Obviously ANALYZE shouldn't update any
globally visible data.

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

2016-08-12 Thread Christoph Berg

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 PostgreSQL server, not the client. You may
> want psql's \copy or a driver COPY ... FROM STDIN wrapper

+1 on the idea.

> postgres=# COPY x TO '/root/nopermissions';
> ERROR:  could not open file "/root/nopermissions" for writing: Permission
> denied
> HINT:  Paths for COPY are on the PostgreSQL server, not the client. You may
> want psql's \copy or a driver COPY ... FROM STDIN wrapper

TO STDOUT.

Also, I vaguely get what you wanted to say with "a driver ...
wrapper", but it's pretty nonsensical if one doesn't know about the
protocol details. I don't have a better suggestion now, but I think it
needs rephrasing.

Christoph


signature.asc
Description: PGP signature

Re: [HACKERS] pg_size_pretty, SHOW, and spaces

2016-08-02 Thread Christoph Berg

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 "pretty" :)

:)

> > SHOW does not:
> > 
> > # show work_mem;
> >  work_mem
> > ──
> >  1MB
> 
> The original idea might have been to allow that value to be passed back
> into the settings system, without having to quote the space.  I'm not
> sure, but I think changing that might cause some annoyance.

That's a good argument for keeping it that way, yes.


Re: Bruce Momjian 2016-08-01 <20160801162508.ga28...@momjian.us>
> Looking at the Wikipedia article I posted earlier, that also doesn't use
> spaces:
> 
>   https://en.wikipedia.org/wiki/Binary_prefix

That article has plenty of occurrences of "10 MB" "528 MB/s" and the
like.

> I think the only argument _for_ spaces is the output of pg_size_pretty()
> now looks odd, e.g.:
> 
>10 | 10 bytes   | -10 bytes
>  1000 | 1000 bytes | -1000 bytes
>   100 | 977KB  | -977KB
>10 | 954MB  | -954MB
> 1 | 931GB  | -931GB
>  1000 | 909TB  | -909TB
> ^ ^
> 
> The issue is that we output "10 bytes", not "10bytes", but for units we
> use "977KB".  That seems inconsistent, but it is the normal policy
> people use.  I think this is because "977KB" is really "977K bytes", but
> we just append the "B" after the "K" for bevity.

It's the other way round:

https://en.wikipedia.org/wiki/International_System_of_Units#General_rules

| The value of a quantity is written as a number followed by a space
| (representing a multiplication sign) and a unit symbol; e.g., 2.21 kg
[...]

I'd opt to omit the space anywhere where the value is supposed to be
fed back into the config (SHOW, --parameters), but use the "pretty"
format with space everywhere otherwise (documentation, memory counts
in explain output, pg_size_pretty() etc.)

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] pg_size_pretty, SHOW, and spaces

2016-08-01 Thread Christoph Berg

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);
 pg_size_pretty

 1024 kB

SHOW does not:

# show work_mem;
 work_mem
──
 1MB

The SHOW output is formatted by _ShowOption() using 'INT64_FORMAT "%s"',
via convert_from_base_unit(). The latter has a comment attached...
/*
 * Convert a value in some base unit to a human-friendly unit.  The output
 * unit is chosen so that it's the greatest unit that can represent the value
 * without loss.  For example, if the base unit is GUC_UNIT_KB, 1024 is
 * converted to 1 MB, but 1025 is represented as 1025 kB.
 */
... where the spaces are present again.

General typesetting standard seems to be "1 MB", i.e. to include a
space between value and unit. (This would also be my preference.)

Opinions? (I'd opt to insert spaces in the docs now, and then see if
inserting a space in the SHOW output is acceptable for 10.0.)

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] sslmode=require fallback

2016-07-19 Thread Christoph Berg

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: Peter Eisentraut 2016-07-17 <
>> d6b22200-0e65-d17e-b227-b63d81720...@2ndquadrant.com>
>> > 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 towards encouraging people.
>> >
>> > Debian, which I guess sort of started this, does not, but there are
>> > allusions to it in the TODO list.
>>
>> I guess we should actually do that if we had any non-local(host)
>> entries in there by default, but we don't touch the default
>> pg_hba.conf from pg_createcluster.
>>
>
>What could actually be useful there is to explicitly put hostnossl on
>the
>localhost entries. With the current defaults on the clients, that
>wouldn't
>break anything, and it would leave people without the performance
>issues
>that you run into in the default deployments. And for localhost it
>really
>does't make sense to encrypt -- for the local LAN segment that can be
>argued, but for localhost...
>
>
>-- 
> Magnus Hagander
> Me: http://www.hagander.net/
> Work: http://www.redpill-linpro.com/

Re: [HACKERS] sslmode=require fallback

2016-07-17 Thread Christoph Berg

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 towards encouraging people.
> 
> Debian, which I guess sort of started this, does not, but there are
> allusions to it in the TODO list.

I guess we should actually do that if we had any non-local(host)
entries in there by default, but we don't touch the default
pg_hba.conf from pg_createcluster.

Possibly we could add some hostssl example in comments to the end of
the .sample file so people could grow the habit of using that instead
of host (I certainly aren't doing myself that yet), but I'd rather see
that changed upstream.

So, how about something like this for the end of pg_hba.conf.sample?

# Examples for allowing access from given networks:
#hostssl all  all  192.0.2.0/24   @authmethod@
#hostssl all  all  2001:DB8::/32  @authmethod@

(These are "documentation" networks from RF5737/RFC3849.)

Christoph

signature.asc
Description: PGP signature

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

2016-07-02 Thread Christoph Berg

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:  get_typlenbyval, lsyscache.c:1976

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

2016-07-02 Thread Christoph Berg

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", pgcrypto still
> > needs work, though:
> 
> Thanks, I had forgotten pgcrypto.

pgcrypto works now as well, thanks!

Re: Alvaro Herrera 2016-07-02 <20160702002846.GA376611@alvherre.pgsql>
> Generally, version number tests sprinkled all over the place are not
> terribly nice.  I think it would be better to get configure to define a
> symbol like HAVE_BIO_METH_NEW.  Not sure about the other hunks in this
> patch; perhaps HAVE_BIO_SET_DATA, and #define both those macros if not.

Otoh these symbols are strictly version-dependant on OpenSSL, it's not
like one of the symbols would appear or disappear for other reasons
(like different TLS implementation, or different operating system).

Once we decide (in 10 years?) that the minimum supported OpenSSL
version is >= 1.1, we can just drop the version checks. If these are
converted to feature tests now, it will be much harder to remember at
which point they can be dropped.

Christoph

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Broken handling of lwlocknames.h

2016-07-02 Thread Christoph Berg

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 pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

2016-07-01 Thread Christoph Berg

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 applied all there patches on top of HEAD
(10c0558f). The server builds and passes "make check", pgcrypto still
needs work, though:

./configure --with-openssl
make world

gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement 
-Wendif-labels -Wmissing-format-attribute -Wformat-security 
-fno-strict-aliasing -fwrapv -fexcess-precision=standard -O2 -fpic -I. -I. 
-I../../src/include -D_GNU_SOURCE   -c -o openssl.o openssl.c
openssl.c:205:13: error: field ‘ctx’ has incomplete type
  EVP_MD_CTX ctx;
 ^
openssl.c: In function ‘digest_free’:
openssl.c:253:2: warning: implicit declaration of function ‘EVP_MD_CTX_cleanup’ 
[-Wimplicit-function-declaration]
  EVP_MD_CTX_cleanup(>ctx);
  ^
openssl.c: In function ‘init_openssl_rand’:
openssl.c:990:24: warning: implicit declaration of function ‘RAND_SSLeay’ 
[-Wimplicit-function-declaration]
   RAND_set_rand_method(RAND_SSLeay());
^
openssl.c:990:24: warning: passing argument 1 of ‘RAND_set_rand_method’ makes 
pointer from integer without a cast [-Wint-conversion]
In file included from openssl.c:40:0:
/usr/include/openssl/rand.h:41:5: note: expected ‘const RAND_METHOD * {aka 
const struct rand_meth_st *}’ but argument is of type ‘int’
 int RAND_set_rand_method(const RAND_METHOD *meth);
 ^
openssl.c: In function ‘px_get_pseudo_random_bytes’:
openssl.c:1017:2: warning: ‘RAND_pseudo_bytes’ is deprecated 
[-Wdeprecated-declarations]
  res = RAND_pseudo_bytes(dst, count);
  ^
In file included from openssl.c:40:0:
/usr/include/openssl/rand.h:51:5: note: declared here
 DEPRECATEDIN_1_1_0(int RAND_pseudo_bytes(unsigned char *buf, int num))
 ^
openssl.c: In function ‘digest_block_size’:
openssl.c:222:1: warning: control reaches end of non-void function 
[-Wreturn-type]
 }
 ^
openssl.c: In function ‘digest_result_size’:
openssl.c:214:1: warning: control reaches end of non-void function 
[-Wreturn-type]
 }
 ^
: die Regel für Ziel „openssl.o“ scheiterte
make[2]: *** [openssl.o] Fehler 1
make[2]: Verzeichnis „/home/cbe/projects/postgresql/pg/master/contrib/pgcrypto“ 
wird verlassen

ii  libssl-dev:amd641.1.0~pre5-4 amd64Secure Sockets 
Layer toolkit - development files
ii  libssl1.0.0:amd64   1.0.2d-1 amd64Secure Sockets 
Layer toolkit - shared libraries
ii  libssl1.0.2:amd64   1.0.2h-1 amd64Secure Sockets 
Layer toolkit - shared libraries
ii  libssl1.1:amd64 1.1.0~pre5-4 amd64Secure Sockets 
Layer toolkit - shared libraries
ii  openssl 1.0.2h-1 amd64Secure Sockets 
Layer toolkit - cryptographic utility

Christoph


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Broken handling of lwlocknames.h

2016-06-27 Thread Christoph Berg

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.  The failure looks like
> 
> gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement 
> -Wendif-labels -Wmissing-format-attribute -Wformat-security 
> -fno-strict-aliasing -fwrapv -g -O1 -fpic -I../../../src/include 
> -D_GNU_SOURCE   -c -o regress.o regress.c
> In file included from ../../../src/include/storage/lock.h:23,
>  from ../../../src/include/access/heapam.h:22,
>  from ../../../src/include/nodes/execnodes.h:18,
>  from ../../../src/include/commands/trigger.h:17,
>  from regress.c:29:
> ../../../src/include/storage/lwlock.h:129:33: error: storage/lwlocknames.h: 
> No such file or directory
> make: *** [regress.o] Error 1
> 
> So this is some sort of fallout from commit aa65de042f582896, which
> invented that as a generated file.
> 
> Perhaps the solution is to extend src/test/regress/GNUmakefile to know
> about this file explicitly (as it already does know about
> src/port/pg_config_paths.h).  But that seems rather brute-force; in
> particular it seems like that does nothing to keep us from getting burnt
> again the same way in future.  I wonder if we should modify
> src/backend/Makefile so that it exposes a phony target for "update all the
> generated include files", and then have src/test/regress/GNUmakefile call
> that.  Or maybe there are other ways.

That would also fix the "build plpython3 only" problem I was aiming at
in https://www.postgresql.org/message-id/20150916200959.gb32...@msg.df7cb.de

So another +1 from a packagers perspective.

Christoph


signature.asc
Description: PGP signature

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

2016-06-27 Thread Christoph Berg

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 removal of the SSL_library_init
> symbol anywhere. They changed the function into a macro in the following
> commit. I guess we have to check for some other symbol, like SSL_new.

I'm not an autoconf expert, but as said in the original mail, I could
get the SSL_library_init check to work, even if that's a macro now:

> -  AC_CHECK_LIB(ssl,SSL_library_init, [], [AC_MSG_ERROR([library 
> 'ssl' is required for OpenSSL])])
> +  AC_CHECK_LIB([ssl],  [SSL_library_init])

(I haven't investigated if that's due to the quoting, the removal of
the extra arguments, or simply because I reran autoreconf.)

> I think much of the above is missing from the release notes I have found. I
> hope they will be more complete at the time of the release. I am working on
> a patch to handle these API changes.
> 
> - https://www.openssl.org/news/openssl-1.1.0-notes.html
> - https://wiki.openssl.org/index.php/1.1_API_Changes

Nod, I was also disappointed when browsing the API changes document,
given it didn't mention any of the problems I was seeing.

Christoph


signature.asc
Description: PGP signature

1 2 3 4 >

1 - 100 of 308 matches

Mail list logo