On Fri, Mar 26, 2021 at 09:49:00AM +0900, Michael Paquier wrote:
> Yes, you are right here. I missed the parts before
> mock_scram_secret() gets called and there are comments in the whole
> area. Hmm, at the end of the day, I think that would just have
> verify_client_proof() fill
plication_name = 'fdw_retry_check';
I think that you are making the tests less stable by doing that. A
couple of buildfarm machines are very slow, and 10 seconds would not
be enough. So it seems to me that this patch is trading what is a
stable solution for a solution that may finish by r
On Mon, Mar 22, 2021 at 10:17:56AM +0900, Michael Paquier wrote:
> The Release Management Team (RMT) for the PostgreSQL 14 is assembled
> and has determined that the feature freeze date for the PostgreSQL 11
> release will be April 7, 2021. This means that any feature for the
> P
on Windows any module with NO_INSTALLCHECK does not get tested
as we rely mostly on an installed server to do all the tests and avoid
the performance impact of setting up a new server for each module's
test.
--
Michael
signature.asc
Description: PGP signature
On Thu, Apr 08, 2021 at 10:50:39AM -0700, Andres Freund wrote:
> Obviously all very far from being ready, but this seemed like a good
> enough excuse to mention it ;)
This is nice. Are there any parallelism capabilities?
--
Michael
signature.asc
Description: PGP signature
dea, but from the point of
view of the buildfarm the WARNING introduced by aaf0432 is a no-go. I
honestly don't quite get the benefit in issuing a WARNING in this case
anyway, as the code already returns false on timeout so as caller
would know the status of the operation.
--
Michael
mission there. It's
> working for me so I added an item with a link to the patch!
As long as you have a community account, you should have the
possibility to edit the page. So if you feel that any change is
required, please feel free to do so, of course.
--
Michael
signature.asc
Description: PGP signature
hink that the biggest thanks here goes to you, for cleaning the CF
entries completely. So, thanks!
--
Michael
signature.asc
Description: PGP signature
On Sat, Apr 03, 2021 at 08:25:46PM -0500, Justin Pryzby wrote:
> Forking this thread
> https://www.postgresql.org/message-id/20210403154336.GG29125%40momjian.us
Didn't see this one, thanks for forking.
> I understood "developer" to mean someone who's debugging postgres itself, not
> (say) a funct
= InvalidOid; /* ... so it has no collation */
>> break;
>
> This is much clearer, yeah.
+1.
--
Michael
signature.asc
Description: PGP signature
case.
So there is no new information here to the user, only a duplicate of
what's already known to the caller of this function. I see more
advantages in removing this WARNING rather than keeping it.
--
Michael
signature.asc
Description: PGP signature
ve fixed it down where needed, for the parts that did not
conflict too heavily.
--
Michael
signature.asc
Description: PGP signature
tested on Linux and MSVC.
To get some coverage with the CF bot, I am adding a CF entry with this
thread.
I am still not sure if people would prefer this approach over what's
on HEAD. So if there are any opinions, please feel free.
--
Michael
diff --git a/src/test/regress/input/tablespace.
On Fri, Apr 09, 2021 at 09:13:04AM +, Daniel Westermann (DWE) wrote:
> there is a small typo in guc.c. Attached patch fixes this.
Indeed, there is. I'll apply and backpatch if there are no
objections.
--
Michael
signature.asc
Description: PGP signature
e consistent with the rest.
--
Michael
diff --git a/src/bin/psql/common.c b/src/bin/psql/common.c
index 028a357991..f289f05843 100644
--- a/src/bin/psql/common.c
+++ b/src/bin/psql/common.c
@@ -1117,7 +1117,6 @@ SendQueryAndProcessResults(const char *query, double *pelapsed_msec,
On Fri, Apr 09, 2021 at 08:52:20AM +0200, Fabien COELHO wrote:
> There is not a single test of "ctrl-c" which would have caught this trivial
> and irritating regression. ISTM that a TAP test is doable. Should one be
> added?
If you can design something reliable, I would welco
as
> ill-advised, and it ought to be reverted. We can try again later.
Yes, I agree that a revert would be more adapted at this stage.
Peter?
--
Michael
signature.asc
Description: PGP signature
for testing purposes?
- Should we make more general the description of the developer options
in the docs?
I have applied the patch for log_autovacuum_min_duration for now, as
this one is clearly wrong.
--
Michael
signature.asc
Description: PGP signature
t's a4d75c8, for Tomas.
>> I think it's cleanest to write:
>> |HeapTupleData tmptup = {0};
I agree that this would be cleaner.
While on it, if you could not top-post..
--
Michael
signature.asc
Description: PGP signature
e rules. I can get that it could be interesting
to be able to pass down a custom path for the test tablespace, but do
we really have a need for that?
It took some time for the CF bot to run the patch of this thread, but
from what I can see the tests are passing on Windows under Cirrus CI:
http
ue.
> With the attached patch, we could remove the procedure
> terminate_backend_and_wait altogether. Thoughts?
That's clearly better, and logically it would work. As those tests
are new in 14, it may be a good idea to cleanup all that so as all the
branches have the same set
While making the feature run on some test server, I have noticed that
%Q would log some garbage query ID for autovacuum workers that's kept
around. That looks wrong.
Thoughts?
--
Michael
signature.asc
Description: PGP signature
Hi,
On Mon, Apr 12, 2021 at 02:56:59PM +0800, Julien Rouhaud wrote:
> On Mon, Apr 12, 2021 at 03:12:40PM +0900, Michael Paquier wrote:
> > Fujii-san has reported on Twitter that enabling the computation of
> > query IDs does not work properly with log_statement as the query ID is
s can be
> reproduced by trying to run "START_REPLICATION" via psql.
Yes, that's another problem, and this causes an infinite loop where
we would just report one error previously :/
--
Michael
signature.asc
Description: PGP signature
THRESHOLD_PAGES as
parameter name. For all the other parameters of autovacuum, we use
"threshold" for a fixed number of items, not a percentage of a given
item.
--
Michael
signature.asc
Description: PGP signature
nother solution would be to make use
of schema_include_oids to filter out the schemas we don't want, but
that would mean that --extension gets priority over --schema or
--table but we did ot want that per the original discussion.
--
Michael
signature.asc
Description: PGP signature
hing that needs to be
acted on here for the moment, I would just close the case. If there
are more voices in favor of the SQL function using mkdir(), I would
not object to use that, as that looks to work for all the cases where
pg_regress is used.
--
Michael
signature.asc
Description: PGP signature
On Mon, Apr 12, 2021 at 01:40:52AM -0400, Tom Lane wrote:
> Michael Paquier writes:
>> However, I'd like to think that we can do better than what's proposed
>> in the patch. There are a couple of things to consider here:
>> - Should the parameter be renamed to
bit first to see if Fujii-san has any
objections to this cleanup as that's his code originally, from
32a9c0bd.
--
Michael
signature.asc
Description: PGP signature
On Tue, Apr 13, 2021 at 08:00:34AM -0700, Noah Misch wrote:
> On Tue, Apr 13, 2021 at 02:43:11PM +0900, Michael Paquier wrote:
>>> - If extschema='public', "pg_dump -e plpgsql --schema=public" includes
>>> commands to dump the relation data. This
On Sat, Jul 18, 2020 at 04:49:23PM +0530, vignesh C wrote:
> Thanks Michael for the clarification, the patch looks fine to me.
Thanks for the confirmation, committed.
--
Michael
signature.asc
Description: PGP signature
oup leader with a PID match but not a
backend type check so as this could be useful for other types of
processes. This leads me to the attached with the docs updated
(tested with read-only pgbench spawning parallel workers with
pg_stat_activity queried in parallel), to be applied down to 13.
Thoug
On Mon, Jul 20, 2020 at 11:12:31PM -0500, Justin Pryzby wrote:
> On Tue, Jul 21, 2020 at 12:51:45PM +0900, Michael Paquier wrote:
> The documentation could talk about either:
>
> 1) "lock group leader" - low-level, raw view of the internal data structure
> (with a seco
query for a query before
that.
--
Michael
signature.asc
Description: PGP signature
n line with the upstream docs:
https://www.openssl.org/docs/manmaster/man7/OPENSSL_API_COMPAT.html
So we are all good.
--
Michael
signature.asc
Description: PGP signature
ent and bypass its execution. I think
that using a plpgsql function wrapping an ALTER TABLE query with an
exception block for an error generated by an event trigger if seeing
table_rewrite allows to do that, though.
--
Michael
signature.asc
Description: PGP signature
On Tue, Jul 21, 2020 at 06:25:00PM -0400, Tom Lane wrote:
> Ugh. It's clear from your stack trace that neqjoinsel() has forgotten to
> pass through collation to eqjoinsel(). Will fix.
Why didn't you include a regression test in bd0d893?
--
Michael
signature.asc
Description: PGP signature
the file.
Thanks, fixed. The style of the surroundings is to not use an hyphen,
so fine by me to stick with that.
--
Michael
signature.asc
Description: PGP signature
default engine, 1.0.2
only the PID but RAND_cleanup is a no-op only after 1.1.0).
--
Michael
signature.asc
Description: PGP signature
eit negligibly)
> increase seed predictability, I like your decision here.
Thanks Noah for taking care of it. No plans for a backpatch, right?
--
Michael
signature.asc
Description: PGP signature
Sounds fine to me. Thanks.
Do others have any objections with this wording?
--
Michael
signature.asc
Description: PGP signature
t of null doesn't apply.
Sorry for the confusion. This part of the thread applies to the open
item for v13 related to pg_stat_activity's leader_pid. A different
thread should have been spawned for this specific topic, but things
are as they are..
--
Michael
signature.asc
Description: PGP signature
her areas impacted,
and I'll try to take care at the beginning of next week.
--
Michael
signature.asc
Description: PGP signature
invalid value. This could confuse some users. Note that we are
careful enough to not print a context message if the block number is
invalid.
--
Michael
signature.asc
Description: PGP signature
ver a
> bug, fixed in 1.1.1d or thereabouts as CVE-2019-1549, where the fork
> protection
> wasn't activated by default.. so there is that. Since that bug was found,
> there has been tests introduced to catch any regression on that which is
> comforting.
No idea about this one actually.
--
Michael
signature.asc
Description: PGP signature
On Thu, Jul 23, 2020 at 09:52:14AM +0900, Michael Paquier wrote:
> Sounds fine to me. Thanks.
>
> Do others have any objections with this wording?
I have used the wording suggested by Alvaro, and applied the patch
down to 13. Now let's see about the original item of this threa
On Sat, Jul 25, 2020 at 06:17:42PM +0900, Michael Paquier wrote:
> ECPGset_noind_null() and ECPGis_noind_null() in misc.c show that
> ECPGgeneric_bytea is attached to ECPGt_bytea. The two structures may
> be the same now, but if a bug fix or a code change involves a change
> in t
ant. I am not
sure that if it is worth the time spent here though, as it took
roughly 10 years to notice the problem (and I don't really count the
time where the tool was under src/tools/ but this did not build the
tool on Windows).
--
Michael
signature.asc
Description: PGP signature
PGPROC *leader = MyProc->lockGroupLeader;
> +if (leader && leader->pid != MyProcPid)
> +appendStringInfo(&buf, "%d", leader->pid);
> +}
> +
Same here.
Except for those nits, I have tested the patch and things behave as we
want (including padding and docs), so this looks good to me.
--
Michael
signature.asc
Description: PGP signature
Oids are unsigned. We don't backpatch such things
usually, do we? Particularly, this one should not be triggerable
normally because no code paths should call JsonEncodeDateTime() with
an unsupported type Oid.
--
Michael
signature.asc
Description: PGP signature
On Tue, Jul 28, 2020 at 10:35:54AM -0400, Tom Lane wrote:
> Yeah, given that it should be an unreachable case, there's likely
> no need to back-patch.
Thanks. Fixed on HEAD then.
--
Michael
signature.asc
Description: PGP signature
fine enough here.
> I don't know what the policy is on backpatching doc fixes, but
> personally I think it should be.
This is actually a bug fix, because we include in the docs some
incorrect information, so it should be backpatched. If there are no
objections, I'll t
you notice that
your new Query_for_list_of_vacuumables becomes the same query as
Query_for_list_of_indexables? You can make your patch more simple.
--
Michael
signature.asc
Description: PGP signature
On Wed, Jul 01, 2020 at 06:24:18PM +0900, Michael Paquier wrote:
> I am not sure either, still it looks worth thinking about it.
> Attached is a rebased version of the last patch. What this currently
> holds is just the switch to heap_multi_insert() for the three catalogs
>
eds to be applied to the translation
repository first though:
https://git.postgresql.org/gitweb/?p=pgtranslation/messages.git;a=summary
I am adding Alvaro and Peter in CC as they take care of that usually
(I don't think I have an access to this repo).
--
Michael
signature.asc
Description: PGP signature
sted to
the user at all for any command. This comes down to the same point
that we don't have pg_toast in search_path, and going down to this
level of operations is an expert-level mode, not something we should
recommend to the average user in psql IMO.
--
Michael
signature.asc
Description: PGP signature
ndling of
dependencies for ALTER TABLE mainly.
--
Michael
diff --git a/src/include/catalog/heap.h b/src/include/catalog/heap.h
index cbfdfe2abe..d31141c1a2 100644
--- a/src/include/catalog/heap.h
+++ b/src/include/catalog/heap.h
@@ -93,10 +93,11 @@ extern void heap_truncate_check_FKs(List *relat
of_indexables to not say "index creation", but just
"supporting indexing" instead.
Fujii-san, perhaps you would prefer taking care of this patch? I am
fine to do it if you wish.
--
Michael
signature.asc
Description: PGP signature
d not
be possible anymore to make the difference in the stats between what
one or the other do.
--
Michael
signature.asc
Description: PGP signature
On Wed, Jul 29, 2020 at 03:06:58PM +0900, Michael Paquier wrote:
> This is actually a bug fix, because we include in the docs some
> incorrect information, so it should be backpatched. If there are no
> objections, I'll take care of that.
And done.
--
Michael
signature.asc
De
ed */
> + longlocal_blks_dirtied; /* # of local blocks dirtied */
Indeed. Let's fix this.
--
Michael
signature.asc
Description: PGP signature
pg_namespace rows and I
have not looked how to do that, but I feel that it may not be that
complicated.
For now I have applied the proposed patch.
--
Michael
signature.asc
Description: PGP signature
es in
the python or OpenSSL paths (see beb2516 and ad7595b).
--
Michael
signature.asc
Description: PGP signature
t. The attached fixes this regression by delaying the
slot initialization until we know that it will be used. This does not
matter for pg_attribute as we know in advance the number of attributes
to insert.
--
Michael
diff --git a/src/backend/catalog/pg_shdepend.c b/src/backend/catalog/pg_shdepend.c
On Thu, Jul 30, 2020 at 05:57:40PM +0900, Michael Paquier wrote:
> Indeed. Let's fix this.
And done.
--
Michael
signature.asc
Description: PGP signature
ww.postgresql.org/docs/current/install-windows-full.html#id-1.6.4.8.8
--
Michael
signature.asc
Description: PGP signature
or
pg_regress_check and pg_regress_installcheck.
--
Michael
signature.asc
Description: PGP signature
, but Windows is a
platform full of undiscovered mysteries, and I have never seen the
output of cl being an issue even for some of my company work, which
uses stuff much more fancy than the normal way of compiling on
Windows, requiring me to patch a bit the scripts of src/tools/msvc/ in
a different way.
--
Michael
signature.asc
Description: PGP signature
privacy; gen_random_uuid() may come closest.
FWIW, I am not sure that we need extra level of complexity when it
comes to random number generation, so having only one API to rule them
all sounds sensible to me, particularly if we know that the API used
has more private protections.
--
Michael
signature.asc
Description: PGP signature
specific to
Windows for tab-complete.c? Also, how complicated does the proposed
patch become if we remove the dependency to Expect.pm and just rely on
IO::Pty?
--
Michael
signature.asc
Description: PGP signature
moved unnecessary header inclusion, etc.), and committed it,
meaning that we are done here.
--
Michael
signature.asc
Description: PGP signature
sing_toast_table);
Not much a fan of the addition of this parameter on this routine to
track down if the call should process a toast relation or not.
Couldn't you just prevent the call to vacuum_rel() to happen at all?
--
Michael
signature.asc
Description: PGP signature
ly doom others. I have an idea though: we
could make the scheduling behavior of autovacuum optional.
Anyway, the thread has stalled for a couple of months now, and we
don't have a clear consensus about this approach, so I am marking this
thread as returned with feedback.
--
Michael
signature.asc
Description: PGP signature
ome testing done on other hardware.
Worth noting that the patch set fails to apply. I have moved this
entry to the next CF, waiting on author.
--
Michael
signature.asc
Description: PGP signature
once a rebase
is done.
--
Michael
signature.asc
Description: PGP signature
eed, applied. I can reproduce the failure easily, and bdd6e9b is
the previous fix you are mentioning. It is the only test where we
don't rely on an $common_connstr that sets sslcert and sslrootcert to
an invalid value, so the rest looks fine.
--
Michael
signature.asc
Description: PGP signature
y the code your change makes sense. Still, there could be a
point in keeping this optimization, but fix the comment to remove the
platform-dependent part of it. Any thoughts?
--
Michael
signature.asc
Description: PGP signature
ference. Indeed it looks that it would hurt
even with just a simple PL function.
--
Michael
signature.asc
Description: PGP signature
of vacuum though. So let's see first
if others have an opinion to offer.
--
Michael
signature.asc
Description: PGP signature
being critical issues, but let's fix them at least
on HEAD. So, please see the attached, where I have also added some
basic TAP tests for both tools.
Thanks,
--
Michael
diff --git a/src/bin/pg_test_fsync/.gitignore b/src/bin/pg_test_fsync/.gitignore
index f3b5932498..5eb5085f45 100644
---
commit fest. Thoughts are
welcome.
Thanks,
--
Michael
From cd117fa88938c89ac953a5e3c036828337150b07 Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Fri, 7 Aug 2020 10:57:40 +0900
Subject: [PATCH 1/2] Use multi-inserts for pg_depend
This is a follow-up of the work done in e3931d01. This case
On Fri, Aug 07, 2020 at 03:16:19PM +0900, Michael Paquier wrote:
> I am adding this thread to the next commit fest. Thoughts are
> welcome.
Forgot to mention that this is based on some initial work from Daniel,
and that we have discussed the issue before I worked on it.
--
M
h
restrictive REVOKE privileges, but I am not sure that we have enough
user cases to justify this addition.
--
Michael
signature.asc
Description: PGP signature
an inconsistent state.
--
Michael
signature.asc
Description: PGP signature
been looking at that stuff again,
and restore_command can be called in the context of a WAL sender
process within the page_read callback of logical decoding via
XLogReadDetermineTimeline(), as readTimeLineHistory() could look for a
timeline history file. So restore_command is not used on
the LSN that points to the beginning of the most recently
> flushed WAL segment.
>
> The patch passes tests under src/test/recovery and top level “make check”.
I have not really looked at the proposed patch, but it would be good
to have some documentation.
--
Michael
signature.asc
Description: PGP signature
esent, as CONCURRENTLY goes missing.
The presence of CONCURRENTLY makes the completion a bit more complex
than the other commands, as we need to add this keyword if still not
specified with the other objects of the wanted type to reindex, but it
can be done as the attached. What do you think?
--
Michae
hat for the most
support, so we need to live with that. I wonder if we should simplify
ReindexStmt and move the "concurrent" flag to be under "options", but
that may not be worth the time spent on as long as we don't have
CONCURRENTLY part of the parenthesized grammar.
--
Michael
signature.asc
Description: PGP signature
s that we are sure will be inserted after doing a first
pass to discard the unwanted entries.
> Seems several places have been modified to new APIs despite only
> covering a single dependency. Perhaps worth mentioning?
Yeah, I need to think more about this commit message.
--
Michael
signature.asc
Description: PGP signature
c() looks at
some of the block information, so there are overlaps. It may be
worth thinking about showing more information for has_image and
apply_image if a block is in_use?
--
Michael
signature.asc
Description: PGP signature
On Sun, Aug 09, 2020 at 06:44:23PM -0500, Justin Pryzby wrote:
> On Sun, Aug 09, 2020 at 02:00:09PM +0900, Michael Paquier wrote:
>> For now, I would recommend to focus first on 0001 to add support for
>> partitioned tables and indexes to REINDEX. CIC is much more
>> complica
On Wed, Aug 12, 2020 at 12:28:20AM -0500, Justin Pryzby wrote:
> On Wed, Aug 12, 2020 at 01:54:38PM +0900, Michael Paquier wrote:
>> +++ b/src/backend/catalog/index.c
>> @@ -3661,20 +3662,12 @@ reindex_relation(Oid relid, int flags, int options)
>> +elog(ERROR,
, see for example sepgsql_set_client_label, so this
clarifies things.
Any thoughts?
--
Michael
diff --git a/contrib/sepgsql/label.c b/contrib/sepgsql/label.c
index 32e405530b..b00b91df5a 100644
--- a/contrib/sepgsql/label.c
+++ b/contrib/sepgsql/label.c
@@ -120,7 +120,7 @@ sepgsql_set_client_label
at it?
>
> Seconded.
Thirded.
--
Michael
signature.asc
Description: PGP signature
test that
fails on HEAD with a cache lookup failure. I am adding that to the
next CF for now, and I would rather fix this issue before moving on
with REINDEX for partitioned relations as fixing this issue reduces
the use of session locks for partition trees.
Any thoughts?
--
Michael
diff -
aking one infinity
> value to become some other infinity value sounds useless.
>
> So I agree with what Andres said. Let's have just one such define and
> be done with it.
Okay. Would src/include/catalog/catalog.h be a suited location for
this flag or somebody has a better idea?
--
Michael
signature.asc
Description: PGP signature
27;s the version of libselinux used in rhinoceros? 2.5?
Based on this information, what if we increased the minimum support to
2.3 then? That's a release from 2014, and maintaining such legacy
code does not seem much worth the effort IMO.
--
Michael
signature.asc
Description: PGP signature
ks, I think
> we're fine. So based on this, no objection, and I think no need to
> change our statement about what's supported.
Okay, thanks for confirming. Let's do so then, I'll just wait a bit
to see if there are more comments from others.
--
Michael
signature.asc
Description: PGP signature
ike MAX_CATALOG_INSERT_BYTES or such I guess.
--
Michael
signature.asc
Description: PGP signature
On Thu, Aug 13, 2020 at 06:54:41AM -0400, Joe Conway wrote:
> On 8/13/20 1:22 AM, Michael Paquier wrote:
>> Joe, what's the version of libselinux used in rhinoceros? 2.5?
>
> rpm -q libselinux
> libselinux-2.5-15.el7.x86_64
Thanks!
--
Michael
signature.asc
Description: PGP signature
901 - 1000 of 12102 matches
Mail list logo
