Here is the updated patch. It should fix the meson issue when no doxygen is
present.
doxygen-v3.patch
Description: doxygen-v3.patch
>> I wish you'd stop proposing the lex filter so that we can discuss the
>> Doxyfile.in file and the accompanying Meson rule.
I see no obstacle to discussing Doxyfile.in and the meson.build file. Your
suggestions are welcome. If you can find the original Doxyfile, it
would make sense to incorpora
>> It seems something you want to keep for your personal use.
>> I think this filter is the kind of genious idea that it's OK if you
>> can do it at home
I don’t agree with your characterization.
The purpose of the filter is to bring existing Postgres comments into the
doxygen output. While I ha
>> I think all the explanatory messages in doc/doxygen/meson.build
>> are a bit much. I think it's enough to just not define the target
>> when the required conditions (dependencies, options) are not there.
>> Maybe something like docs_pdf can serve as an example.
Makes sense, and it is simpler.
L
>> Maybe this is something that can be tweaked on the doxygen side?
I’ll look into that idea. Doxygen is a separate project with its own developers
to persuade. I could imagine a special “C” or “C++” mode. I wanted to keep
things simple, and the filter mechanism is how they extend doxygen to sup
>> I think all the explanatory messages in doc/doxygen/meson.build
>> are a bit much. I think it's enough to just not define the target
Here is a patch with an updated meson.build as you suggested. I agree the
messages were a bit much.
On the other hand, I would like to see clear error messages
>> We also have a handful of .cpp files.
Fortunately, our .cpp files are simple and do not include C++ specific features.
We shouldn’t have any problem adding .cpp to the filter list.
At some point it will be necessary to support general C++, but I wasn’t
planning to do it yet.
>> This file isn'
Update: another patch with 1) suggested changes, 2) delete old html before
generating new, and 3) added flex names for the more complex regular
expressions.
Exercising the “ninja doxygen” command, brought up some issues.
1. The generated html directory contained old as well as new pages.
Th
pendent of doxygen.)
I find it ironic I’ve gone from being a long-time hater of doxygen to being its
advocate.
* John Morris
Tiny tidbit of history. Back in the 70’s, I created a comment extractor for the
language Ratfor. We used it to maintain an alphabetical index of functions and
to d
Looks good to me.
* John
From: Nathan Bossart
Date: Thursday, February 29, 2024 at 8:34 AM
To: Andres Freund
Cc: Stephen Frost , John Morris
, Bharath Rupireddy
, Michael Paquier
, Robert Haas ,
pgsql-hack...@postgresql.org
Subject: Re: Atomic ops for unlogged LSN
Here is a new
c you are
currently using. I need to think about it a bit more and will get back to you
later on that.
* John Morris
complete? I don't want people to think we're imposing new
standards or legislating new commenting styles. It's more a matter of
describing what we currently do, maybe with some minor suggestions for
improving.
* John Morris
Keeping things up to date. Here is a rebased patch with no changes from
previous one.
* John Morris
atomic-lsn.patch
Description: atomic-lsn.patch
* This patch looks a little different than the last version I see posted
[0].
That last version of the patch (which appears to be just about committable)
My oops – I was looking at the wrong commit. The newer patch has already been
committed, so pretend that last message didn’t happen. Than
Here is what I meant to do earlier. As it turns out, this patch has not been
merged yet.
This is a rebased version . Even though I labelled it “v3”, there should be no
changes from “v2”.
atomicLSN-v3-Use-atomic-ops-for-unloggedLSNs.patch
Description: atomicLSN-v3-Use-atomic-ops-for-unloggedLSN
l.org , 'Bruce
Momjian' , postg...@coyotebush.net ,
John Morris
Subject: Re: Including Doxyfile and Meson script for docs into main source tree
Hi Bohdan!
I will see about making th ecurrent doxygen configuration available as a
download again in the next few days. Not sure whether there is
I incorporated your suggestions and added a few more. The changes are mainly
related to catching potential errors if some basic assumptions aren’t met.
There are basically 3 assumptions. Stating them as conditions we want to avoid.
* We should not get an unlogged LSN before reading the contr
Another update, this time with an abbreviated Doxyfile. Rather than including
the full Doxyfile, this updated version only includes modified settings. It is
more compact and more likely to survive across future doxygen versions.
* John Morris
doxygen_v2.patch
Description: doxygen_v2
>I wonder if it's worth providing a set of "locked read" functions.
Most out-of-order machines include “read acquire” and “write release” which are
pretty close to what you’re suggesting. With the current routines, we only have
“read relaxed” and “write relaxed”. I think implementing acquire/re
* So I think that code simplification and easy adoption of in-memory data
changes (such as encryption or compression) are two rather distinct goals.
admit that I'm running out of ideas how to develop a framework that'd be
useful for both.
I’m also wondering about code simplification vs a more
>> Why don't we just use a barrier when around reading the value? It's not like
>> CreateCheckPoint() is frequent?
One reason is that a barrier isn’t needed, and adding unnecessary barriers can
also be confusing.
With respect to the “debug only” comment in the original code, whichever value
is
> what happens if … reader here stores the old unloggedLSN value
> to control file and the server restarts (clean exit). So, the old
>value is loaded back to unloggedLSN upon restart and the callers of
> GetFakeLSNForUnloggedRel() will see an old/repeated value too. Is it a
> problem?
First, a c
Based on your feedback, I’ve updated the patch with additional comments.
1. Explain the two cases when writing to the control file, and
2. a bit more emphasis on unloggedLSNs not being valid after a crash.
Thanks to y’all.
* John
v2-0001-Use-atomic-ops-for-unloggedLSNs.patch
Descript
I’m a latecomer to the discussion, but as a word of introduction, I’m working
with Stephen, and I have started looking over the temp file proposal with the
idea of helping it move along.
I’ll start by summarizing the temp file proposal and its goals.
>From a high level, the proposed code:
*
This is a short patch which cleans up code for unlogged LSNs. It replaces the
existing spinlock with
atomic ops. It could provide a performance benefit for future uses of
unlogged LSNS, but for now it is simply a cleaner implementation.
0001-Use-atomic-ops-for-unloggedLSNs.patch
Description: 0
25 matches
Mail list logo
