writing another
> > * output method outside walsender, e.g. in a bgworker.
I don't see a reason to remove this comment as this routine can still
be useful for many purposes. What kind of rewording do you have in
mind?
--
Michael
signature.asc
Description: PGP signature
the feature freeze date, but the sooner
a version is available, the sooner I could look at what is proposed.
Recalling my memories of the discussion, there was not much to
address, and the logic was rather clear.
--
Michael
signature.asc
Description: PGP signature
could see the
difference by running the tests manually on Windows command prompt for
example.
> That seems great, thanks for picking this up.
Okay. Applied, then.
--
Michael
signature.asc
Description: PGP signature
more tests with several scenarios (aggressive segment
recycling or segment rotation) to get more reproducible scenarios,
but I was wondering if anybody had ideas around that.
So, thoughts?
--
Michael
signature.asc
Description: PGP signature
But I am
> assuming are unlikely to be able to create their own builds easily,
> given the complexity of doing so on Windows). Given that this is a
> pretty isolated change, it should hopefully be easy enough to back out
> for testing.
There is a large pool of bug reporters, hopefully on
On Mon, Oct 26, 2020 at 09:09:17PM +0300, Anastasia Lubennikova wrote:
> November commitfest will start just in a few days.
> I'm happy to volunteer to be the CFM for this one. With a help of Georgios
> Kokolatos [1].
Thanks to both of you for volunteering.
--
Michael
signature.a
On Fri, Oct 23, 2020 at 06:06:30PM +0900, Michael Paquier wrote:
> On Fri, Oct 23, 2020 at 04:31:56PM +0800, Julien Rouhaud wrote:
>> Mmm, is it really an improvement to report warnings during this
>> function execution? Note also that PageIsVerified as-is won't report
>&
s a lot!
Thanks for confirming. I have gone through the whole set today,
splitted the thing into two commits and applied them. We had
buildfarm member florican complain about a mistake in one of the
GetDatum() calls that I took care of already, and there is nothing
else on my radar.
--
Micha
rework a bit to execute ANALYZE as a
> last step.
I agree that this is not user-friendly, and I suspect that we will
need to do something within index_concurrently_swap() to fill in the
stats of the new index from the data of the old one (not looked at
that in details yet).
--
Michael
signature.asc
Description: PGP signature
On Tue, Oct 27, 2020 at 05:40:09PM -0400, John Naylor wrote:
> Ok, here is a patch to fix that, and also throw an error if pg_proc.dat has
> an explicitly defined symbol.
I am not seeing any uses of HEAP_TABLE_AM_HANDLER_OID in the wild, so
+1 for just removing it, and not back-patch.
--
M
enough.
--
Michael
signature.asc
Description: PGP signature
On Wed, Oct 28, 2020 at 04:11:56PM +0900, Michael Paquier wrote:
> Thanks. The patch for v13 cannot use a macro, but one of the versions
> of upthread would do just fine. I have been wondering about using the
> new CheckBuffer() for the purpose of the retry to make it
> concurrent-
da-san.
--
Michael
signature.asc
Description: PGP signature
On Thu, Oct 29, 2020 at 12:02:11AM +0100, Tomas Vondra wrote:
> On Wed, Oct 28, 2020 at 05:43:08PM -0300, FabrÃzio de Royes Mello wrote:
>> 2) REINDEX CONCURRENTLY does not keep statistics (pg_statistc) like a
>> regular REINDEX for indexes using expressions and to me it&#
rior
|to a specific base backup without error.
At the very least, the commit message should give a rationale on why
pg_archivebackup is retired, and what it should be replaced with, in
case valid use-cases for it are still present.
Michael
--
Michael Banck
Projektleiter / Senior Berater
Tel.: +49
that, I was wondering of the potential need of
this error code for other encryption code paths, but it happens that
this is only specific to OpenSSL. Rijndael or Blowfish don't need
it.
--
Michael
signature.asc
Description: PGP signature
On Thu, Oct 22, 2020 at 10:41:53AM +0900, Michael Paquier wrote:
> We cannot trust the fields fields of the page header because these may
> have been messed up with some random corruption, so what really
> matters is that the checksums don't match, and that we can just rely
> o
On Wed, Oct 28, 2020 at 04:43:44PM +0900, Michael Paquier wrote:
> On Wed, Oct 28, 2020 at 04:11:56PM +0900, Michael Paquier wrote:
>> Thanks. The patch for v13 cannot use a macro, but one of the versions
>> of upthread would do just fine.
For the note, I have posted a set of pat
such return a text and not a Datum, and
move the null check + text-to-datum conversion into a separate macro.
I am not sure if this would be an improvement in terms of readability
though.
--
Michael
signature.asc
Description: PGP signature
On Thu, Oct 29, 2020 at 10:59:52AM +0900, Michael Paquier wrote:
> REINDEX CONCURRENTLY is by design wanted to provide an experience
> transparent to the user similar to what a plain REINDEX would do, at
> least that's the idea behind it, so.. This qualifies as a bug to me,
> i
d Appveyor
> runs, will fix over the weekend. Thanks for the heads-up.
It seems to me that you are just missing to declare a new error number
in px.h, so I would suggest to just use -19.
--
Michael
signature.asc
Description: PGP signature
t that, the logic looks fine at quick glance. In the long-term,
I also think that it would make sense to move both routnes out of
heap.c into a separate pg_statistic.c. That's material for a separate
patch of course.
--
Michael
signature.asc
Description: PGP signature
On Fri, Oct 30, 2020 at 10:30:13PM -0500, Justin Pryzby wrote:
> (I'm quoting from the commit message of the patch I wrote, which is same as
> your patch).
(I may have missed something, but you did not send a patch, right?)
--
Michael
signature.asc
Description: PGP signature
use different partitions for pg_wal/ and the main data folder.
--
Michael
signature.asc
Description: PGP signature
On Sat, Oct 31, 2020 at 09:40:12PM +0100, Daniel Gustafsson wrote:
> Ah yes, I accidentally fat-fingered the git add -p when splitting up the NSS
> patch into bite size pieces. Sorry about that. The attached v2 has the error
> declaration.
Thanks for updatng the patch. Applied.
-
On Sun, Nov 01, 2020 at 09:23:44AM +0900, Michael Paquier wrote:
> By doing so, there is no need to include pg_statistic.h in index.c.
> Except that, the logic looks fine at quick glance. In the long-term,
> I also think that it would make sense to move both routnes out of
> h
start.
- It is still useful to check that a page is in shared buffers IMO, so
as if it is dirty we just discard it from the checks and rely on the
next checkpoint to do a flush. It is also useful to check the state
of the on-disk data is good or not if the page is not dirty, as the
page could have
On Sun, Nov 01, 2020 at 05:39:40PM -0800, Andres Freund wrote:
> I'm a bit limited writing - one handed for a while following an injury
> on Friday...
Oops. Take care.
> On 2020-11-02 10:05:25 +0900, Michael Paquier wrote:
> > There is no place doing that on HEAD.
>
>
subsequent
>> + * execution to detect ties.
What you have sent for xml.c is a clear improvement, but I am not sure
if that's the best we can do. So I have left this part out, and
applied the rest.
PS: I am also quite fond of "unbetimes".
--
Michael
signature.asc
Description: PGP signature
On Sun, Nov 01, 2020 at 05:50:06PM -0800, Andres Freund wrote:
> On 2020-11-02 10:45:00 +0900, Michael Paquier wrote:
> > On 2020-11-02 10:05:25 +0900, Michael Paquier wrote:
> > > > There is no place doing that on HEAD.
> > >
> > > Err?
> > >
X INDEX, and one
set of indexes on a single relation for REINDEX TABLE).
--
Michael
signature.asc
Description: PGP signature
that aren't even relations? (though
> maybe that goes for other parts of amcheck at some point as well?)
I also thought about amcheck when looking at this thread, but it did
not seem the right place as this applies to any AM able that could
load stuff into the shared buffers.
--
Michael
signature.asc
Description: PGP signature
; Don't think we need a share lock. That still allows the buffer to be
> written out (and thus a torn read). What we need is to set
> BM_IO_IN_PROGRESS on the buffer in question - only one backend can set
> that. And then unset that again, without unsetting
> BM_DIRTY/BM_JUST_DIRTIED.
If that can work, we could make use of some of that for base backups
for a single retry of a page that initially failed.
--
Michael
signature.asc
Description: PGP signature
ing a process is irrelevant in 1.1.1.
We are still many years away from removing its support though.
No idea if other SSL implementations would require such a thing.
Daniel, what about NSS?
--
Michael
signature.asc
Description: PGP signature
xt arrays as partition key fails.
>
>> The attached patch fixes this. I propose to backpatch this.
>
> LGTM
+1.
--
Michael
signature.asc
Description: PGP signature
code when adding a new SSL implementation to make sure
that we never see CVE-2013-1900 again, say:
void
pg_strong_random_init(void)
{
#ifdef USE_SSL
#ifdef USE_OPENSSL
RAND_poll();
#elif USE_NSS
/* do the NSS initialization */
#else
Hey, you are missing something here.
On Tue, Nov 03, 2020 at 06:46:12PM +0900, Michael Paquier wrote:
> Yep, that's clear. I'll deal with that tomorrow. That's more than a
> simple rework.
This part is now done as of e152506a.
--
Michael
signature.asc
Description: PGP signature
d in that variable, say '/tmp, /var/run/postgresql'. Possibly
> the behavior would change for pathnames containing spaces or the
> like, but it is probably kinda broken for such cases today anyway.
>
> In any case, Michael had promised to test this aspect before committing.
P
leased [1].
>
> [1]
> https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-lcid/70feba9f-294e-491e-b6eb-56532684c37f
I am honestly not a fan of something like that as it has good chances
to rot.
--
Michael
signature.asc
Description: PGP signature
On Fri, Oct 30, 2020 at 11:30:28AM +0900, Michael Paquier wrote:
> Playing with dd and generating random pages, this detects random
> corruptions, making use of a wait/retry loop if a failure is detected.
> As mentioned upthread, this is a double-edged sword, increasing the
> numbe
Hi,
Am Mittwoch, den 04.11.2020, 17:48 +0900 schrieb Michael Paquier:
> On Fri, Oct 30, 2020 at 11:30:28AM +0900, Michael Paquier wrote:
> > Playing with dd and generating random pages, this detects random
> > corruptions, making use of a wait/retry loop if a failure is detected.
&
, with the change for pg_dump
included. I have reorganized the list in variable_is_guc_list_quote()
alphabetically while on it.
Robert, is your previous question answered?
--
Michael
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index a62d64eaa4..bb34630e8e 100644
--- a/src/b
On Wed, Nov 04, 2020 at 05:41:39PM +0100, Michael Banck wrote:
> Am Mittwoch, den 04.11.2020, 17:48 +0900 schrieb Michael Paquier:
>> So, I have done much more testing of this patch using an instance with
>> a small shared buffer pool and pgbench running in parallel for having
>
sed while
building with OpenSSL, but perhaps I am just too much of a pessimistic
nature.
--
Michael
diff --git a/src/include/port.h b/src/include/port.h
index d25716bf7f..5dfb00b07c 100644
--- a/src/include/port.h
+++ b/src/include/port.h
@@ -513,6 +513,7 @@ extern char *pg_inet_net_ntop(int af, c
On Thu, Oct 15, 2020 at 03:56:21PM +0900, Michael Paquier wrote:
> I got my hands on that, and this proves to simplify a lot things. In
> bonus, attached is a 0003 that cleans up some code in pgcrypto so as
> it uses the in-core resowner facility to handle EVP contexts.
This conflicte
> +#if defined(USE_OPENSSL_RANDOM)
>
> I'm not sure this comment adds any value, we currently have two non-TLS
> library
> PRNGs in pg_strong_random, so even if we add NSS it will at best be 50%:
I don't mind removing this part, the compilation hint may be enough,
indeed.
--
Michael
signature.asc
Description: PGP signature
It seems to me that this one would become incorrect if compiling with
OpenSSL but select a random source that requires an initialization, as
it would enforce only OpenSSL initialization all the time.
Theoretical point now, of course, because such combination does not
exist yet in the co
and replace the comment by a
simple "initialization already done above".
--
Michael
signature.asc
Description: PGP signature
ock on the
relations involved before doing such lookups, so that's a defensive
move. By switching the code as you do in 0002, you could mask such
logical problems as different errors could get raised. So I don't
think that it is a good idea.
--
Michael
signature.asc
Description: PGP signature
Thanks,
[1]: https://www.postgresql.org/message-id/20200924025314.ge7...@paquier.xyz
--
Michael
From 0e0404232072d096cae61fbf1e3135516b18fd0e Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Thu, 5 Nov 2020 15:53:00 +0900
Subject: [PATCH 1/3] Add APIs to control EVP contexts for resource owners
This will
On Fri, Nov 06, 2020 at 01:31:44PM +0100, Magnus Hagander wrote:
> I think the defensive-in-code instead of defensive-in-docs is a really
> strong argument, so I have pushed it as such.
Fine by me. Thanks for the commit.
--
Michael
signature.asc
Description: PGP signature
backend-only. Both fixed in the attached.
Thanks John. Both look right to me. I'll apply both in a bit.
--
Michael
signature.asc
Description: PGP signature
On Sat, Nov 07, 2020 at 09:29:30AM +0900, Michael Paquier wrote:
> Thanks John. Both look right to me. I'll apply both in a bit.
Done that now. Just for the note: you forgot to run pgperltidy.
--
Michael
signature.asc
Description: PGP signature
On Thu, Nov 05, 2020 at 09:16:10AM +0900, Michael Paquier wrote:
> No arguments against this point either. If you consider all that, the
> switch can be done with the attached, with the change for pg_dump
> included. I have reorganized the list in variable_is_guc_list_quote()
> al
the index at all, regardless of
> concurrently or not. So we can reduce this message to be identical to
> the one we throw in the non-concurrent case.
No issues from me here.
> Patch 0004 just adds a comment to clarify a message that I found
> confusing when doing the translation.
+1.
--
Michael
signature.asc
Description: PGP signature
ld just apply your stuff after the version is tagged (not
stamped as there could be urgent bug fixes between the stamp time and
the tag time, like packaing issues).
--
Michael
signature.asc
Description: PGP signature
her postmaster already running on port 5432? If not,
remove socket file "@tmp/.s.PGSQL.5432" and retry.
Instead of showing paths with at signs, wouldn't it be better to
mention it is an abstract socket address?
I am not sure that 0002 is an improvement. It would be more read
ut why it's correct as is.
FWIW, I saw an extra case with parsePGArray() today. I am not sure
about the addition of repalloc(), as it is quite obvious that one has
to use its result. Lists are fine, these are proper to PG internals
and beginners tend to be easily confused in the way to use them.
--
Michael
signature.asc
Description: PGP signature
notice -- PFA a rebased version!
No objections to remove this script from me.
I have spotted one small-ish thing. This patch is missing to update
the following code in vcregress.pl:
print "\nSetting up stats on new cluster\n\n";
system(".\\analyze_new_cluster.bat")
more need.
> There are already separate tests for testing vacuumdb.
True, 102_vacuumdb_stages.pl already does all that.
--
Michael
signature.asc
Description: PGP signature
On Mon, Nov 09, 2020 at 04:47:43PM +0100, Dmitry Dolgov wrote:
> > On Tue, Nov 03, 2020 at 07:14:47PM +0100, Dmitry Dolgov wrote:
> > > On Thu, Aug 20, 2020 at 03:11:19PM +0900, Michael Paquier wrote:
> > > On Wed, Aug 19, 2020 at 02:16:46PM -0400, Alvaro Herrera wrote:
&
held for a very short time, so IMO it won't
matter much in practice, particularly if you compare that with the
potential gains related to the existing wait phases.
--
Michael
signature.asc
Description: PGP signature
building with OpenSSL), but at
least it gives an escape route with 13.
Thoughts?
--
Michael
diff --git a/src/backend/replication/backup_manifest.c b/src/backend/replication/backup_manifest.c
index 556e6b5040..bab5e2f53b 100644
--- a/src/backend/replication/backup_manifest.c
+++ b/src/backend
a small performance test without this patch. vacuum_rel() sets
the flag for a non-full VACUUM, so with one backend running a manual
VACUUM in loop on an empty relation could apply some pressure on any
benchmark, even a simple pgbench.
--
Michael
signature.asc
Description: PGP signature
On Mon, Nov 09, 2020 at 08:23:31AM +0100, Peter Eisentraut wrote:
> On 2020-11-09 07:56, Michael Paquier wrote:
>> This is accepted by clang, and MSVC has visibly an equivalent for
>> that, as of VS 2012:
>> #elif defined(_MSC_VER) && (_MSC_VER >= 1700)
>> #de
On Fri, Nov 06, 2020 at 04:34:34PM +0900, Michael Paquier wrote:
> The attached patch set does a bit of rework to make the Postgres code
> more consistent with OpenSSL, similarly to the work I did for all the
> SHA2 implementations with EVP in [1]:
> - 0001 is something stolen from
On Thu, Nov 05, 2020 at 10:57:16AM +0900, Michael Paquier wrote:
> I was referring to the patch I sent on this thread that fixes the
> detection of a corruption for the zero-only case and where pd_lsn
> and/or pg_upper are trashed by a corruption of the page header. Both
> cases
On Mon, Nov 09, 2020 at 09:04:24AM +0100, Peter Eisentraut wrote:
> On 2020-11-09 07:08, Michael Paquier wrote:
> The @ is the standard way of representing this in the user interface and the
> configuration, so it seems sensible to me that way.
Ok.
> Can you sketch how you would st
On Tue, Nov 10, 2020 at 09:50:15AM +0100, Andreas Karlsson wrote:
> I submitted patches to pgformatter, bucardo and ledgersmb. Both davical and
> sql-ledger only seems to have them in old upgrade scripts.
Thanks, Andreas!
--
Michael
signature.asc
Description: PGP signature
efined on Linux. Unsure why it wasn't before on Windows.
Your patch is grabbing the value of PG_CPPFLAGS from ltree's
Makefile, which is fine. We may be able to remove this flag and rely
on pg_tolower() instead in the long run? I am not sure about
FLG_CANLOOKSIGN() though.
--
Michael
signature.asc
Description: PGP signature
c
And this configuration matches exactly what you have with the host
where the test passed.
Now I do see a difference in the Windows 10 build involved, 10.0.19041
fails but 10.0.18363 passes. I find rather hard to buy that this is
directly a Postgres bug. The compiler version is the same, so the
issue seems to be related to the way the code compiled is
interpreted.
--
Michael
signature.asc
Description: PGP signature
On Tue, Nov 10, 2020 at 10:21:04AM +0900, Michael Paquier wrote:
> On Mon, Nov 09, 2020 at 03:47:22PM +0100, Peter Eisentraut wrote:
>> You should just remove those calls. There is no need to replace them with
>> vacuumdb calls. The reason those calls were there is that they were
function args or such when it comes to pre-8.4 dumps. This
issue is unlikely going to matter in practice, so I don't propose a
backpatch.
Thoughts?
--
Michael
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index c68db75b97..dc1d41dd8d 100644
--- a/src/bin/pg_dump/pg_dump.c
issue I can see is that you would bypass
ExecutorCheckPerms_hook_type when using WITH NO DATA. This could
silently break the users of this hook.
--
Michael
signature.asc
Description: PGP signature
On Wed, Nov 11, 2020 at 04:51:27PM +0100, Magnus Hagander wrote:
> Gah. For some reason, I did not spot this email until after I had
> applied the other patch. And not only that, I also missed one line in
> my patch that you included in yours :/
>
> My apologies.
No worries, tha
On Tue, Nov 10, 2020 at 11:00:14AM +0900, Michael Paquier wrote:
> Attached is a patch that I would like to back-patch down to v13 to
> avoid this useless initialization, giving users the possibility to
> take base backups with FIPS when not using a backup manifest. Without
> the sol
o?
> Or we just drop the hint in the Unix case. The primary error message is
> clear enough.
Dropping the hint for the abstract case sounds fine to me.
--
Michael
signature.asc
Description: PGP signature
into_schema.tmp5 (a,b,c)
+ AS SELECT oid,relname,relacl FROM pg_class
+ WHERE relname like '%c%' WITH NO DATA; -- error
RESET SESSION AUTHORIZATION;
What your patch set does is to allow the second case to pass (or even
the EXECUTE case to pass). HEAD is indeed a bi
k of, coming down actually to the callers of
CreateIntoRelDestReceiver:
- A plain CTAS WITH NO DATA, that should pass,
- CTAS EXECUTE WITH NO DATA, that should pass.
- CTAS EXECUTE WITH DATA, that should not pass.
- EXPLAIN CTAS WITH DATA, that should not pass.
--
Michael
signature.asc
Description: PGP signature
tching vacuumFlags to use atomics
is very appealing in the long term, with or without considering this
patch, even if we had better be sure that this patch has no actual
effect on concurrency first if atomics are not used in worst-case
scenarios.
--
Michael
signature.asc
Description: PGP signature
On Thu, Nov 05, 2020 at 03:41:23PM +0900, Michael Paquier wrote:
> This conflicted on HEAD with pgcrypto. Please find attached a rebased
> set.
I got to think more about this stuff and attached is a new patch set
that redesigns the generic interface used for the crypto hash
functions, in
myState->output_cid = GetCurrentCommandId(true);
myState->ti_options = TABLE_INSERT_SKIP_FSM;
- myState->bistate = GetBulkInsertState();
+ myState->output_cid = GetCurrentCommandId(true);
The changes related to the bulk-insert state data look fine per se.
One nit: I would set bi
or error messages:
>
> - "extented statistics",
> + "extended statistics",
>
> It's used in an elog for cache lookup failures, so maybe it should be
> backported?
This is new as of HEAD (b1d32d3), so applied there. Thanks!
--
Michael
signature.asc
Description: PGP signature
t USE_OPENSSL.
- rand.h needs to be included under USE_OPENSSL.
--
Michael
diff --git a/src/port/pg_strong_random.c b/src/port/pg_strong_random.c
index 6d85f50b7c..c5dfe4b072 100644
--- a/src/port/pg_strong_random.c
+++ b/src/port/pg_strong_random.c
@@ -24,7 +24,7 @@
#include
#include
-#ifde
On Sun, Nov 15, 2020 at 04:37:36PM +0100, Magnus Hagander wrote:
> On Tue, Nov 10, 2020 at 5:44 AM Michael Paquier wrote:
>> On Thu, Nov 05, 2020 at 10:57:16AM +0900, Michael Paquier wrote:
>>> I was referring to the patch I sent on this thread that fixes the
>>> detect
l. Even if you don't use that in some sanity checks for
code paths, which I think we actually should really do for at least
inittapes() and leader_takeover_tapes() when it comes to the number of
participants assumed to exist, that's useful for debugging purposes.
Robert, this code has bee
would have caused failures
in the buildfarm, as any role created needs to be prefixed with
"regress_".
--
Michael
signature.asc
Description: PGP signature
l() with repetitive call handling? This may
not be the only place where we care about that, particularly for
non-core code.
No objections with the two changes from pg_usleep() to WaitLatch() so
they could be applied separately first.
--
Michael
signature.asc
Description: PGP signature
o is the same, but I find rather scary that this tool is used
in exactly zero tests.
Echoing with Robert, I think that pg_archivecleanup is still useful in
many cases, so that's not something we should remove.
--
Michael
signature.asc
Description: PGP signature
up without a
transaction context.
--
Michael
signature.asc
Description: PGP signature
houldn't be required at all. I suggest we consider doing that
> instead. I don't see a use for the current behavior.
Hmm. Is there anything specific for materialized views? They've
checked for INSERT privileges at this phase since their introduction
in 3bf3ab8c.
--
Michael
signature.asc
Description: PGP signature
no objections.
Please note that git diff --check and that the indentation does not
seem quite right, but that's easy enough to fix.
--
Michael
signature.asc
Description: PGP signature
lete.c more thoroughly.
Agreed. One thing that I'd think could help is a new wild card to
make some of the words conditional in the list of items. But that may
be tricky once you consider the case of a group of words.
I don't think that this is a requirement for this thread, though.
--
Mic
N32_RANDOM" = x"1" ; then
+elif test x"$PORTANME" = x"win32" ; then
Typo here, s/PORTANME/PORTNAME.
--
Michael
signature.asc
Description: PGP signature
nsactionId);
> + */
> +static inline void
> +set_safe_index_flag(void)
This routine name is rather close to index_set_state_flags(), could it
be possible to finish with a better name?
--
Michael
signature.asc
Description: PGP signature
is makes sense. For both, removing the "port" part is indeed
a good idea as long as you keep around the full socket file name.
--
Michael
signature.asc
Description: PGP signature
On Mon, Nov 16, 2020 at 10:14:10PM -0500, Tom Lane wrote:
> Michael Paquier writes:
>> I don't think that this is a requirement for this thread, though.
>
> Agreed, I'm not trying to block this patch. Just wishing
> there were a better way.
Okay. I have tweaked a c
t's true for most use cases.
> Thoughts? Can anyone suggest test scenarios to verify the performance of
> this?
Playing with catcache.c is the first thing that came to my mind.
After that some micro-benchmarking with DSM or snapshots? I am not
sure if we would notice a difference in a r
t something on this thread
that nobody likes :)
--
Michael
signature.asc
Description: PGP signature
allargtypes includes correct
data even if argmodes and/or argnames parsing has failed, so you would
cause a crash as long as nallargs is set if you free allargtypes like
that. You could allow those free calls if resetting nallargs to 0 if
the parsing of argmodes or argnames has failed, but that would make
the logic less flexible.
--
Michael
signature.asc
Description: PGP signature
401 - 500 of 11789 matches
Mail list logo
