Re: [PATCH v20] GSSAPI encryption support

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, David Steele <david(at)pgmasters(dot)net>, Joe Conway <mail(at)joeconway(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Michael Paquier <michael(at)paquier(dot)xyz>, Nico Williams <nico(at)cryptonector(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Robbie Harwood <rharwood(at)redhat(dot)com>
Subject: Re: [PATCH v20] GSSAPI encryption support
Date: 2019-04-04 17:05:29
Message-ID: 18056.1554397529@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> Watching the test logs, I see that essentially all the time on the RHEL6
>> machine is consumed by the two
>> # Running: /usr/sbin/kdb5_util create -s -P secret0
>> steps. Is there a case for merging the two scripts so we only have to
>> do that once? Maybe not, if nobody else sees this.

> I do think that mergeing them would be a good idea and I can look into
> that, though at least locally that step takes less than a second.. I
> wonder if you might strace (or whatever is appropriate) that kdb5_util
> and see what's taking so long. I seriously doubt it's the actual
> kdb5_util code and strongly suspect it's some kernel call.

"strace -r" pins the blame pretty firmly on /dev/random:

0.000076 open("/dev/random", O_RDONLY) = 3
0.000227 fcntl(3, F_SETFD, FD_CLOEXEC) = 0
0.000061 fstat(3, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 8), ...}) = 0
0.000068 read(3, "\336&\301\310V\344q\217\264-\262\320w-", 64) = 14
0.000091 read(3, "\326\353I\371$\361", 50) = 6
15.328306 read(3, "\214\301\313]I\325", 44) = 6
17.418929 read(3, "z\251\37\275\365\24", 38) = 6
13.366997 read(3, "6\257I\315f\3", 32) = 6
11.457994 read(3, "\370\275\2765\31(", 26) = 6
23.472194 read(3, "\226\r\314\373\2014", 20) = 6
11.746848 read(3, "\335\336BR\30\322", 14) = 6
20.823940 read(3, "\366\214\r\211\0267", 8) = 6
14.429214 read(3, ",g", 2) = 2
15.494835 close(3) = 0

There's no other part of the trace that takes more than ~ 0.1s.
So this boils down to the old bugaboo about how much entropy
there really is in /dev/random.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2019-04-04 17:10:44 Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits
Previous Message Mark Wong 2019-04-04 16:59:27 Re: [GSoC 2019] Proposal: Develop Performance Farm Database and Website