%params instead
of %parameters, so perhaps this should be changed as well in the
description?
Both are my things. Thanks in advance if you wish to take care of
this by yourself..
--
Michael
signature.asc
Description: PGP signature
definitions of the
callbacks being incorrect.
It would be nice to plant a bit more InjectionPointCallback around
these callback declarations, actually. I'll look into that later.
I have now applied all that and closed the open item, keeping an eye
on the buildfarm in case.
--
Michael
On Fri, May 09, 2025 at 10:48:45AM +0900, Michael Paquier wrote:
> Thanks for the input. Will proceed if there are no objections, then.
By the way, Greg, v2-0003 in the patch set you have posted was
incorrect; it missed most of the wanted changes to get rid of the
workarounds in the AIO c
to match with the internals of pg_stat_statements as far as I
recall. Doing the same here would not hurt, but it may be better
depending on the cases to rely on a start/end. I suspect that
switching from one to the other should not change much the internal
squashing logic.
--
Michael
sign
be possible to
salvage some of it for the back branches, but I'm not clear if this
would be possible yet. That would be nice, but we'll see.
--
Michael
signature.asc
Description: PGP signature
hanks for the input. Will proceed if there are no objections, then.
--
Michael
signature.asc
Description: PGP signature
th more cases, including expressions,
parameters and sublinks, with checks on pg_stat_statements.calls to
see how the counters are aggregated. That's going to be important
when people play with this code to track how things change when
manipulating the element jumbling. I'd suggest to do that separately
of the rest.
--
Michael
signature.asc
Description: PGP signature
ng these tests across
branches.
Have others an opinion to offer here?
--
Michael
signature.asc
Description: PGP signature
lookup. Did you cross-check with the
information that IWYU generates? Do we have some consistency?
All that is potential work for v19, of course.
--
Michael
signature.asc
Description: PGP signature
d catch. It looks like I've fat-fingered the tag in
97957fdbaa42. The suggested patch looks OK here.
--
Michael
signature.asc
Description: PGP signature
till around, but I'm equally worrying about the loss of information
for CLOSE that this new normalization would imply. Perhaps my worries
don't have a reason to exist here and I'm just a naturally-pessimistic
being.
--
Michael
signature.asc
Description: PGP signature
at seems necessary to have when going through
jumbleElements().
--
Michael
signature.asc
Description: PGP signature
On Wed, May 07, 2025 at 11:40:14AM +0300, Nikita Malakhov wrote:
> Michael, what do you think of this approach (extending varatt_external)
> vs extending varatt itself by new tag and structure?
I'm reserved on that. What I'm afraid here is more complications in
the backend code
e the in-memory comparisons, and
noted two things:
- check-world was OK.
- a pg_upgrade'd instance with a regression database seems kind of
OK, but I've not done that much in-depth checking on this side so I
have less confidence about that.
--
Michael
signature.asc
Description: PGP signature
gain soon.
Thanks, for both things.
--
Michael
signature.asc
Description: PGP signature
comes
wrong.
Shouldn't we have a new struct portion in varattrib_4b's union for
this purpose at least (I don't recall that we rely on varattrib_4b's
size which would get larger with this extra byte for the new extended
data with the three bits set for the compression are set in
va_extinfo, correct me if I'm wrong here).
--
Michael
signature.asc
Description: PGP signature
ect.
Adjusted these two as well, applied the result.
--
Michael
signature.asc
Description: PGP signature
is an artifact from one of the original versions
of the patch compared to what has been committed when this feature has
been discussed. Corey?
--
Michael
signature.asc
Description: PGP signature
* even take heavyweight locks. There can be only one of each of these
> - * running at a time.
> + * running at a time, except for IO worker.
Right. Perhaps this should say "IO workers", no?
--
Michael
signature.asc
Description: PGP signature
ted to
the dump of subscriptions, where we could switch the queries to the
new grammar for backend versions able to support the new grammar,
meaning that we could remove entirely these parts in 11~12 years once
the versions that do not support the new reg shortcut would be out of
scope. :D
--
Micha
d/CACJufxF9hqyfmKEdpiG%3DPbrGdKVNP2BQjHFJh4q6639sV7NmvQ%40mail.gmail.com
(FWIW, I've seen assumptions around the detection of specific
locations done outside the parser in pg_hint_plan as well, that did
not finish well because the code makes assumptions that natural
parsers are just better at because they&#
that I would the check there, as that's safer in the long-run
to enforce the rule to all potential callers of this API. If the
votes balance in favor of keeping it in the SQL function, that's OK by
me as well, so feel free to ignore me if you feel strongly about it
overall.
--
Michael
sig
conclude that tracking this information through
the parser based on the start and end positions in a query string
for a set of values is more relevant, then we would be redesigning the
facility from the ground, so the old approach would not be really
relevant..
--
Michael
signature.asc
Descrip
t; code from the tree when implementing their
own extensions.
--
Michael
signature.asc
Description: PGP signature
m lwlock,
> custom waitevent, and custom EXPLAIN option etc.
Yeah, agreed with the search_path concerns. We are getting better at
making areas of Postgres more pluggable lately, having a loading path
where we don't have any of these potential issues by design matters.
--
Michael
signature.asc
Description: PGP signature
really leaning towards that we should revert this feature as the
> limitation we have now with parameters is a rather large one and I think
> we need to go back and address this issue.
I am wondering if this would not be the best move to do on HEAD.
Let's see where the discussion drives
the named case with an extra boolean
field, for example. I would suggest to add some tests for CLOSE ALL
anyway; we don't have any currently.
--
Michael
signature.asc
Description: PGP signature
d be also cheaper
than going through all the elements in the list, tweaking things when
dealing with a subquery..
The PARAM_EXTERN part has been mentioned a couple of weeks ago here,
btw:
https://www.postgresql.org/message-id/CAA5RZ0tu6_KRiYJCFptf4_--wjFSu9cZMj1XNmOCqTNxu=v...@mail.gmail.com
--
Michael
signature.asc
Description: PGP signature
such
patterns, because this is enforcing assumptions directly hidden to the
callers.
--
Michael
signature.asc
Description: PGP signature
econds. (This
+ includes the time spent sleeping due to cost-based delay.)
Hmm, okay, adding this information to these four new fields is fine
here, so I'll apply that on HEAD shortly. I can see that this matches
with the style used for some of the other fields, like n
e need a
point much earlier than the startup process beginning any redo
activity, so I don't think that this would be useful.
--
Michael
signature.asc
Description: PGP signature
t.
Thanks,
[1]: https://www.postgresql.org/message-id/z_xyka21kyleh...@paquier.xyz
--
Michael
From daf866a6584e24bd69f4fa126ae1799f1ba0c912 Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Tue, 22 Apr 2025 12:59:30 +0900
Subject: [PATCH 1/3] Add InjectionPointList() to retrieve list of injectio
nverted to the table's columns, an
> error is raised.
That depends. If the code can be made more verbose with more details
depending on the error path reached without blowing up the whole COPY,
knowing more about the incorrect state of a row without extending
ON_ERROR with a new mode seem
tion_origin_create(), while replorigin_create() is the one
that actually matters. While it is true that these restrictions are
enforced for the current callers in core, it could also be called by
stuff outside of core. It seems important to me to let these
potential callers know about the restr
KHC%2BqCJvzCRVCpY%40paquier.xyz
I agree with applying that to v18 now and treat it as a defect rather
than wait for v19 and treat this patch as a new feature. Bonus points
for the patch being straight-forward.
--
Michael
signature.asc
Description: PGP signature
needs to look up at the SQL function's data.
--
Michael
signature.asc
Description: PGP signature
On Sat, Apr 26, 2025 at 08:31:32AM +, Bertrand Drouvot wrote:
> On Sat, Apr 26, 2025 at 04:42:56PM +0900, Michael Paquier wrote:
>> Splitting the values
>> of the wait classes into their own header makes sense, but the header
>> name wait_class_constants.h sounds a bit of
ses.h" that gets included by wait_event.h and
wait_event_types.h?
--
Michael
signature.asc
Description: PGP signature
varatt more extensible with
plain zstd support first, because diving in all these details. We are
going to need it anyway.
[1]: https://facebook.github.io/zstd/zstd_manual.html#Chapter10
--
Michael
signature.asc
Description: PGP signature
doing that. Note that I'm not planning to do anything here
for v18 now that we are in feature freeze, these would be for v19 once
the branch opens.
--
Michael
signature.asc
Description: PGP signature
On Wed, Apr 23, 2025 at 04:13:14PM +0900, Michael Paquier wrote:
> The tweak for psql_fails_like() was kind of independent of the rest of
> the fix, so I have applied that as a commit of its own. I am not
> convinced about the addition of a 4th test where we use the queries
> wit
heck based on the kind ID should be enough, because this ensures
that we'll have the PgStat_KindInfo to rely on. So stable branches
are OK as they are.
--
Michael
signature.asc
Description: PGP signature
have applied that as a commit of its own. I am not
convinced about the addition of a 4th test where we use the queries
with semicolons without a \getresults between the sync and the end.
--
Michael
From 2641356ffacc0c69779a6252a8072f41521c0f3f Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date:
the
assertion down to v15.
--
Michael
signature.asc
Description: PGP signature
ttached if the build uses USE_INJECTION_POINTS.
--
Michael
From 53447da561a03afa7e162c2bd478f3b76f984209 Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Tue, 22 Apr 2025 12:59:30 +0900
Subject: [PATCH v4 1/2] Add InjectionPointList() to retrieve list of injection
points
This hides the inter
On Mon, Apr 21, 2025 at 12:10:51PM +, Hayato Kuroda (Fujitsu) wrote:
> Thanks for suggesting them. ISTM, you are correct. PSA updated version.
Thanks, I've applied some slight tweaks, and applied the result down
to v17, leaving the heap_update point alone.
--
Michael
signa
On Mon, Apr 21, 2025 at 03:22:28PM +0900, Michael Paquier wrote:
> Anyway, I don't think that there is much we can do under a
> PGRES_FATAL_ERROR in this code path when discarding the pipe results.
> As far as I can tell, the server has failed the query suddenly and the
> whole
this lacks a reference regarding the end of a transaction. Perhaps
something like "end-transaction-process-inval" would be better?
--
Michael
signature.asc
Description: PGP signature
for more
advanced options with the compression methods in the shape of dicts or
more requirements linked to other compression methods, but I think the
topic is complex enough that we should make sure that these basics are
implemented in a way sane enough so as we'd be able to extend them
with
On Wed, Apr 16, 2025 at 09:18:01AM -0700, Michael Paquier wrote:
> On Wed, Apr 16, 2025 at 09:31:59PM +0700, a.kozhemyakin wrote:
>> After commit 2cce0fe on master
>>
>> ERROR: unexpected message type 0x50 during COPY from stdin
>> CONTEXT: COPY psql_pipeline,
ith the new sub-section for the extended protocol
versions.
There is still one pending item for the assertion failure, registered
as an open item.. I'll catch up with that soon.
--
Michael
signature.asc
Description: PGP signature
w I/O and backend flush calls.
pg_stat_io has been added in v16, but isn't that something that could
be reached even today down to v15? For example, imagine the case of a
background worker that does periodic stats reports with interactions
on existing stats. pgstats stored in shmem has been a
s.
Thanks for sharing the command able to spot all these.
--
Michael
signature.asc
Description: PGP signature
On Wed, Apr 16, 2025 at 03:25:19PM -0700, Michael Paquier wrote:
> If anybody objects about the points getting renamed here, please let
> me know.
Applied this one as 114f7fa81c72.
--
Michael
signature.asc
Description: PGP signature
ch with the
reality. I've checked all these, and they're good for me.
> GIN_TUPLE_ -> GIN_TUPLE_H
This one is interested. It should be harmless in practice, but it
could cause conflicts in theory.
--
Michael
signature.asc
Description: PGP signature
what Alexander has sent
because what EndCompressorZstd() not doing what the other methods do
makes no sense. Perhaps you are already on it, Daniel?
--
Michael
signature.asc
Description: PGP signature
CPR01MB14966.jpnprd01.prod.outlook.com
Thanks, I'll check that.
If anybody objects about the points getting renamed here, please let
me know.
--
Michael
signature.asc
Description: PGP signature
On Mon, Apr 14, 2025 at 04:05:40AM -0400, Andres Freund wrote:
> On 2025-04-14 16:46:22 +0900, Michael Paquier wrote:
>> We are still in early April, and I'd like to propose a cleanup of the
>> AIO code on HEAD, even if we are post-feature freeze, to not release
>> t
On Tue, Apr 15, 2025 at 02:34:50PM -0700, Noah Misch wrote:
> On Fri, Feb 21, 2025 at 11:33:41AM +0900, Michael Paquier wrote:
> commit 41625ab wrote:
>> * \syncpipeline queues a synchronisation request, without flushing the
>> commands to the server, equivalent of
tedPipelineResults: Assertion `res == ((void
> *)0) || result_status == PGRES_PIPELINE_ABORTED' failed.
> Aborted (core dumped)
Reproduced here, thanks for the report. I'll look at that at the
beginning of next week, adding an open item for now.
--
Michael
signature.asc
Description: PGP signature
our head a little. It's just that the
whole thing would be a really big step for Postgres, maybe similar to
deciding we want in-core replication way back when.
Michael
ng something.
> Also, should we define pg_get_injection_points in the injection_points
> extension maybe?
As this is global for all libraries, that's not something I would add
there.
--
Michael
signature.asc
Description: PGP signature
the fuzzy reply, I cannot dive into all the details now,
that's just a quick take on the matter so I may be wrong with my
assumptions.)
--
Michael
signature.asc
Description: PGP signature
first patch anyway.
--
Michael
From d738943616f1af8fc2ce1d309a3b7a0b77f29a22 Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Tue, 15 Apr 2025 14:40:30 +0900
Subject: [PATCH v3 1/2] Add InjectionPointList() to retrieve list of injection
points
This hides the internals of the shmem array lookup
injection-points is not used.
--
Michael
signature.asc
Description: PGP signature
hould not use "idx"
> for
> the result array - PSA the fix.
Oops. That's a brain fart from my side. Thanks.
--
Michael
From ee033a0f883d52638cc9c90b9c0eff29b9dde5a5 Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Tue, 15 Apr 2025 08:39:36 +0900
Subject: [PATCH v2] Ad
yway, would you like to propose a patch for the documentation?
--
Michael
signature.asc
Description: PGP signature
0001.
The CI is passing. Thoughts and comments are welcome.
--
Michael
From 7e8453987d127144477a8e7e9fa7ae61e48091be Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Mon, 14 Apr 2025 16:24:18 +0900
Subject: [PATCH 1/3] Add support for runtime arguments in injection points
The mac
On Mon, Apr 14, 2025 at 01:24:30PM +0900, Michael Paquier wrote:
> IMO, we ought to clean up the way the AIO code does its tests with
> injection point with something like the patch of this thread. And
> perhaps even do it in v18 to have the code in a cleaner state at
> release. I&#x
Hi all,
(well, Andres)
93bc3d75d8e1 has introduced a couple of new injection points, but
these don't follow the convention in-place where points are named
more-or-less-like-that. Please find attached a patch to make all
these more consistent.
Thoughts or comments?
--
Michael
diff --git
On Wed, Feb 05, 2025 at 09:19:22AM +0900, Michael Paquier wrote:
> On Mon, Feb 03, 2025 at 09:30:33PM -0800, Jeff Davis wrote:
>> One extra benefit of supporting arguments is that it would be a more
>> flexible way to change the local state around the injection point.
>> Righ
, but I am sending an independent patch
as this stuff is useful on its own.
The patch includes a couple of tests and some documentation.
Thanks,
--
Michael
From 8865e2ca3b1b6291e94d2a5476926095245a4e2f Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Mon, 14 Apr 2025 09:26:52 +0900
Subject: [
On Sun, Apr 13, 2025 at 11:51:57AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > Tom and Michael, do you still object to the test addition, or not? If there
> > are no new or renewed objections by 2025-04-20, I'll proceed to add the
> > test.
>
> While I sti
that's a start.
--
Michael
signature.asc
Description: PGP signature
s for the fsync stats are not being exercised in
> the buildfarm.
One thing I fear here is the impact for animals with little capacity,
like PIs and the like. On the other hand, I could just switch one of
my animals to use fsync = on on at least one branch.
--
Michael
signature.asc
Description: PGP signature
On Fri, Apr 11, 2025 at 01:26:04PM -0700, Jonathan S. Katz wrote:
> Please join us in wishing Jacob much success and few reverts!
Congratulations and welcome, Jacob!
May your path lead to a peaceful buildfarm and few reverts.
--
Michael
signature.asc
Description: PGP signature
tedly taken.
FWIW, I'm with these changes to delay these initializations as you are
proposing. The RMT has a say about such changes post feature-freeze,
though, even if the one in pg_overexplain.c is new to v18.
--
Michael
signature.asc
Description: PGP signature
xt commit fest that will begin in
July, this refactoring proposal is too late to be considered for v18.
--
Michael
signature.asc
Description: PGP signature
at is intentional to reduce the amount of duplication
in the docs regarding this level of details to one place: the section
that describes in details the internals of the WAL I/O activity.
--
Michael
signature.asc
Description: PGP signature
ncs? This translates to the attached, which
is the same as your patch, but this is more consistent with the code.
--
Michael
From c4c8993275e27cc5fde38f4d24ad223beb2debd4 Mon Sep 17 00:00:00 2001
From: Sami Imseih
Date: Fri, 11 Apr 2025 13:16:28 +0900
Subject: [PATCH v2] Fix stats.sql test for system
On Thu, Apr 10, 2025 at 12:55:54PM +0300, Maksim.Melnikov wrote:
> On 10.04.2025 12:15, Michael Paquier wrote:
>> Hmm, yeah. Instead of last, it would be better to put it in second
>> place perhaps, for clarity? That would be the same at the end, but we
>> would be slightly
I'm OK with how things are on HEAD.
--
Michael
signature.asc
Description: PGP signature
e of the test as there is enough activity happening
between the resets and the poll check. So, done down to v16.
--
Michael
signature.asc
Description: PGP signature
On Tue, Apr 08, 2025 at 01:26:59AM -0400, Tom Lane wrote:
> +1. When I saw the patch I was mainly afraid that pgindent would
> make a hash of it.
Yes. I was actually surprised to see that it did not mess up with the
code generated.
--
Michael
signature.asc
Description: PGP signature
u think?
Hmm, yeah. Instead of last, it would be better to put it in second
place perhaps, for clarity? That would be the same at the end, but we
would be slightly more consistent with the past logic regarding the
ordering. Does that look OK to you?
--
Michael
From b3b43a7eff2fd83a118cab13b99acd6cc8
FWIW, I think that living with the current
state of things to limit backpatch pain is fine. There is no need to
change the existing code as an attempt to apply more standardization
even if one or more code grammar patterns mean the same thing.
--
Michael
signature.asc
Description: PGP signature
like to think that we are OK here, still this information is free to
have and it could be useful if we still have problems. A custom
message WAL record is overdoing in it a bit, IMO, an elog() with the
LSN returned should be enough.
--
Michael
signature.asc
Description: PGP signature
s been the origin of
some spurious failures in the buildfarm. I cannot point my finger to
a particular one now, but it would not go unnoticed especially on the
slow animals..
What do you think?
--
Michael
From f60a004116bc21440b8769c75f11126ac4ef667f Mon Sep 17 00:00:00 2001
From: Michael Paquier
Da
er TAP tests; these rely on check_extension()
and $ENV{enable_injection_points}.
--
Michael
signature.asc
Description: PGP signature
the injection point skip-log-running-xacts for
other tests, and I suspect that there will be some as the standby
snapshots can be really annoying in tests where we want a predictible
set of WAL records when wal_level is "replica" or "logical".
--
Michael
signature.asc
Description: PGP signature
DATALEN. The restriction
suggested by Nathan at 512 bytes should be plenty enough.
> This additional TOAST table has no or rare use. +1 for removing it. It is one
> less file, one less table and one less index; in short, one less source of
> data
> corruption. ;)
I guess that's th
e strings given in input.
--
Michael
signature.asc
Description: PGP signature
faster as well.
Nice.
--
Michael
signature.asc
Description: PGP signature
future improvements at this stage.
--
Michael
signature.asc
Description: PGP signature
n that we should think
more carefully about the interface to provide here, and not rush
things.
--
Michael
signature.asc
Description: PGP signature
avoid the generation of these files. Note that
delete_old_cluster.sh would be left around even if not using a VPATH
build with ./configure (your commit message does not mention that).
Even if .gitignore discards it, the file is here.
--
Michael
signature.asc
Description: PGP signature
%d", num_db_restore);
> ~~~
>
> The attached patch fixes that issue.
Nice catch. I'll go fix this one.
--
Michael
signature.asc
Description: PGP signature
here is a version 7 with all that included, which is
simpler to read.
--
Michael
From 9f6dadc679cdc0da7c005d005a06dad6e81020ad Mon Sep 17 00:00:00 2001
From: Bertrand Drouvot
Date: Tue, 25 Feb 2025 10:18:05 +
Subject: [PATCH v7] Flush the IO statistics of active walsenders
The walsender doe
On Thu, Apr 03, 2025 at 12:36:59AM +0900, Ryo Kanbayashi wrote:
> I'll reflect your notice and suggestion to the patch current I'm
> working on :)
Thanks for that.
And I have forgotten to add you as a reviewer of what has been
committed as 2c7bd2ba507e. Sorry for th
as you have proposed, mostly, and I have added more
documentation explaining the idea behind the dummy node.
--
Michael
signature.asc
Description: PGP signature
1 - 100 of 2303 matches
Mail list logo
