I wrote:
> Thomas Munro writes:
>> On Wed, May 13, 2020 at 3:16 AM Tom Lane wrote:
>>> Hash/Batch/Allocating
>>> Hash/Batch/Electing
>>> Hash/Batch/Loading
>>> Hash/GrowBatches/Allocating
>> Perhaps we should also drop the 'ing' from the verbs, to be more like
>> ...Read etc.
> Yeah, that aspec
On 2020-May-14, Tom Lane wrote:
> A case could be made for doing s/async/notify/ more widely in async.c;
> for instance it's odd that the struct protected by NotifyQueueLock
> didn't get renamed to NotifyQueueControl. But that seems a bit out
> of scope for the immediate problem, and anyway I'm n
I wrote:
> Digging through the existing callers of SimpleLruInit, we have
> namecontrol locksubdir
> "async" AsyncCtlLock"pg_notify"
> "clog" CLogControlLock "pg_xact"
> "commit_timestamp"
On Thu, May 14, 2020 at 3:58 PM Tom Lane wrote:
> I submit that at least part of the problem is precisely one of crappy
> naming. I didn't know what OldSerXidLock did either, until yesterday
> when I dug into the code to find out. If it's named something like
> "SerialSLRULock", then at least so
Robert Haas writes:
> That being said, my view of this system is that it's good to document
> the wait events that we have, but also that there are almost certainly
> going to be cases where we can't say a whole lot more than "go read
> the code," or at least not without an awful lot of work.
Can
On Thu, May 14, 2020 at 2:54 PM Tom Lane wrote:
> Well, we could solve this problem very easily by ripping out everything
> having to do with wait-state monitoring ... and personally I'd be a lot
> in favor of that, because I haven't seen anything about either the
> design or documentation of the
Robert Haas writes:
> I tend to prefer that modules register their own tranches rather than
> having a central table someplace, because I like the idea that the
> things that a particular module knows about are contained within its
> own source files and not spread all over the code base. I think
On Tue, May 12, 2020 at 10:54 PM Tom Lane wrote:
> I don't actually understand why the LWLock tranche mechanism is designed
> the way it is. It seems to be intended to support different backends
> having different sets of LWLocks, but I fail to see why that's a good idea,
> or even useful at all.
The attached patch doesn't actually change any LWLock names, but it
is a useful start on that project. What it does is to get rid of the
current scheme of dynamically registering the names of built-in
LWLocks in favor of having a constant array of those names. It's
completely foolish to expend pr
I looked through the naming situation for LWLocks, and SLRUs which turn
out to be intimately connected to that, because most of the dubious
LWLock names we're currently exposing actually are derived from SLRUs.
Here's some ideas (not quite a full proposal yet) for changing that.
Note that because
Isaac Morland writes:
> ... I'm wondering because it seems
> like it might be helpful to have a system view which gives all the wait
> event types, names, and descriptions. Maybe even add a column for which
> extension (or core) it came from. The documentation could then just explain
> the genera
Thomas Munro writes:
> On Wed, May 13, 2020 at 3:16 AM Tom Lane wrote:
>> Hash/Batch/Allocating
>> Hash/Batch/Electing
>> Hash/Batch/Loading
>> Hash/GrowBatches/Allocating
> Perhaps we should also drop the 'ing' from the verbs, to be more like
> ...Read etc.
Yeah, that aspect was bothering me t
On Wed, May 13, 2020 at 3:16 AM Tom Lane wrote:
> And then somebody else, unwilling to use either of those styles,
> thought it would be cute to do
>
> Hash/Batch/Allocating
> Hash/Batch/Electing
> Hash/Batch/Loading
> Hash/GrowBatches/Allocating
Perhaps we should
On Tue, 12 May 2020 at 18:11, Tom Lane wrote:
> Alvaro Herrera writes:
> > (Didn't we have a patch to generate the table programmatically?)
>
> Having now looked around a bit at where the names come from, I think
> such a patch would be impossible as things stand, which is a pity
> because as-th
For the specific category of the heavyweight lock types, I'm
now thinking that we can't change the event names very much, because
those are also exposed in pg_locks' locktype column. We can be
darn certain, for example, that changing the spelling of "relation"
in that column would break a lot of u
Alvaro Herrera writes:
> (Didn't we have a patch to generate the table programmatically?)
Having now looked around a bit at where the names come from, I think
such a patch would be impossible as things stand, which is a pity
because as-things-stand is a totally unmaintainable situation.
Anybody a
On Tue, 12 May 2020 at 21:00, Tom Lane wrote:
> Simon Riggs writes:
> > On Tue, 12 May 2020 at 19:11, Tom Lane wrote:
> >> Anyway, I was just throwing this idea out to see if there would be
> >> howls of "you can't rename anything" anguish. Since there haven't
> >> been so far, I'll spend a bi
Robert Haas writes:
> On Tue, May 12, 2020 at 4:00 PM Tom Lane wrote:
>> Said user-facing documentation largely fails to explain that the
>> set of wait events can be enlarged by extensions; that needs to
>> be fixed, too.
> Is that true? How can they do that? I thought they were stuck with
> PG
Robert Haas writes:
> On Tue, May 12, 2020 at 11:16 AM Tom Lane wrote:
>> I've been trying to reformat table 27.4 (wait events) to fit
>> into PDF output, which has caused me to study its contents
>> more than I ever had before.
> That reminds me that it might be easier to maintain that table if
On Tue, May 12, 2020 at 8:16 AM Tom Lane wrote:
> I'm not sure what our stance is on version-to-version consistency
> of these names, but I'd like to think that we are not stuck for
> all time with the results of these random coin tosses.
These names are fundamentally implementation details, and
On 2020-May-12, Robert Haas wrote:
> That reminds me that it might be easier to maintain that table if we
> broke it up into one table per major category - that is, one table for
> lwlocks, one table for IPC, one table for IO, etc. - instead of a
> single table with a row-span number that is large
On Tue, May 12, 2020 at 11:16 AM Tom Lane wrote:
> I've been trying to reformat table 27.4 (wait events) to fit
> into PDF output, which has caused me to study its contents
> more than I ever had before.
That reminds me that it might be easier to maintain that table if we
broke it up into one tab
On Tue, May 12, 2020 at 4:00 PM Tom Lane wrote:
> Said user-facing documentation largely fails to explain that the
> set of wait events can be enlarged by extensions; that needs to
> be fixed, too.
Is that true? How can they do that? I thought they were stuck with
PG_WAIT_EXTENSION.
--
Robert H
> There are a lot of other things that seem inconsistent, but I'm not sure
> how much patience people would have for judgment-call renamings. An
> example is that "ProcSignalBarrier" is under IO, but why? Shouldn't it
> be reclassified as IPC?
Hmm, that seems like a goof.
> Other than that, *al
Simon Riggs writes:
> On Tue, 12 May 2020 at 19:11, Tom Lane wrote:
>> Anyway, I was just throwing this idea out to see if there would be
>> howls of "you can't rename anything" anguish. Since there haven't
>> been so far, I'll spend a bit more time and try to create a concrete
>> list of possib
On Tue, 12 May 2020 at 19:11, Tom Lane wrote:
> Anyway, I was just throwing this idea out to see if there would be
> howls of "you can't rename anything" anguish. Since there haven't
> been so far, I'll spend a bit more time and try to create a concrete
> list of possible changes.
>
If we add
"Andrey M. Borodin" writes:
> 3. I think names observed in wait_event and wait_event_type should not
> duplicate information. i.e. "XidGenLock" is already "LWLock".
Yeah, I'd been wondering about that too: we could strip the "Lock" suffix
from all the names in the LWLock category, and make pg_st
> 12 мая 2020 г., в 20:16, Tom Lane написал(а):
>
> Thoughts?
>
I've been coping with cognitive load of these names recently. 2 cents of my
impressions:
1. Names are somewhat recognisable and seem to have some meaning. But there is
not so much information about them in the Internet. But I
On Tue, May 12, 2020 at 11:16 AM Tom Lane wrote:
> My inclination is to propose that we settle on the first style
> shown above, which is the majority case now, and rename the
> other events to fit that. As long as we're breaking compatibility
> anyway, I'd also like to shorten one or two of the
I've been trying to reformat table 27.4 (wait events) to fit
into PDF output, which has caused me to study its contents
more than I ever had before. The lack of consistency, or
even any weak attempt at consistency, is not just glaring;
it's embarrassing.
We have a lot of wait event names like the
30 matches
Mail list logo
