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
Hi, thanks for your fix! I am currently working on implementing the lz4 support for libpq compression. Looking forward to post an update soon.—Daniil ZakhlystovOn 2 Oct 2021, at 02:20, Daniel Gustafsson wrote:On 2 Sep 2021, at 00:29, Daniel Gustafsson wrote:On 29 Jul 2021, at 16:57, Daniil Zakhly
We generally only expect amvacuumcleanup() routines to be called
during VACUUM. But some ginvacuumcleanup() calls are an exception to
that general rule -- these are calls made during autoanalyze, where
ginvacuumcleanup() does real pending list cleanup work (not just a
no-op return). That'll only ha
On Thu, Oct 07, 2021 at 11:39:11PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Thu, Oct 07, 2021 at 03:44:48PM -0400, Tom Lane wrote:
> >>> (1) I'm distrustful of the idea that perl 5.8.x will compile
> >>> cleanly, or at all, on modern platforms. Certainly Postgres
> >>> releases of simil
On Thu, Oct 7, 2021 at 8:43 PM Thomas Munro wrote:
> On Sat, Jun 12, 2021 at 8:31 PM Zhihong Yu wrote:
> > +#ifdef POLLRDHUP
> > + if ((cur_event->events & WL_SOCKET_CLOSED) &&
> > + (cur_pollfd->revents & (POLLRDHUP | errflags)))
> >
> > It seems the last condition above
On Thu, Oct 7, 2021 at 12:39 PM Amit Langote wrote:
>
> 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 vi
On Sat, Jun 12, 2021 at 8:31 PM Zhihong Yu wrote:
> +#ifdef POLLRDHUP
> + if ((cur_event->events & WL_SOCKET_CLOSED) &&
> + (cur_pollfd->revents & (POLLRDHUP | errflags)))
>
> It seems the last condition above should be written as:
>
> ((cur_pollfd->revents & POLLRDHUP) | (
Noah Misch writes:
> On Thu, Oct 07, 2021 at 03:44:48PM -0400, Tom Lane wrote:
>>> (1) I'm distrustful of the idea that perl 5.8.x will compile
>>> cleanly, or at all, on modern platforms. Certainly Postgres
>>> releases of similar vintage won't.
> perlbrew uses the patchperl system to build old
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
On Thu, Oct 7, 2021 at 9:30 PM Tom Lane wrote:
>
> "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?
>
>
On Tue, Oct 05, 2021 at 04:18:17PM +0900, Michael Paquier wrote:
> 0002 and 0004 could be more polished and most of their pieces had
> better be squashed together. 0003, though, would improve the case of
> WIN32 where only csvlog is enabled so as log entries are properly
> redirected to the event
On Thursday, October 7, 2021 1:20 PM Masahiko Sawada
wrote:
> Regarding the patch details, I have two comments:
>
> ---
> + if ((parsed->xinfo & XACT_XINFO_HAS_INVALS) && last_running) {
> + /* make last_running->xids bsearch()able */
> + qsort(last_running->xids,
> + last_r
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
On Thu, Oct 07, 2021 at 01:26:46PM +0900, Michael Paquier wrote:
> On Wed, Oct 06, 2021 at 09:33:24PM -0500, Chris Bandy wrote:
>>> + /* Write to CSV log, if enabled */
>>> + if ((Log_destination & LOG_DESTINATION_CSVLOG) != 0)
>>
>> This was originally "if (Log_destination & LOG_DESTINATION_C
On Thu, Oct 07, 2021 at 03:44:48PM -0400, 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.
>
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > 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) Le
At Fri, 08 Oct 2021 09:56:32 +0900 (JST), Kyotaro Horiguchi
wrote in
> Hello.
>
> At Thu, 7 Oct 2021 03:07:33 +, "kuroda.hay...@fujitsu.com"
> wrote in
> > Dear Hackers,
> >
> > While reading source codes about timeouts and GUC and I found that
> > strange behavior about client_connecti
Hello.
At Thu, 7 Oct 2021 03:07:33 +, "kuroda.hay...@fujitsu.com"
wrote in
> Dear Hackers,
>
> While reading source codes about timeouts and GUC and I found that
> strange behavior about client_connection_check_interval.
>
> Currently we did not an assign_hook about client_connection_chec
On Fri, Oct 8, 2021 at 11:40 AM Tom Lane wrote:
> Thomas Munro writes:
> > (Hmm, in hindsight, I don't know why we need "--with-bsd-auth" instead
> > of detecting it, but I don't plan to work on that...)
>
> As far as that goes, I thought we had a policy against auto-detecting
> user-visible feat
On Wed, 30 Jun 2021 at 06:53, Takashi Menjo wrote:
>
> Rebased.
Thanks for these patches!
I recently took a dive into the WAL subsystem, and got to this
patchset through the previous ones linked from [0]. This patchset
seems straightforward to understand, so thanks!
I've looked over the patches
On Thu, Oct 07, 2021 at 03:26:46PM -0500, Jaime Casanova wrote:
> 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_expression
Thomas Munro writes:
> (Hmm, in hindsight, I don't know why we need "--with-bsd-auth" instead
> of detecting it, but I don't plan to work on that...)
As far as that goes, I thought we had a policy against auto-detecting
user-visible features. From memory, the rationale goes like "if you
want fea
On 2021-Oct-07, Tom Lane wrote:
> +Portability
> +---
> +
> +Avoid using any bleeding-edge Perl features. We have buildfarm animals
> +running Perl versions as old as 5.8.3, so your tests will be expected
> +to pass on that.
> +
> +Also, do not use any non-core Perl modules except IPC::Ru
Hi,
I noticed that for NetBSD we only have one animal, and it's running
EOL'd release 7. To give decent visibility of relevant portability
problems it'd be nice to have one of the current supported releases[1]
in there. CC'ing owner; any interest in updating this animal to 9.x?
For FreeBSD the
> On 7 Oct 2021, at 23:48, Tom Lane wrote:
> Concretely, then, I propose the attached.
LGTM. Good idea to change the section heading, Portability is a better title
for this.
--
Daniel Gustafsson https://vmware.com/
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
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:
>> 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 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
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 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
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, 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
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 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 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
[ 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
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 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 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
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
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.
> 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
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
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.
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
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
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
> 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
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
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
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
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 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_
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 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
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: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 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 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 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
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 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
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 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
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
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
"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
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
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'
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
> 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
>>
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 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.
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
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
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
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
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 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, 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:
> 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
1 - 100 of 125 matches
Mail list logo
