fferently from the
existing, such that the if (res) clause is indented equally to the previous
pg_free(tableinfo.relam) call, making it look like they are in the same block:
> +if (tableinfo.relam)
> +pg_free(tableinfo.relam);
>
> if (res)
> PQclear(res);
--
Daniel Gustafsson https://vmware.com/
201d we no longer need be concerned
with test counts, so we can replace this with normal is() tests, as per the
attached, making the output in the errorpath consistent with other tests.
Unless I'm missing something important here.
--
Daniel Gustafsson https://vmware.com/
0001-Use
> On 21 Feb 2022, at 03:03, Michael Paquier wrote:
>
> On Fri, Feb 18, 2022 at 10:00:43PM +0100, Daniel Gustafsson wrote:
>> This is good idea, I was going in a different direction earlier with a test
>> but
>> this is cleaner. The attached 0001 refactors pump_unti
> On 21 Feb 2022, at 02:07, Andres Freund wrote:
> Baring that, anybody against committing this?
LGTM. The above mentioned comment was the only thing I found as well.
--
Daniel Gustafsson https://vmware.com/
Starting a new thread on the TAP patch from the "[RFC] building postgres with
meson" thread at 20220221165228.aqnfg45mceym7...@alap3.anarazel.de to have
somewhere to discuss this patch.
> On 21 Feb 2022, at 17:52, Andres Freund wrote:
> On 2021-10-13 13:54:10 +0200, Daniel
have it.
The section in question was added to our docs 22 years ago, to make it reflect
the current operating systems in use maybe just not mentioning more(1) is the
easiest?:
"The text browsing tool less can be invoked as less -x4 to make it show
tabs appropriately."
Or perhaps remove that section altogether?
--
Daniel Gustafsson https://vmware.com/
> On 22 Feb 2022, at 00:08, Daniel Gustafsson wrote:
> I'll fix that.
The attached v3 fixes that thinko, and cleans up a lot of the output which
isn't diagnostic per the TAP spec to make it less noisy. It also fixes tag
support used in the ECPG tests and a few small cleanups.
> On 22 Feb 2022, at 18:13, Andres Freund wrote:
> On 2022-02-22 15:10:11 +0100, Daniel Gustafsson wrote:
>> The errorpaths that exit(2) the testrun should be converted to "bail out"
>> lines
>> when running with TAP output, but apart from that I think it&#x
> On 21 Feb 2022, at 16:17, Andrew Dunstan wrote:
> Looks OK.
Thanks, pushed.
--
Daniel Gustafsson https://vmware.com/
> On 22 Feb 2022, at 02:13, Michael Paquier wrote:
> The patch set looks fine overall.
Thanks for reviewing and testing, I pushed this today after taking another
round at it.
--
Daniel Gustafsson https://vmware.com/
thers agree?
Many +1's on that.
> The tap test needs a bit more polish, mostly posted this to get some feedback
> before wasting more time :)
Skimming the new test it seems structurally fine to me.
--
Daniel Gustafsson https://vmware.com/
In pg_regress we realloc() with the destination and source pointer being equal,
without checking for OOM. While a fairly unlikely source of errors, is there a
reason not to use pg_realloc() there for hygiene?
--
Daniel Gustafsson https://vmware.com/
pg_regress_realloc.diff
to
> address it [1].
There is yet another related patch which provides a parameter to pass in
restore_command in cases where postgresq.conf isn't reachable:
https://commitfest.postgresql.org/37/3213/
--
Daniel Gustafsson https://vmware.com/
code easier.
I don't have any strong opinions on this, but if we go ahead with it I think
there should be a short note in src/test/perl/README about when substest could
be considered.
--
Daniel Gustafsson https://vmware.com/
the format is not changed. Maybe a comment could be added to explain the
> reason behind it.
That doesn't sound like an overwhelmingly convincing argument to print some
messages with 'X %' and others with 'X%'.
--
Daniel Gustafsson https://vmware.com/
g_rewind) is a recipe
for them diverging.
--
Daniel Gustafsson https://vmware.com/
> On 24 Feb 2022, at 07:32, Kyotaro Horiguchi wrote:
>
> At Thu, 24 Feb 2022 14:44:56 +0900 (JST), Kyotaro Horiguchi
> wrote in
>> At Tue, 22 Feb 2022 09:59:09 +0100, Daniel Gustafsson
>> wrote in
>>> The section in question was added to our docs 22 y
> On 23 Feb 2022, at 23:05, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> In pg_regress we realloc() with the destination and source pointer being
>> equal,
>> without checking for OOM. While a fairly unlikely source of errors, is
>> there a
>> r
> On 27 Feb 2022, at 18:42, Tom Lane wrote:
> I'd rather keep all the ModifyTable code in one .c file, even if that one is
> bigger than our usual practice.
Agreed, I also prefer a (too) large file over a set of .c #include's.
--
Daniel Gustafsson https://vmware.com/
production which allow compression.
--
Daniel Gustafsson https://vmware.com/
> On 28 Feb 2022, at 12:56, Peter Eisentraut
> wrote:
> On 28.02.22 11:50, Dagfinn Ilmari Mannsåker wrote:
>> Daniel Gustafsson writes:
>>> This was originally done, but all client side changes reverted as there
>>> still
>>> are server versions in
> On 1 Mar 2022, at 09:44, Peter Eisentraut
> wrote:
> I propose a reduced patch that just removes the "bits" display, since that is
> redundant with the "cipher"
No objections from me.
--
Daniel Gustafsson https://vmware.com/
> On 1 Mar 2022, at 17:16, Greg Stark wrote:
> Last November Daniel Gustafsson did a patch triage. It took him three
> emails to get through the patches in the commitfest back then.
It should be noted that I only powered through the patches that had been in 3+
commitfests at
> On 3 Mar 2022, at 10:11, Yugo NAGATA wrote:
> I think this patch set needs more reviews to be commitable in 15, so I
> returned the target version to blank. I'll change it to 16 later.
I've added 16 as a target version in the CF app now.
--
Daniel Gustafsson https://vmware.com/
itrarily complex and it's up to the user to measure
and decide - but the bare overhead we impose is still of interest of course.
--
Daniel Gustafsson https://vmware.com/
even
drop the trigger, restart in single-user mode and you'll be able to do
that."
Something like a '-c ignore_event_trigger=' GUC perhaps?
--
Daniel Gustafsson https://vmware.com/
er having been used temporary, and then X timeunits later someone realize
that the backup has never actually really worked due to a subtle issue, or
something else unpleasant.
The row_security GUC is kind of different IMO, as it's required for pg_dump
(though it can be used in the same way as the
eviously posted v25 login event trigger patch, and 0003 adapts is to
allow ignoring it (0002/0003 split only for illustrative purposes of course).
Is this along the lines of what you were thinking?
--
Daniel Gustafsson https://vmware.com/
v26-0003-Add-IGNORE_EVENT_TRIGGER_LOGIN.patch
> On 14 Mar 2022, at 17:10, Andres Freund wrote:
>
> Hi,
>
> On 2022-03-14 14:47:09 +0100, Daniel Gustafsson wrote:
>>> On 14 Mar 2022, at 01:08, Andres Freund wrote:
>>
>>> I was thinking that the way to use it would be to specify it as
> On 16 Mar 2022, at 08:36, Kyotaro Horiguchi wrote:
> I think we don't want this behavior.
Agreed.
> The attached fixes that and make-world successfully finished even if I
> have a cert file in my home direcotory.
Seems correct to me, thanks!
--
Daniel Gustafsson
"$common_connstr sslrootcert=invalid sslmode=require",
+ "$common_connstr sslmode=require",
..is making it fairly hard to read the test and visualize what the connection
string is and how the test should behave. I don't have a better idea off the
top of my head right now, but I think this is an area to revisit and improve
on.
--
Daniel Gustafsson https://vmware.com/
7;s not entirely clear to me what the original
author really intended here, so I've changed it up a bit to actually test
something and removed the need for the regress_user role. I've also fixed the
silly mistake highlighted in the postgresql.conf.sample test.
--
Daniel Gustafsson
> On 22 Mar 2022, at 04:48, Andres Freund wrote:
> docs fail to build:
> https://cirrus-ci.com/task/5556234047717376?logs=docs_build#L349
Ugh, that one was on me and not the original author. Fixed.
--
Daniel Gustafsson https://vmware.com/
v29-0001-Provide-
ordinal--; */ /* skip current outer row, reset counter */
Is this dead code to be removed, or left in there as a reminder to fix
something?
--
Daniel Gustafsson https://vmware.com/
> On 1 Dec 2020, at 06:38, Michael Paquier wrote:
>
> On Mon, Nov 30, 2020 at 02:29:29PM +0100, Daniel Gustafsson wrote:
>> Yeah, that's along the lines of what I was thinking of.
>
> Hmm. I have looked at that, and thought first about having directly a
> referenc
> On 2 Dec 2020, at 12:54, Peter Eisentraut
> wrote:
> While reading about deprecating and removing various things in other threads,
> I was wondering about how deprecated SELECT INTO is. There are various
> source code comments about this, but the SELECT INTO reference page only
> contains
> On 3 Dec 2020, at 03:03, Michael Paquier wrote:
> Any objections to rename that to cryptohashfuncs.c? That would be
> much more consistent with the surroundings (cleaning up anythig
> related to MD5 is on my TODO list). Patch is attached.
+1 on this proposed rename.
cheers ./daniel
> On 3 Dec 2020, at 02:47, Michael Paquier wrote:
>
> On Wed, Dec 02, 2020 at 12:03:49PM +0900, Michael Paquier wrote:
>> Thanks. 0001 has been applied and the buildfarm does not complain, so
>> it looks like we are good (I'll take care of any issues, like the one
>> Fujii-san has just reported)
> On 20 Nov 2020, at 22:13, Stephen Frost wrote:
> Attached is a patch to move from 'default role' terminology to
> 'predefined role' in the documentation. In the code, I figured it made
> more sense to avoid saying either one and instead opted for just
> 'ROLE_NAME_OF_ROLE' as the #define, whic
> On 4 Dec 2020, at 08:05, Michael Paquier wrote:
>
> On Tue, Nov 10, 2020 at 01:28:09PM +0900, Michael Paquier wrote:
>> The CF bot has been complaining on Windows and this issue is fixed in
>> the attached. A refresh of src/tools/msvc for pgcrypto was just
>> missing.
>
> Now that HEAD has th
> On 9 Dec 2020, at 06:47, Michael Paquier wrote:
> In short, this seems rather committable to me.
Agreed, this version of the patch looks good to me. I've looked over the
attributions for the code movement and it seems to match now, and all tests
pass etc. +1 on going ahead with this version.
> On 2 Dec 2020, at 22:38, Bruce Momjian wrote:
>
> Attached is a patch for key management, which will eventually be part of
> cluster file encryption (CFE), called TDE (Transparent Data Encryption)
> by Oracle.
The attackvector protected against seems to be operating systems users
(*without* an
I went looking at the SSL connection state change information callback we
install when setting up connections with OpenSSL, and I wasn't getting the
state changes I expected. Turns out we install it at the tail end of setting
up the connection so we miss most of the calls. Moving it to the beginn
> On 16 Dec 2020, at 17:26, Stephen Frost wrote:
>
> Greetings,
>
> * Michael Paquier (mich...@paquier.xyz) wrote:
>> On Tue, Dec 15, 2020 at 02:09:09PM -0500, Stephen Frost wrote:
>>> Yeah, looking at what's been done there seems like the right approach to
>>> me as well, ideally we'd have one
> On 28 Dec 2020, at 13:04, Masahiko Sawada wrote:
> if you want your patch to be reviewed as part of the
> upcoming CommitFest, then you need to add it yourself before
> 2021-01-01 AoE[2]. Thanks for your contributions.
I thought I had added it but clearly I had missed doing so, fixed now. Tha
> On 5 Jan 2021, at 18:19, Michael Banck wrote:
>> diff --git a/doc/src/sgml/ref/initdb.sgml b/doc/src/sgml/ref/initdb.sgml
>> index 385ac25150..e3b0048806 100644
>> --- a/doc/src/sgml/ref/initdb.sgml
>> +++ b/doc/src/sgml/ref/initdb.sgml
>> @@ -219,6 +219,7 @@ PostgreSQL documentation
>>
atches to attempts such state changes we can see which
pieces of infrastructure we're lacking to reduce complexity. A good example is
the ProcSignalBarrier work that Andres and Robert did, inspired in part by this
patch IIUC. The more we do, the more we learn.
--
Daniel Gustafsson https://vmware.com/
he patch has been registered in the commitfest app so it
may have been forgotten about, the number of proposed patches often outnumber
the code review bandwidth. Please register it at:
https://commitfest.postgresql.org/32/
..to make sure it doesn't get lost.
--
Daniel Gustafsson https://vmware.com/
> On 17 Feb 2021, at 02:02, Jacob Champion wrote:
> On Mon, 2020-07-20 at 15:35 +0200, Daniel Gustafsson wrote:
>> This version adds support for sslinfo on NSS for most the functions.
>
> I've poked around to see what can be done about the
> unimplemented ssl_client
keep?
--
Daniel Gustafsson https://vmware.com/
[0]
https://www.postgresql.org/message-id/flat/595cf3b1-4ffe-7f05-6f72-f72b7afa7993%402ndquadrant.com
openssl_disallow_compression.patch
Description: Binary data
> On 22 Feb 2021, at 11:52, Magnus Hagander wrote:
>
> On Thu, Feb 18, 2021 at 1:51 PM Daniel Gustafsson wrote:
>>
>> A few years ago we discussed whether to disable SSL compression [0] which
>> ended
>> up with it being off by default combined with a recomme
influence the content in a lot of repeated
> encrypted packets between client/server that are otherwise unchanged (or
> predictable). It's possible that you can come up with something
> contorted if the attacker controls the data the client requests, but
> I don't
> On 27 Jul 2019, at 08:42, Peter Eisentraut
> wrote:
>
> On 2019-07-25 16:33, Daniel Gustafsson wrote:
>> Fair enough, those are both excellent points. I’ve shuffled the code around
>> to
>> move back the check for exec_path to setup (albeit earlier than bef
tified but under "Options"
all long-options are aligned with space indentation for missing shorts. Some
tools do it like this, where others like createuser left justifies under
Options as well. Maybe not the most pressing issue, but consistency is always
good in user interfaces so mayb
> On 26 Feb 2021, at 11:02, Magnus Hagander wrote:
> On Mon, Feb 22, 2021 at 12:28 PM Daniel Gustafsson wrote:
>>
>>> On 22 Feb 2021, at 11:52, Magnus Hagander wrote:
>>> Agreed. It will also help with not having to implement it in new SSL
>>> implementa
tty removal from 2003, and raise you one "authtype" which was axed
on January 26 1998 in commit d5bbe2aca55bc833e38c768d7f82, but which is still
around. More on that in a separate thread though.
--
Daniel Gustafsson https://vmware.com/
east remove the environment variable and
default compiled fallback for it to save us a getenv call when filling in the
option defaults?
--
Daniel Gustafsson https://vmware.com/
0001-Remove-defaults-from-authtype-parameter.patch
Description: Binary data
te that returning 'false' can lead to
-* very frequent retries, so try hard to make that an uncommon case.
-*/
+ smgrrelease();
Should this instead be in smgr.c to avoid setting a precedent for procsignal.c
to be littered with absorption functions?
--
Daniel Gustafsson https://vmware.com/
> On 2 Mar 2021, at 07:04, Michael Paquier wrote:
> I have also removed the assertions based on the version number of the
> backend, based on Daniel's input sent upthread.
>
> What do you think?
+1, no objections from me after a readthrough of this version.
n port/qsort.c referring back to
sort_template.h for documentation.
--
Daniel Gustafsson https://vmware.com/
[0] https://github.com/dwyl/english-words/ shuffled 20 times over
qsort_tmpl_strcmp-patch
Description: Binary data
> On 2 Mar 2021, at 14:20, Peter Eisentraut
> wrote:
>
> On 23.02.21 17:14, Daniel Gustafsson wrote:
>> This exports validate_exec to reduce duplication, and implements a custom
>> find_other_exec-like function in pg_upgrade to check each binary for the
>> version
> On 3 Mar 2021, at 09:57, Peter Eisentraut
> wrote:
> I committed this. I added a pg_strip_crlf() so that there are no newlines in
> the error message.
Right, that's much better, thanks!
--
Daniel Gustafsson https://vmware.com/
> On 26 Feb 2021, at 20:34, Daniel Gustafsson wrote:
> Attached is a v2 which retains the sslcompression parameter for backwards
> compatibility.
And now a v3 which fixes an oversight in postgres_fdw as well as adds an SSL
TAP test to cover deprecated parameters.
--
Daniel G
sting this on Linux and macOS by inducing the codepath. Will try to do
some testing in Windows as well.
--
Daniel Gustafsson https://vmware.com/
> On 3 Mar 2021, at 14:47, Peter Eisentraut wrote:
>
> On 26.02.21 21:02, Daniel Gustafsson wrote:
>> When looking at disallowing SSL compression I found the parameter "authtype"
>> which was deprecated in commit d5bbe2aca55bc8 on January 26 1998. While I do
>
> On 3 Mar 2021, at 15:14, Peter Eisentraut
> wrote:
>
> On 03.03.21 11:31, Daniel Gustafsson wrote:
>>> On 26 Feb 2021, at 20:34, Daniel Gustafsson wrote:
>>> Attached is a v2 which retains the sslcompression parameter for backwards
>>> compatibility.
&
o keep around
> pg_stat_ssl.compression while we know that it will always be false.
> Wouldn't it be better to get rid of that in PgBackendSSLStatus and
> pg_stat_ssl then?
Fixed in the v4 posted just now, although I opted for keeping the column in
pg_stat_ssl for backwards compatibility with a doc note.
--
Daniel Gustafsson https://vmware.com/
> On 5 Mar 2021, at 08:04, Michael Paquier wrote:
>
> On Thu, Mar 04, 2021 at 11:52:56PM +0100, Daniel Gustafsson wrote:
>> The attached version takes a step further and removes sslcompression from
>> pg_conn and just eats the value as there is no use in setting a dummy
> On 3 Mar 2021, at 23:19, Thomas Munro wrote:
> On Thu, Mar 4, 2021 at 4:18 AM Daniel Gustafsson wrote:
>> Since there is no way to get make the first destroy_tablespace_directories
>> call
>> fail on purpose in testing, the assertion coverage may have limited use
der what is generally backported into a stable release?
--
Daniel Gustafsson https://vmware.com/
oach?
Michael Banck started a new thread for that forking off of this one on message
id 8f193f949b39817b9c642623e1fe7ccb94137ce4.ca...@credativ.de so it's probably
better to continue the discussion of that over there.
--
Daniel Gustafsson https://vmware.com/
s of this CF entry, and perhaps also on the status
> of OpenSSL compatibility in general?
Let's just wait for 3.0.0 to ship before we do anything.
--
Daniel Gustafsson https://vmware.com/
return PXE_CIPHER_INIT;
if (!EVP_CIPHER_CTX_set_key_length(od->evp_ctx, od->klen))
return PXE_CIPHER_INIT;
if (!EVP_EncryptInit_ex(od->evp_ctx, NULL, NULL, od->key,
od->iv))
.. then all the pgcrypto tests pass for me as w
> On 12 Mar 2021, at 00:04, Peter Eisentraut
> wrote:
>
> On 11.03.21 11:41, Daniel Gustafsson wrote:
>> Then there are a few where we get padding back where we really should have
>> ended up with the "Cipher cannot be initialized" error since DES is in
Commit b918bf86c65 added the errorcode PXE_DECRYPT_FAILED to the existing set
of PXE_ error codes. When pgcrypto was changed to the EVP APIs in 5ff4a67f63,
no new error codes were added in favour of existing ones. This results in
encryption failures returning PXE_ERR_GENERIC, which seems a bit in
While hacking on the NSS patch I realized that sslinfo was passing the ->ssl
Port member directly to OpenSSL in order to extract information regarding the
connection. This breaks the API provided by the backend, as well as duplicates
code for no real benefit. The attached 0001 patch rewrites ssli
> On 30 Oct 2020, at 00:40, Andres Freund wrote:
> There's quite a few copies of this code that look exactly the same,
> except for the be_tls_get_* call. Do you see a way to have fewer copies
> of the same code?
There's really only two of the same, and two sets of those. I tried some
variation
> On 30 Oct 2020, at 16:54, Georgios Kokolatos
> wrote:
> I did notice that the cfbot [1] is not failing for this patch.
I assume you mean s/failing/passing/? I noticed the red Travis and Appveyor
runs, will fix over the weekend. Thanks for the heads-up.
cheers ./daniel
> On 31 Oct 2020, at 02:03, Michael Paquier wrote:
> It seems to me that you are just missing to declare a new error number
> in px.h, so I would suggest to just use -19.
Ah yes, I accidentally fat-fingered the git add -p when splitting up the NSS
patch into bite size pieces. Sorry about that. T
> On 3 Nov 2020, at 10:05, Magnus Hagander wrote:
> Applied, with the small adjustment of the comma in the docs.
Thanks!
> I wonder if we should perhaps backpatch 0002? The changes to sslinfo
> that were ported go all the way back to 9.6, so it should be a safe
> one I think?
It should be safe
> On 3 Nov 2020, at 11:35, Michael Paquier wrote:
>
> On Tue, Nov 03, 2020 at 10:15:48AM +0100, Magnus Hagander wrote:
>> On Wed, Aug 26, 2020 at 2:19 PM Daniel Gustafsson wrote:
>>> That's certainly true. The intention though is to make the code easier
> On 2 Nov 2020, at 15:17, Andrew Dunstan wrote:
> We could generalize that saving mechanism and do it if any module
> required it. But instead of testing against a different branch, we'd
> test against a different animal. So we'd have two animals, one building
> with openssl and one with nss, an
> On 5 Nov 2020, at 04:44, Michael Paquier wrote:
>
> On Wed, Nov 04, 2020 at 10:05:48AM +0100, Magnus Hagander wrote:
>> Yes, we should absolutely do that. We already do this for
>> pg_strong_random() itself, and we should definitely repeat the pattern
>> in the init function.
>
> This poked at
> On 5 Nov 2020, at 13:12, Michael Paquier wrote:
>
> On Thu, Nov 05, 2020 at 10:49:45AM +0100, Daniel Gustafsson wrote:
>> This must check for USE_OPENSSL as well as per my original patch, since we'd
>> otherwise fail to perform post-fork initialization in cas
> On 5 Nov 2020, at 13:28, Michael Paquier wrote:
> It seems to me that this one would become incorrect if compiling with
> OpenSSL but select a random source that requires an initialization, as
> it would enforce only OpenSSL initialization all the time.
Right, how about something like the atta
> On 6 Nov 2020, at 00:36, Michael Paquier wrote:
> I still don't see the point of this extra complexity, as
> USE_OPENSSL_RANDOM implies USE_OPENSSL,
As long as we're sure that we'll remember to fix this when that assumption no
longer holds (intentional or unintentional) then it's fine to skip
> On 10 Nov 2020, at 21:11, Jacob Champion wrote:
> On Nov 6, 2020, at 3:11 PM, Daniel Gustafsson wrote:
>> The attached switches to SSL_ConfigServerSessionIDCacheWithOpt
>> with which one can explicitly make the cache non-shared, which in turn backs
>> the mutexes wit
> On 11 Nov 2020, at 20:44, Bruce Momjian wrote:
> On Tue, Nov 10, 2020 at 01:38:14PM +0800, Craig Ringer wrote:
>> I noticed that when recovery.conf was removed in 2dedf4d9a8 (yay!) the docs
>> for
>> it were removed completely as well. That's largely sensible, but is confusing
>> when users ha
> On 11 Nov 2020, at 21:01, Bruce Momjian wrote:
>
> On Wed, Nov 11, 2020 at 08:59:40PM +0100, Daniel Gustafsson wrote:
>>> On 11 Nov 2020, at 20:44, Bruce Momjian wrote:
>>> On Tue, Nov 10, 2020 at 01:38:14PM +0800, Craig Ringer wrote:
>>
>>>> I n
> On 5 Oct 2020, at 14:14, Heikki Linnakangas wrote:
>
> Replying to an older message in this thread:
>
>>> + /*
>>> + * If we reach this point with checksums in inprogress state, we notify
>>> + * the user that they need to manually restart the process to enable
>>> + * checksums. This is becau
> On 11 Nov 2020, at 21:44, Andrew Dunstan wrote:
> If people like this idea I'll add tests and docco and add it to the next CF.
Sounds like a good idea, please do.
Can this case really happen in non-ancient OpenSSL version?
+ if (!x509name)
Doesn't this returnpath need a pfree(p
When spellchecking one of my patches for submission, a few other typos fell out
as per the attached. The one change which isn't in a comment is the object
address class description used for error messages:
- "extented statistics",
+ "extended statistics",
It's used in
> On 16 Nov 2020, at 01:20, Michael Paquier wrote:
>
> On Sun, Nov 15, 2020 at 12:16:56PM -0500, Tom Lane wrote:
>> The obvious problem with this is that if !USE_OPENSSL, we will not have
>> pulled in openssl's headers.
>
> FWIW, I argued upthread against including this part because it is
> usel
> On 16 Nov 2020, at 16:06, Tom Lane wrote:
>
> Magnus Hagander writes:
>> I agree with those -- either we remove the ability to choose random source
>> independently of the SSL library (and then only use the windows crypto
>> provider or /dev/urandom as platform-specific choices when *no* SSL l
> On 18 Nov 2020, at 02:31, Michael Paquier wrote:
>
> On Tue, Nov 17, 2020 at 09:24:30PM +0100, Daniel Gustafsson wrote:
>> I tend to agree, randomness is complicated enough without adding a compile
>> time
>> extensibility which few (if anyone) will ever use.
> On 11 Nov 2020, at 07:13, Michael Paquier wrote:
> I would like to propose the attached to tighten the error handling in
> the area, generating a fatal error if an array cannot be parsed.
I agree that we should fix this even if it will have quite limited impact in
production settings. Patch L
> On 18 Nov 2020, at 09:54, Michael Paquier wrote:
>
> On Wed, Nov 18, 2020 at 09:25:44AM +0100, Daniel Gustafsson wrote:
>> Technically that is what it does, except for setting the USE_*RANDOM
>> variables
>> for non-OpenSSL builds. We could skip that too, w
> On 18 Nov 2020, at 19:01, Andrew Dunstan wrote:
> OK, here's a new patch, including docco and tests.
Looks good on a quick skim, the only thing that stood out was:
+ This option is probably best used in comjunction with a username map.
s/comjunction/conjunction/
Will do more testing an
> On 19 Nov 2020, at 04:34, Michael Paquier wrote:
>
> On Wed, Nov 18, 2020 at 10:43:35AM +0100, Daniel Gustafsson wrote:
>> While it does simplify configure.ac, I'm just not a fan of the strict
>> ordering
>> which is required without the labels even implying
> On 19 Nov 2020, at 02:37, Michael Paquier wrote:
>
> On Wed, Nov 18, 2020 at 10:19:40AM +0100, Daniel Gustafsson wrote:
>> I agree that we should fix this even if it will have quite limited impact in
>> production settings. Patch LGTM, +1.
>
> Thanks. I have revie
1 - 100 of 2328 matches
Mail list logo
