On Sun, Jul 20, 2025 at 10:13 AM Michael J. Baars
wrote:
>
> On Sat, Jul 19, 2025 at 5:36 PM Tom Lane wrote:
> >
> > "Michael J. Baars" writes:
> > > Compiling from source with a default ./configure --prefix=/usr/local
> > > solves the problem.
&g
On Sat, Jul 19, 2025 at 5:36 PM Tom Lane wrote:
>
> "Michael J. Baars" writes:
> > Compiling from source with a default ./configure --prefix=/usr/local
> > solves the problem.
>
> Cool. I confess I have no idea what the triggering difference
> was, because t
On Fri, Jul 18, 2025 at 4:09 PM Tom Lane wrote:
>
> "Michael J. Baars" writes:
> > Somewhere in between release 16.3 and
> > release 16.9, changes must have been implemented that make the execution
> > engine about two times slower than it was.
>
> That
On Fri, Jul 18, 2025 at 4:09 PM Tom Lane wrote:
>
> "Michael J. Baars" writes:
> > Somewhere in between release 16.3 and
> > release 16.9, changes must have been implemented that make the execution
> > engine about two times slower than it was.
>
> That
On Fri, Jul 18, 2025 at 4:12 PM Tom Lane wrote:
>
> "Michael J. Baars" writes:
> > I receive data from a data provider on a daily basis, and noticed how they
> > use fixed type floating point in text mode, to transmit data. As you might
> > know, this type of tr
only if regression tests are failed and
> both primary and standby are alive.
This one looks acceptable to me, so applied to begin with something,
splitting things into two pieces for clarity with some tweaks. I have
changed things to use system_log() at the end, with fat-commas to link
the long options and their arguments.
--
Michael
signature.asc
Description: PGP signature
hat for the basics you should
just need 0003, 0004, the parts with the GUC to switch the TOAST table
type and the dump/restore/upgrade bits.
--
Michael
signature.asc
Description: PGP signature
Hello fellow PostgreSQL users and developers,
I installed a new Fedora release last week and ran into a peculiar problem:
Each night I need to run computations through about 70.000 rows and using
release 16.3 that took about 4 hours to complete, but using release 16.9
the same computations now ta
Hi,
I receive data from a data provider on a daily basis, and noticed how
they use fixed type floating point in text mode, to transmit data. As
you might know, this type of transmission is not lossless.
Because the PostgreSQL binary format is not very portable across
different database providers,
Hi,
I receive data from a data provider on a daily basis, and noticed how they
use fixed type floating point in text mode, to transmit data. As you might
know, this type of transmission is not lossless.
Because the PostgreSQL binary format is not very portable across different
database providers,
On Wed, Jul 16, 2025 at 02:04:12PM +0300, Aleksander Alekseev wrote:
> Hi Michael,
>
> > depending on what's set in a URI. I think that we need to redesign a
> > bit ecpg_strdup(), perhaps by providing an extra input argument so as
> > we can detect hard failur
has some coverage.
A second thing is AdjustUpgrade.pm, which has the matview compressmv
with a qual based on cmdata1, but I think we're OK as this is an
adjustment of the upgrade dumps for 74a3fc36f314, which exists in
v16~. I'll keep an eye on the buildfarm anyway, in case something
shows up.
--
Michael
signature.asc
Description: PGP signature
gt; As a way to prevent this to occur we might want to add extra input file(s)
> parameter to generate-wait_event_types.pl (as proposed in [1]).
>
> [1]:
> https://www.postgresql.org/message-id/flat/aDQdDhcwMHjZRhSV%40ip-10-97-1-34.eu-west-3.compute.internal
That's the second
On Wed, Jul 16, 2025 at 02:32:53PM +0300, Nazir Bilal Yavuz wrote:
> On Wed, 16 Jul 2025 at 04:39, Michael Paquier wrote:
>> Hmm. Is that actually useful as we know that the standby has been
>> stalen down when running the test? Even if we report something, we
>> could a
ons, we have been using MultiXactOffsetSLRU (documented), not
MultixactOffsetSLRU. So there is some history here.
--
Michael
signature.asc
Description: PGP signature
, because that's
what I guess we would use as common point for all the sub-functions
when joining them.
--
Michael
signature.asc
Description: PGP signature
On Wed, Jun 11, 2025 at 11:42:02AM +0900, Michael Paquier wrote:
> The split of the tests is not completely clean as presented in your
> patch, though. Your patch only does a copy-paste of the original
> file. Some of the basic tests of compression.sql check the
> interactions betwee
se we think it's good enough?
The fact that we expect the primary and the standby to be alive once
the tests are run and the addition of two tests related to them seems
unrelated to the diff report improvements, so I'd suggest to do both
things separately.
--
Michael
signature.asc
Description: PGP signature
m benefits. We still have
default_with_oids in guc_tables.c, for example. That's a nobrainer to
keep it in the GUC tables, and we avoid breaking the world.
--
Michael
signature.asc
Description: PGP signature
ad. Nathan has
proposed a patch set there.
--
Michael
signature.asc
Description: PGP signature
as a "temporary" anchor in a session, has more benefits
IMO, particularly more if the connections have a rather higher
turnover.
--
Michael
signature.asc
Description: PGP signature
ill good enough without it.
>> With all that said, I'll move on with this stuff once the embargo for
>> v18 beta2 is lifted and the tag is pushed. That should happen in 24h
>> or so, I guess.
>
> The provided patches looks good to me.
Thanks for the reviews!
--
Michael
signature.asc
Description: PGP signature
s as
the join search hook is far from being the most popular one AFAIK.
So dropping the item and do nothing is a fine answer.
--
Michael
signature.asc
Description: PGP signature
mitted by
> me.
>
> Anyway, please, hold on pushing this for ~1 day to let me do final
> review of this.
If you want to apply all of this yourself, please feel free, of
course.
--
Michael
signature.asc
Description: PGP signature
On Mon, Jul 14, 2025 at 04:03:42PM +0300, Aleksander Alekseev wrote:
> Hi Michael,
>
> > Should we actually check sqlca_t more seriously if failing one of the
> > strdup calls used for the port, host, etc. when attempting the
> > connection? The ecpg_log() assumes th
enerated before the checkpoint is completed, leading to the same
result.
With all that said, I'll move on with this stuff once the embargo for
v18 beta2 is lifted and the tag is pushed. That should happen in 24h
or so, I guess.
--
Michael
From 4c920861f07e0f4e6e21e24e5f6a9060054c3232 Mon Se
that on a different thread, though, if you finish with a
patch or something worth looking at for others.
--
Michael
signature.asc
Description: PGP signature
re changing here has no
interaction with the beginning of recovery, the other thread is about
the fact that reading the 2PC files from disk when !reachedConsistency
is a bad concept that we should avoid, impacting the assumption the
code path you are changing here relies on. At the end, it may be
p
On Mon, Jul 14, 2025 at 02:35:31PM +0800, jian he wrote:
> here, "text_eq" should be "texteq"?
Yes, I think that you are right here.
--
Michael
signature.asc
Description: PGP signature
On Thu, Jul 10, 2025 at 02:21:38PM +0900, Michael Paquier wrote:
> After that, I have applied a few cosmetic tweaks here and there, and
> attached is what I have staged for commit, minus proper commit
> messages. The new TAP tests have some WIN32-specific things, and I
> won't b
ng the
connection? The ecpg_log() assumes that a NULL value equals a
, which would be wrong if we failed one of these allocations
on OOM.
--
Michael
signature.asc
Description: PGP signature
as we're just adding that for the
case where a record needs to reconstructed across two pages, perhaps
I'm just worrying too much.
> Yeah, that doesn't seem like a regression.
Yep.
--
Michael
signature.asc
Description: PGP signature
ng at some replay cases, a TAP test would be
the way to go.
--
Michael
signature.asc
Description: PGP signature
On Wed, Jul 09, 2025 at 04:31:31PM +0900, Michael Paquier wrote:
> Attached is a rebased version of the rest, with the recent stanza
> related to fef6da9e9c87 taken into account. 0002 still has a change
> that should be in 0001: I have not really touched the structure of the
> t
On Wed, Jul 09, 2025 at 06:21:05PM -0700, Paul Jungwirth wrote:
> Here is a patch with the new order.
Thanks, done.
--
Michael
signature.asc
Description: PGP signature
tion error when I
> removed this.
Right, this one was not needed. Removed this bit and pushed the
addition of the function to the module injection_points.
--
Michael
signature.asc
Description: PGP signature
's a sufficiently odd test (as noted in its comments)
> that one could debate whether using it for an extension's
> purposes would be correct anyway.
+1.
--
Michael
signature.asc
Description: PGP signature
gt;> Maybe that is superstitious.
>
> Yeah, I'd be inclined to swap them. I dislike code that has no
> ordering principle other than feature development order.
Ordering them by number in the unified script makes more sense here.
> LGTM other than that nit. Michael, do you want
the
two remaining patches yet.
--
Michael
From 19d59646e1842ffd73aa0d79fc80c89370878f60 Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Wed, 9 Jul 2025 16:17:36 +0900
Subject: [PATCH v12 1/2] servicefile option usage on connection string feature
and its tests.
---
src/interfaces/libpq/fe-
r the other patch. The prompt shortcut retrieves the value using
a GetVariable(), rather than looking at the connection options all the
time.
--
Michael
signature.asc
Description: PGP signature
_CACHE_ALWAYS, if my memory serves me well. There are some
machines with a valgrind setup, additionally, that can take some time,
but I am not sure about their timings when it comes to a bootstrap
setup.
--
Michael
signature.asc
Description: PGP signature
ted? Yes, I was getting the
impression while reading your patch that this did not require this
complexity when generating the code for the pending data. Getting rid
of this part would be a nice outcome.
--
Michael
signature.asc
Description: PGP signature
ays
limiting ourselves to a single new version bump.
--
Michael
signature.asc
Description: PGP signature
s.so, for
example.
--
Michael
signature.asc
Description: PGP signature
add a new in-core type, or something else to a
different catalog, then you need to be aware of a completely different
.dat file. This set of instructions read as being a bit misleading,
IMO.
--
Michael
signature.asc
Description: PGP signature
le as an extra
> column. If all of the TOAST fits in the single record, this will be
> empty, else it will have an array of tids for all the pages for this
> toasted field." - Hannu Krosing in an email to me after
> PGConf.dev/2025
Sure, you could do that as well, but I suspect that we'll need the
steps of at least up to 0003 to be able to handle more easily multiple
external TOAST pointer types, or the code will be messier than it
currently is. :D
--
Michael
signature.asc
Description: PGP signature
On Tue, Jul 08, 2025 at 09:31:29PM +0300, Nikita Malakhov wrote:
> Michael, one more thing forgot to mention yesterday -
> #define TOAST_EXTERNAL_INFO_SIZE (VARTAG_ONDISK_OID + 1)
> static const toast_external_info
> toast_external_infos[TOAST_EXTERNAL_INFO_SIZE]
> VARTAG_ONDISK_O
don't really disagree with all that. Now the history of the TOAST
threads point out that we've good at proposing complex things, but
these had a high footprint. What I'm proposing is lighter than that,
I think, tackling my core issue with the infra supporting backward
compatibility
is point I'd be prepared to bet that there are.)
I've been reading through the patch (not tested), and no objections
with the concept here. I would have kept that a HEAD-only change due
to the proposed location for SetProcessingMode(), but, well, if I'm
in minority that's fin
with that, the situation was stable here with two hours running
the test in a loop.
> I got failures on iterations 3, 5, 1. With your patch applied, I got 100
> iterations passed.
This is good enough for me, so applied. Thanks for double-checking.
--
Michael
signature.asc
Description: PGP signature
On Mon, Jul 07, 2025 at 03:07:12PM +, Bertrand Drouvot wrote:
> On Mon, Jul 07, 2025 at 02:56:29PM +0900, Michael Paquier wrote:
>> On Mon, Jun 30, 2025 at 01:36:12PM +, Bertrand Drouvot wrote:
>
> Yeah, I think that this is needed for the custom wait events. But do we need
hread to use a conninfo is
stright-forward. How about extending the get_service_name()@common.c
I've proposed upthread so as it takes a string in input and it could
be reused for more connection options than only "service" so as it
could be reused there as well?
--
Michael
signature.asc
Description: PGP signature
as a template) hard to follow. The comments don't seem to
> explain what the detach and wait functions actually do, and how and
> why one might want to call them together.
If you see ways to improve the existing template, please feel free to
propose something, sure.
--
Michael
signature.asc
Description: PGP signature
On Mon, Jul 07, 2025 at 01:58:18PM +0700, John Naylor wrote:
> With that, can this CF entry be closed?
I've missed that there was a CF entry. Closed now.
--
Michael
signature.asc
Description: PGP signature
nfo) | (((uint64) wait_event_info) << 32)
>
> for the hash key.
Using uint32 for the hash key is fine. At least it's not an issue for
the pgstats machinery. So I would recommend to stick to
WAIT_EVENT_CLASS_MASK and WAIT_EVENT_ID_MASK for the computation of
the key of the entry inserted in shmem. Then when writing the stats
we can guess what are the class name and event names based on the key.
--
Michael
signature.asc
Description: PGP signature
ks harmless.
Thanks. I've applied the refactoring piece for now, and marked the CF
entry as returned with feedback. I'm hoping to get back to that for
the September commit fest.
--
Michael
signature.asc
Description: PGP signature
K to live with anyway.
What do you think about the attached, then?
--
Michael
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index 9fcd2db83265..c839634d4233 100644
--- a/src/bin/psql/command.c
+++ b/src/bin/psql/command.c
@@ -4480,6 +4480,7 @@ SyncVariables(void)
{
char v
;> waiting. Comments are welcome.
>
> Seems reasonable.
Thanks, applied.
--
Michael
signature.asc
Description: PGP signature
ProcessWalSummarizerInterrupts();
> +pg_usleep(100);
> summarizer_wait_for_wal();
>
> Michael, as you added the test case, could you please have a look?
I'm failing to reproduce it, unfortunately. It looks like just a
timing issue with the reports
mode, and if it's a viable
strategy in the long-term..
> If we went this way, we'd presumably revert 5a6c39b6d in favor
> of marking track_commit_timestamp with this flag.
Makes sense, on HEAD.
--
Michael
signature.asc
Description: PGP signature
gres/tree/toast_64bit
That's much dirtier, always WIP, just one of my playgrounds.
--
Michael
signature.asc
Description: PGP signature
ons to be an extra documentation burden if one
wants to add more tools, which may be in the scope of a bug fix as
that would just cause extra work.
--
Michael
signature.asc
Description: PGP signature
nsactionCommit. So v3 takes his patch. v3 also
>> added the testcase suggested by Michael for test coverage, it clearly
>> proves the bug is fixed now.
>
> The patch looks good to me.
I was wondering if we should backpatch that, and decided towards a
yes here as it can be annoyi
On Fri, Jul 04, 2025 at 01:03:01PM +0900, Michael Paquier wrote:
> A colleague, Walid Abrahim, has reported that contrib/xml2/ gives a
Oops, Walid Ibrahim. Sorry for the mistake.
--
Michael
signature.asc
Description: PGP signature
w.postgresql.org/message-id/1012981.1713222...@sss.pgh.pa.us
Regards,
--
Michael
diff --git a/contrib/xml2/xpath.c b/contrib/xml2/xpath.c
index 3f733405ec6d..11216b9b7f9a 100644
--- a/contrib/xml2/xpath.c
+++ b/contrib/xml2/xpath.c
@@ -209,7 +209,7 @@ pgxmlNodeSetToText(xmlNodeSetPtr nodeset,
xm
On Thu, May 29, 2025 at 06:09:00AM +0800, Quan Zongliang wrote:
> Updated
Applied, with a fixed indentation.
--
Michael
signature.asc
Description: PGP signature
On Thu, Jul 03, 2025 at 08:51:56AM +0900, Michael Paquier wrote:
> This results in the second patch attached. Comments are welcome.
There has been a blip with the regression test output, so rebased.
--
Michael
From e70d1606306a9933655fbae6f8a3f472c110 Mon Sep 17 00:00:00 2001
From: Mich
MAX in the
code.
Thanks for your patience!
--
Michael
signature.asc
Description: PGP signature
am not sure
that the argument about all the other GUCs potentially impacted holds
much value; we are talking about a specific code path.
--
Michael
signature.asc
Description: PGP signature
_ts/t. Just changing 001_base.pl should be
enough to trigger your original failure, making sure that this never
breaks again.
--
Michael
signature.asc
Description: PGP signature
On Tue, Apr 15, 2025 at 08:00:50AM +0900, Michael Paquier wrote:
> On Mon, Apr 14, 2025 at 04:29:37PM +0300, Aleksander Alekseev wrote:
>> If I didn't miss anything, all SQL functions dealing with injection
>> points are gathered in injection_points extension so IMO
>&g
On Wed, Jun 04, 2025 at 09:15:08AM +0900, Michael Paquier wrote:
> On Tue, Jun 03, 2025 at 03:34:16PM -0400, Andres Freund wrote:
>> I'm somewhat doubtful this is is the right direction. Tests that require
>> injection points before consistency also can't wait for injectio
elegant IMO.
--
Michael
signature.asc
Description: PGP signature
to backpatch
LSN_FORMAT_ARGS() and this LSN_FORMAT in the back-branches, leading to
less friction when backpatching fixes, but we don't deal with many
stable fixes that would require these.
--
Michael
signature.asc
Description: PGP signature
ver-side and client-side [de]compressions. I
have reused what you have suggested, adjusting the tests in the
back-branches based on the fact that int->bytea casts don't exist up
to v17 and that the command structures were a bit different in test
008.
And fixed down to v15.
--
Michael
si
On Wed, Jun 18, 2025 at 02:13:27PM +0900, Michael Paquier wrote:
> v3 seems sensible here. Thanks for the updated patch.
I did a new pass over that. All the code blocks moved to the new file
are identical. However, it is really easy to miss the change in
bytea_string_agg_transfn() with
ssingMode() for code paths that we do not want to
reach while in bootstrap mode. Could the same be done here?
--
Michael
signature.asc
Description: PGP signature
On Tue, Jul 01, 2025 at 10:01:37PM +0200, Michael Banck wrote:
> On Tue, Jul 01, 2025 at 12:41:50PM -0400, Tom Lane wrote:
>> Pushed, after some fooling with the comments and commit messages.
>
> Thanks! Also for back-patching them.
Catching up on this thread after-the-fact, speci
l documentation from the PostgreSQL wiki:
https://wiki.postgresql.org/wiki/Mailing_Lists
--
Michael
signature.asc
Description: PGP signature
ome, tweaked a bit the comments, and the result looked
fine. At the end, applied.
--
Michael
signature.asc
Description: PGP signature
Hi,
On Tue, Jul 01, 2025 at 12:41:50PM -0400, Tom Lane wrote:
> Michael Banck writes:
> > please find attached the current patches required to get master built
> > and the testsuites run on Debian's hurd-i386 port. I have not had the
> > time to test the hurd-amd64 por
will be lowercase when this view is installed in database. So, the test
> result does not change.
Yes, that was the part where I need to learn to read my greps more
correctly. Applied as-is on HEAD.
--
Michael
signature.asc
Description: PGP signature
ut having to look at a cost close to an infinite value. A bunch
of plans in the regression tests have changed while making the code
stable with v18 because we show some nodes as disabled but still used
by the planner, but that was not a big deal at the end.
In short, thanks all for the work done here!
--
Michael
signature.asc
Description: PGP signature
high-resolution timers in order to avoid regression test failures, and
the buildfarm client run does not like debug_parallel_query.
Michael
[1]
https://www.postgresql.org/message-id/685a3ccd.170a0220.2d27e6.2232%40mx.google.com
>From 2cf70fa676bacf97c24fd0b80bab6fec06b9f2db Mon Sep 17 00:00
On Wed, Jun 25, 2025 at 10:21:03AM -0500, Nathan Bossart wrote:
> On Wed, Jun 25, 2025 at 10:31:35AM +0900, Michael Paquier wrote:
>> Attached is the remaining patch for HEAD, planned once v19 opens, and
>> the tests I have used on the back-branches as a txt to not confuse the
>&
On Fri, Jun 20, 2025 at 04:20:21PM +0900, Michael Paquier wrote:
> Coming back to this thread as v19 is going to open up rather soon, the
> suggestion from Tom seems to be the consensus reached, which is to use
> the same value of log_line_prefix in the CI and the TAP as in
>
ests are going to fail: rules.out reports the definition of
pg_stat_activity, and the characters casing matters in this case.
Note that the new development cycle has officially begin, so that
would touch only v19.
--
Michael
signature.asc
Description: PGP signature
able via hacks, just a little more work).
>
> But are you going to backpatch all new features of injection points
> in future? It's potentially x6 more work.
That may be nice, but I'd be interested in seeing how things evolve
across v17 first before taking a decision for o
the following parts to
REL_17_STABLE:
- Cached points and loading, for critical sections.
- IS_INJECTION_POINT_ATTACHED(), for stack manipulations.
- Runtime arguments.
Thoughts or comments?
--
Michael
From d5d3f0bb997a5698ffdb0fa89131d1683460a15c Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date
On Thu, Jun 26, 2025 at 05:25:42PM +0530, vignesh C wrote:
> On Thu, 26 Jun 2025 at 06:22, Michael Paquier wrote:
>> So you are suggesting the addition of an extra ReadPageInternal() that
>> forces a read of only the read, perform the checks on the header, then
>> read the
it a day. It would not be the first
reproducer that fails on timeout if a problem arises. The important
fact is to be informed about the failure, while keeping tests fast in
the "normal" cases. We have a few tests like that already in the
tree, where a timeout is the best thing we can re
On Thu, Jun 26, 2025 at 07:37:46AM +0900, Michael Paquier wrote:
> No problem, good catches. Agreed to remove these references in the
> README of backend/lib/. Will fix if there are no objections.
Applied that.
--
Michael
signature.asc
Description: PGP signature
least there is
the trick with SET enable_self_join_elimination available as a last
resort method.
--
Michael
signature.asc
Description: PGP signature
On Thu, Jun 26, 2025 at 08:48:32AM +0530, Dilip Kumar wrote:
> On Thu, Jun 26, 2025 at 6:22 AM Michael Paquier wrote:
>> So you are suggesting the addition of an extra ReadPageInternal() that
>> forces a read of only the read, perform the checks on the header, then
>>
past behavior", I'm OK with that. I just
wanted to raise the issue before this goes GA. And well, I have a
pretty big pool of users that rely on this module, so..
--
Michael
signature.asc
Description: PGP signature
I'm not really excited about this prospect in
xlogreader.c which can be also used in the frontend.
--
Michael
signature.asc
Description: PGP signature
tmp/client-backup-lz4/
pg_verifybackup: error: checksum mismatch for file "junk" in archive
"base.tar.lz4"
--
Michael
signature.asc
Description: PGP signature
o objections.
--
Michael
signature.asc
Description: PGP signature
ate going down on slower machines, it is just cheaper and more
reliable to check directly the contents of VacuumParams. Note that
your original set of tests only covered the case of multiple
relations, and it missed coverage for the TOAST relation vacuumed
after its main relation.
--
Michael
sign
side of core may use it, and they would fail to
compile. This can break code, and keeping them around has no
maintenance cost.
--
Michael
signature.asc
Description: PGP signature
1 - 100 of 2412 matches
Mail list logo
