Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?

Greetings, * Jeff Davis (pg...@j-davis.com) wrote: > On Fri, 2021-10-15 at 09:08 -0400, Robert Haas wrote: > > I think we'd at least need to check that the view owner has execute > > permission on the function. I'm not sure whether there are any other > > gotchas. > > Right, like we do for

Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?

Greetings, * Jeff Davis (pg...@j-davis.com) wrote: > On Wed, 2021-10-13 at 10:03 -0400, Robert Haas wrote: > > Yeah. I think we should really only use predefined roles where it's > > not practical to have people use GRANT/REVOKE. > > That sounds like a good rule. > > A minor complaint though:

Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?

Greetings, * Isaac Morland (isaac.morl...@gmail.com) wrote: > On Thu, 14 Oct 2021 at 09:11, Robert Haas wrote: > > According to https://www.postgresql.org/docs/current/sql-createview.html > > it always works like that: "Access to tables referenced in the view is > > determined by permissions of

Re: pg14 psql broke \d datname.nspname.relname

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Oct 13, 2021 at 12:54 PM Justin Pryzby wrote: > > It seems unfortunate if names from log messages qualified with datname were > > now > > rejected. Like this one: > > > > | automatic analyze of table

Re: storing an explicit nonce

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

Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?gr

Greeting, On Wed, Oct 13, 2021 at 04:14 Bharath Rupireddy < bharath.rupireddyforpostg...@gmail.com> wrote: > On Wed, Oct 13, 2021 at 1:24 PM Michael Paquier > wrote: > > > > On Wed, Oct 13, 2021 at 11:15:16AM +0530, Bharath Rupireddy wrote: > > > IMO, we can just retain the "if (!superuser())"

Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?gr

Greetings, On Wed, Oct 13, 2021 at 03:54 Michael Paquier wrote: > On Wed, Oct 13, 2021 at 11:15:16AM +0530, Bharath Rupireddy wrote: > > IMO, we can just retain the "if (!superuser())" check in the > > pg_log_backend_memory_contexts as is. This would be more meaningful as > > the error "must be

Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?

Greetings, On Tue, Oct 12, 2021 at 20:26 Bossart, Nathan wrote: > On 10/9/21, 2:12 AM, "Bharath Rupireddy" < > bharath.rupireddyforpostg...@gmail.com> wrote: > > Here's the v1, please review it further. > > Thanks for the patch. > > - /* Only allow superusers to log memory contexts. */ >

Re: storing an explicit nonce

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

Re: pg14 psql broke \d datname.nspname.relname

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Oct 12, 2021 at 10:31 AM Tom Lane wrote: > > If the behavior v14 had implemented were "throw an error if the > > first word doesn't match the current database name", perhaps nobody > > would have questioned it. But that's not

Re: storing an explicit nonce

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

Re: storing an explicit nonce

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

Re: storing an explicit nonce

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

Re: storing an explicit nonce

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 > >

Re: storing an explicit nonce

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 "

Re: Proposal: allow database-specific role memberships

Greetings, * David G. Johnston (david.g.johns...@gmail.com) wrote: > On Monday, October 11, 2021, Stephen Frost wrote: > > I don't think "just don't grant access to those other databases" > > is actually a proper answer- there is certainly a use-case for "I want

Re: Proposal: allow database-specific role memberships

Greetings, * David G. Johnston (david.g.johns...@gmail.com) wrote: > On Sun, Oct 10, 2021 at 2:29 PM Kenaniah Cerny wrote: > > > In building off of prior art regarding the 'pg_read_all_data' and > > 'pg_write_all_data' roles, I would like to propose an extension to roles > > that would allow

Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?

Greetings, * Bossart, Nathan (bossa...@amazon.com) wrote: > On 10/8/21, 12:01 AM, "Bharath Rupireddy" > wrote: > > I think we can remove the below revoke statements from > > system_views.sql and place the checks shown at (2) in the underlying > > functions pg_get_shmem_allocations,

Re: storing an explicit nonce

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 a

Re: storing an explicit nonce

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 lo

Re: storing an explicit nonce

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 > > re

Re: Role Self-Administration

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)

Re: storing an explicit nonce

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

Re: storing an explicit nonce

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 th

Re: Role Self-Administration

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

Re: storing an explicit nonce

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;

Re: storing an explicit nonce

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. >

Re: storing an explicit nonce

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

Re: storing an explicit nonce

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

Re: Role Self-Administration

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 e

Re: Role Self-Administration

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 dec

Re: storing an explicit nonce

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

Re: Role Self-Administration

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 &quo

Re: storing an explicit nonce

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 > > previou

Re: Role Self-Administration

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 &g

Re: storing an explicit nonce

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 a

Re: Role Self-Administration

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 de

Re: Role Self-Administration

Greetings, On Wed, Oct 6, 2021 at 16:28 Robert Haas wrote: > On Wed, Oct 6, 2021 at 3:29 PM Stephen Frost wrote: > > Does that mean that we also get to change what a specific set of > > commands, which are all well-defined in the standard, do even when that > > goe

Re: Role Self-Administration

Greetings, On Wed, Oct 6, 2021 at 16:01 Mark Dilger wrote: > > On Oct 6, 2021, at 11:48 AM, Stephen Frost wrote: > > > > In the spec, under , there is a 'General Rules' > > section (as there is with most statements) and in that section it says > > that for

Re: Role Self-Administration

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Oct 6, 2021 at 2:48 PM Stephen Frost wrote: > > What I'm saying above is that the command explicitly listed there > > *isn't* 'DROP ROLE A DB', even though that is something which the spec > > *could* have

Re: storing an explicit nonce

Greetings, * 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 wrote: > > > On Mon, 27 Sept 2021 at 23:34, Bruce Momjian wrote: > > > We are still working on our TDE patch. Right now

Re: Role Self-Administration

Greetings, * Mark Dilger (mark.dil...@enterprisedb.com) wrote: > > On Oct 6, 2021, at 11:09 AM, Stephen Frost wrote: > > After all, it says > > "REOKVE R FROM A DB", not "DROP ROLE A CASCADE". > > Wait, are you arguing what DROP ROLE A CASCADE shoul

Re: Role Self-Administration

Greetings, * Mark Dilger (mark.dil...@enterprisedb.com) wrote: > > On Oct 6, 2021, at 10:20 AM, Stephen Frost wrote: > > > > Consistency is not having dangling pointers around to things which no > > longer exist- FK reference kind of things. Object management is a

Re: Role Self-Administration

Greetings, * Mark Dilger (mark.dil...@enterprisedb.com) wrote: > > On Oct 6, 2021, at 9:01 AM, Stephen Frost wrote: > > I can see how what you describe as the behavior you'd like to see of > > DROP ROLE ... CASCADE could be useful... However, at least in the > > latest

Re: Role Self-Administration

Greetings, * Mark Dilger (mark.dil...@enterprisedb.com) wrote: > > On Oct 5, 2021, at 10:20 AM, Stephen Frost wrote: > > On Tue, Oct 5, 2021 at 13:17 Mark Dilger > > wrote: > > > On Oct 5, 2021, at 10:14 AM, Stephen Frost wrote: > > > > > > What

Re: storing an explicit nonce

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Oct 5, 2021 at 1:24 PM Robert Haas wrote: > > On Mon, Oct 4, 2021 at 10:00 PM Stephen Frost wrote: > > > I do want to point out, as I think I did when we discussed this but want > > > to be sure it's

Re: Role Self-Administration

Greetings, On Tue, Oct 5, 2021 at 13:17 Mark Dilger wrote: > > On Oct 5, 2021, at 10:14 AM, Stephen Frost wrote: > > > > What does the “ownership” concept actually buy us then? > > DROP ... CASCADE I’m not convinced that we need to invent the concept of ownership in

Re: Role Self-Administration

Greetings, On Tue, Oct 5, 2021 at 13:09 Robert Haas wrote: > On Tue, Oct 5, 2021 at 12:38 PM Mark Dilger > wrote: > > Additionally, role "alice" might not exist anymore, which would leave > the privilege irrevocable. > > I thought that surely this couldn't be right, but apparently we have >

Re: Role Self-Administration

Greetings, On Tue, Oct 5, 2021 at 12:38 Mark Dilger wrote: > > > > On Oct 5, 2021, at 9:23 AM, Robert Haas wrote: > > > >> - Disallow roles from being able to REVOKE role membership that they > >> didn't GRANT in the first place. > > > > I think that's not quite the right test. For example,

Re: Role Self-Administration

Greetings, On Tue, Oct 5, 2021 at 12:23 Robert Haas wrote: > On Mon, Oct 4, 2021 at 10:57 PM Stephen Frost wrote: > > - Disallow roles from being able to REVOKE role membership that they > > didn't GRANT in the first place. > > I think that's not quite the right test.

Re: Role Self-Administration

Greetings, * Noah Misch (n...@leadboat.com) wrote: > On Mon, Oct 04, 2021 at 10:57:46PM -0400, Stephen Frost wrote: > > "A role is not considered to hold WITH ADMIN OPTION on itself, but it > > may grant or revoke membership in itself from a database session where > >

Re: parallelizing the archiver

Greetings, * Bossart, Nathan (bossa...@amazon.com) wrote: > On 10/4/21, 7:21 PM, "Stephen Frost" wrote: > > This has something we've contemplated quite a bit and the last thing > > that I'd want to have is a requirement to configure a whole bunch of > > additional

Role Self-Administration

Greetings, There's been various discussions about CREATEROLE, EVENT TRIGGERs, and other things which hinge around the general idea that we can create a 'tree' of roles where there's some root and then from that root there's a set of created roles, or at least roles which have been GRANT'd other

Re: Triage on old commitfest entries

Greetings, * Peter Geoghegan (p...@bowt.ie) wrote: > On Sun, Oct 3, 2021 at 1:30 PM Tom Lane wrote: > > Fair. My concern here is mostly that we not just keep kicking the > > can down the road. If we see that a patch has been hanging around > > this long without reaching commit, we should

Re: parallelizing the archiver

Greetings, * Bossart, Nathan (bossa...@amazon.com) wrote: > On 10/1/21, 12:08 PM, "Andrey Borodin" wrote: > > 30 сент. 2021 г., в 09:47, Bossart, Nathan написал(а): > >> Of course, there are drawbacks to using an extension. Besides the > >> obvious added complexity of building an extension in

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

Greetings, * Bossart, Nathan (bossa...@amazon.com) wrote: > On 9/27/21, 11:16 AM, "Mark Dilger" wrote: > > On Sep 21, 2021, at 12:58 PM, Andrew Dunstan wrote: > >> I do like the basic thrust of reducing the power of CREATEROLE. There's > >> an old legal maxim I learned in my distant youth that

Re: storing an explicit nonce

Greetings, * Ants Aasma (a...@cybertec.at) wrote: > On Mon, 27 Sept 2021 at 23:34, Bruce Momjian wrote: > > On Sun, Sep 5, 2021 at 10:51:42PM +0800, Sasasu wrote: > > > It looks like we are still considering AES-CBC, AES-XTS, and > > AES-GCM(-SIV). > > > I want to say something that we don't

Re: proposal: possibility to read dumped table's name from file

Greetings, On Fri, Sep 17, 2021 at 14:07 Daniel Gustafsson wrote: > > On 17 Sep 2021, at 13:59, Pavel Stehule wrote: > > pá 17. 9. 2021 v 13:56 odesílatel Daniel Gustafsson > napsal: > > > On 17 Sep 2021, at 13:51, Pavel Stehule >

Re: proposal: possibility to read dumped table's name from file

Greetings, On Fri, Sep 17, 2021 at 13:59 Pavel Stehule wrote: > > > pá 17. 9. 2021 v 13:56 odesílatel Daniel Gustafsson > napsal: > >> > On 17 Sep 2021, at 13:51, Pavel Stehule >> wrote: >> > pá 17. 9. 2021 v 13:42 odesílatel Daniel Gustafsson > > napsal: >> >> > I am

Re: parallelizing the archiver

Greetings, * Julien Rouhaud (rjuju...@gmail.com) wrote: > On Fri, Sep 10, 2021 at 2:03 PM Andrey Borodin wrote: > > > 10 сент. 2021 г., в 10:52, Julien Rouhaud написал(а): > > > Yes, but it also means that it's up to every single archiving tool to > > > implement a somewhat hackish parallel

Re: New predefined roles- 'pg_read/write_all_data'

Greetings, On Sun, Sep 5, 2021 at 07:43 Shinoda, Noriyoshi (PN Japan FSIP) < noriyoshi.shin...@hpe.com> wrote: > I have tested this new feature with PostgreSQL 14 Beta 3 environment. > I created a user granted with pg_write_all_data role and executed UPDATE > and DELETE statements on tables

Re: automatic analyze: readahead - add "IO read time" log message

Greetings, * Stephen Frost (sfr...@snowman.net) wrote: > * Egor Rogov (e.ro...@postgrespro.ru) wrote: > > On 11.02.2021 01:10, Stephen Frost wrote: > > >* Heikki Linnakangas (hlinn...@iki.fi) wrote: > > >>On 05/02/2021 23:22, Stephen Frost wrote: > > >>&

Re: pgsql: Deduplicate choice of horizon for a relation procarray.c.

Greetings, * Andres Freund (and...@anarazel.de) wrote: > As the code in question was only introduced in dc7420c2c92 it seems worth > backpatching this change as well, otherwise 14 will look different from all > other branches. Interestingly, these patches ended up actually introducing a

Re: New predefined roles- 'pg_read/write_all_data'

Greetings, * Michael Banck (michael.ba...@credativ.de) wrote: > On Thu, Apr 01, 2021 at 04:00:06PM -0400, Stephen Frost wrote: > > diff --git a/doc/src/sgml/user-manag.sgml b/doc/src/sgml/user-manag.sgml > > index d171b13236..fe0bdb7599 100644 > > --- a/doc/src/sgml/user-man

Re: log_autovacuum in Postgres 14 -- ordering issue

Greetings, * Peter Geoghegan (p...@bowt.ie) wrote: > On Fri, Aug 27, 2021 at 12:30 PM Stephen Frost wrote: > > I don't particularly care for that explain rule, ultimately, but it's > > been around longer than I have and so I guess it wins. I'm fine with > > always s

Re: log_autovacuum in Postgres 14 -- ordering issue

Greetings, * Peter Geoghegan (p...@bowt.ie) wrote: > On Fri, Aug 27, 2021 at 11:35 AM Stephen Frost wrote: > > > BTW, I noticed one thing about the track_io_time stuff. Sometimes it > > > looks like this: > > > > > > I/O timings: > > > &

Re: log_autovacuum in Postgres 14 -- ordering issue

Greetings, * Peter Geoghegan (p...@bowt.ie) wrote: > On Wed, Aug 25, 2021 at 2:07 PM Stephen Frost wrote: > > I generally like the idea though I'm not sure about changing things in > > v13 as there's likely code out there that's already parsing that data > > and it

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Thu, Aug 26, 2021 at 01:03:54PM -0400, Stephen Frost wrote: > > Yes, we're talking about either incremental (or perhaps differential) > > backup where only the files which are actually different would be backed > > u

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Thu, Aug 26, 2021 at 12:34:56PM -0400, Stephen Frost wrote: > > * Bruce Momjian (br...@momjian.us) wrote: > > > On Thu, Aug 26, 2021 at 11:36:51AM -0400, Stephen Frost wrote: > > > > * Bruce Mo

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Aug 26, 2021 at 11:39 AM Stephen Frost wrote: > > This looks like a pretty good analysis to me. As it relates to the > > question about allowing users to specify an OID, I'd be inclined to > > allow it b

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Thu, Aug 26, 2021 at 11:36:51AM -0400, Stephen Frost wrote: > > * Bruce Momjian (br...@momjian.us) wrote: > > > On Thu, Aug 26, 2021 at 11:00:47AM -0400, Robert Haas wrote: > > > > Anyone see a flaw in th

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Aug 17, 2021 at 2:50 PM Robert Haas wrote: > > > Less sure that this is a good idea, though. In particular, I do not > > > think that you can make it work in the face of > > > alter database template1 rename to oops; > >

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Thu, Aug 26, 2021 at 11:00:47AM -0400, Robert Haas wrote: > > Anyone see a flaw in that analysis? > > I am still waiting to hear the purpose of this preservation. As long as > you don't apply the patch, I guess I will just stop asking.

Re: log_autovacuum in Postgres 14 -- ordering issue

Greetings, * Peter Geoghegan (p...@bowt.ie) wrote: > On Wed, Aug 25, 2021 at 11:42 AM Nikolay Samokhvalov > wrote: > > The last two lines are also "*** usage" -- shouldn't the buffer numbers be > > next to them? > > I agree that that would be better still -- but all the "usage" stuff >

Re: log_autovacuum in Postgres 14 -- ordering issue

Greetings, * Peter Geoghegan (p...@bowt.ie) wrote: > log_autovacuum output looks like this (as of Postgres 14): > > LOG: automatic vacuum of table "regression.public.bmsql_order_line": > index scans: 1 > pages: 0 removed, 8810377 remain, 0 skipped due to pins, 3044924 frozen > tuples: 16819838

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Aug 24, 2021 at 12:43 PM Bruce Momjian wrote: > > Yes, it is a trade-off. If we had pg_upgrade create the new cluster, > > the pg_upgrade instructions would be simpler, but pg_upgrade would be > > more complex since it has to

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Aug 23, 2021 at 5:12 PM Stephen Frost wrote: > > Regarding that ... I have to wonder just what promises we feel we've > > made when it comes to what a user is expected to be able to do with the > > new cluste

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Fri, Aug 20, 2021 at 1:36 PM Shruthi Gowda wrote: > > Thanks Robert for your comments. > > I have split the patch into two portions. One that handles DB OID and > > the other that > > handles tablespace OID and relfilenode OID. > >

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

Greetings, * Mark Dilger (mark.dil...@enterprisedb.com) wrote: > > On Aug 23, 2021, at 12:51 PM, Stephen Frost wrote: > > Simply using superuser_arg() isn't sufficient is exactly the point that > > I'm trying to make. As a 'landlord', I might very well want to have > >

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

Greetings, * Mark Dilger (mark.dil...@enterprisedb.com) wrote: > > On Aug 23, 2021, at 11:13 AM, Stephen Frost wrote: > > This I have to object to pretty strongly- we have got to get away from > > the idea that just because X isn't a superuser or isn't owned by a > >

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Aug 23, 2021 at 2:13 PM Stephen Frost > wrote:> This I have to object to pretty strongly- we have got to get > away from > > the idea that just because X isn't a superuser or isn't owned by a > > superuser

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

Greetings, * Mark Dilger (mark.dil...@enterprisedb.com) wrote: > > On Jul 22, 2021, at 1:01 PM, Robert Haas wrote: > > It's awkward. I think that we can't afford to create a separate > > predefined role for every single thing that someone could > > theoretically want to sever, because then we'll

Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Robert Haas writes: > > To me, adding a separate TOC entry for a thing that is not really a > > separate object seems like a scary hack that might come back to bite > > us. Unfortunately, I don't know enough about pg_dump to say exactly > > how

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

Greetings, * Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote: > On 2021-Jul-26, Tom Lane wrote: > > > What if we allow event triggers owned by non-superusers, but only fire > > them on commands performed by the trigger's owner? This sidesteps all > > the issues of who has which privileges and

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Jul 26, 2021 at 4:12 PM Robert Haas wrote: > > I think I may not have expressed myself clearly enough here. What I'm > > concerned about is: Alice should not be permitted to preventing Bob > > from doing something which Bob is

Re: needless complexity in StartupXLOG

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Jul 26, 2021 at 1:32 PM Stephen Frost wrote: > > Yeah, tend to agree with this too ... but something I find a bit curious > > is the comment: > > > > * Insert a special WAL record to mark the end of >

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Fri, Jul 23, 2021 at 4:57 PM Mark Dilger > wrote: > > > On Jul 23, 2021, at 1:54 PM, Robert Haas wrote: > > > Yeah, but you're inventing a system for allowing the restriction on a > > > GUC to be something other than is-superuser in

Re: needless complexity in StartupXLOG

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > So at the moment I am leaning toward the view that we should just > remove this check entirely, as in the attached, proposed patch. Haven't dug in deeply but at least following your explanation and reading over the patch and the code a

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

Greetings, * Mark Dilger (mark.dil...@enterprisedb.com) wrote: > > On Jul 23, 2021, at 6:22 AM, Robert Haas wrote: > > And I think that's a good illustration of why it's a bad idea to > > categorize things according to whether or not they have a certain > > consequence. > > Well, one very big

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Jul 1, 2021 at 11:59 AM Mark Dilger > wrote > > > On Jun 29, 2021, at 6:25 PM, Mark Dilger > > > wrote: > > > Please find attached a new set of patches. > > > > And again, this time attaching a fifth patch which includes the

Re: proposal: possibility to read dumped table's name from file

Greetings, * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > On 2021-Jul-13, Stephen Frost wrote: > > The simplest possible format isn't going to work with all the different > > pg_dump options and it still isn't going to be 'simple' since it needs > > to work with the fle

Re: proposal: possibility to read dumped table's name from file

Greetings, * Tomas Vondra (tomas.von...@enterprisedb.com) wrote: > On 7/13/21 10:55 PM, Stephen Frost wrote: > >On Tue, Jul 13, 2021 at 16:44 Daniel Gustafsson ><mailto:dan...@yesql.se>> wrote: > > > > > On 13 Jul 2021, at 18:14, Tomas V

Re: proposal: possibility to read dumped table's name from file

Greetings, On Tue, Jul 13, 2021 at 16:44 Daniel Gustafsson wrote: > > On 13 Jul 2021, at 18:14, Tomas Vondra > wrote: > > > FWIW I don't understand why would they need to write parsers. > > It's quite common to write unit tests for VM recipes/playbooks wheen using > tools like Chef etc,

Re: proposal: possibility to read dumped table's name from file

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Alvaro Herrera writes: > > [1] your proposal of "[+-] OBJTYPE OBJIDENT" plus empty lines allowed > > plus lines starting with # are comments, seems plenty. Any line not > > following that format would cause an error to be thrown. > >

Re: What are exactly bootstrap processes, auxiliary processes, standalone backends, normal backends(user sessions)?

Greetings, * Bharath Rupireddy (bharath.rupireddyforpostg...@gmail.com) wrote: > I've always had a hard time distinguishing various types of > processes/terms used in postgres. I look at the source code every time > to understand them, yet I don't feel satisfied with my understanding. > I request

Re: Support kerberos authentication for postgres_fdw

Greetings, * Magnus Hagander (mag...@hagander.net) wrote: > On Mon, Jul 12, 2021 at 5:43 AM Peifeng Qiu wrote: > > >As you note, this'd have to be restricted to superusers, which makes it > > >seem like a pretty bad idea. We really don't want to be in a situation > > >of pushing people to run

Re: .ready and .done files considered harmful

Greetings, * Dipesh Pandit (dipesh.pan...@gmail.com) wrote: > We have addressed the O(n^2) problem which involves directory scan for > archiving individual WAL files by maintaining a WAL counter to identify > the next WAL file in a sequence. This seems to have missed the concerns raised in

Re: Can a child process detect postmaster death when in pg_usleep?

Greetings, * Michael Paquier (mich...@paquier.xyz) wrote: > On Fri, Jul 02, 2021 at 12:03:07PM +0530, Bharath Rupireddy wrote: > > My bad. I was talking about the cases when do_pg_stop_backup is called > > while the server is in recovery mode i.e. backup_started_in_recovery = > >

Re: Disable WAL logging to speed up data loading

Greetings, * osumi.takami...@fujitsu.com (osumi.takami...@fujitsu.com) wrote: > On Monday, July 5, 2021 10:32 AM Michael Paquier wrote: > > On Sun, Jul 04, 2021 at 11:02:01AM -0400, Stephen Frost wrote: > > > Rather than RfC, the appropriate status seems like it should

Re: Disable WAL logging to speed up data loading

Greetings, * vignesh C (vignes...@gmail.com) wrote: > On Wed, Apr 7, 2021 at 12:13 PM osumi.takami...@fujitsu.com > wrote: > > Mainly affected by a commit 9de9294, > > I've fixed minor things to rebase the patch. > > All modifications I did are cosmetic changes and > > a little bit of

<    1   2   3   4   5   6   7   8   9   10   >