mproved, probably it's worth fixing that bug too.)
>
> [1]
> https://www.postgresql.org/message-id/flat/16527-ef7606186f0610a1%40postgresql.org
FWIW, I think that this one has been fixed by 076f4d9, where we make
sure that the page is correctly aligned. Are you still seeing this
prob
;
> The attached fixes that and make-world successfully finished even if I
> have a cert file in my home direcotory.
That's the same issue as the one fixed in dd87799, using the same
method. I'll double-check on top of looking at what you are
suggesting here.
--
Michael
signature.asc
Description: PGP signature
raw(), of course, but
the gain is the portability of the functions.
(One can have a lot of fun playing with random inputs and breaking
most code paths, but that's not new.)
--
Michael
diff --git a/contrib/pageinspect/brinfuncs.c b/contrib/pageinspect/brinfuncs.c
index bf12901ac3..87e75f663c
ure.
> It successfully builds and runs on Rocky8 and Windows11.
Thanks for the review. After a second look, it seemed fine so I have
applied it. (I'll try to jump on the tablespace patch for recovery
soon-ish-ly if nobody beats me to it.)
--
Michael
signature.asc
Description: PGP signature
e the attached, but that's a kind of
ugly hack. Another alternative would be to drop those two tests, and
I am not sure how much we care about these two negative scenarios.
Thoughts?
--
Michael
diff --git a/src/test/ssl/t/001_ssltests.pl b/src/test/ssl/t/001_ssltests.pl
index 5c5b
ing like that:
"A relative path to the data directory is returned for tablespaces
created with an empty location string specified in the CREATE
TABLESPACE query when allow_in_place_tablespaces is enabled (see link
blah)."
But perhaps that's just me being overly pedantic :p
--
Michael
signature.asc
Description: PGP signature
On Thu, Mar 17, 2022 at 02:59:26PM +0900, Michael Paquier wrote:
> In both cases, enforcing sslcrl to a value of "invalid" interferes
> with the failure scenario we expect from sslcrldir. It is possible to
> bypass that with something like the attached, but that's a kind
using, is
> it? And the existing treatment "Returns the file system path that
> this tablespace is located in" is not invalidated by this special
> case, so maybe we shouldn't mention it?
Right, I see your point. The existing description is not wrong
either. Fine by me t
string would be better, even if that
duplicates more the keys in those final strings.
Another thing that Horiguchi-san has pointed out upthread (?) is 003,
where it is also possible to trigger failures once the environment is
hijacked. The attached allows the full test suite to pass witho
On Thu, Mar 17, 2022 at 06:12:20AM -0500, Justin Pryzby wrote:
> I think this should use
>
> +#include "lz4frame.h"
>
> commit ba595d2322da095a1e6703171b3f1f2815cb
> Author: Michael Paquier
> Date: Fri Nov 5 11:33:25 2021 +0900
>
> Add support
or something environment-sensitive (macos, 32b, etc.)?
> pageinspect-zeros-v2.patch doesn't help too.
Well, the scope is different, so that's not a surprise.
--
Michael
signature.asc
Description: PGP signature
he first and third patches are only for HEAD, while
the documentation hole with SET TABLESPACE should go down to v10.
Backpatching the tests of ALTER MATERIALIZED VIEW ALL IN TABLESPACE
would not hurt, either, as there is zero coverage for that now.
--
Michael
signature.asc
Description: PGP signature
On Fri, Mar 18, 2022 at 03:13:05PM +0900, Michael Paquier wrote:
> Thanks. This looks rather sane to me. I'll split things into 3
> commits in total, as of the psql completion, SET TABLESPACE and SET
> ACCESS METHOD. The first and third patches are only for HEAD, while
> the d
On Sat, Mar 19, 2022 at 12:28:46PM +0100, Hannu Krosing wrote:
> Which hook should I use when overriding the COPY command in an extension?
CopyStmt goes through ProcessUtility(), so you can use the hook called
ProcessUtility_hook to override what you want.
--
Michael
signature.asc
Descript
On Fri, Mar 18, 2022 at 06:15:28PM -0400, Andrew Dunstan wrote:
> On 3/17/22 21:02, Michael Paquier wrote:
>> Another thing that Horiguchi-san has pointed out upthread (?) is 003,
>> where it is also possible to trigger failures once the environment is
>> hijacked. The att
the code moved is identical.
So at the end this part looks rather commitable to me.
I have not been able to test 0002 in details, but it looks rather
rather sane to me at quick glance, and it is simple. The argument
about more TAP tests applies to it, though, even if there is one SQL
test to ch
's stick with it.
--
Michael
signature.asc
Description: PGP signature
ghtling differently.
If we could reduce this number rather than increasing it, the better.
I would be also curious to see how much those parameters become
relevant with more compression options possible with toast values.
--
Michael
signature.asc
Description: PGP signature
ct if there is free space in the map or not, which goes down to
>>>> detecting if pg_freespace() returns 0 or a number strictly higher than
>>>> 0, so wouldn't it be enough to stick some > 0 in your test queries?
>>>
>>> I edited the previous patch
in the docs of pg_stat_file() about
the case where "filename" is a link, because the code internally uses
stat(). The function name makes that obvious, but that's not
commonly known, I guess. Please see the attached, that I would be
fine to apply.
--
Michael
diff --git a/doc/src/sgml/func.
e end-user,
and we are talking about a Linux-only thing here anyway. So, at the
end, I am tempted to just add the "2> /dev/null" as suggested upthread
by Nathan and call it a day. Does that sound fine?
--
Michael
signature.asc
Description: PGP signature
On Fri, Mar 18, 2022 at 06:43:39AM +0300, Alexander Lakhin wrote:
> Hello Michael,
> No, just x86_64, Ubuntu 20.04, gcc 11, valgrind 3.15. I just put that query
> in page.sql and see the server abort.
Bah, of course, I have missed the valgrind part of the problem.
The problem is that w
On Wed, Mar 23, 2022 at 10:45:19AM -0300, FabrÃzio de Royes Mello wrote:
> On Wed, Mar 23, 2022 at 3:05 AM Michael Paquier wrote:
>> Another thing that itched me is that we
>> could also test more with indexes, particularly with btree, BRIN and
>> hash (the latter should n
On Mon, Nov 30, 2020 at 04:15:27PM -0300, Alvaro Herrera wrote:
> In the interest of showing progress, I'm going to mark this CF item as
> committed, and I'll submit the remaining pieces in a new thread.
Thanks for splitting!
--
Michael
signature.asc
Description: PGP signature
ERBOSE [ boolean ]
Forgot about CONCURRENTLY as an option here, as this becomes
possible.
--
Michael
diff --git a/src/include/catalog/index.h b/src/include/catalog/index.h
index f4559b09d7..c041628049 100644
--- a/src/include/catalog/index.h
+++ b/src/include/catalog/index.h
@@ -29,6 +29,15 @@ typ
ch? Sure, it is not optimal to not
truncate all the segments when a transaction dropping a relation
commits, but this was not completely broken either.
--
Michael
signature.asc
Description: PGP signature
version supported
on HEAD. So I'd like to apply the attached first and sort out the
resowner stuff in a next step.
--
Michael
From 5ffd653336f1c41043635fad3618cf0bae7b1cec Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Tue, 1 Dec 2020 13:21:44 +0900
Subject: [PATCH v6] Rework SHA2
erience, any TAP tests making use of LSN operations can just
let the backend do the maths, so I am not much a fan of duplicating
that stuff in a perl module. Wouldn't it be better to add an
equivalent of your add() function in the backend then? That could
also get tested in the main regression test suite.
--
Michael
signature.asc
Description: PGP signature
ion for such a long time :/
> Of course I'll be happy to revert it from the back-branches if
> that's the consensus. Any > other opinions?
If there are no other opinions, I am also fine to rely on your
judgment.
--
Michael
signature.asc
Description: PGP signature
day), so I think that it is fair to
say that both of you should be listed as authors and credited as such
in the release notes for this one.
--
Michael
signature.asc
Description: PGP signature
On Tue, Dec 01, 2020 at 03:14:06PM +0900, Fujii Masao wrote:
> You mean the same function as the commit 9bae7e4cde provided?
Completely forgot about this one, thanks.
/me hides
--
Michael
signature.asc
Description: PGP signature
On Mon, Nov 30, 2020 at 03:46:19PM -0500, Tom Lane wrote:
> Michael Paquier writes:
> > So this comes down to 5 items, as per the attached. Thoughts?
>
> These items look fine to me, except this bit seems a bit awkward:
>
> + Note that the delayed indexing t
esowner.c. So, I am not sure if we
need to do anything here, and I am discarding this part.
--
Michael
From d2c9f2a9c9a36d80a014d588334e21a709a1c27d Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Wed, 2 Dec 2020 11:51:43 +0900
Subject: [PATCH v7] Switch cryptohash_openssl.c to use EVP
Postgres
On Tue, Dec 01, 2020 at 07:39:30PM +0800, Craig Ringer wrote:
> On Wed, 14 Oct 2020, 13:06 Michael Paquier, wrote:
>> Yeah, it is safer to assume that it is the responsability of the
>> backup tool to ensure that because it could be possible that a host is
>> unplugged just
g on that!
--
Michael
signature.asc
Description: PGP signature
pact when migrating applications
though. SELECT INTO has a different meaning in Oracle, but SQL server
creates a new table like Postgres.
--
Michael
signature.asc
Description: PGP signature
On Tue, Dec 01, 2020 at 03:10:13PM +0900, Michael Paquier wrote:
> Well, my impression is that both of you kept exchanging patches,
> touching and reviewing each other's patch (note that Alexei has also
> sent a rebase of 0002 just yesterday), so I think that it is fair to
> say
On Wed, Dec 02, 2020 at 12:03:49PM +0900, Michael Paquier wrote:
> Thanks. 0001 has been applied and the buildfarm does not complain, so
> it looks like we are good (I'll take care of any issues, like the one
> Fujii-san has just reported). Attached are new patches for 0002, th
That's fine even if it is in Japanese.
--
Michael
signature.asc
Description: PGP signature
surroundings (cleaning up anythig
related to MD5 is on my TODO list). Patch is attached.
Thoughts?
--
Michael
From d84ccefbf13f44c352d985dd87eadcc998cfb7b9 Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Thu, 3 Dec 2020 11:02:39 +0900
Subject: [PATCH] Rename cryptohashes.c to cryptohashfuncs.c
that
all those %s are options related to checkpoint/restartpoints?
The ones in geqo_erx.c look like debugging information, and the ones
in win32_shmem.c for segment creation are code paths only used by the
postmaster.
--
Michael
signature.asc
Description: PGP signature
CallbackState
> {
> - int options;/* options from
> statement */
> + boolconcurrently;
> Oid locked_table_oid; /* tracks previously
> locked table */
> };
Here also, I think that we should ju
out of memory");
> Shouldn't that be an ereport using ERRCODE_OUT_OF_MEMORY?
That makes sense, fixed.
I have done more testing across all versions of OpenSSL, and applied
this one, meaning that we are done for SHA2. Thanks for the reviews!
Now, moving back to MD5..
--
Michael
signature.asc
Description: PGP signature
, it may make sense to extend
that even more to the places where it would apply like the places
mentioned one paragraph above.
--
Michael
signature.asc
Description: PGP signature
On Thu, Dec 03, 2020 at 10:10:44PM +0100, Daniel Gustafsson wrote:
> +1 on this proposed rename.
Thanks. I have been able to get that done as of bd94a9c.
--
Michael
signature.asc
Description: PGP signature
On Tue, Nov 10, 2020 at 01:28:09PM +0900, Michael Paquier wrote:
> The CF bot has been complaining on Windows and this issue is fixed in
> the attached. A refresh of src/tools/msvc for pgcrypto was just
> missing.
Now that HEAD has the necessary infrastructure to be able to plug in
e
of those structures
exist as such for a long time.
--
Michael
diff --git a/src/include/catalog/index.h b/src/include/catalog/index.h
index c041628049..8f80f9f3aa 100644
--- a/src/include/catalog/index.h
+++ b/src/include/catalog/index.h
@@ -30,13 +30,10 @@ typedef enum
} IndexStateFlagsAction;
/* opt
ParseState *pstate, CheckPointStmt *stmt)
+{
Nit: perhaps this could just be ExecCheckPoint()? See the existing
ExecVacuum().
+ flags = CHECKPOINT_WAIT |
+ (RecoveryInProgress() ? 0 : CHECKPOINT_FORCE) |
+ (spread ? 0 : CHECKPOINT_IMMEDIATE);
The handling done fo
W, I disagree with the approach taken by eb93f3a. As of HEAD, it
is now required to translate all those strings. I think that it would
have been better to remove the function names from all those error
messages and not require the same pattern to be translated N times.
--
Michael
signature.asc
Description: PGP signature
ier as well.
--
Michael
signature.asc
Description: PGP signature
_MEMORY),
And this original position is IMO more correct.
Anyway, at quick glance, the backtrace of upthread is indicating a
double-free with an attempt to free a resource owner that has been
already free'd.
--
Michael
signature.asc
Description: PGP signature
to change all that, hexa style sounds good to me too.
Would it be worth an addition to the docs, say in [1] to tell that
this is a preferred style?
[1]: https://www.postgresql.org/docs/devel/source-conventions.html?
--
Michael
signature.asc
Description: PGP signature
On Sat, Dec 05, 2020 at 10:42:05AM -0500, Bruce Momjian wrote:
> On Sat, Dec 5, 2020 at 09:54:33PM +0900, Michael Paquier wrote:
>> On Fri, Dec 04, 2020 at 10:52:29PM -0500, Bruce Momjian wrote:
>>> if (state->evpctx == NULL)
>>> {
>>> -
get rid of checkpoint_completion_target entirely as an option.
> The main argument against that is that it could be annoying for people
> upgrading, but changing the default to 0.9 would definitely be an
> improvement.
Not sure there is enough ground to do that though.
--
Michael
signature.asc
Description: PGP signature
e nice.
> Yes the attached patch looks good to me for PostgreSQL. Thanks Michael.
Okay, committed to HEAD then.
--
Michael
signature.asc
Description: PGP signature
a description at the top of
this helper routine (say a simple "get the combining class of given
code"). Anything else you can think of?
--
Michael
signature.asc
Description: PGP signature
On Tue, Dec 08, 2020 at 02:25:43PM -0400, John Naylor wrote:
> Thanks for taking a look. Sounds good, I've made those adjustments and
> wrote a commit message. I took another look and didn't see anything else to
> address.
Looks good to me, so applied.
--
Michael
signature.a
the amount of noise diffs (pgindent
has adjusted some things by itself for the new files). In short, this
seems rather committable to me.
--
Michael
From 6692b6131b8d0a60ab51583b80edf1c41bae5770 Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Wed, 9 Dec 2020 14:39:19 +0900
Subject: [PATC
d be adapted is "performing".
> *If* we want to monitor the current status of
> checkpointer, it should be shown as wait event in pg_stat_activity,
> instead?
That would be WAIT_EVENT_CHECKPOINTER_MAIN, now there has been also on
this thread an argument that you would not have access to
pg_stat_activity until crash recovery completes and consistency is
restored.
--
Michael
signature.asc
Description: PGP signature
nderstand.
>
> commit message could reasonably say that maybe, but I don't think we
> need to memorialize it in a comment. lsyscache.c *is* where one
> would expect to find a simple catalog-field-fetch function like this.
> The previous implementation was not that, so it didn't belong there.
Agreed.
--
Michael
signature.asc
Description: PGP signature
he parallel
> check-world for ages.
Perhaps you have just increased -j lately or moved to a faster machine
where there are higher changes of collision?
--
Michael
diff --git a/src/bin/pg_upgrade/test.sh b/src/bin/pg_upgrade/test.sh
index 04aa7fd9f5..355477a8ee 100644
--- a/src/bin/pg_upgrade/
notice when looking
> at that file).
Good catch. I have fixed this one, looked again at the code this
morning, did more tests on Linux/Windows with/without OpenSSL, and
finally committed the patch.
--
Michael
signature.asc
Description: PGP signature
n/{md5.c,sha2.c}.
I am adding this patch set to the next commit fest. Thanks for
reading!
--
Michael
From 9d9a9bb6d9b4eb93ecf3e7e3c5695a2ac2c2a2d7 Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Thu, 10 Dec 2020 16:34:19 +0900
Subject: [PATCH 1/2] Adjust some code of cryptohash
This adj
On Wed, Dec 09, 2020 at 06:37:22PM +, Bossart, Nathan wrote:
> On 12/8/20, 10:16 PM, "Michael Paquier" wrote:
>> Yeah, I'd rather leave out the part of the patch where we have the
>> checkpointer say "idle". So I still think that what v3 did upthread
On Thu, Dec 10, 2020 at 10:02:10PM -0600, Justin Pryzby wrote:
> Isn't the sense of "reset" inverted ?
It is ;p
--
Michael
signature.asc
Description: PGP signature
orking on instead that gets
updated before the validation part, because we update ReadRecPtr and
EndRecPtr only after this initial validation is done.
--
Michael
signature.asc
Description: PGP signature
's something easy to reason about, and the docs
were written originally to remain simple.
--
Michael
signature.asc
Description: PGP signature
lent to exist on Windows. That would not be the first time
either that there is a TAP test that skips some tests if a module does
not exist. See for example what psql does with IO::Pty.
[1]: https://metacpan.org/pod/Archive::Tar
--
Michael
signature.asc
Description: PGP signature
sts? Or would you execute
it, still insert nothing on the result relation because it already
exists, even if the inner query may have inserted something as part of
its execution on a different relation?
--
Michael
signature.asc
Description: PGP signature
to so as we avoid useless system calls, so I think that this
stuff had better use a common path for the set and reset logic.
My counter-proposal is like the attached, with the set/reset part not
reversed this time, and the code indented :p
--
Michael
From cb7c41b70ff798870f2eddcaa2782bd47b5fd57f M
s changed. It is worth
noting that all the REINDEX_REL_* handling could be brushed. Another
point that has been raised on a recent thread by Peter was that people
preferred an hex style for the declarations rather than bit shifts.
What do you think?
--
Michael
signature.asc
Description: PGP signature
ill never forget
to a LSN in any of the messages produced by xlogreader.c or any of the
callbacks used by pg_waldump. FWIW, I'd rather let a position in this
report than none. At least it allows users to know the area where the
problem happened.
--
Michael
signature.asc
Description: PGP signature
On Sat, Dec 12, 2020 at 12:41:25AM +, Bossart, Nathan wrote:
> On 12/11/20, 4:00 PM, "Michael Paquier" wrote:
>> My counter-proposal is like the attached, with the set/reset part not
>> reversed this time, and the code indented :p
>
> Haha. LGTM.
Thanks.
On Thu, Dec 10, 2020 at 05:07:05PM +0900, Michael Paquier wrote:
> - 0001 is a set of small adjustments for the existing code of
> cryptohashes: some cleanup for MD5 in uuid-ossp, and more importantly
> one fix to call explicit_bzero() on the context data for the fallback
> implementa
just calling
> set_ps_display(""); after "Real work is done".
This behavior exists for ages and there were not a lot of complaints
on this matter, so I see no reason to touch back-branches more than
necessary.
--
Michael
signature.asc
Description: PGP signature
yours has the advantage to make debugging a
no-brainer, which is good. For any approach taken, it seems to me
that the same style should be applied to ClusterOption and
Vacuum{Option,Params}.
--
Michael
signature.asc
Description: PGP signature
ypassed but the query got executed and inserted tuples.
That's one example of behavior that may be confusing. There may be
others, but it seems to me that it may be simpler to execute or even
plan the query at all if the relation already exists.
--
Michael
signature.asc
Description: PGP signature
On Mon, Dec 14, 2020 at 03:15:12PM +0900, Michael Paquier wrote:
> Please note that this case fails with your patch, but the presence of
> IF NOT EXISTS should ensure that we don't fail and issue a NOTICE
> instead, no? Taking this case specifically (OK, I am playing with
> t
jobs). What would be the benefit in having more
complexity with library-dependent settings while we could take care
of the use cases that matter the most with a simple grammar? Perhaps
"not_current" is not the best match as a keyword, we could just use
"collation" and handle that a
on a separate thread? I have
mostly missed your message here.
--
Michael
signature.asc
Description: PGP signature
plit IMO. We should avoid as much as
possible OpenSSL-specific code paths in files part of src/common/ when
not building with OpenSSL. So this is now a mixed bag of
dependencies.
--
Michael
signature.asc
Description: PGP signature
oth of you seem to agree about having more details about that, which
is fine by me at the end. Horiguchi-san, do you have more thoughts to
offer? Benoit's version is similar to yours, just simpler.
--
Michael
signature.asc
Description: PGP signature
On Mon, Dec 14, 2020 at 10:19:02PM -0500, Bruce Momjian wrote:
> On Tue, Dec 15, 2020 at 10:05:49AM +0900, Michael Paquier wrote:
>> - The HMAC split is terrible, as mentioned upthread. I think that you
>> would need to extract this stuff as a separate patch, and not add more
the parent table. Of course, we could decide to implement a
redistribution logic in all frontend tools that need such things, like
reindexdb, but that's not something I think we should let the client
decide of. A backend-side filtering is IMO much simpler, less code,
and more elegant.
--
Michael
signature.asc
Description: PGP signature
ncmds.c and string_is_ascii() in
pgp-pgsql.c. I don't think we need a fourth copy of the same logic,
even if it is dead simple.
--
Michael
signature.asc
Description: PGP signature
... This is interesting. What did curl do wrong here? It is
always good to hear from such past experiences.
--
Michael
signature.asc
Description: PGP signature
hacky. I'm open to alternatives.
FWIW, I agree with Simon's feeling that bypassing a sanity check does
not feel like a good solution in the long term.
--
Michael
signature.asc
Description: PGP signature
n that regard.
ABI flexibility is a good point here. I did not consider this point
of view. Thanks!
--
Michael
signature.asc
Description: PGP signature
ostgresql.org/31/2868/. If all that is
done correctly, a lot of code can be cleaned up while making things
still pluggable with various SSL libraries.
--
Michael
signature.asc
Description: PGP signature
On Tue, Dec 15, 2020 at 10:09:35AM +0900, Michael Paquier wrote:
> Both of you seem to agree about having more details about that, which
> is fine by me at the end. Horiguchi-san, do you have more thoughts to
> offer? Benoit's version is similar to yours, just simpler.
Okay, ap
id/X9lhi1ht04I+v/r...@paquier.xyz
[2]: https://commitfest.postgresql.org/31/2868/
Thanks,
--
Michael
From 26f9375c72a512640711953b6b52f227863e9113 Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Wed, 16 Dec 2020 16:15:05 +0900
Subject: [PATCH] Refactor HMAC implementations
---
src/inc
On Wed, Dec 16, 2020 at 05:04:12PM -0500, Bruce Momjian wrote:
> On Wed, Dec 16, 2020 at 10:23:23AM +0900, Michael Paquier wrote:
>> Hmm. I don't think that this is right. First, this still mixes
>> ciphers and HMAC.
>
> I looked at the code. The HMAC function body
o get down to that for Postgres and keep things so as we are
only able to use one TLS library at the same time, the one compiled
with. This makes the protocol simpler. But perhaps I just lack
ambition and vision.
--
Michael
signature.asc
Description: PGP signature
t this
is not really a burden when it comes to long-term maintenance. And
the git history tells, at least it seems to me so, that this is not
manipulated much.
--
Michael
signature.asc
Description: PGP signature
ys
have in the tree what we consider as a clean state and don't
accumulate duplications. That pays off a lot when it comes to the
buildfarm turning suddenly red where a revert is necessary, as
incremental changes reduce the number of things to work on at once,
and the number of
farm code, but then any TAP tests that want it will likewise
> need to live there.
This facility gives us the possibility to clean up the test code of
pg_upgrade and move it to a TAP test, so I'd say that it is worth
having in the core code in the long-term.
--
Michael
signature.asc
Description: PGP signature
patibility with what
we do. All this stuff is already in the tree for ages, it was just
not shaped for a more centralized reuse.
> Agreed. I think there is serious risk we would do AES in a different
> way than OpenSSL, especially if I did it. ;-) We can add a native AES
> one day if
Fujii-san and Horiguchi-san in CC for more
details as I recall that they were involved in such things, with
pg_rman coming first into mind. (No idea about French users.)
--
Michael
signature.asc
Description: PGP signature
ior (like
looking at the diffs with the tests of the patch, but without the
diffs in src/backend/).
--
Michael
signature.asc
Description: PGP signature
--
Michael
diff --git a/src/include/common/string.h b/src/include/common/string.h
index 6a4baa6f35..655ccc0570 100644
--- a/src/include/common/string.h
+++ b/src/include/common/string.h
@@ -18,6 +18,7 @@ extern int strtoint(const char *pg_restrict str, char **pg_restrict endptr,
int base);
extern
101 - 200 of 11789 matches
Mail list logo
