On Fri, Sep 17, 2021 at 7:38 PM Amit Kapila wrote:
> On Fri, Sep 17, 2021 at 11:36 AM houzj.f...@fujitsu.com
> wrote:
> > On Thursday, September 16, 2021 6:05 PM Amit Kapila
> >
> > > > On Tuesday, September 14, 2021 10:41 PM vignesh C
> > > > wrote:
> > > > > On Tue, Sep 7, 2021 at 11:38 AM
On Wed, Oct 6, 2021 at 4:42 PM vignesh C wrote:
>
> Attached v37 patch has the changes for the same.
>
A small issue I noticed is that using "\dS" in PSQL shows UNLOGGED
tables as belonging to a publication, if the table belongs to a schema
that was added to the publication using ALL TABLES IN SC
On Thu, Oct 7, 2021 at 2:05 AM Robert Haas wrote:
>
> On Mon, Oct 4, 2021 at 12:44 PM Shruthi Gowda wrote:
> > Thanks for the inputs, Robert. In the v4 patch, an unused OID (i.e, 4)
> > is fixed for the template0 and the same is removed from unused oid
> > list.
> >
> > In addition to the review
On Thu, Oct 07, 2021 at 06:00:08AM +, Bossart, Nathan wrote:
> The attached patch seems to fix it.
Thanks, sorry about that. I was able to see that once I compiled
without assertions.
--
Michael
signature.asc
Description: PGP signature
On Thu, Oct 07, 2021 at 03:24:53PM +0900, Masahiko Sawada wrote:
> Indeed. I've attached a patch that also deals with "false : true" cases.
Looks right. I would be tempted to keep the one in readfuncs.c
though, mostly as a matter of style, and I would add a comparison with
NULL for the return res
Hi,
Thank you for the review.
I wasn't quite sure where to start counting the characters,
but I used pgindent to properly format it, so hopefully everything is
okay.
Also, I sorted them in alphabetical order just to make it look prettier.
* The below change crosses the 80-character li
Bruce Momjian wrote:
> On Tue, Oct 5, 2021 at 04:29:25PM -0400, Bruce Momjian wrote:
> > On Tue, Sep 28, 2021 at 12:30:02PM +0300, Ants Aasma wrote:
> > > On Mon, 27 Sept 2021 at 23:34, Bruce Momjian wrote:
> > > We are still working on our TDE patch. Right now the focus is on
> > > refactorin
At Thu, 30 Sep 2021 09:40:06 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Mon, 27 Sep 2021 17:31:03 +1300, Thomas Munro
> wrote in
> > On Thu, Jul 15, 2021 at 4:48 PM Kyotaro Horiguchi
> > wrote:
> > > Gah... Thank you for noticing me. I thought that I have sent the
> > > rebased version. T
On Thu, Oct 7, 2021 at 12:05 PM Amit Langote wrote:
> On Wed, Oct 6, 2021 at 5:41 PM Etsuro Fujita wrote:
> > Rereading the comment, I think it would be better to add “will” to the
> > second part “the partitions with the same cardinal positions form the
> > pairs” as well. Updated patch attache
On 10/6/21 8:48 PM, Stephen Frost wrote:
> Consider that with what you're proposing, a user could execute the
> following series of entirely SQL-spec compliant statements, and get
> very different results depending on if we have this 'ownership' concept
> or not:
>
> SET ROLE postgres;
> CREATE RO
When producing a forked version of PostgreSQL, there is no
straightforward way to enforce that users don't accidentally load
modules built for the non-forked (standard, community) version. You can
only distinguish by PostgreSQL major version and a few compile-time
settings. (see internal_load
On Wed, Oct 6, 2021 at 8:39 PM Bharath Rupireddy
wrote:
> On Wed, Oct 6, 2021 at 4:55 PM Etsuro Fujita wrote:
> > On Wed, Oct 6, 2021 at 6:37 PM Bharath Rupireddy
> > wrote:
> > > +1 for rewording the comments. Here are my thoughts on the patch:
> > >
> > > 1) Just to be consistent(we are using
On 2021-10-07 17:14, katouknl wrote:
Hi,
Thank you for the review.
I wasn't quite sure where to start counting the characters,
but I used pgindent to properly format it, so hopefully everything is
okay.
Also, I sorted them in alphabetical order just to make it look
prettier.
* The be
čt 7. 10. 2021 v 11:28 odesílatel Peter Eisentraut <
peter.eisentr...@enterprisedb.com> napsal:
> When producing a forked version of PostgreSQL, there is no
> straightforward way to enforce that users don't accidentally load
> modules built for the non-forked (standard, community) version. You ca
Thanks Nitin,
v4 patches applied cleanly and make check is passing now. While testing
further I observed that if multiple values are given for a single
column list partition it is not giving error instead it is changing values
itself. Please find the example below.
postgres=# CREATE TABLE plt1 (a
Hi,
On Thu, Oct 7, 2021 at 1:29 PM k.jami...@fujitsu.com
wrote:
> That said, if we're going to initially support it on postgres_fdw, which is
> simpler
> than the latest patches, we need to ensure that abnormalities and errors
> are properly handled and prove that commit performance can be impro
Hi,
On Wed, Sep 29, 2021 at 8:14 PM Alvaro Herrera wrote:
>
> On 2021-Sep-24, Alvaro Herrera wrote:
>
> > Here's the set for all branches, which I think are really final, in case
> > somebody wants to play and reproduce their respective problem scenarios.
> > Nathan already confirmed that his rep
Hi,
I was able to create a table in "information_schema" schema, but
pg_dump does not dumps the table that was created in
"information_schema" schema:
create table information_schema.t1(c1 int);
The similar problem exists in case of create publication, we are able
to create publications for table
Hi, Anton!
I've corrected the patch and attached a new version.
--
Andrei Zubkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Wed, 2021-10-06 at 18:13 +0300, Мельников Антон Андреевич wrote:
> Hi, Andrey!
>
> I’ve tried to apply your patch v2-0001 on curre
On Wed, Oct 6, 2021 at 11:12 AM vignesh C wrote:
>
> Attached v37 patch has the changes for the same.
>
Few comments:
==
v37-0001-Added-schema-level-support-for-publication
1.
+ *
+ * The first scan will get all the 'r' relkind tables for the specified schema,
+ * iterate the 'r' relk
Hi Robert,
I think the patch v6-0007-Support-base-backup-targets.patch has broken
the case for multiple tablespaces. When I tried to take the backup
for target 'none' and extract the base.tar I was not able to locate
tablespace_map file.
I debugged and figured out in normal tar backup i.e. '-Ft'
Hi,
I adjusted a bit the code and configured my mail client to
send patch attachments appropiately(hopefully). :)
So here is my second version.
Cheers,
Florin IrionFrom 9a50261faad3a7578dab150f1c05b510285e283c Mon Sep 17 00:00:00 2001
From: Florin Irion
Date: Thu, 7 Oct 2021 09:51:29 +0200
There is an issue with this patch. It's main purpose is the ability to
calculate values of pg_stat_statements view for a time period between
two samples without resetting pg_stat_statements being absolutely sure
that the statement was not evicted.
Such approach solves the problem for metrics with e
On Thu, Oct 7, 2021 at 5:56 AM Jaime Casanova
wrote:
>
> On Tue, Oct 05, 2021 at 04:11:58PM +0530, Amul Sul wrote:
> >On Mon, Oct 4, 2021 at 1:57 PM Rushabh Lathia
> > wrote:
> > >
> > > I tried to apply the patch on the master branch head and it's failing
> > > with conflicts.
> > >
> >
> >
Hello,
Thanks for the revised patch.
It is very good, but it seems to me that there are some tab-completion
> missing in COMMENT command.
Thanks Shinya, for having a look. I was also about to say that it would be
good
if we take care of tab-completion for other options as well in this patch
itse
On 2021-Oct-07, Amul Sul wrote:
> While reading this commit (ff9f111bce24), wondered can't we skip
> missingContrecPtr global variable declaration and calculate that from
> abortedRecPtr value whenever it needed. IIUC, missingContrecPtr is the
> next page to the page that abortedRecPtr contain and
On Thu, 7 Oct 2021 at 6:41 PM, Alvaro Herrera
wrote:
> On 2021-Oct-07, Amul Sul wrote:
>
> > While reading this commit (ff9f111bce24), wondered can't we skip
> > missingContrecPtr global variable declaration and calculate that from
> > abortedRecPtr value whenever it needed. IIUC, missingContrecP
On 2021-Oct-07, Amul Sul wrote:
> Make sense, thanks for the explanation.
You're welcome. Also, I forgot: thank you for taking the time to review
the code. Much appreciated.
--
Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/
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.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Thursday, October 7, 2021, vignesh C wrote:
>
> Should tables be allowed to create in "information_schema" schema, if
> yes should the tables/publications be dumped while dumping database
> contents?
>
>
I presume you have to be superuser to do this. If so, this would seem to
fit under the “w
Greetings,
* Vik Fearing (v...@postgresfriends.org) wrote:
> On 10/6/21 8:48 PM, Stephen Frost wrote:
> > Consider that with what you're proposing, a user could execute the
> > following series of entirely SQL-spec compliant statements, and get
> > very different results depending on if we have th
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Wed, Oct 6, 2021 at 03:17:00PM -0400, Stephen Frost wrote:
> > * Bruce Momjian (br...@momjian.us) wrote:
> > > On Tue, Oct 5, 2021 at 04:29:25PM -0400, Bruce Momjian wrote:
> > > > On Tue, Sep 28, 2021 at 12:30:02PM +0300, Ants Aasma wrot
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 general idea was to use the path to
> the file and the filename itse
On 2021/10/07 19:47, Etsuro Fujita wrote:
Hi,
On Thu, Oct 7, 2021 at 1:29 PM k.jami...@fujitsu.com
wrote:
That said, if we're going to initially support it on postgres_fdw, which is
simpler
than the latest patches, we need to ensure that abnormalities and errors
are properly handled
Yes.
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Oct 6, 2021, at 1:48 PM, Stephen Frost wrote:
> > This specific syntax, including the CASCADE bit, has, at minimum, at least
> > been contemplate by the SQL folks sufficiently to be described in one
> > specific way. I don’t
> On Oct 7, 2021, at 7:43 AM, Stephen Frost wrote:
>
>> Assuming no concept of role ownership exists, but that DROP ROLE bob CASCADE
>> is implemented in a spec compliant way, if there is a role "bob" who owns
>> various objects, what happens when DROP ROLE bob CASCADE is performed? Do
>>
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
Peter Eisentraut writes:
> I'm thinking about adding two more int fields to Pg_magic_struct: a
> product or vendor magic number, and an ABI version that can be used
> freely within a product/vendor.
Who would hand out these magic numbers?
If the answer is "choose a random one, it probably won'
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: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
"David G. Johnston" writes:
> On Thursday, October 7, 2021, vignesh C wrote:
>> Should tables be allowed to create in "information_schema" schema, if
>> yes should the tables/publications be dumped while dumping database
>> contents?
> I presume you have to be superuser to do this. If so, this
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Oct 7, 2021, at 7:43 AM, Stephen Frost wrote:
> >> Assuming no concept of role ownership exists, but that DROP ROLE bob
> >> CASCADE is implemented in a spec compliant way, if there is a role "bob"
> >> who owns various objec
AFAICS we have consensus on doing these things (in HEAD only):
* update ppport.h to perl 5.34.0
* adjust configure and docs to set 5.8.3 as the minimum perl version
* adjust docs to say we don't test or support AIX below 7.1.
I'll go make these things happen.
regards, t
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 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:49:57 AM PDT, Tom Lane
>I'm also kind of unclear on why we need to do anything about this
>in the community version. If someone has forked PG and changed
>APIs to the extent that extensions are unlikely to work, there's
>not much stopping them from also making the two-l
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
Andres Freund writes:
> On October 7, 2021 8:49:57 AM PDT, Tom Lane
>> I'm also kind of unclear on why we need to do anything about this
>> in the community version. If someone has forked PG and changed
>> APIs to the extent that extensions are unlikely to work, there's
>> not much stopping them
> On Oct 7, 2021, at 9:05 AM, Stephen Frost wrote:
>
>> Hmmph. I think it would be strange if all of the following were true:
>>
>> 1) DROP ROLE bob CASCADE drops all objects owned by bob
>> 2) Roles can own other roles
>> 3) DROP ROLE bob CASCADE never cascades to other roles
>>
>> I'm ass
On Mon, Oct 4, 2021 at 8:22 PM Bossart, Nathan wrote:
> The changes for adding GUC management roles seem pretty
> straightforward and would likely be helpful for service providers.
> However, I was kind of surprised that membership to such roles also
> provided access to ALTER SYSTEM SET. IMO the
On 10/7/21 4:21 PM, Stephen Frost wrote:
> Greetings,
>
> * Vik Fearing (v...@postgresfriends.org) wrote:
>> On 10/6/21 8:48 PM, Stephen Frost wrote:
>>> Consider that with what you're proposing, a user could execute the
>>> following series of entirely SQL-spec compliant statements, and get
>>> v
On Thu, Oct 7, 2021 at 12:52 PM Vik Fearing wrote:
> I can agree with you now, but it's certainly not the easiest thing to
> interpret.
That's putting it mildly.
--
Robert Haas
EDB: http://www.enterprisedb.com
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 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: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 10/07/21 12:42, Tom Lane wrote:
> Can we make the addition be a string not a number, so that we
> could include something more useful than "1234" in the error
> message?
I was wondering the same thing, just to sidestep the "who hands out IDs"
question.
Just using a string like "EDB v" + somet
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 Oct 6, 2021, at 10:48 PM, Bharath Rupireddy
> wrote:
>
> Hi Mark, thanks for this work. I'm late to be here in this thread,
> please note that I didn't go through the entire thread as it is quite
> long for me to read.
Thanks for joining.
> I have a question: it looks like the view pg_
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
On Thu, Oct 7, 2021 at 10:29 PM Mark Dilger
wrote:
> > I have a question: it looks like the view pg_backend_memory_contexts
> > and the function pg_log_backend_memory_contexts are superuser only.
> > Isn't it a good idea to allow users with a pg_monitor or some other
> > similar role to use these
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Oct 7, 2021, at 9:05 AM, Stephen Frost wrote:
> > I don't think the spec supports any of the three rules you list.
>
> And I'm not seeing that it prohibits any of them.
I don't agree that we can decide to have random statemen
Hi,
In a typical production environment, the user (not necessarily a
superuser) sometimes wants to analyze the memory usage via
pg_backend_memory_contexts view or pg_log_backend_memory_contexts
function which are accessible to only superusers. Isn't it better to
allow non-superusers with an approp
> On Oct 7, 2021, at 10:23 AM, Stephen Frost wrote:
>
>> And I'm not seeing that it prohibits any of them.
>
> I don't agree that we can decide to have random statements which are
> defined explicitly in the standard to do X end up doing X+Y, simply
> because the standard didn't explicitly sa
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Oct 7, 2021, at 10:23 AM, Stephen Frost wrote:
> >> And I'm not seeing that it prohibits any of them.
> >
> > I don't agree that we can decide to have random statements which are
> > defined explicitly in the standard to do X
I wrote:
> * adjust configure and docs to set 5.8.3 as the minimum perl version
When I went to update the docs, I found they already said 5.8.3
is the minimum. Excavating in the git log led me to this old
discussion:
https://www.postgresql.org/message-id/flat/16894.1501392088%40sss.pgh.pa.us#2c7
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 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
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 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
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
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
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.
>
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,
* 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 10/7/21, 10:42 AM, "Bharath Rupireddy"
wrote:
> In a typical production environment, the user (not necessarily a
> superuser) sometimes wants to analyze the memory usage via
> pg_backend_memory_contexts view or pg_log_backend_memory_contexts
> function which are accessible to only superusers.
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
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, 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 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 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 Oct 7, 2021, at 11:30 AM, Stephen Frost wrote:
>
>> Because we've already decided how object ownership works. I didn't write
>> any code to have roles get dropped when their owners get dropped. I just
>> put ownership into the system and this is how it naturally works. So you
>> are
Chapman Flack writes:
> On 10/07/21 12:42, Tom Lane wrote:
>> Can we make the addition be a string not a number, so that we
>> could include something more useful than "1234" in the error
>> message?
> Just using a string like "EDB v" + something would probably rule out
> collisions in practice.
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Oct 7, 2021, at 11:30 AM, Stephen Frost wrote:
> >> Because we've already decided how object ownership works. I didn't write
> >> any code to have roles get dropped when their owners get dropped. I just
> >> put ownership i
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 Oct 7, 2021, at 12:19 PM, Stephen Frost wrote:
>
> Uh, I didn't say it 'must not fail'.
Ah-hah, right, I misremembered. You were quoting the spec at me, and I went to
read a copy of the spec as a consequence, and saw something like that there.
Let me see if I can find that again.
—
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
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
[ cc'ing Craig and Noah, as author/committer of the existing text ]
Daniel Gustafsson writes:
> On 7 Oct 2021, at 21:02, Tom Lane wrote:
>> BTW, looking at that a second time, I wonder if that advice is
>> really of any use.
> Yeah, I would have to agree. Reading that again I think what it per
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
> On 7 Oct 2021, at 21:44, Tom Lane wrote:
>
> [ cc'ing Craig and Noah, as author/committer of the existing text ]
>
> Daniel Gustafsson writes:
>> On 7 Oct 2021, at 21:02, Tom Lane wrote:
>>> BTW, looking at that a second time, I wonder if that advice is
>>> really of any use.
>
>> Yeah, I w
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,
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 2021-Oct-07, Daniel Gustafsson wrote:
> Agreed, that's a lot more helpful. Since the set of core Perl modules change
> over time as modules are brought in (at least that's my understanding of it),
> that last paragraph might want to discourage use of modules that aren't
> expected to be in-cor
Alvaro Herrera writes:
> Maybe we can mention `corelist -a` as a way to find out the module
> versions shipped with each Perl version.
Hm, I don't see that on my RHEL box.
It does exist on my Mac, but the output is very unhelpful:
$ which corelist
/usr/bin/corelist
$ corelist -a
The content
On 2021-Oct-07, Tom Lane wrote:
> Alvaro Herrera writes:
> > Maybe we can mention `corelist -a` as a way to find out the module
> > versions shipped with each Perl version.
>
> Hm, I don't see that on my RHEL box.
Oh, that's strange. It's installed by the perl package on my system, so
I had as
On Sun, Sep 26, 2021 at 03:25:50PM -0500, Justin Pryzby wrote:
> On Sat, Sep 25, 2021 at 05:31:52PM -0500, Justin Pryzby wrote:
> > It seems like your patch should also check "inh" in examine_variable and
> > statext_expressions_load.
>
> I tried adding that - I mostly kept my patches separate.
>
> On Oct 7, 2021, at 12:31 PM, Mark Dilger wrote:
>
> Let me see if I can find that again.
12.6
::=
DROP ROLE
Syntax Rules
1) Let R be the role identified by the specified .
General Rules
1) Let A be any identified by a role authorization
descriptor as having been granted
to R.
2) Th
Alvaro Herrera writes:
> On 2021-Oct-07, Tom Lane wrote:
>> So this isn't looking promising :-(
> Looking in the archives, apparently people use
> perl -MModule::CoreList
> but I see that that module, at least in Debian, is distributed even less
> widely than corelist(1) itself, because it's a
On 2021-Oct-07, Tom Lane wrote:
> Hmm. I do see that Module::CoreList knows not only which modules
> are in core but when they were brought in, so that does seem like
> a really valuable reference to know about. Let's just say something
> like "You can consult Module::CoreList to find out whethe
Alvaro Herrera writes:
> On 2021-Oct-07, Tom Lane wrote:
>> Hmm. I do see that Module::CoreList knows not only which modules
>> are in core but when they were brought in, so that does seem like
>> a really valuable reference to know about. Let's just say something
>> like "You can consult Module
1 - 100 of 125 matches
Mail list logo
