Robert Haas writes:
> On Thu, Apr 21, 2022 at 1:53 PM Tom Lane wrote:
>> 0001 attached is a revised patch that does it that way. This seems
>> like a clearly better answer.
>> 0002 contains the perhaps-slightly-more-controversial changes of
>> changing the macro names and explicitly pinning no d
On Thu, Apr 21, 2022 at 1:53 PM Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Apr 20, 2022 at 4:56 PM Tom Lane wrote:
> >> Having just had to bury my nose in renumber_oids.pl, I thought of a
> >> different approach we could take to expose these OIDs to Catalog.pm.
> >> That's to invent a new
Robert Haas writes:
> On Wed, Apr 20, 2022 at 4:56 PM Tom Lane wrote:
>> Having just had to bury my nose in renumber_oids.pl, I thought of a
>> different approach we could take to expose these OIDs to Catalog.pm.
>> That's to invent a new macro that Catalog.pm recognizes, and write
>> something a
On Wed, Apr 20, 2022 at 4:56 PM Tom Lane wrote:
> Having just had to bury my nose in renumber_oids.pl, I thought of a
> different approach we could take to expose these OIDs to Catalog.pm.
> That's to invent a new macro that Catalog.pm recognizes, and write
> something about like this in pg_databa
Robert Haas writes:
> On Wed, Apr 20, 2022 at 2:34 PM Tom Lane wrote:
>> The attached draft patch attempts to improve this situation.
>> It reserves these OIDs, and creates the associated macros, through
>> the normal BKI infrastructure by adding entries in pg_database.dat.
>> We have to delete t
On Wed, Apr 20, 2022 at 2:34 PM Tom Lane wrote:
> The attached draft patch attempts to improve this situation.
> It reserves these OIDs, and creates the associated macros, through
> the normal BKI infrastructure by adding entries in pg_database.dat.
> We have to delete those rows again during init
Robert Haas writes:
> On Sat, Jan 22, 2022 at 2:20 AM Shruthi Gowda wrote:
>> Agree. In the latest patch, the template0 and postgres OIDs are fixed
>> to unused manually assigned OIDs 4 and 5 respectively. These OIDs are
>> no more listed as unused OIDs.
> Thanks. Committed with a few more cosme
On Mon, Mar 21, 2022 at 8:52 PM Andres Freund wrote:
> I noticed this still has an open CF entry:
> https://commitfest.postgresql.org/37/3296/
> I assume it can be marked as committed?
Yeah, done now. But don't forget that we still need to do something on
the "wrong fds used for refilenodes afte
On 2022-01-24 14:44:10 -0500, Robert Haas wrote:
> On Sat, Jan 22, 2022 at 2:20 AM Shruthi Gowda wrote:
> > Agree. In the latest patch, the template0 and postgres OIDs are fixed
> > to unused manually assigned OIDs 4 and 5 respectively. These OIDs are
> > no more listed as unused OIDs.
>
> Thanks
On Tue, Jan 25, 2022 at 10:19:53AM +0530, Shruthi Gowda wrote:
> On Tue, Jan 25, 2022 at 1:14 AM Robert Haas wrote:
> > On Sat, Jan 22, 2022 at 2:20 AM Shruthi Gowda wrote:
> > > Agree. In the latest patch, the template0 and postgres OIDs are fixed
> > > to unused manually assigned OIDs 4 and 5 r
Stephen Frost wrote:
> Perhaps this is all too meta and we need to work through some specific
> ideas around just what this would look like. In particular, thinking
> about what this API would look like and how it would be used by
> reorderbuffer.c, which builds up changes in memory and then doe
On Tue, Jan 25, 2022 at 1:14 AM Robert Haas wrote:
>
> On Sat, Jan 22, 2022 at 2:20 AM Shruthi Gowda wrote:
> > Agree. In the latest patch, the template0 and postgres OIDs are fixed
> > to unused manually assigned OIDs 4 and 5 respectively. These OIDs are
> > no more listed as unused OIDs.
>
> Th
On Sat, Jan 22, 2022 at 2:20 AM Shruthi Gowda wrote:
> Agree. In the latest patch, the template0 and postgres OIDs are fixed
> to unused manually assigned OIDs 4 and 5 respectively. These OIDs are
> no more listed as unused OIDs.
Thanks. Committed with a few more cosmetic changes.
--
Robert Haa
On Sat, Jan 22, 2022 at 12:47:35PM +0530, Shruthi Gowda wrote:
> On Sat, Jan 22, 2022 at 12:27 AM Tom Lane wrote:
> >
> > Robert Haas writes:
> > > It seems to me that what this comment is saying is that OIDs in the
> > > second and third categories are doled out by counters. Therefore, we
> > >
On Sat, Jan 22, 2022 at 12:17 AM Robert Haas wrote:
>
> On Fri, Jan 21, 2022 at 8:40 AM Shruthi Gowda wrote:
> > From what I see in the code, template0 and postgres are the last
> > things that get created in initdb phase. The system OIDs that get
> > assigned to these DBs vary from release to re
On Sat, Jan 22, 2022 at 12:27 AM Tom Lane wrote:
>
> Robert Haas writes:
> > It seems to me that what this comment is saying is that OIDs in the
> > second and third categories are doled out by counters. Therefore, we
> > can't know which of those OIDs will get used, or how many of them will
> >
Robert Haas writes:
> It seems to me that what this comment is saying is that OIDs in the
> second and third categories are doled out by counters. Therefore, we
> can't know which of those OIDs will get used, or how many of them will
> get used, or which objects will get which OIDs. Therefore, I t
On Fri, Jan 21, 2022 at 8:40 AM Shruthi Gowda wrote:
> From what I see in the code, template0 and postgres are the last
> things that get created in initdb phase. The system OIDs that get
> assigned to these DBs vary from release to release. At present, the
> system assigned OIDs of template0 and
On Fri, Jan 21, 2022 at 1:08 AM Robert Haas wrote:
>
> On Thu, Jan 20, 2022 at 11:03 AM Shruthi Gowda wrote:
> > It is not required for PostgresObjectId. The unused_oids script
> > provides a list of unused oids in the manually-assignable OIDs range
> > (1-).
>
> Well, so ... why are we not t
On Thu, Jan 20, 2022 at 11:03 AM Shruthi Gowda wrote:
> It is not required for PostgresObjectId. The unused_oids script
> provides a list of unused oids in the manually-assignable OIDs range
> (1-).
Well, so ... why are we not treating the OIDs for these two databases
the same? If there's a r
On Thu, Jan 20, 2022 at 7:57 PM Robert Haas wrote:
>
> On Thu, Jan 20, 2022 at 7:09 AM Shruthi Gowda wrote:
> > > Here's an updated version in which I've reverted the changes to gram.y
> > > and tried to improve the comments and documentation. Could you have a
> > > look at implementing (2) above
On Thu, Jan 20, 2022 at 7:09 AM Shruthi Gowda wrote:
> > Here's an updated version in which I've reverted the changes to gram.y
> > and tried to improve the comments and documentation. Could you have a
> > look at implementing (2) above?
>
> Attached is the patch that implements comment (2).
This
On Tue, Jan 18, 2022 at 2:34 AM Robert Haas wrote:
>
> On Mon, Jan 17, 2022 at 9:57 AM Shruthi Gowda wrote:
> > I have rebased and generated the patches on top of PostgreSQL commit
> > ID cf925936ecc031355cd56fbd392ec3180517a110.
> > Kindly apply v8-0001-pg_upgrade-Preserve-relfilenodes-and-table
On Tue, Jan 18, 2022 at 12:35 AM Robert Haas wrote:
>
> On Tue, Dec 14, 2021 at 1:21 PM Shruthi Gowda wrote:
> > Thanks, Robert for the updated version. I reviewed the changes and it
> > looks fine.
> > I also tested the patch. The patch works as expected.
>
> Thanks.
>
> > > - I adjusted the fun
On Mon, Jan 17, 2022 at 9:57 AM Shruthi Gowda wrote:
> I have rebased and generated the patches on top of PostgreSQL commit
> ID cf925936ecc031355cd56fbd392ec3180517a110.
> Kindly apply v8-0001-pg_upgrade-Preserve-relfilenodes-and-tablespace-O.patch
> first and then v8-0002-Preserve-database-OIDs-
On Tue, Dec 14, 2021 at 1:21 PM Shruthi Gowda wrote:
> Thanks, Robert for the updated version. I reviewed the changes and it
> looks fine.
> I also tested the patch. The patch works as expected.
Thanks.
> > - I adjusted the function header comment for heap_create. Your
> > proposed comment seeme
On Sat, Jan 15, 2022 at 11:17 AM Julien Rouhaud wrote:
>
> Hi,
>
> On Fri, Dec 17, 2021 at 01:03:06PM +0530, Shruthi Gowda wrote:
> >
> > I have updated the DBOID preserve patch to handle this case and
> > generated the latest patch on top of your v7-001-preserve-relfilenode
> > patch.
>
> The cfb
Hi,
On Fri, Dec 17, 2021 at 01:03:06PM +0530, Shruthi Gowda wrote:
>
> I have updated the DBOID preserve patch to handle this case and
> generated the latest patch on top of your v7-001-preserve-relfilenode
> patch.
The cfbot reports that the patch doesn't apply anymore:
http://cfbot.cputube.org
On Mon, Dec 13, 2021 at 8:43 PM Shruthi Gowda wrote:
>
> On Mon, Dec 6, 2021 at 11:25 PM Robert Haas wrote:
> >
> > On Sun, Dec 5, 2021 at 11:44 PM Sadhuprasad Patro wrote:
> > > 3.
> > > @@ -504,11 +525,15 @@ createdb(ParseState *pstate, const CreatedbStmt
> > > *stmt)
> > > */
> > > pg_da
On 12/15/21 12:09 AM, tushar wrote:
I spent much of today reviewing 0001. Here's an updated version, so
far only lightly tested. Please check whether I've broken anything.
Thanks Robert, I tested from v96/12/13/v14 -> v15( with patch)
things are working fine i.e table /index relfilenode is prese
On 12/14/21 2:35 AM, Robert Haas wrote:
I spent much of today reviewing 0001. Here's an updated version, so
far only lightly tested. Please check whether I've broken anything.
Thanks Robert, I tested from v96/12/13/v14 -> v15( with patch)
things are working fine i.e table /index relfilenode is p
On Tue, Dec 14, 2021 at 2:35 AM Robert Haas wrote:
>
> On Mon, Dec 13, 2021 at 9:40 AM Shruthi Gowda wrote:
> > > I am reviewing another patch
> > > "v5-0001-Preserve-relfilenode-and-tablespace-OID-in-pg_upg" as well
> > > and will provide the comments soon if any...
>
> I spent much of today rev
On Mon, Dec 13, 2021 at 9:40 AM Shruthi Gowda wrote:
> > I am reviewing another patch
> > "v5-0001-Preserve-relfilenode-and-tablespace-OID-in-pg_upg" as well
> > and will provide the comments soon if any...
I spent much of today reviewing 0001. Here's an updated version, so
far only lightly teste
On Mon, Dec 6, 2021 at 11:25 PM Robert Haas wrote:
>
> On Sun, Dec 5, 2021 at 11:44 PM Sadhuprasad Patro wrote:
> > 3.
> > @@ -504,11 +525,15 @@ createdb(ParseState *pstate, const CreatedbStmt *stmt)
> > */
> > pg_database_rel = table_open(DatabaseRelationId, RowExclusiveLock);
> >
> > - do
>
On Mon, Dec 6, 2021 at 10:14 AM Sadhuprasad Patro wrote:
>
> On Tue, Oct 26, 2021 at 6:55 PM Shruthi Gowda wrote:
> >
> >
> > I have revised the patch w.r.t the way 'create_storage' is interpreted
> > in heap_create() along with some minor changes to preserve the DBOID
> > patch.
> >
>
> Hi Shrut
On Sun, Dec 5, 2021 at 11:44 PM Sadhuprasad Patro wrote:
> 1.
> --- a/doc/src/sgml/ref/create_database.sgml
> +++ b/doc/src/sgml/ref/create_database.sgml
> @@ -31,7 +31,8 @@ CREATE DATABASE class="parameter">name
> - [ IS_TEMPLATE [=] class="parameter">istemplate ] ]
> + [ IS
On Tue, Oct 26, 2021 at 6:55 PM Shruthi Gowda wrote:
>
>
> I have revised the patch w.r.t the way 'create_storage' is interpreted
> in heap_create() along with some minor changes to preserve the DBOID
> patch.
>
Hi Shruthi,
I am reviewing the attached patches and providing a few comments here
be
On Tue, Oct 12, 2021 at 10:26:54AM -0400, Robert Haas wrote:
> > specifically: Appendix C: Tweaks
> >
> > Quoting a couple of paragraphs from that appendix:
> >
> > """
> > In general, if there is information that is available and statically
> > associated with a plaintext, it is recommended to use
Sasasu wrote:
> On 2021/10/6 23:01, Robert Haas wrote:
> > This seems wrong to me. CTR requires that you not reuse the IV. If you
> > re-encrypt the page with a different IV, torn pages are a problem. If
> > you re-encrypt it with the same IV, then it's not secure any more.
> for CBC if the IV i
On Thu, Oct 7, 2021 at 7:33 PM Robert Haas wrote:
>
> On Thu, Oct 7, 2021 at 3:24 AM Shruthi Gowda wrote:
> > Every other
> > caller/flow passes false for 'create_storage' and we still need to
> > create storage in heap_create() if relkind has storage.
>
> That seems surprising.
I have revised t
On Wed, Oct 13, 2021 at 09:16:37AM -0400, Stephen Frost wrote:
> Greetings,
>
> * Ants Aasma (a...@cybertec.at) wrote:
> > On Wed, 13 Oct 2021 at 02:20, Bruce Momjian wrote:
> > > On Wed, Oct 13, 2021 at 12:48:51AM +0300, Ants Aasma wrote:
> > > > On Wed, 13 Oct 2021 at 00:25, Bruce Momjian wrot
Greetings,
* Ants Aasma (a...@cybertec.at) wrote:
> On Wed, 13 Oct 2021 at 02:20, Bruce Momjian wrote:
> > On Wed, Oct 13, 2021 at 12:48:51AM +0300, Ants Aasma wrote:
> > > On Wed, 13 Oct 2021 at 00:25, Bruce Momjian wrote:
> > >
> > > On Tue, Oct 12, 2021 at 11:21:28PM +0300, Ants Aasma wro
On Wed, 13 Oct 2021 at 02:20, Bruce Momjian wrote:
> On Wed, Oct 13, 2021 at 12:48:51AM +0300, Ants Aasma wrote:
> > On Wed, 13 Oct 2021 at 00:25, Bruce Momjian wrote:
> >
> > On Tue, Oct 12, 2021 at 11:21:28PM +0300, Ants Aasma wrote:
> > > Page encrypting to all zeros is for all practi
On Wed, Oct 13, 2021 at 12:48:51AM +0300, Ants Aasma wrote:
> On Wed, 13 Oct 2021 at 00:25, Bruce Momjian wrote:
>
> On Tue, Oct 12, 2021 at 11:21:28PM +0300, Ants Aasma wrote:
> > Page encrypting to all zeros is for all practical purposes impossible to
> hit.
> > Basically an att
Greetings,
On Tue, Oct 12, 2021 at 17:49 Ants Aasma wrote:
>
> On Wed, 13 Oct 2021 at 00:25, Bruce Momjian wrote:
>
>> On Tue, Oct 12, 2021 at 11:21:28PM +0300, Ants Aasma wrote:
>> > On Tue, 12 Oct 2021 at 16:14, Bruce Momjian wrote:
>> >
>> > Well, how do you detect an all-zero page vs a
On Wed, 13 Oct 2021 at 00:25, Bruce Momjian wrote:
> On Tue, Oct 12, 2021 at 11:21:28PM +0300, Ants Aasma wrote:
> > On Tue, 12 Oct 2021 at 16:14, Bruce Momjian wrote:
> >
> > Well, how do you detect an all-zero page vs a page that encrypted to
> all
> > zeros?
> >
> > Page encrypting to
On Tue, Oct 12, 2021 at 11:21:28PM +0300, Ants Aasma wrote:
> On Tue, 12 Oct 2021 at 16:14, Bruce Momjian wrote:
>
> Well, how do you detect an all-zero page vs a page that encrypted to all
> zeros?
>
> Page encrypting to all zeros is for all practical purposes impossible to hit.
> Basic
On Tue, 12 Oct 2021 at 16:14, Bruce Momjian wrote:
> Well, how do you detect an all-zero page vs a page that encrypted to all
> zeros?
>
Page encrypting to all zeros is for all practical purposes impossible to
hit. Basically an attacker would have to be able to arbitrarily set the
whole contents
On Tue, Oct 12, 2021 at 10:39 AM Stephen Frost wrote:
> Using fake LSNs isn't new.. how is this not a concern already then?
>
> Also wondering why the buffer manager would care about the LSN on pages
> which are not BM_PERMANENT..?
>
> I'll admit that I might certainly be missing something here.
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Oct 11, 2021 at 1:30 PM Stephen Frost wrote:
> > Regarding unlogged LSNs at least, I would think that we'd want to
> > actually use GetFakeLSNForUnloggedRel() instead of just having it zero'd
> > out. The fixed value for GiST inde
On Mon, Oct 11, 2021 at 1:30 PM Stephen Frost wrote:
> Regarding unlogged LSNs at least, I would think that we'd want to
> actually use GetFakeLSNForUnloggedRel() instead of just having it zero'd
> out. The fixed value for GiST index pages is just during the index
> build process, as I recall, an
On Thu, Oct 7, 2021 at 11:05 PM Stephen Frost wrote:
> Sure, I get that. Would be awesome if all these things were clearly
> documented somewhere but I've never been able to find it quite as
> explicitly laid out as one would like.
:-(
> specifically: Appendix C: Tweaks
>
> Quoting a couple of
On Tue, Oct 12, 2021 at 08:49:28AM -0400, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > I thought he was saying that when you extend a file, you might have to
> > extend it with all zeros, rather than being able to extend it with
> > an actual encrypted page of zeros. For ex
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Tue, Oct 12, 2021 at 08:25:52AM -0400, Stephen Frost wrote:
> > * Bruce Momjian (br...@momjian.us) wrote:
> > > On Tue, Oct 12, 2021 at 08:40:17AM +0300, Ants Aasma wrote:
> > > > On Mon, 11 Oct 2021 at 22:15, Bruce Momjian wrote:
> > > >
On Tue, Oct 12, 2021 at 08:25:52AM -0400, Stephen Frost wrote:
> Greetings,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Tue, Oct 12, 2021 at 08:40:17AM +0300, Ants Aasma wrote:
> > > On Mon, 11 Oct 2021 at 22:15, Bruce Momjian wrote:
> > >
> > > > Yes, that's the direction that I wa
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Tue, Oct 12, 2021 at 08:40:17AM +0300, Ants Aasma wrote:
> > On Mon, 11 Oct 2021 at 22:15, Bruce Momjian wrote:
> >
> > > Yes, that's the direction that I was thinking also and specifically
> > with
> > > XTS as the encryption al
On Tue, Oct 12, 2021 at 08:40:17AM +0300, Ants Aasma wrote:
> On Mon, 11 Oct 2021 at 22:15, Bruce Momjian wrote:
>
> > Yes, that's the direction that I was thinking also and specifically with
> > XTS as the encryption algorithm to allow us to exclude the LSN but keep
> > everything el
On Mon, 11 Oct 2021 at 22:15, Bruce Momjian wrote:
> > Yes, that's the direction that I was thinking also and specifically with
> > XTS as the encryption algorithm to allow us to exclude the LSN but keep
> > everything else, and to address the concern around the nonce/tweak/etc
> > being the same
On Mon, Oct 11, 2021 at 01:30:38PM -0400, Stephen Frost wrote:
> Greetings,
>
> > Keep in mind that in our existing code (not my patch), the LSN is zero
> > for unlogged relations, a fixed value for some GiST index pages, and
> > unchanged for some hint bit changes. Therefore, while we can includ
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Fri, Oct 8, 2021 at 02:34:20PM -0400, Stephen Frost wrote:
> > What I think is missing from this discussion is the fact that, with XTS
> > (and XEX, on which XTS is built), the IV *is* run through a forward
> > cipher function, just as sug
On Mon, Oct 11, 2021 at 01:01:08PM -0400, Stephen Frost wrote:
> > It is more than just the page format --- it would also be the added
> > code, possible performance impact, and later code maintenance to allow
> > for are a more complex or two different page formats.
>
> Yes, there is more to it t
On Fri, Oct 8, 2021 at 02:34:20PM -0400, Stephen Frost wrote:
> What I think is missing from this discussion is the fact that, with XTS
> (and XEX, on which XTS is built), the IV *is* run through a forward
> cipher function, just as suggested above needs to be done for CBC. I
> don't see any reas
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Thu, Oct 7, 2021 at 11:32:07PM -0400, Stephen Frost wrote:
> > Part of the meeting was specifically about "why are we doing this?" and
> > there were a few different answers- first and foremost was "because
> > people are asking for it", f
On Thu, Oct 7, 2021 at 11:32:07PM -0400, Stephen Frost wrote:
> Part of the meeting was specifically about "why are we doing this?" and
> there were a few different answers- first and foremost was "because
> people are asking for it", from which followed that, yes, in many cases
> it's to satisfy
On 2021/10/6 23:01, Robert Haas wrote:
> This seems wrong to me. CTR requires that you not reuse the IV. If you
> re-encrypt the page with a different IV, torn pages are a problem. If
> you re-encrypt it with the same IV, then it's not secure any more.
for CBC if the IV is predictable will case "
Greetings,
* Antonin Houska (a...@cybertec.at) wrote:
> Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> > > On Thu, Oct 7, 2021 at 3:38 PM Stephen Frost wrote:
> > > > While I certainly also appreciate that we want to get this as right as
> > > > we possibly can from the
Stephen Frost wrote:
> Greetings,
>
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Thu, Oct 7, 2021 at 3:38 PM Stephen Frost wrote:
> > > While I certainly also appreciate that we want to get this as right as
> > > we possibly can from the start, I strongly suspect we'll have one of two
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Oct 7, 2021 at 12:57 PM Stephen Frost wrote:
> > Yes, for integrity verification (also known as 'authenticated
> > encryption') we'd definitely need to store a larger nonce value. In the
> > very, very long term, I think it'd be g
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Oct 7, 2021 at 3:38 PM Stephen Frost wrote:
> > While I certainly also appreciate that we want to get this as right as
> > we possibly can from the start, I strongly suspect we'll have one of two
> > reactions- either we'll be more
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Oct 7, 2021 at 3:31 PM Ashwin Agrawal wrote:
> > Not at all knowledgeable on security topics (bravely using terms and
> > recommendation), can we approach decisions like AES-XTS vs AES-GCM (which
> > in turn decides whether we ne
On Thu, Oct 7, 2021 at 3:38 PM Stephen Frost wrote:
> While I certainly also appreciate that we want to get this as right as
> we possibly can from the start, I strongly suspect we'll have one of two
> reactions- either we'll be more-or-less ignored and it'll be crickets
> from the security folks,
On Thu, Oct 7, 2021 at 03:38:58PM -0400, Stephen Frost wrote:
> > Now none of that is to say that we shouldn't limit risk - I mean less
> > risk is always better than more. But we need to be sure this is not
> > like a 90% thing, where we're pretty sure it works. We can get by with
> > that for a
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Oct 7, 2021 at 2:52 PM Stephen Frost wrote:
> > Assuming that's correct, and I don't see any reason to doubt it, then
> > perhaps it would make sense to have the LSN be unencrypted and include
> > it in the tweak as that would limi
On Thu, Oct 7, 2021 at 3:31 PM Ashwin Agrawal wrote:
> Not at all knowledgeable on security topics (bravely using terms and
> recommendation), can we approach decisions like AES-XTS vs AES-GCM (which in
> turn decides whether we need to store nonce or not) based on which compliance
> it can ach
On Thu, Oct 7, 2021 at 12:12 PM Robert Haas wrote:
> On Thu, Oct 7, 2021 at 2:52 PM Stephen Frost wrote:
> > Assuming that's correct, and I don't see any reason to doubt it, then
> > perhaps it would make sense to have the LSN be unencrypted and include
> > it in the tweak as that would limit th
On Thu, Oct 7, 2021 at 2:52 PM Stephen Frost wrote:
> Assuming that's correct, and I don't see any reason to doubt it, then
> perhaps it would make sense to have the LSN be unencrypted and include
> it in the tweak as that would limit the risk from re-use of the same
> tweak over time.
Talking ab
On Thu, Oct 7, 2021 at 09:59:31PM +0300, Ants Aasma wrote:
> On Thu, 7 Oct 2021 at 21:52, Stephen Frost wrote:
>
> With XTS this isn't actually the case though, is it..? Part of the
> point of XTS is that the last block doesn't have to be a full 16 bytes.
> What you're saying is tru
On Thu, Oct 7, 2021 at 02:52:07PM -0400, Stephen Frost wrote:
> > > Is there a particular reason why you would prefer not to use LSN? I
> > > suggested
> > > it because in my view having a variable tweak is still better than not
> > > having
> > > it even if we deem the risks of XTS tweak reuse
On Thu, Oct 7, 2021 at 12:57 PM Stephen Frost wrote:
> Yes, for integrity verification (also known as 'authenticated
> encryption') we'd definitely need to store a larger nonce value. In the
> very, very long term, I think it'd be great to have that, and the patch
> proposed on this thread seems
On Thu, 7 Oct 2021 at 21:52, Stephen Frost wrote:
> With XTS this isn't actually the case though, is it..? Part of the
> point of XTS is that the last block doesn't have to be a full 16 bytes.
> What you're saying is true for XEX, but that's also why XEX isn't used
> for FDE in a lot of cases, b
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Oct 7, 2021 at 1:09 PM Bruce Momjian wrote:
> > Are you saying a base backup could read a page from the file system and
> > see a partial write, even though the write is written as 8k? I had not
> > thought about that.
>
> Yes; s
On Thu, Oct 7, 2021 at 02:44:43PM -0400, Robert Haas wrote:
> > I think this whole discussion is about whether we need full page images
> > for hint bit changes. I think we do if we use the LSN for the nonce (in
> > the old patch), and probably need it for hint bit changes when using
> > block ci
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Thu, Oct 7, 2021 at 09:38:45PM +0300, Ants Aasma wrote:
> > On Wed, 6 Oct 2021 at 23:08, Bruce Momjian wrote:
> >
> > Yes, I would prefer we don't use the LSN. I only mentioned it since
> > Ants Aasma mentioned LSN use above.
>
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Oct 7, 2021 at 12:56 PM Bruce Momjian wrote:
> > Uh, do backups get torn and later used?
>
> Yep. That's why base backup mode forces full_page_writes on
> temporarily even if it's off in general.
Right, so this shouldn't be an is
On Thu, Oct 7, 2021 at 1:09 PM Bruce Momjian wrote:
> Are you saying a base backup could read a page from the file system and
> see a partial write, even though the write is written as 8k? I had not
> thought about that.
Yes; see my other response.
> I think this whole discussion is about wheth
On Thu, Oct 7, 2021 at 09:38:45PM +0300, Ants Aasma wrote:
> On Wed, 6 Oct 2021 at 23:08, Bruce Momjian wrote:
>
> Yes, I would prefer we don't use the LSN. I only mentioned it since
> Ants Aasma mentioned LSN use above.
>
>
> Is there a particular reason why you would prefer not to u
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Oct 7, 2021 at 12:26 PM Andres Freund wrote:
> > We rely on it today, e.g. for the control file.
>
> I think that's the only place, though. We can't rely on it for data
> files because base backups don't go through shared buffers,
On Wed, 6 Oct 2021 at 23:08, Bruce Momjian wrote:
> Yes, I would prefer we don't use the LSN. I only mentioned it since
> Ants Aasma mentioned LSN use above.
>
Is there a particular reason why you would prefer not to use LSN? I
suggested it because in my view having a variable tweak is still be
On Thu, Oct 7, 2021 at 12:56 PM Bruce Momjian wrote:
> Uh, do backups get torn and later used?
Yep. That's why base backup mode forces full_page_writes on
temporarily even if it's off in general.
Crazy, right?
--
Robert Haas
EDB: http://www.enterprisedb.com
On Thu, Oct 7, 2021 at 12:56:22PM -0400, Bruce Momjian wrote:
> On Thu, Oct 7, 2021 at 12:32:16PM -0400, Robert Haas wrote:
> > On Thu, Oct 7, 2021 at 12:26 PM Andres Freund wrote:
> > > We rely on it today, e.g. for the control file.
> >
> > I think that's the only place, though. We can't rely
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Oct 7, 2021 at 11:45 AM Bruce Momjian wrote:
> > I continue to be concerned that a page format change will decrease the
> > desirability of this feature by making migration complex and increasing
> > its code complexity. I am uncl
On Thu, Oct 7, 2021 at 12:32:16PM -0400, Robert Haas wrote:
> On Thu, Oct 7, 2021 at 12:26 PM Andres Freund wrote:
> > We rely on it today, e.g. for the control file.
>
> I think that's the only place, though. We can't rely on it for data
> files because base backups don't go through shared buff
On Thu, Oct 7, 2021 at 09:26:26AM -0700, Andres Freund wrote:
> Hi,
>
> On October 7, 2021 8:54:54 AM PDT, Bruce Momjian wrote:
>
> >Uh, technically most drives use 512-byte sectors, but I don't know if
> >there is any guarantee that 512-byte sectors will not be torn --- I have
> >a feeling th
On Thu, Oct 7, 2021 at 12:29:04PM -0400, Robert Haas wrote:
> On Thu, Oct 7, 2021 at 11:45 AM Bruce Momjian wrote:
> > I continue to be concerned that a page format change will decrease the
> > desirability of this feature by making migration complex and increasing
> > its code complexity. I am
On Thu, Oct 7, 2021 at 12:26 PM Andres Freund wrote:
> We rely on it today, e.g. for the control file.
I think that's the only place, though. We can't rely on it for data
files because base backups don't go through shared buffers, so reads
and writes can get torn in memory and not just on sector
On Thu, Oct 7, 2021 at 11:45 AM Bruce Momjian wrote:
> I continue to be concerned that a page format change will decrease the
> desirability of this feature by making migration complex and increasing
> its code complexity. I am unclear if it is necessary.
>
> I think the big question is whether X
Hi,
On October 7, 2021 8:54:54 AM PDT, Bruce Momjian wrote:
>Uh, technically most drives use 512-byte sectors, but I don't know if
>there is any guarantee that 512-byte sectors will not be torn --- I have
>a feeling there isn't. I think we get away with the hint bit case
>because you can't tea
On Thu, Oct 7, 2021 at 10:27:15AM +0200, Antonin Houska wrote:
> Bruce Momjian wrote:
> > The above text isn't very clear. What I am saying is that currently
> > torn pages can be tolerated by hint bit writes because only a single
> > byte is changing. If we use a block cipher like AES-XTS, lat
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Oct 6, 2021 at 3:17 PM Stephen Frost wrote:
> > With AES-XTS, we don't need to use the LSN as part of the nonce though,
> > so I don't think this argument is actually valid..? As discussed
> > previously regarding AES-XTS, the gen
On Thu, Oct 7, 2021 at 10:28:55AM -0400, Robert Haas wrote:
> However, there's also the option of storing a nonce in each page, as
> suggested by the subject of this thread. I think that's probably a
> pretty workable approach, as demonstrated by the patch that started
> this thread. We'd need to
1 - 100 of 296 matches
Mail list logo
