Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 6/14/19 6:09 PM, Bruce Momjian wrote: > On Fri, Jun 14, 2019 at 02:27:17PM -0400, Joe Conway wrote: >> On 6/13/19 11:07 AM, Bruce Momjian wrote: >> > In addition, while the 8k blocks would use a block cipher, the WAL would >> > likely use a stream cipher, and

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 6/15/19 9:28 PM, Bruce Momjian wrote: > On Fri, Jun 14, 2019 at 02:27:17PM -0400, Joe Conway wrote: >> On 6/13/19 11:07 AM, Bruce Momjian wrote: >> > On Thu, Jun 13, 2019 at 04:26:47PM +0900, Masahiko Sawada wrote: >> >> Yeah, in principle since data key of

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 6/16/19 9:45 AM, Bruce Momjian wrote: > On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrote: >> In any case it doesn't address my first point, which is limiting the >> volume encrypted with the same key. Another valid reason is you might >> have data at vary

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 6/16/19 9:46 AM, Bruce Momjian wrote: > On Sun, Jun 16, 2019 at 09:45:09AM -0400, Bruce Momjian wrote: >> On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrote: >> > And although I'm not proposing this for the first implementation, yet >> > another reason

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 6/17/19 8:12 AM, Stephen Frost wrote: >> But there's about 0% chance we'll get that in v1, of course, so we need >> s "minimum viable product" to build on anyway. > > There seems like a whole lot of space between something very elaborate > and only supporting one key. I think this is exactly t

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 6/17/19 8:29 AM, Masahiko Sawada wrote: > From perspective of cryptographic, I think the fine grained TDE would > be better solution. Therefore if we eventually want the fine grained > TDE I wonder if it might be better to develop the table/tablespace TDE > first while keeping it simple as much

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 6/20/19 8:34 AM, Masahiko Sawada wrote: > I think even if we provide the per table encryption we can have > encryption keys per tablepaces. That is, all tables on the same > tablespace encryption use the same encryption keys but user can > control encrypted objects per tables. > >> Will we add

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/8/19 10:19 AM, Bruce Momjian wrote: > When people are asking for multiple keys (not just for key rotation), > they are asking to have multiple keys that can be supplied by users only > when they need to access the data. Yes, the keys are always in the > datbase, but the feature request is tha

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/8/19 11:56 AM, Peter Eisentraut wrote: > On 2019-07-08 17:47, Stephen Frost wrote: >> Of course, we can discuss if what websites do with over-the-wire >> encryption is sensible to compare to what we want to do in PG for >> data-at-rest, but then we shouldn't be talking about what websites do,

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/8/19 6:04 PM, Stephen Frost wrote: > * Bruce Momjian (br...@momjian.us) wrote: >> Uh, well, renaming the user was a big problem, but that is the only case >> I can think of. I don't see that as an issue for block or WAL sequence >> numbers. If we want to use a different nonce, we have to fin

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/9/19 4:34 AM, Tomas Vondra wrote: > On Mon, Jul 08, 2019 at 06:45:50PM -0400, Bruce Momjian wrote: >>On Mon, Jul 8, 2019 at 06:23:13PM -0400, Bruce Momjian wrote: >>> Yes, 'postgres' can be used to create a nice md5 rainbow table that >>> works on many servers --- good point. Are rainbow tab

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/9/19 4:23 AM, Tomas Vondra wrote: > On Mon, Jul 08, 2019 at 06:24:40PM -0400, Joe Conway wrote: >>On 7/8/19 6:04 PM, Stephen Frost wrote: >>> * Bruce Momjian (br...@momjian.us) wrote: >>>> Uh, well, renaming the user was a big problem, but that is the only case

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/9/19 6:07 AM, Peter Eisentraut wrote: > On 2019-07-08 18:09, Joe Conway wrote: >> In my mind, and in practice to a >> large extent, a postgres tablespace == a unique mount point. > > But a critical difference is that in file systems, a separate mount > point has it

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/9/19 8:39 AM, Ryan Lambert wrote: > Hi Thomas, > >> CBC mode does require >> random nonces, other modes may be fine with even sequences as long as >> the values are not reused.    > > I disagree that CBC mode requires random nonces, at least based on what > NIST has published.  They only req

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/9/19 11:11 AM, Bruce Momjian wrote: > On Tue, Jul 9, 2019 at 09:16:17AM -0400, Joe Conway wrote: >> On 7/9/19 8:39 AM, Ryan Lambert wrote: >> > Hi Thomas, >> > >> >> CBC mode does require >> >> random nonces, other modes may be fine with

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/9/19 3:50 PM, Bruce Momjian wrote: > On Tue, Jul 9, 2019 at 02:09:38PM -0400, Joe Conway wrote: >> On 7/9/19 11:11 AM, Bruce Momjian wrote: >> > Good point about nonce and IV. I wonder if running the nonce >> > through the cipher with the key makes it random

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/9/19 4:12 PM, Tomas Vondra wrote: > On Tue, Jul 09, 2019 at 03:50:39PM -0400, Bruce Momjian wrote: >>On Tue, Jul 9, 2019 at 02:09:38PM -0400, Joe Conway wrote: >>> the input nonce used to generate the IV could be something like >>> pg_class.oid and blocknum conc

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/9/19 5:42 PM, Tomas Vondra wrote: > There are two basic ways to construct nonces - CSPRNG and sequences, and > then a combination of both, i.e. one part is generated from a sequence > and one randomly. > > FWIW not sure using OIDs as nonces directly is a good idea, as those are > inherently l

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/9/19 7:28 PM, Stephen Frost wrote: > Greetings, > > * Joe Conway (m...@joeconway.com) wrote: >> On 7/9/19 5:42 PM, Tomas Vondra wrote: >> > There are two basic ways to construct nonces - CSPRNG and sequences, and >> > then a combination of both, i.e. one

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/9/19 10:06 PM, Stephen Frost wrote: > Greetings, > > * Ryan Lambert (r...@rustprooflabs.com) wrote: >> > What I think Tomas is getting at here is that we don't write a page only >> > once. >> >> > A nonce of tableoid+pagenum will only be unique the first time we write >> > out that page. Se

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/10/19 2:40 AM, Masahiko Sawada wrote: > On Tue, Jul 9, 2019 at 10:16 PM Joe Conway wrote: >> >> On 7/9/19 8:39 AM, Ryan Lambert wrote: >> > Hi Thomas, >> > >> >> CBC mode does require >> >> random nonces, other modes may be fine with

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/10/19 2:38 AM, Masahiko Sawada wrote: > On Tue, Jul 9, 2019 at 9:01 PM Joe Conway wrote: >> >> On 7/9/19 6:07 AM, Peter Eisentraut wrote: >> > On 2019-07-08 18:09, Joe Conway wrote: >> >> In my mind, and in practice to a >> >> large exten

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/10/19 4:47 AM, Antonin Houska wrote: > Tomas Vondra wrote: >> I don't think that works, because that'd mean we're encrypting the same >> page with the same nonce over and over, which means reusing the reuse >> (even if you hash/encrypt it). Or did I miss something? > > I found out that it's

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/10/19 4:24 AM, Antonin Houska wrote: > Joe Conway wrote: > >> On 7/8/19 6:04 PM, Stephen Frost wrote: >> > * Bruce Momjian (br...@momjian.us) wrote: >> >> Uh, well, renaming the user was a big problem, but that is the only case >> >> I can thin

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/10/19 2:45 AM, Masahiko Sawada wrote: > On Wed, Jul 10, 2019 at 11:06 AM Stephen Frost wrote: >> >> Greetings, >> >> * Ryan Lambert (r...@rustprooflabs.com) wrote: >> > > What I think Tomas is getting at here is that we don't write a page only >> > > once. >> > >> > > A nonce of tableoid+page

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/10/19 8:34 AM, Stephen Frost wrote: > Greetings, > > * Joe Conway (m...@joeconway.com) wrote: >> On 7/9/19 7:28 PM, Stephen Frost wrote: >> > * Joe Conway (m...@joeconway.com) wrote: >> >> On 7/9/19 5:42 PM, Tomas Vondra wrote: >> >> > Th

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/10/19 3:53 PM, Alvaro Herrera wrote: > On 2019-Jul-10, Bruce Momjian wrote: > >> Good, so I think we all now agree we have to put the nonce >> (pg_class.oid, LSN, page-number) though the cipher using the secret. (been traveling -- just trying to get caught up on this thread) > Actually, why

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/11/19 6:37 PM, Bruce Momjian wrote: > On Wed, Jul 10, 2019 at 12:26:24PM -0400, Bruce Momjian wrote: >> On Wed, Jul 10, 2019 at 08:31:17AM -0400, Joe Conway wrote: >>> Please see my other reply (and >>> https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublicat

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/12/19 2:45 PM, Bruce Momjian wrote: > On Fri, Jul 12, 2019 at 12:41:19PM -0600, Ryan Lambert wrote: >> >> I vote for AES 256 rather than 128. >> > >> > Why?  This page seems to think 128 is sufficient: >> > >> >         https://crypto.stackexchange.com/questions/20/ >> what-are-the-practical-d

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/11/19 9:05 PM, Bruce Momjian wrote: > On Thu, Jul 11, 2019 at 08:41:52PM -0400, Joe Conway wrote: >> On 7/11/19 6:37 PM, Bruce Momjian wrote: >> > Our first implementation will encrypt the entire cluster. We can later >> > consider encryption per table or ta

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/13/19 9:38 AM, Joe Conway wrote: > On 7/11/19 9:05 PM, Bruce Momjian wrote: >> On Thu, Jul 11, 2019 at 08:41:52PM -0400, Joe Conway wrote: >>> On 7/11/19 6:37 PM, Bruce Momjian wrote: >>> > Our first implementation will encrypt the entire cluster. We can later

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/13/19 2:41 PM, Joe Conway wrote: > [2] > https://www.postgresql.org/message-id/20190708194733.cztnwhqge4acepzw%40development BTW I managed to mess up this link. This is what I intended to link there (from Tomas): [2] https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html I a

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/13/19 5:58 PM, Tomas Vondra wrote: > On Sat, Jul 13, 2019 at 02:41:34PM -0400, Joe Conway wrote: >>[2] also says provides additional support for AES 256. It also mentions >>CBC versus XTS -- I came across this elsewhere and it bears discussion: >> >>"C

Re: sepgsql seems rather thoroughly broken on Fedora 30

On 7/17/19 12:54 PM, Tom Lane wrote: > I wrote: >> I tried to run the contrib/sepgsql tests, following the instructions, >> on a recently-set-up Fedora 30 machine. I've done that successfully >> on previous Fedora releases, but it's no go with F30. >> ... >> I'm pretty sure the test recipe last wo

Re: missing toast table for pg_policy

On 07/09/2018 09:16 PM, Michael Paquier wrote: > On Mon, Jul 09, 2018 at 02:45:26PM +0200, Peter Eisentraut wrote: >> On 15.06.18 21:15, Joe Conway wrote: >>> Not surprising -- thanks for the update. >>> >>>> It occurred to be that we could go fu

assert in nested SQL procedure call in current HEAD

My colleague Yogesh Sharma discovered an assert in nested SQL procedure calls after ROLLBACK is used. Minimal test case and backtrace below. I have not yet tried to figure out exactly what is going on beyond seeing that it occurs in pg_plan_query() where the comment says "Planner must have a snapsh

Re: Redesigning the executor (async, JIT, memory efficiency)

On 05/24/2018 11:26 PM, Heikki Linnakangas wrote: > Cool stuff! > > On 25/05/18 06:35, Andres Freund wrote: >> For example, this converts this converts TPCH's Q01: +1 Wicked cool! -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open So

Re: Add CONTRIBUTING.md

On 05/29/2018 11:38 AM, Magnus Hagander wrote: > On Tue, May 29, 2018 at 5:36 PM, Andres Freund > wrote: > > Hi, > > A lot of people contribute in communities via github these days. We > should add a CONTRIBUTING.md that explains how to do so, given that we

Re: New committers announced at PGCon 2018

On 06/01/2018 05:14 PM, Andres Freund wrote: > On 2018-06-01 17:05:11 -0400, Tom Lane wrote: >> The core team is pleased to announce the appointment of seven >> new Postgres committers: >> >> Etsuro Fujita >> Peter Geoghegan >> Amit Kapila >> Alexander Korotkov >> Thomas Munro >> Michael Paquier >>

Re: commitfest 2018-07

On 06/05/2018 10:43 AM, Andres Freund wrote: > On 2018-06-05 10:20:55 -0400, Tom Lane wrote: >> Andres Freund writes: >>> I'd rather create a new 2018-07, and just manually move old patches to >>> it. Otherwise we'll not really focus on the glut of old things, but >>> everyone just restarts workin

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 06/11/2018 05:22 AM, Masahiko Sawada wrote: > As per discussion at PGCon unconference, I think that firstly we need > to discuss what threats we want to defend database data against. Exactly. While certainly there is demand for encryption for the sake of "checking a box", different designs will

Re: missing toast table for pg_policy

On 06/15/2018 02:40 PM, John Naylor wrote: > On 2/19/18, Joe Conway wrote: >> The attached does exactly this. Gives all system tables toast tables >> except pg_class, pg_attribute, and pg_index, and includes cat version >> bump and regression test in misc_sanity. >>

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 06/14/2018 12:19 PM, Masahiko Sawada wrote: > On Wed, Jun 13, 2018 at 10:20 PM, Joe Conway wrote: >> The idea has not been extensively fleshed out yet, but the thought was >> that we create column level POLICY, which would transparently apply some >> kind of transform o

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 06/18/2018 09:49 AM, Robert Haas wrote: > On Wed, Jun 13, 2018 at 9:20 AM, Joe Conway wrote: >>> Also, if I understand correctly, at unconference session there also >>> were two suggestions about the design other than the suggestion by >>> Alexander: implemen

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 06/18/2018 10:26 AM, Robert Haas wrote: > On Mon, Jun 18, 2018 at 10:12 AM, Joe Conway wrote: >> Not necessarily. Our pages probably have enough predictable bytes to aid >> cryptanalysis, compared to user data in a column which might not be very >> predicable. > >

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 06/18/2018 10:52 AM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Jun 18, 2018 at 10:12 AM, Joe Conway wrote: >>> Not necessarily. Our pages probably have enough predictable bytes to aid >>> cryptanalysis, compared to user data in a column which might

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 06/20/2018 05:09 PM, Bruce Momjian wrote: > On Mon, Jun 18, 2018 at 09:49:20AM -0400, Robert Haas wrote: >> know the ordering of the values under whatever ordering semantics >> apply to that index. It's unclear to me how useful such information > > I don't think an ordered index is possible, o

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 06/20/2018 05:05 PM, Bruce Momjian wrote: > On Mon, Jun 18, 2018 at 08:29:32AM -0400, Joe Conway wrote: >>>> Or >>>> maybe key management is really tied into the separately discussed effort >>>> to create SQL VARIABLEs somehow. >>> >>> C

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 06/20/2018 05:03 PM, Bruce Momjian wrote: > On Wed, Jun 13, 2018 at 09:20:58AM -0400, Joe Conway wrote: >> The idea has not been extensively fleshed out yet, but the thought was >> that we create column level POLICY, which would transparently apply some >> kind of tran

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 06/20/2018 05:12 PM, Bruce Momjian wrote: > On Mon, Jun 18, 2018 at 11:06:20AM -0400, Joe Conway wrote: >>> At the same time, having to have a bunch of independently-decipherable >>> short field values is not real secure either, especially if they're known >>>

Re: [HACKERS] Row Level Security Bug ?

On 11/13/2017 09:09 PM, Andrea Adami wrote: > As suggested from Joe i changed the db definition as enclosed. > Now when i do: > > select * fom schools  > > all works fine  > > but when i do: [SELECT from VIEW] > always i get the error:  > > permission denied for relation schools > SQL state:

has_sequence_privilege() never got the memo

I just noticed that has_sequence_privilege() never got the memo about "WITH GRANT OPTION". Any objections to the attached going back to all supported versions? Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development d

Re: has_sequence_privilege() never got the memo

On 11/23/2017 07:16 AM, Peter Eisentraut wrote: > On 11/22/17 22:58, Tom Lane wrote: >> Joe Conway writes: >>> I just noticed that has_sequence_privilege() never got the memo about >>> "WITH GRANT OPTION". Any objections to the attached going back to all >

Re: [HACKERS] PG10 partitioning - odd behavior/possible bug

On 11/28/2017 04:40 PM, Robert Haas wrote: > On Sun, Sep 3, 2017 at 5:28 PM, Joe Conway wrote: >> I was playing around with partitioning and found an oddity that is best >> described with the following reasonably minimal test case: > > I can reproduce this without partition

Re: [HACKERS] Re: [HACKERS] generated columns

On 12/27/2017 09:31 AM, Peter Eisentraut wrote: > On 9/12/17 15:35, Jaime Casanova wrote: >> On 10 September 2017 at 00:08, Jaime Casanova >> wrote: >>> >>> During my own tests, though, i found some problems: > > Here is an updated patch that should address the problems you have found. In the co

Re: [HACKERS] Re: [HACKERS] generated columns

On 12/31/2017 09:38 AM, Peter Eisentraut wrote: > On 12/30/17 16:04, Joe Conway wrote: >> + >> + The generation expression can refer to other columns in the table, but >> + not other generated columns. Any functions and operators used must be >> + immutable. Referen

Re: doc - add missing documentation for "acldefault"

On 08/03/2018 09:04 AM, Fabien COELHO wrote: > Here is a version of the patch which documents briefly all aclitem-related > functions, in a separate table. I claimed this patch for review and commit. Comments: --- * There is a comment in src/backend/utils/adt/acl.c noting that acldefault is "no

Re: doc - add missing documentation for "acldefault"

On 09/19/2018 10:54 AM, Tom Lane wrote: > Joe Conway writes: >> * I do believe aclitemeq() has utility outside internal purposes. > > Our normal policy is that we do not document functions that are meant to > be invoked through operators. The \df output saying that is suffic

Re: doc - add missing documentation for "acldefault"

On 09/19/2018 12:30 PM, John Naylor wrote: > On 9/19/18, Tom Lane wrote: >> However, I don't object to documenting any function that has its >> own pg_description string. > > Speaking of, that description string seems to have been neglected. > I've attached a remedy for that. Thanks, will take c

Re: doc - add missing documentation for "acldefault"

On 09/19/2018 11:18 AM, Joe Conway wrote: > On 09/19/2018 10:54 AM, Tom Lane wrote: >> Joe Conway writes: >>> * I do believe aclitemeq() has utility outside internal purposes. >> >> Our normal policy is that we do not document functions that are meant to >> be

Re: doc - add missing documentation for "acldefault"

On 09/21/2018 01:51 PM, Joe Conway wrote: > On 09/19/2018 11:18 AM, Joe Conway wrote: >> On 09/19/2018 10:54 AM, Tom Lane wrote: >>> So maybe what we really need is a table of operators not functions. >> >> Good idea -- I will take a look at that. >> >&g

Re: doc - add missing documentation for "acldefault"

On 09/24/2018 10:01 AM, Tom Lane wrote: > Joe Conway writes: >> Having seen none, committed/pushed. This did not seem worth >> back-patching, so I only pushed to master. > > I don't see anything on gitmaster? Hmm, yes, interesting -- I must of messed up my local git re

Re: doc - add missing documentation for "acldefault"

On 09/24/2018 10:09 AM, Joe Conway wrote: > On 09/24/2018 10:01 AM, Tom Lane wrote: >> Joe Conway writes: >>> Having seen none, committed/pushed. This did not seem worth >>> back-patching, so I only pushed to master. >> >> I don't see anything on git

Re: has_column_privilege behavior (was Re: Assert failed in snprintf.c)

On 10/01/2018 02:41 PM, Stephen Frost wrote: > Tom Lane (t...@sss.pgh.pa.us) wrote: >> But it's not quite clear to me what we want the behavior for bad column >> name to be. A case could be made for either of: >> >> * If either the table OID is bad, or the OID is OK but there's no such >> column,

Re: Commit fest 2018-09

On 10/02/2018 10:13 AM, Tom Lane wrote: > Michael Paquier writes: >> Thanks to all who participated in the patch review, authoring, and >> everybody else who helped in making the different patches move forward. > > Thanks for being CFM! I know it's a lot of work ... +10! Joe -- Crunchy Data

Re: Clock-skew management in logical replication

make this possible, no? -- Joe Conway PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com

Re: Add llvm version into the version string

er a connection (which is all a lot of our users have access to). +1 -- Joe Conway PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com

<    1   2   3   4   5