ftware in C++ that interacts with Postgres?
As far as I know, it should just work like C. I know you can compile
the backend server using a C++ compiler because we get bug reports when
we break it.
--
Bruce Momjian https://momjian.us
EDB https:/
than the statistics. Also, there
> are plenty of cases where the statistics are really just wild guesses.
> They still allow the planner to make decisions about what join orders
> or types and so on given the updated data.
#2 is an interesting distinction.
--
Bruce Momjian
haves
> properly.
What is the logic to removing md5 but keeping 'password'?
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
he plain-password methods were already using SSL
(hopefully with certificate authentication) and they were therefore
safe. Why would we remove something like LDAP if that is what the site
is already using?
--
Bruce Momjian https://momjian.us
EDB ht
errible in this regard because it's a centralized password system,
> meaning that one compromised server will lead to an attacker gaining
> full access to the victim's account throughout the enterprise.
Yes, but the site chose LDAP, and I don't think it is our place to
e also remove things
> on a rather regular basis even when they're being used- generally
> because we have something better, as we do here. I disagree that an
> argument of 'some people use it so we can't remove it' holds any weight
> here.
ng password was 16
> years. It has been 5 years since scram was added.
Uh, when did we remove "password". I still see it mentioned in
pg_hba.conf. Am I missing something?
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.co
On Thu, Mar 3, 2022 at 12:38:32PM -0500, Jonathan Katz wrote:
> On 3/3/22 12:23 PM, Bruce Momjian wrote:
> > On Thu, Mar 3, 2022 at 10:45:42AM +0100, Peter Eisentraut wrote:
> > > On 02.03.22 16:45, Jonathan S. Katz wrote:
> > > > By that argument, we should have
test=> select query, query_id from pg_stat_activity;
query | query_id
---+--
|
|
--> select pg_sleep(1) -- test2; | 2920433178127795318
select
ct
permissions only because it is strictly ordered.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
st_string │
> ╞══╡
> │ Arabic : العربية ↵│
> │ Chinese : 中文 ↵│
> │ English : English ↵│
> │ French : Français ↵│
> │ German : Deutsch ↵│
> │ Greek : Ελληνικά ↵│
> │ Hebrew : עברית ↵│
> │ Japanes
thing
> to do would be to add M4 support to postgresql.conf, but I'm not much of
> a fan of that idea either.)
Yeah, when M4 is your next option, you are in trouble. ;-)
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.c
On Tue, Dec 1, 2020 at 10:16:31AM -0800, Jeff Davis wrote:
> On Thu, 2020-10-08 at 23:17 -0400, Bruce Momjian wrote:
> > As I said before, it is more raw bytes, but
> > we
> > don't have an SQL data type for that.
>
> Sorry to jump in to this thread late.
>
On Wed, Dec 2, 2020 at 02:47:13PM -0500, Stephen Frost wrote:
> Greetings,
>
> * David G. Johnston (david.g.johns...@gmail.com) wrote:
> > On Mon, Nov 30, 2020 at 11:42 AM Bruce Momjian wrote:
> > > The downside is you end up with X-1 dummy sections just to allow for
Enter password: stopped waiting
pg_ctl: could not start server
Examine the log output.
$ tail -2 /u/pg/server.log
2020-12-02 16:32:34.045 EST [13056] FATAL: cluster passphrase does not
match expected passphrase
2020-12-02 16:32:34.047 EST [130
On Wed, Dec 2, 2020 at 05:57:01PM -0500, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > We were not going to use just redirects --- we were going to create a
> > page that had all the renames listed, with links to the new names.
>
> Maybe I'm th
On Wed, Dec 2, 2020 at 08:07:47PM -0500, Isaac Morland wrote:
> On Wed, 2 Dec 2020 at 19:33, David G. Johnston
> wrote:
>
> On Wed, Dec 2, 2020 at 5:26 PM Bruce Momjian wrote:
>
> I think the ideal solution is to create a section for all the rename
>
On Thu, Dec 3, 2020 at 09:04:21AM -0800, Jeff Davis wrote:
> On Wed, 2020-12-02 at 15:16 -0500, Bruce Momjian wrote:
> > Yes, we could, but I thought the format code was not something we set
> > at
> > this level. Looking at byteasend() it is true it just sends the
> >
On Wed, Dec 2, 2020 at 04:38:14PM -0500, Bruce Momjian wrote:
> If most people approve of this general approach, and the design
> decisions made, I would like to apply this in the next few weeks, but
> this brings complications. The syntax added by this commit might not
> prov
On Sat, Dec 5, 2020 at 11:39:18AM +0900, Michael Paquier wrote:
> On Fri, Dec 04, 2020 at 09:08:03PM -0500, Bruce Momjian wrote:
> > Here is an updated patch to handle the new hash API introduced by
> > commit 87ae9691d2.
>
> + if (!ossl_initialized)
he attached patch. The updated
full patch is at the same URL: :-)
https://github.com/postgres/postgres/compare/master...bmomjian:key.diff
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in
On Sat, Dec 5, 2020 at 09:54:33PM +0900, Michael Paquier wrote:
> On Fri, Dec 04, 2020 at 10:52:29PM -0500, Bruce Momjian wrote:
> > OK, I worked with Sawada-san and added the attached patch. The updated
> > full patch is at the same URL: :-)
> >
> > https://g
/postgres/postgres/compare/master...bmomjian:key.diff
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
On Mon, Dec 7, 2020 at 11:03:30AM +0900, Michael Paquier wrote:
> On Sat, Dec 05, 2020 at 10:42:05AM -0500, Bruce Momjian wrote:
> > On Sat, Dec 5, 2020 at 09:54:33PM +0900, Michael Paquier wrote:
> >> On Fri, Dec 04, 2020 at 10:52:29PM -0500, Bruce Momjian wrote:
> &g
On Fri, Dec 4, 2020 at 10:32:45PM -0500, Bruce Momjian wrote:
> I can break out the -R/file descriptor passing part as a separate patch,
> and have the ssl_passphrase_command use that, but that's the only part I
> know can be useful on its own.
>
> Since the patch is large, I
On Wed, Dec 9, 2020 at 10:34:59PM +0100, Daniel Gustafsson wrote:
> > 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 E
On Wed, Dec 9, 2020 at 05:18:37PM -0500, Stephen Frost wrote:
> Greetings,
>
> * Daniel Gustafsson (dan...@yesql.se) wrote:
> > > On 2 Dec 2020, at 22:38, Bruce Momjian wrote:
> > > Attached is a patch for key management, which will eventually be part of
> &g
t here. I had not gotten to using KmgrGetKey
yet, but it clearly needs your suggestion, so have done that.
Thanks for your help.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
On Wed, Dec 9, 2020 at 08:40:50PM -0500, Bruce Momjian wrote:
> My next task is to write a script for Yubikey authentication.
I know Craig Ringer wanted Yubikey support, which allows two-factor
authentication, so I have added it to the most recent patch by adding a
cluster_passphrase_command
On Fri, Dec 11, 2020 at 01:01:14PM -0500, Bruce Momjian wrote:
> On Wed, Dec 9, 2020 at 08:40:50PM -0500, Bruce Momjian wrote:
> > My next task is to write a script for Yubikey authentication.
>
> I know Craig Ringer wanted Yubikey support, which allows two-factor
> authent
On Wed, Dec 2, 2020 at 04:38:14PM -0500, 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. It is an update of Masahiko Sawada's patc
On Tue, Dec 15, 2020 at 10:05:49AM +0900, Michael Paquier wrote:
> On Mon, Dec 14, 2020 at 06:06:15PM -0500, Bruce Momjian wrote:
> > I am getting close to applying these patches, probably this week. The
> > patches are cumulative:
> >
> > https://github.com/postg
; works, hope it can help you.
Thanks. I will work on the items you mentioned. Can you look at the
Cybertec patch and then our wiki to see what needs to be done next?
https://wiki.postgresql.org/wiki/Transparent_Data_Encryption
Thanks for getting a proof-of-concept patch out there. :-)
--
t do that in the long term in my
> opinion, but nobody has come to clean up this stuff. (- -;)
Glad you asked about this. It turns out pg_altercpass works fine with
postgres_fe.h, so I will now use that. pg_resetwal still can't use it
though.
--
Bruce Momjian
On Mon, Dec 14, 2020 at 11:16:18PM -0500, Bruce Momjian wrote:
> > 1. Previously, we added a variable bootstrap_keys_wrap that is used for
> > encryption during initdb. However, since we save the "wrapped" key, we need
> > to
> > use a global KEK that can be
it_ units when visible by users, but I see a
lot of cases where we allocate arrays based on bytes. I am unclear
where the proper units should be. At a minimum, we should specify the
units in the function parameter names.
--
Bruce Momjian https://momjian.us
EnterpriseDB
On Tue, Dec 15, 2020 at 02:20:33PM +0900, Michael Paquier wrote:
> On Mon, Dec 14, 2020 at 10:19:02PM -0500, Bruce Momjian wrote:
> > I am going to need someone to help me make these changes. I don't feel
> > I know enough about the crypto API to do it, and it will take me 1+
On Tue, Dec 15, 2020 at 02:09:09PM -0500, Stephen Frost wrote:
> Greetings,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Tue, Dec 15, 2020 at 10:05:49AM +0900, Michael Paquier wrote:
> > > On Mon, Dec 14, 2020 at 06:06:15PM -0500, Bruce Momjian wrote:
>
t a into t4 from t2;
> >
> > SELECT INTO must be the first query in a statement containing a UNION,
> > INTERSECT or EXCEPT operator.
>
> So, with that in mind, here is an alternative proposal that points out that
> SELECT INTO has some use for compatibility.
Do w
On Tue, Dec 15, 2020 at 01:22:44AM -0800, Jeff Davis wrote:
> On Thu, 2020-12-03 at 13:14 -0500, Bruce Momjian wrote:
> > Andres objected (in a separate conversation) to forcing a binary-
> > > format
> > > value on a client that didn't ask for one. He suggested
I can't see why it would be. The application never
sees the KEK used to wrap the DEK it has stored in the file system,
though that DEK is actually used as a passphrase by Postgres. This is
the same with the Yubikey --- Postgres never sees the private key used
to unlock what it locked with
; child tables of inheritance hierarchies."
I reworded it slightly, attached, and applied it back to PG 10, where we
added the partition syntax.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its
On Wed, Dec 16, 2020 at 06:07:26PM +, Alastair Turner wrote:
> Hi Bruce
>
> On Wed, 16 Dec 2020 at 00:12, Bruce Momjian wrote:
> >
> ...
> >
> > The second approach is to make a new API for what you want
>
> I am trying to motivate for an alterna
On Wed, Dec 16, 2020 at 10:23:23AM +0900, Michael Paquier wrote:
> On Tue, Dec 15, 2020 at 04:02:12PM -0500, Bruce Momjian wrote:
> > I thought this was going to be a huge job, but once I looked at it, it
> > was clear exactly what you were saying. Comparing c
On Wed, Dec 16, 2020 at 04:32:00PM -0500, Stephen Frost wrote:
> Greetings,
>
> * Alastair Turner (min...@decodable.me) wrote:
> > On Wed, 16 Dec 2020 at 00:12, Bruce Momjian wrote:
> > > The second approach is to make a new API for what you want
> >
>
On Wed, Dec 16, 2020 at 01:42:57PM -0500, Bruce Momjian wrote:
> On Wed, Dec 16, 2020 at 06:07:26PM +, Alastair Turner wrote:
> > Hi Bruce
> >
> > On Wed, 16 Dec 2020 at 00:12, Bruce Momjian wrote:
> > >
> > ...
> > >
> > > The
On Fri, Dec 4, 2020 at 02:00:23PM -0500, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > Yes, that is pretty much the same thing I was suggesting, except that
> > each rename has its own _original_ URL link, which I think is also
> > acceptable. My desi
s I
> keep telling to update after a default installation.
+1 for making it 0.9. FYI< Robert Haas has argued that our estimation
of completion isn't great, which is why it defaults to 0.5.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
gt; patches.
> The Attached patch has the changes for the same.
> Thoughts?
Uh, we usually only update the typedefs file before we run pgindent on
the master branch.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefu
e calls
>
> Tom suggested this in 2006 for the sake of orthogonality. Given the amount of
> time passed, it seems not very important.
Yes.
> - Allow DELETE and UPDATE to be used with LIMIT and ORDER BY
>
> Some use cases mentioned, but nearly all have some kind of workaround already.
Agreed.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
of several commits:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=e81c138e18
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
On Thu, Dec 17, 2020 at 11:39:55AM -0500, Stephen Frost wrote:
> Greetings,
>
> * Michael Paquier (mich...@paquier.xyz) wrote:
> > On Wed, Dec 16, 2020 at 05:04:12PM -0500, Bruce Momjian wrote:
> > >> fallback implementation. Finally, pgcrypto is not touched, b
If so, I will delay
my key management patch until this is applied. If not, I will update my
HMAC call when you apply this.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
e way. And for ways
> to speed up COPY in general.
Yes, this makes a lot of sense. Glad you are looking into this.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
On Mon, Dec 14, 2020 at 11:16:18PM -0500, Bruce Momjian wrote:
> On Tue, Dec 15, 2020 at 10:36:56AM +0800, Neil Chen wrote:
> > Since our implementation is not in contrib, I don't think we should put the
> > script there. Maybe we can refer to postgresql.conf.sample?
>
On Fri, Dec 18, 2020 at 11:19:02AM +0800, Neil Chen wrote:
>
>
> On Fri, Dec 18, 2020 at 3:02 AM Bruce Momjian wrote:
>
>
> Here is a run of all four authentication methods, and updated scripts.
> I have renamed Yubiki to PIV since the script should work with
On Fri, Dec 18, 2020 at 10:01:22AM +0900, Michael Paquier wrote:
> On Thu, Dec 17, 2020 at 12:10:22PM -0500, Bruce Momjian wrote:
> > On Thu, Dec 17, 2020 at 11:39:55AM -0500, Stephen Frost wrote:
> >> I don't think there's any need for us to implement a fallback
>
e Michael's API
is final. It is easier for me to change one line to five lines than to
change five lines to five different lines.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
l API or just keep the one-line version.
As far as when to commit this, I think the quiet time is actually better
because if you break something, it is less of a disruption while you fix
it.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
On Fri, Dec 18, 2020 at 11:13:44AM -0500, Stephen Frost wrote:
> Greetings,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Fri, Dec 18, 2020 at 08:18:53AM -0500, Stephen Frost wrote:
> > > - C API in backend - we should try to at least set up the structure t
On Sat, Dec 19, 2020 at 09:35:57AM +0900, Michael Paquier wrote:
> On Fri, Dec 18, 2020 at 10:48:00AM -0500, Bruce Momjian wrote:
> > Great. See my questions in the key manager thread about whether I
> > should use the init/update/final API or just keep the one-line version.
> &
On Fri, Dec 18, 2020 at 07:42:02PM -0500, Bruce Momjian wrote:
> > Please note that on a related thread that I have begun yesterday,
> > Heikki has suggested some changes in the way we handle the opaque data
> > used by each cryptohash implementation.
> > https://www.p
me and one which we should care about.
> >
> > Yes. Caring about that is the reason I've been making a nuisance of myself.
>
> Right, I think we can agree on this aspect and I've chatted with Bruce
> about it some also. When a direct key can be pr
ion of why these additional features are needed. Requiring
the use of a true random number generator is a valid argument, but we
need to figure out, once this is implemented, who really wants that, and
how to implement it cleanly.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
; more accurate
> |estimates of the row count and memory usage when grouping by multiple
> |columns, and more accurate estimates of the row count if WHERE clauses apply
> |to multiple columns and values of some columns are correlated with values of
> |other columns.
Uh, at the time, that was
On Sat, Dec 19, 2020 at 11:58:37AM -0500, Bruce Momjian wrote:
> My final point is that we can find ways to do what you are suggesting as
> an addition to what we are adding now. What we need is clear
> justification of why these additional features are needed. Requiring
> the u
32-byte value in the script. This does mean the
script has to run sha256 for passphrases, but it seems like a win.
Updated script are attached too.
The URLs are still accurate:
https://github.com/postgres/postgres/compare/master...bmomjian:key.diff
https://github.com/bmomjian
ate a new thread
so it is not confused by whatever is posted here.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
for that.
Pushing anymore features into the scripts is going to make that common
case less reliable, which I am opposed to.
Also, as far as Desirability, we only have _one_ person saying people
will want more options. I need to hear from a lot more people before
this gets added to Postgre
ajority of
> the
> target audience seems like it should be considered acceptable.
If you want to debate that TODO section, you will need to start a new
thread. I suggest Alastair's patch also appear in a new thread.
--
Bruce Momjian https://momjian.us
EnterpriseDB
On Mon, Dec 21, 2020 at 04:35:14PM -0500, Bruce Momjian wrote:
> On Sun, Dec 20, 2020 at 05:59:09PM -0500, Stephen Frost wrote:
> OK, here it the updated patch. The major change, as Stephen pointed
> out, is that the cluser_key_command (was cluster_passphrase_command) now
> returns
On Mon, Dec 21, 2020 at 10:07:48PM -0500, Bruce Momjian wrote:
> Attached is the script patch. It is also at:
>
>
> https://github.com/postgres/postgres/compare/master...bmomjian:cfe-sh.diff
>
> I think it still needs docs but those will have to be done after the
&
offline. So getting from passphrase to DEKs should be as
> resource intensive as possible to slow down brute-force attempts.
> Instead of just a SHA hash, this should be at least a PBKDF2 (PKCS#5)
I am satisfied with the security of SHA256.
> On Tue, 22 Dec 2020 at 15:40, Bruce Momjian
On Tue, Dec 22, 2020 at 04:13:06PM -0500, Bruce Momjian wrote:
> On Tue, Dec 22, 2020 at 08:15:27PM +, Alastair Turner wrote:
> > Hi Bruce
> >
> > In ckey_passphrase.sh.sample
> >
> > +
> > +echo "$PASS" | sha256sum | cut -d' ' -f1
On Tue, Dec 22, 2020 at 10:40:17AM -0500, Bruce Momjian wrote:
> On Mon, Dec 21, 2020 at 10:07:48PM -0500, Bruce Momjian wrote:
> > Attached is the script patch. It is also at:
> >
> >
> > https://github.com/postgres/postgres/compare/master...bmomjian:cfe-sh.dif
ct * from pg_database \g (format=tsv) | wl-paste -t application/
> x-libreoffice-tsvc
>
> Implementation of tsv format should not be hard.
>
> What do you think about this?
How would you handle tabs in the data?
--
Bruce Momjian https://momjian.us
Enterpr
On Wed, Dec 23, 2020 at 04:39:48PM +0100, Pavel Stehule wrote:
>
>
> st 23. 12. 2020 v 16:24 odesílatel Tom Lane napsal:
>
> Bruce Momjian writes:
> > On Wed, Dec 23, 2020 at 07:18:24AM +0100, Pavel Stehule wrote:
> >> Implementation of tsv format sho
On Fri, Dec 25, 2020 at 07:30:01PM +0100, Erik Rijkers wrote:
> On 2020-12-25 16:19, Bruce Momjian wrote:
>
> > Add key management system
> > doc/src/sgml/database-encryption.sgml | 97 +
>
> Attached are a few typos.
>
> I also noticed that this optio
ry. No value is currently required.
> I also changed the help message and the manual.
Thank you, applied.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
work, since it would not
know the data format, so we would need another cluster key alter for that.
It could be written as a C extension, but that would be also have C's
limitations. In summary, having the server do most of the complex work
for the default case seems best, and eventually
d/flat/20201227172526.GB17037%40momjian.us#f7c6dd32a5f3af7b8615b7ebfda6e669
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
tion, and key verification.
I will say that if the community feels external-only should be the only
option, I will stop working on this feature because I feel the result
would be too fragile to be reliable, and I would not want to be
associated with it.
--
Bruce Momjian
I now understand the wisdom of moving the remaining hex functions to
/common. I know someone already suggested that, and the attached patch
does this.
I will add the attached patch to the commitfest so I can get cfbot
testing.
--
Bruce Momjian https://momjian.us
EnterpriseDB
On Wed, Dec 30, 2020 at 07:35:57PM -0500, Bruce Momjian wrote:
> I now understand the wisdom of moving the remaining hex functions to
> /common. I know someone already suggested that, and the attached patch
> does this.
>
> I will add the attached patch to the commitfest so
lows changing the KEK.
I think Fabien is saying this all should _only_ be done using external
tools --- that's what I don't agree with.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
can do it obviously).
>
> If you want a special "key_mgt_command = internal" because you feel that
> processes are fragile and unreliable and do not bring security, so be it,
> but I think that the API should be designed beforehand nevertheless.
I think we need a separate command for the fully external case, rather
than trying to lay it on top of the command for the internal one.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
system more secure. I
don't think it does, and I think it makes external key rotation very
difficult, among other negatives. Also, keep in mind any failure of the
key management system could make the cluster unreadable, so making it as
simple/error-free as possible is a big requirement for me.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
. Seems we have to zero out all
future WAL files, not just to the end of the current one, or at least
clear xlp_pageaddr on each future page.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
On Thu, Dec 31, 2020 at 02:27:44PM -0500, Stephen Frost wrote:
> Greetings,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Wed, Dec 30, 2020 at 12:52:46PM -0800, Andres Freund wrote:
> > > A question from a colleague made me wonder if there are scenarios where
>
/compare/master...bmomjian:hex.diff
https://github.com/postgres/postgres/compare/master...bmomjian:key.diff
I will add it to the commitfest. I think we need to figure out how much
of the tests we want to add.
--
Bruce Momjian https://momjian.us
EnterpriseDB
On Thu, Dec 31, 2020 at 11:50:47PM -0500, Bruce Momjian wrote:
> I have completed the key management patch with tests created by Stephen
> Frost. Original patch by Masahiko Sawada. It requires the hex
> reorganization patch first. The key patch is now 2.1MB because of the
> tests,
On Thu, Dec 31, 2020 at 03:10:29PM +0900, Michael Paquier wrote:
> On Wed, Dec 30, 2020 at 08:22:07PM -0500, Bruce Momjian wrote:
> > So, I am learning this cfbot thing. Seems I need -M100% to disable
> > rename detection for diffs to work with cfbot --- makes sense.
>
> A
ine, then implementations
> can be provided, but if people do not want an API in the first place, I'm
> not sure I can see the point of sending patches.
I think you are accurate here. You can certainly propose an external
API, but I think any external API would have more negatives (compl
uld make startup quite
> slow if there are a lot of keys with narrow scope.
We do that already on startup by using GCM to validate the KEK when
encrypting each DEK.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
nt you end up re-litigate this that you
get nothing else done. I know some people who have given up working on
this feature for this reason.
I am not asking we stop discussing it, but I do ask we address the
negatives of suggestions, especially when the negatives have already
been clearly stated.
er the readability
of unified diffs.) Should we document this?
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
, I don't think ecpg ever
used libpgcommon before. For non-Windows, libpgcommon got referenced
anyway in the build, so non-Windows compiles worked, but in Windows,
that was not referenced, meaning the cfbot failed on ecpglib. I have
modified the attached patch with both of these fixed --- let
On Tue, Jan 5, 2021 at 03:47:59PM +0900, Michael Paquier wrote:
> On Mon, Jan 04, 2021 at 10:47:39PM -0500, Bruce Momjian wrote:
> > I can see the value of passing the destination length to the hex
> > functions, and I think you have to pass the src length to pg_hex_encode
> >
On Tue, Jan 5, 2021 at 08:54:11PM +1300, Thomas Munro wrote:
> On Tue, Jan 5, 2021 at 4:47 PM Bruce Momjian wrote:
> > ... let's see how it likes this version.
>
> cfbot ideally processes a new patch fairly quickly but I didn't think
> of ".diff.gz" when
someday, so don't do that. If that
is false, I think we can make it more prominent.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
1 - 100 of 2916 matches
Mail list logo
