On Wed, Apr 13, 2022 at 5:44 PM Tom Lane wrote:
> "David G. Johnston" writes:
> > The attached log is result of (while in the versioned directory, a
> sibling
> > of the git repo)
> > `../postgresql/configure`
> > `make`
> > `tree`
>
> The VPA
Hey,
I've been building in the git repo just fine but wanted to use vpath builds
so I could keep both "maked" v14 and v15 binaries around, ready to be
installed.
The attached log is result of (while in the versioned directory, a sibling
of the git repo)
`../postgresql/configure`
`make`
`tree`
st
On Wed, Apr 13, 2022 at 4:34 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Tue, Apr 5, 2022 at 8:00 PM Andres Freund wrote:
>
>> Here comes v70:
>>
>>
> One thing I just noticed while peeking at pg_stat_slru:
>
> The stats_reset column for
On Tue, Apr 5, 2022 at 8:00 PM Andres Freund wrote:
> Here comes v70:
>
>
One thing I just noticed while peeking at pg_stat_slru:
The stats_reset column for my newly initdb'd cluster is showing me
"2000-01-01 00:00:00" (v15). I was expecting null, though a non-null value
restriction does make s
On Wed, Apr 13, 2022 at 2:19 PM Peter Geoghegan wrote:
> On Wed, Apr 13, 2022 at 1:25 PM Robert Haas wrote:
> > On Wed, Apr 13, 2022 at 12:34 PM Peter Geoghegan wrote:
> > > What do you think of the idea of relating freezing to removing tuples
> > > by VACUUM at this point? This would be a basi
On Tue, Apr 12, 2022 at 5:22 PM Peter Geoghegan wrote:
> I just don't think that you need to make it any more complicated than
> this: physical XID values are only meaningful when compared to other
> XIDs from the same cluster. The system needs to make sure that no two
> XIDs can ever be more tha
On Tue, Apr 12, 2022 at 2:53 PM Peter Geoghegan wrote:
> Recent work on VACUUM and relfrozenxid advancement required that I
> update the maintenance.sgml VACUUM documentation ("Routine
> Vacuuming"). It was tricky to keep things current, due in part to
> certain structural problems. Many of these
On Sat, Apr 9, 2022 at 12:07 PM Andres Freund wrote:
>
> > ... specific counters. In particular, replay will not increment
> > pg_stat_database or pg_stat_all_tables columns, and the startup process
> > will not report reads and writes for the pg_statio views.
> >
> > It would helpful to give at
On Sat, Apr 9, 2022 at 9:27 AM Tom Lane wrote:
> "Jonathan S. Katz" writes:
> > -1, at least for the moment. Sometimes a user doesn't know what they're
> > looking for coupled with being unaware of what the default value is. If
> > a setting is set to a default value and that value is the proble
On Thu, Apr 7, 2022 at 8:59 PM Andres Freund wrote:
>
>
>Cumulative statistics are collected in shared memory. Every
>PostgreSQL process collects statistics
> locally
>then updates the shared data at appropriate intervals. When a server,
>including a physical replica, shuts do
On Thu, Apr 7, 2022 at 7:10 PM Kyotaro Horiguchi
wrote:
> At Thu, 7 Apr 2022 16:37:51 -0700, Andres Freund
> wrote in
> > Hi,
> >
> > On 2022-04-07 00:28:45 -0700, Andres Freund wrote:
> > > I've gotten through the main commits (and then a fix for the apparently
> > > inevitable bug that's immed
On Thu, Apr 7, 2022 at 9:58 AM Joe Conway wrote:
> On 4/7/22 12:37, Tom Lane wrote:
> > Mark Dilger writes:
> >>> On Apr 7, 2022, at 9:29 AM, Tom Lane wrote:
> >>> I wouldn't
> >>> fight too hard if people want to lengthen it to \dconfig for
> consistency
> >>> with set_config().
> >
> >> I'd p
On Thu, Apr 7, 2022 at 7:56 AM Tom Lane wrote:
> "Jonathan S. Katz" writes:
>
>
> Maybe to appeal to all crowds, we say "list configuration parameters
> > (GUCs)"?
>
> I'm in the camp that says that GUC is not an acronym we wish to expose
> to end users.
>
>
I am too. In any case, either go all
On Wed, Apr 6, 2022 at 6:16 PM Tom Lane wrote:
> "Jonathan S. Katz" writes:
> > I am a bit torn between "\dcp" (or \dsetting / \dconfig? we don't
> > necessarily need for it to be super short) and "\sc". Certainly with
> > pattern matching the interface for the "\d" commands would fit that
> > p
On Wed, Apr 6, 2022 at 4:12 PM Andres Freund wrote:
>
> On 2022-04-06 15:32:39 -0700, David G. Johnston wrote:
> > On Wednesday, April 6, 2022, Andres Freund wrote:
> >
> >
> > I like having the SQL function paired with a matching implementation in
> > t
On Wednesday, April 6, 2022, Andres Freund wrote:
>
>
> I'd go for
> pgstat_reset_slru_counter() -> pgstat_reset_slru()
> pgstat_reset_subscription_counter() -> pgstat_reset_subscription()
> pgstat_reset_subscription_counters() -> pgstat_reset_all_subscriptions()
> pgstat_reset_replslot_counter()
On Tue, Apr 5, 2022 at 8:14 PM Andres Freund wrote:
>
> On 2022-04-05 20:00:50 -0700, David G. Johnston wrote:
>
> * Statistics are loaded from the filesystem during startup (by the startup
> * process), unless preceded by a crash, in which case all stats are
> * discarded
On Tue, Apr 5, 2022 at 8:11 PM Greg Stark wrote:
> I've never tried to review a 24-patch series before. It's kind of
> intimidating Is there a good place to start to get a good idea of
> the most important changes?
>
It isn't as bad as the number makes it sound - I just used "git am" to
appl
On Tue, Apr 5, 2022 at 8:00 PM Andres Freund wrote:
>
> Here comes v70:
>
> I think this is basically ready, minus a a few comment adjustments here and
> there. Unless somebody protests I'm planning to start pushing things
> tomorrow
> morning.
>
>
Nothing I've come across, given my area of exper
On Tue, Apr 5, 2022 at 4:16 PM Andres Freund wrote:
> On 2022-04-05 14:43:49 -0700, David G. Johnston wrote:
> > On Tue, Apr 5, 2022 at 2:23 PM Andres Freund wrote:
>
> >
> > > I guess I should add a paragraph about snapshots / fetch consistency.
> > >
> &
On Tue, Apr 5, 2022 at 2:23 PM Andres Freund wrote:
>
> On 2022-04-05 13:51:12 -0700, David G. Johnston wrote:
>
> >, but rather add to the shared queue
>
> Queue? Maybe you mean the hashtable?
>
Queue implemented by a list...? Anyway, I think I mean this:
/*
* List
On Mon, Apr 4, 2022 at 8:05 PM Andres Freund wrote:
> - added an architecture overview comment to the top of pgstat.c - not sure
> if
> it makes sense to anybody but me (and perhaps Horiguchi-san)?
>
>
I took a look at this, diff attached. Some typos and minor style stuff,
plus trying to bring
On Tuesday, April 5, 2022, Andres Freund wrote:
> Hi,
>
> On 2022-04-05 08:49:36 -0700, David G. Johnston wrote:
> > On Mon, Apr 4, 2022 at 7:36 PM Andres Freund wrote:
> >
> > >
> > > I think all this is going to achieve is to making code more
> compli
On Mon, Apr 4, 2022 at 7:36 PM Andres Freund wrote:
>
> I think all this is going to achieve is to making code more complicated.
> There
> is a *single* non-assert use of accessed_across_databases and now a single
> assertion involving it.
>
> What would having PGSTAT_KIND_CLUSTER and PGSTAT_KIND
On Mon, Apr 4, 2022 at 3:44 PM Andres Freund wrote:
> Hi,
>
> On 2022-04-04 15:24:24 -0700, David G. Johnston wrote:
> > Replacing the existing assert(!kind->fixed_amount) with
> > assert(!kind->accessed_across_databases) produces the same result as the
> > l
On Mon, Apr 4, 2022 at 2:54 PM Andres Freund wrote:
>
> > As the existing function only handles functions and relations why not
> just
> > perform a specific Kind check for them? Generalizing to assert on
> whether
> > or not the function works on fixed or variable Kinds seems beyond its
> > pre
On Mon, Apr 4, 2022 at 2:06 PM Andres Freund wrote:
>
> > My first encounter with pg_stat_exists_stat() didn't draw my attention as
> > being problematic so I'd say we just stick with it. As a SQL user
> reading:
> > WHERE exists (...) is somewhat natural; using "have" or back-to-back
> > stat_s
On Sun, Apr 3, 2022 at 9:16 PM Andres Freund wrote:
>
> Please take a look!
>
>
I didn't take the time to fixup all the various odd typos in the general
code comments; none of them reduced comprehension appreciably. I may do so
when/if I do another pass.
I did skim over the entire patch set and
On Sun, Apr 3, 2022 at 12:36 PM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 03.04.22 20:50, David G. Johnston wrote:
> > However, tables having an identity sequence seem to be unaddressed in
> > this patch. The existing (and unchanged) pg_dump.c code
On Sun, Apr 3, 2022 at 12:36 PM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 03.04.22 20:50, David G. Johnston wrote:
> > However, tables having an identity sequence seem to be unaddressed in
> > this patch. The existing (and unchanged) pg_dump.c code
On Sun, Apr 3, 2022 at 10:19 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> Here is an updated patch that fixes this pg_dump/pg_upgrade issue and
> also adds a few more comments and documentation sentences about what
> happens and what is allowed. I didn't change any behaviors;
On Fri, Apr 1, 2022 at 9:31 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 01.04.22 18:22, Peter Eisentraut wrote:
> >
> > On 01.04.22 00:43, Tomas Vondra wrote:
> >> Hmm, so what about doing a little bit different thing:
> >>
> >> 1) owned sequences inherit persistence of th
On Fri, Apr 1, 2022 at 9:22 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
>
> On 01.04.22 00:43, Tomas Vondra wrote:
> > Hmm, so what about doing a little bit different thing:
> >
> > 1) owned sequences inherit persistence of the table by default
> >
> > 2) allow ALTER SEQUENCE t
On Thu, Mar 31, 2022 at 7:33 PM Kyotaro Horiguchi
wrote:
> At Thu, 31 Mar 2022 14:04:16 -0700, Andres Freund
> wrote in
> > Hi,
> >
> > On 2022-03-31 16:16:31 +0900, Kyotaro Horiguchi wrote:
> > > After moving to shared stats, we might want to expose the GUC variable
> > > itself. Then hide/remo
On Thu, Mar 31, 2022 at 6:03 PM Robert Haas wrote:
> On Thu, Mar 31, 2022 at 8:44 PM David G. Johnston
> wrote:
>
> > The "give the user power" argument is also valid. But since they
> already have power through unowned sequences, having the owned sequences
>
On Thu, Mar 31, 2022 at 6:03 PM Robert Haas wrote:
>
> In this new system, does the user still get a logged sequence? If they
> get an unlogged sequence, how does dump-and-restore work? What if they
> want to still have a logged sequence? But for sequences that are
> simply owned, there is no pro
On Thu, Mar 31, 2022 at 5:25 PM Robert Haas wrote:
> On Thu, Mar 31, 2022 at 10:14 AM Tomas Vondra
> wrote:
> > * When linking a sequence to a table (ALTER SEQUENCE ... OWNED BY),
> > there's an ereport(ERROR) if the relpersistence values do not match.
> >
> > * Disallow changing persistence for
On Thu, Mar 31, 2022 at 4:39 PM Bradley Ayers
wrote:
>
> I'm interested in adding more ergonomics to DDL commands, in
> particular supporting IF EXISTS for ALTER TABLE … ALTER COLUMN, so
> that if a column doesn't exist the command is skipped.
>
> IF EXISTS is already supported in various places
On Thu, Mar 31, 2022 at 3:43 PM Tomas Vondra
wrote:
> On 3/31/22 22:40, David G. Johnston wrote:
> > On Thu, Mar 31, 2022 at 1:05 PM Tomas Vondra
> > mailto:tomas.von...@enterprisedb.com>>
> > wrote:
> >
> >
> > I agree the first part is not
On Thu, Mar 31, 2022 at 1:40 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> The DBA just has to execute the ALTER SEQUENCE command on all relevant
> sequences.
>
Additional, if we do not implement the forced matching of persistence mode,
we should consider adding an &
On Thu, Mar 31, 2022 at 1:05 PM Tomas Vondra
wrote:
>
> I agree the first part is not contentious, so shall we extract this part
> of the patch and get that committed for PG15? Or is that too late to
> make such changes to the patch?
>
>
The minimum viable feature for me, given the written goal f
On Thu, Mar 31, 2022 at 12:36 PM Tomas Vondra
wrote:
> On 3/31/22 19:35, David G. Johnston wrote:
> > On Thu, Mar 31, 2022 at 9:28 AM Andres Freund > <mailto:and...@anarazel.de>> wrote:
> >
> > I agree it makes sense to have logged sequences with unlogged
On Thu, Mar 31, 2022 at 9:28 AM Andres Freund wrote:
> I agree it makes sense to have logged sequences with unlogged tables. We
> should call out the behavioural change somewhere prominent in the release
> notes.
>
>
We can/do already support that unlikely use case by allowing one to remove
the O
On Wed, Mar 30, 2022 at 1:39 PM Andres Freund wrote:
> Hi,
>
> On 2022-03-30 12:29:51 -0700, David G. Johnston wrote:
> > On Wednesday, March 30, 2022, Andres Freund wrote:
> > > My current proposal is to just have two reset times. One for the
> contents
> >
On Wednesday, March 30, 2022, Andres Freund wrote:
>
> My current proposal is to just have two reset times. One for the contents
> of
> pg_stat_database (i.e. not affected by pg_stat_reset_single_*_counters()),
> and
> one for stats within the entire database.
>
>
What IS it affected by? And doe
On Wed, Mar 30, 2022 at 9:01 AM Piotr Styczyński
wrote:
> I don’t know if this mailing list is a good place to ask this question,
> but if it’s not, just correct me.
>
pgsql-general is probably better
> *The problem:*
>
> We currently have a one-to-many function (an operation that produces
> mu
On Wed, Mar 30, 2022 at 8:46 AM Tom Lane wrote:
> I don't want to do that with
> a blunderbuss, but perhaps there's an argument to do it for specific
> cases (search_path comes to mind, though the performance cost could be
> significant, since I think setting that in function SET clauses is
> com
On Wed, Mar 30, 2022 at 8:12 AM Andrew Dunstan wrote:
>
> On 3/30/22 09:26, Tom Lane wrote:
>
> >
> > What this loses is the ability to revoke public SET permissions
> > on USERSET GUCs. I claim that that is not so valuable as to
> > justify all the complication needed to deal with it.
Agreed,
On Tue, Mar 29, 2022 at 9:00 PM Mark Dilger
wrote:
> A grant or revoke on an unrecognized custom parameter will create a SUSET
> placeholder,
[...]
> which cleans up the problem, with one exception: if the user executes a
> "revoke set on parameter some.such from public" prior to loading the
On Tue, Mar 22, 2022 at 6:52 AM Michail Nikolaev
wrote:
> Hello, Andres.
>
> > Fails to apply at the moment: http://cfbot.cputube.org/patch_37_2947.log
>
> Thanks for notifying me. BTW, some kind of automatic email in case of
> status change could be very helpful.
>
> > Marked as waiting for auth
On Tue, Mar 29, 2022 at 5:56 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Tue, Mar 29, 2022 at 5:50 PM Andres Freund wrote:
>
>> Hi,
>>
>> On 2022-03-29 17:06:24 -0700, David G. Johnston wrote:
>> > On Tue, Mar 29, 2022 at 4:43 PM A
On Tue, Mar 29, 2022 at 5:50 PM Andres Freund wrote:
> Hi,
>
> On 2022-03-29 17:06:24 -0700, David G. Johnston wrote:
> > On Tue, Mar 29, 2022 at 4:43 PM Andres Freund
> wrote:
> > > But more importantly, a
> > > per-relation/function reset field wouldn'
On Tue, Mar 29, 2022 at 5:20 PM Peter Geoghegan wrote:
> On Tue, Mar 29, 2022 at 4:55 AM Michail Nikolaev
> wrote:
>
> I think that you could do a better job of explaining and promoting the
> problem that you're trying to solve here. Emphasis on the problem, not
> so much the solution.
As a sp
On Tue, Mar 29, 2022 at 4:52 PM Greg Stark wrote:
> On Mon, 28 Mar 2022 at 16:30, Andres Freund wrote:
> >
> > > Make ON COMMIT DELETE ROWS reset relfrozenxmin and other table
> stats
> > > like normal truncate. Otherwise even typical short-lived
> transactions
> > > using temporary
On Tue, Mar 29, 2022 at 4:43 PM Andres Freund wrote:
> But more importantly, a
> per-relation/function reset field wouldn't address Tomas's concern: He
> wants a
> single thing to check to see if any stats have been reset - and that's imo
> a
> quite reasonable desire.
>
Per the original email:
On Tue, Mar 29, 2022 at 1:37 PM Andres Freund wrote:
> > Secondly, to do anything really meaningful you need to calculate deltas,
> > and be able to detect if some of the stats were reset for the particular
> > interval. And the stat_reset timestamp was designed to be a simple way
> > to detect t
On Sun, Mar 27, 2022 at 11:17 AM James Coleman wrote:
> Hmm, I didn't realize that was project policy,
Guideline/Rule of Thumb is probably a better concept.
> but I'm a bit
> surprised given that the sentence which 0001 replaces seems like a
> direct violation of that also: "In neither case
On Sun, Mar 27, 2022 at 10:00 AM James Coleman wrote:
> As shown above, table scans (and specifically table scans used to
> validate constraints, which is what this patch is about) are clearly
> documented (more than once!) in the ALTER TABLE documentation. In fact
> it's documented specifically
On Sat, Mar 26, 2022 at 4:36 PM Tom Lane wrote:
> "David G. Johnston" writes:
> > Or, we can leave it where things are and make sure the reader understands
> > there are two paths to having a NOT NULL constraint on the newly added
> > column. Something like:
>
On Sat, Mar 26, 2022 at 4:14 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
>
> I would suggest rewriting 0001 to target ALTER COLUMN instead of in the
> generic notes section (in the paragraph beginning "Adding a column with a
> volatile DEFAULT") for the d
On Sat, Mar 26, 2022 at 3:25 PM James Coleman wrote:
> On Fri, Mar 25, 2022 at 4:40 PM Robert Haas wrote:
> >
> > On Tue, Jan 25, 2022 at 8:49 AM James Coleman wrote:
> > > Here's a version that looks like that. I'm not convinced it's an
> > > improvement over the previous version: again, I exp
On Sat, Mar 26, 2022 at 1:53 AM Laetitia Avrot
wrote:
> Hello all,
>
> Le sam. 26 mars 2022 à 01:13, Michael Paquier a
> écrit :
>
>> On Fri, Mar 25, 2022 at 10:09:33PM +0100, Daniel Gustafsson wrote:
>> > Agreed. In this case it seems that adding --exclude-extension would
>> make sense
>> > to
On Fri, Mar 25, 2022 at 2:55 PM Tom Lane wrote:
> Daniel Gustafsson writes:
> >> On 25 Mar 2022, at 19:37, Tom Lane wrote:
> >> I'd vote for changing the behavior of --table rather than trying to
> >> be bug-compatible with this decision.
>
> > Agreed. Question is what to do for "-t pg_class",
On Fri, Mar 25, 2022 at 1:40 PM Robert Haas wrote:
> On Tue, Jan 25, 2022 at 8:49 AM James Coleman wrote:
> > Here's a version that looks like that. I'm not convinced it's an
> > improvement over the previous version: again, I expect more advanced
> > users to already understand this concept, an
On Friday, March 25, 2022, Tom Lane wrote:
> "David G. Johnston" writes:
> > On Fri, Mar 25, 2022 at 10:57 AM Tom Lane wrote:
> >> pg_dump never dumps system objects, so I don't see a need for
> >> a switch to tell it not to.
>
> > I consider
On Fri, Mar 25, 2022 at 10:57 AM Tom Lane wrote:
> "David G. Johnston" writes:
>
> > Except succinctly
> > omitting system objects which should get its own general option.
>
pg_dump never dumps system objects, so I don't see a need for
> a switch to tell
On Fri, Mar 25, 2022 at 9:44 AM Laetitia Avrot
wrote:
>
> Actually, I thought of it after the --schema-only flag (which is kind of
> confusing, because it won't export only schema creation DDL).
>
--schema-only is talking about the different sections of the dump file, not
namespace schema object
On Thu, Mar 24, 2022 at 5:40 PM Tom Lane wrote:
> "David G. Johnston" writes:
> > The extension object type does not seem to have gotten the
> > --exclude-extension capability that it would need to conform to the
> general
> > design exemplified by --table
On Mon, Jan 24, 2022 at 10:49 PM Michael Paquier
wrote:
> What about patterns? Switches like --table or
> --extension are able to digest a psql-like pattern to decide which
> objects to dump.
>
The extension object type does not seem to have gotten the
--exclude-extension capability that it wou
On Thu, Mar 24, 2022 at 4:42 PM Chapman Flack wrote:
> On 03/27/21 08:57, Andrew Dunstan wrote:
> > We can bikeshed the name of the flag at some stage. --procedures-only
> > might also make sense
>
> Any takers for --routines-only ?
>
> "Routine" is the genuine, ISO SQL umbrella term for a functi
On Wed, Mar 23, 2022 at 5:55 PM Andres Freund wrote:
>
> Starting with the below commit, pg_stat_reset_single_function_counters,
> pg_stat_reset_single_table_counters don't just reset the stats for the
> individual function, but also set pg_stat_database.stats_reset.
>
> commit 4c468b37a281941afd
On Tue, Mar 22, 2022 at 3:39 PM David Rowley wrote:
> On Thu, 17 Mar 2022 at 17:04, Corey Huinker
> wrote:
> > It seems like this effort would aid in implementing what some other
> databases implement via the QUALIFY clause, which is to window functions
> what HAVING is to aggregate functions.
>
On Tue, Mar 15, 2022 at 12:31 PM Mark Dilger
wrote:
>
> > On Mar 15, 2022, at 12:27 PM, Robert Haas wrote:
> >
> > - Justin Pryzby, who originally discovered the problem, prefers the
> > same behavior that I prefer long-term, but thinks Tom's behavior is
> > better than doing nothing.
> > - Mark
On Fri, Mar 11, 2022 at 8:32 AM Stephen Frost wrote:
>
> Such scripts as will break will still
> break in a pretty clear way with a clear answer as to how to fix them
> and I don't think there's some kind of data corruption or something that
> would happen.
>
>
I largely agree and am perfectly fi
On Fri, Mar 11, 2022 at 6:55 AM Robert Haas wrote:
> On Thu, Mar 10, 2022 at 5:14 PM Tom Lane wrote:
> > This seems reasonable in isolation, but
> >
> > (1) it implies a persistent relationship between creating and created
> > roles. Whether you want to call that ownership or not, it sure walks
On Thu, Mar 10, 2022 at 3:01 PM Robert Haas wrote:
> On Thu, Mar 10, 2022 at 4:00 PM David G. Johnston
> wrote:
> > I dislike changing the documented behavior of CREATEROLE to the degree
> suggested here. However, there are three choices here, only one of which
> can be
On Thu, Mar 10, 2022 at 12:58 PM Stephen Frost wrote:
> I don't think we're that far from having all of these though. To start
> with, we remove from CREATEROLE the random things that it does which go
> beyond what folks tend to expect- remove the whole 'grant any role to
> any other' stuff, rem
On Thu, Mar 10, 2022 at 12:45 PM Stephen Frost wrote:
>
> * David G. Johnston (david.g.johns...@gmail.com) wrote:
> > On Thu, Mar 10, 2022 at 11:05 AM Stephen Frost
> wrote:
>
Why not just look at the admin_option field of pg_auth_members...? I
> don't get why that
On Thu, Mar 10, 2022 at 11:05 AM Stephen Frost wrote:
> Greetings,
>
> * David G. Johnston (david.g.johns...@gmail.com) wrote:
> > On Thu, Mar 10, 2022 at 9:19 AM Stephen Frost
> wrote:
> > > * David G. Johnston (david.g.johns...@gmail.com) wrote:
> > > >
On Thu, Mar 10, 2022 at 9:19 AM Stephen Frost wrote:
> Greetings,
>
> * David G. Johnston (david.g.johns...@gmail.com) wrote:
> > On Thu, Mar 10, 2022 at 7:46 AM Robert Haas
> wrote:
> > > On Wed, Mar 9, 2022 at 4:31 PM Tom Lane wrote:
> > > > I don'
On Thu, Mar 10, 2022 at 7:46 AM Robert Haas wrote:
> On Wed, Mar 9, 2022 at 4:31 PM Tom Lane wrote:
> > I don't think we need syntax to describe it. As I just said in my
> > other reply, we have a perfectly good precedent for this already
> > in ordinary object permissions. That is: an object
On Wed, Mar 9, 2022 at 2:31 PM Tom Lane wrote:
> Robert Haas writes:
> > Well, the problem is that as far as I can see, the admin option is an
> > optional feature of membership. You can grant someone membership
> > without admin option, or with admin option, but you can't grant them
> > the adm
On Tue, Mar 8, 2022 at 7:32 PM Andres Freund wrote:
> we need a descriptive term / shorthand that
> describes the type of statistics we currently send to the stats collector.
>
> "cumulative stats subsystem"?
>
>
I'm growing fond of "cumulative". It is more precise (and restrictive)
than "metric
On Tue, Mar 8, 2022 at 6:50 PM Andres Freund wrote:
> On 2022-03-08 15:55:04 -0700, David G. Johnston wrote:
> > On Tue, Mar 8, 2022 at 1:54 PM Andres Freund wrote:
> > > One thing I'm not yet happy around the shared memory stats patch is
> > > naming. Curren
On Tue, Mar 8, 2022 at 1:54 PM Andres Freund wrote:
>
> One thing I'm not yet happy around the shared memory stats patch is
> naming. Currently a lot of comments say things like:
>
> * [...] We convert to
> * microseconds in PgStat_Counter format when transmitting to the
> collector.
>
> or
>
On Fri, Mar 4, 2022 at 2:49 AM Japin Li wrote:
> Thanks for your review. Modified.
>
Works for me. I have some additional sparks of ideas but nothing that need
hold this up.
David J.
On Thu, Mar 3, 2022 at 11:05 PM Kyotaro Horiguchi
wrote:
> But,
> anyway, IMHO, it is mere a performance tips that is not necessarily
> required in this section, or even in this documentaiotn. Addtion to
> that, if we write this for max_wal_senders, archive_mode will deserve
> the similar tips b
On Mon, Mar 7, 2022 at 1:16 PM Tom Lane wrote:
> Based on Robert's archaeological dig, it now seems that the fact that
> we have any such behavior at all was just a mistake. What would be
> lost if we drop it?
>
Probably nothing that couldn't be replaced, and with a better model, but I
do have
On Mon, Mar 7, 2022 at 11:18 AM Robert Haas wrote:
> In terms of how
>
things work today, see Joshua Brindle's email about the use of groups
> in pg_hba.conf. That is an excellent example of how removing oneself
> from a group could enable one to bypass security restrictions intended
> by the DBA
On Mon, Mar 7, 2022 at 11:18 AM Robert Haas wrote:
> On Sun, Mar 6, 2022 at 11:01 PM David G. Johnston
> wrote:
> > The example, which you moved here, then attempts to demonstrate this
> "fact" but gets it wrong. Boss became a member of peon so if you want to
> dem
On Mon, Mar 7, 2022 at 9:04 AM Tom Lane wrote:
> Just looking at it now, without having done any historical research,
>
I wonder why it is that we don't attach significance to WITH ADMIN
> OPTION being granted to the role itself. It seems like the second
> part of that sentence is effectively sa
On Mon, Mar 7, 2022 at 8:37 AM Robert Haas 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 the session user matches the
> role."
>
> Is there some use case for the behavior described in that l
On Sun, Mar 6, 2022 at 8:19 AM Robert Haas wrote:
> The choice of names in my example wasn't accidental. If the granted
> role is a login role, then the superuser's intention was to vest the
> privileges of that role in some other role, and it is surely not right
> for that role to be able to dec
On Sun, Mar 6, 2022 at 9:53 AM Tom Lane wrote:
> Robert Haas writes:
> > ... Suppose the superuser grants "admin" to both "joe" and "sally".
> > Now "joe" can SET ROLE to "admin" and revoke it from "sally", and the
> > superuser has no tool to prevent this.
>
> Really?
>
> regression=# grant adm
On Fri, Mar 4, 2022 at 1:50 PM Robert Haas wrote:
> On Mon, Feb 28, 2022 at 2:09 PM Stephen Frost wrote:
> > The ability of a role to revoke itself from some other role is just
> > something we need to accept as being a change that needs to be made, and
> > I do believe that such a change is sup
On Wed, Mar 2, 2022 at 7:44 PM Japin Li wrote:
>
> Hi, hackers
>
> When I try to change wal_level to minimal and restart the database, it
> complains
> max_wal_senders > 0.
>
> 2022-03-03 10:10:16.938 CST [6389] FATAL: WAL streaming (max_wal_senders
> > 0) requires wal_level "replica" or "logica
On Sat, Feb 26, 2022 at 5:42 AM Shay Rojansky wrote:
> FWIW I've received feedback from a SQL Server engineer that one definitely
> should *not* depend on such ordering there, and that future optimizations
> (e.g. parallel insertion of many rows) could result in row ordering which
> differs from
On Sun, Feb 20, 2022 at 10:10 PM Amit Kapila
wrote:
> On Sat, Feb 19, 2022 at 10:35 PM David G. Johnston
> wrote:
> >
> > On Sat, Feb 19, 2022 at 9:37 AM Andres Freund
> wrote:
> >>
> >> IMO the type of information you'd want for apply failures i
On Mon, Feb 21, 2022 at 2:19 AM Amit Kapila wrote:
> On Mon, Feb 21, 2022 at 1:18 PM Andres Freund wrote:
>
> > > The view name could be pg_stat_subscription_lrep,
> > > pg_stat_logical_replication, or something on those lines.
> >
> > pg_stat_subscription_stats :)
> >
>
> Having *stat* two time
On Sat, Feb 19, 2022 at 9:37 AM Andres Freund wrote:
> IMO the type of information you'd want for apply failures is substantially
>
different enough from worker failures that I don't really see the temptation
> to put them in the same table.
>
>
It's an error message and a transaction LSN in both
601 - 700 of 1043 matches
Mail list logo
