Noah Misch writes:
> Done. This upset one buildfarm member so far:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gaur=2021-06-29%2001%3A43%3A14
> I don't know what happened there. Tom, could you post a tar of the
> src/bin/pg_dump/tmp_check/tmp_test_* directory after a failed "make
On Mon, 1 Feb 2021 at 18:42, Craig Ringer
wrote:
> On Sun, 24 Jan 2021 at 09:12, Andres Freund wrote:
>
>> Hi,
>>
>> On 2021-01-19 14:16:07 +0800, Craig Ringer wrote:
>> > AFAICS it'd be necessary to expand PROCLOG to expose this in shmem.
>> > Probably by adding a small bitfield where bit 0 is
On Sun, May 02, 2021 at 10:57:47PM -0700, Noah Misch wrote:
> On Sat, May 01, 2021 at 09:43:36AM -0700, Zhihong Yu wrote:
> > On Sat, May 1, 2021 at 8:16 AM Asif Rehman wrote:
> > > The new status of this patch is: Ready for Committer
> I'll push this when v15 branches.
Done. This upset one
On Sat, 20 Mar 2021 at 03:46, Tom Lane wrote:
> Robert Haas writes:
> > On Fri, Mar 19, 2021 at 3:25 PM Tom Lane wrote:
> >> I'm not very comfortable about the idea of having the postmaster set
> >> child processes' latches ... that doesn't sound terribly safe from the
> >> standpoint of not
Laurenz,
Thanks for your comments. Sorry it's taken me so long to get back to you.
Commenting inline below on anything I think needs comment; other proposed
changes look good.
On Sun, 30 May 2021 at 19:20, Laurenz Albe wrote:
> + always use
On Tue, Jun 22, 2021 at 09:11:26AM +0900, Michael Paquier wrote:
> What about the following error then? Say:
> "image at %X/%X compressed with LZ4 not supported by build, block
> %d".
>
>> Also, maybe %s can be inlined to lz4 in this case.
>
> I think that's a remnant of the zstd part of the
On Friday, June 25, 2021 2:25 AM vignesh C wrote:
>
> Thanks for reporting these warnings, I have fixed this in the v8 patch
> attached at [1].
> [1] - https://www.postgresql.org/message-
> id/CALDaNm044P_cds1OxZvFse5rE_qQfhbUg5MdtMgsa7t_bZGJdw%40mail.
> gmail.com
>
Thanks for your patch. The
On Mon, Jun 28, 2021 at 11:02 AM vignesh C wrote:
>
> On Mon, Jun 7, 2021 at 2:38 PM Amit Kapila wrote:
> >
> > On Thu, Jun 3, 2021 at 10:39 PM Tom Lane wrote:
> > >
>
> Attached patch has the documentation changes for the back-branches. As
> there is no specific reason for this, I have just
On Tue, Jun 29, 2021 at 10:29:43AM +0800, Julien Rouhaud wrote:
> On Tue, Jun 29, 2021 at 10:09 AM Justin Pryzby wrote:
>
> Is "identical structure" really accurate here? For instance a multi
> tenant application could rely on the search_path and only use
> unqualified relation name. So while
On Tue, Jun 29, 2021 at 10:09 AM Justin Pryzby wrote:
>
> Checking back - here's the latest patch.
>
> diff --git a/doc/src/sgml/pgstatstatements.sgml
> b/doc/src/sgml/pgstatstatements.sgml
> index 930081c429..9e98472c5c 100644
> --- a/doc/src/sgml/pgstatstatements.sgml
> +++
On Mon, Jun 28, 2021 at 09:01:40PM -0400, Bruce Momjian wrote:
> On Fri, Jun 25, 2021 at 06:04:56PM -0500, Justin Pryzby wrote:
> > > The postgres_fdw supports these type of scans if async_capable is set.
> > this type
> > remove "The" ?
>
> New text is:
>
>
On Wed, Apr 21, 2021 at 10:40:07AM -0500, Justin Pryzby wrote:
> On Thu, Apr 22, 2021 at 12:13:17AM +0900, Fujii Masao wrote:
> > On 2021/04/21 23:53, Justin Pryzby wrote:
> > > Or:
> > >
> > > Enabling this parameter may incur a noticeable performance
> > > penalty,
> > >
I spotted a mistake in v3: I didn't rename ST_COMPARE_TYPE to
ST_COMPARE_RET_TYPE in the 0009 patch (well, I did, but forgot to
commit before I ran git format-patch). I won't send another tarball
just for that, but will correct it next time.
On Fri, Jun 25, 2021 at 06:04:56PM -0500, Justin Pryzby wrote:
> > Require custom server variable names to use only character which are valid
> > for unquoted SQL identifiers (Tom Lane)
>
> characters plural (since 69a58bfe4)
Fixed.
> > This is similar to how Unicode can be specified in
Hi John,
On Tue, Jun 29, 2021 at 7:13 AM John Naylor
wrote:
> I plan to do some performance testing with VACUUM, ANALYZE etc soon, to see
> if I can detect any significant differences.
Thanks!
> I did a quick check of the MacOS/clang binary size (no debug symbols):
>
> master:8108408
>
On Mon, Jun 28, 2021 at 01:42:25PM -0700, Peter Geoghegan wrote:
> On Sun, Jun 27, 2021 at 11:08 PM Peter Geoghegan wrote:
> > > That said, the relevant table is the active "alarms" table, and it
> > > would've
> > > gotten plenty of DML with no issue for months running v13.
> >
> > It might not
On Tue, 2021-04-20 at 14:19 -0700, SATYANARAYANA NARLAPURAM wrote:
> One idea here is to make the backend ignore query
> cancellation/backend termination while waiting for the synchronous
> commit ACK. This way client never reads the data that was never
> flushed remotely. The problem with this
Here I'm just reviewing a couple items in the Sorting section:
https://wiki.postgresql.org/wiki/Todo#Sorting
- Consider whether duplicate keys should be sorted by block/offset
https://www.postgresql.org/message-id/flat/23321.1205726381%40sss.pgh.pa.us
It's moot since we started requiring tid
On Sun, Jun 27, 2021 at 11:08 PM Peter Geoghegan wrote:
> > That said, the relevant table is the active "alarms" table, and it would've
> > gotten plenty of DML with no issue for months running v13.
>
> It might not have been visibly broken without assertions enabled,
> though. I sprinkled
I wrote:
> This relies on "nm" being able to work on shlibs, which it's not
> required to by POSIX. However, it seems to behave as desired even
> on my oldest dinosaurs. In any case, if "nm" doesn't work then
> we'll just not detect such problems on that platform, which should
> be OK as long as
> On 28 Jun 2021, at 21:15, Tom Lane wrote:
> I wrote:
>>> Not real sure what to do about PGTHREAD_ERROR.
>
>> I wonder if we shouldn't simply nuke that macro and change the
>> call sites into "Assert(false)".
>
> After further study this still seems like the best available choice.
While this
On Sun, 27 Jun 2021, Tom Lane wrote:
You should let the server infer its type, instead, which it can easily
do from context in this example. That is, pass zero as the type OID, or
leave out the paramTypes
Ah, thank you, that works brilliantly. Sorry for the noise!
-E
Andrew Dunstan writes:
> The README for pg_indent says:
> ./configure # "make" will not work in an unconfigured tree
> cd src/include/catalog
> make reformat-dat-files
> cd ../../..
> This looks like a case of using a sledgehammer to crack a nut.
> I did this, which amounts
The README for pg_indent says:
./configure # "make" will not work in an unconfigured tree
cd src/include/catalog
make reformat-dat-files
cd ../../..
This looks like a case of using a sledgehammer to crack a nut.
I did this, which amounts to the same thing and is faster:
On Mon, Jun 28, 2021 at 11:45 AM Arne Roland wrote:
> Hi,
>
> *From:* Zhihong Yu
> *Sent:* Monday, June 28, 2021 15:28
> *Subject:* Re: Rename of triggers for partitioned tables
>
> > -void *arg)
> > +callbackForRenameTrigger(char *relname, Oid relid)
> >
> >
I wrote:
>> Not real sure what to do about PGTHREAD_ERROR.
> I wonder if we shouldn't simply nuke that macro and change the
> call sites into "Assert(false)".
After further study this still seems like the best available choice.
We do not have the option to make either default_threadlock() or
On Wed, Jun 16, 2021 at 1:55 AM Thomas Munro wrote:
[v2 patch]
Hi Thomas,
I plan to do some performance testing with VACUUM, ANALYZE etc soon, to see
if I can detect any significant differences.
I did a quick check of the MacOS/clang binary size (no debug symbols):
master:8108408
Le 28/06/2021 à 18:41, Julien Rouhaud a écrit :
> Thanks for the feedback Gilles!
>
> On Mon, Jun 28, 2021 at 04:06:54PM +0200, Gilles Darold wrote:
>> If we could at least call get_query_def()through an extension if we didn't
>> have a functionit would be ideal for DBAs.I agree this is unusual
On 6/28/21 1:04 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> This has been completed.
> Doesn't look like the buildfarm has heard of REL_14_STABLE yet?
>
>
Will do shortly. On at least one occasion we've been caught by updating
it before the new branch had reached
Andrew Dunstan writes:
> This has been completed.
Doesn't look like the buildfarm has heard of REL_14_STABLE yet?
regards, tom lane
On 4/24/21 3:14 PM, Alvaro Herrera wrote:
> On 2021-Apr-24, Andrew Dunstan wrote:
>
>> I would like to undertake some housekeeping on PostgresNode.pm.
>>
>> 1. OO modules in perl typically don't export anything. We should remove
>> the export settings. That would mean that clients would have to
On 2021-Jun-28, Daniel Gustafsson wrote:
> I happened to spot the below call in src/bin/pg_basebackup/streamutil.c which
> has an unbounded %s in the format.
>
> /* fetch xlog value and unit from the result */
> if (sscanf(PQgetvalue(res, 0, 0), "%d%s", _val, xlog_unit) != 2)
>
> There
Fabien COELHO writes:
>> I suggest applying the attached in branches that have the required
>> functions.
> The proposed patch does fix the issue in pgbench TAP test. I'd suggest to
> add unlikely() on all these conditions, as already done elsewhere. See
> attached version.
Done that way,
Thanks for the feedback Gilles!
On Mon, Jun 28, 2021 at 04:06:54PM +0200, Gilles Darold wrote:
>
> If we could at least call get_query_def()through an extension if we didn't
> have a functionit would be ideal for DBAs.I agree this is unusual but when
> it does happen to you being able to call
> On Jun 28, 2021, at 9:05 AM, Mark Dilger wrote:
>
> Is it worth sharting a static inline function that uses your optimization in
> other places?
s/sharting/sharing/
> How confident are you that your optimization really helps?
By which I mean, is the optimization worth the extra branch
> On Jun 27, 2021, at 3:41 AM, Andrey Borodin wrote:
>
> And here's what I've come up with.
I have not tested the patch yet, but here are some quick review comments:
> #define PGLZ_HISTORY_SIZE 0x0fff - 1 /* to avoid compare in iteration
> */
...
> static PGLZ_HistEntry
On 6/27/21 10:55 AM, Andrew Dunstan wrote:
> I am planning on forking the tree so we can start adding developments
> for Postgres 15 in the upcoming commitfest. This will be done tomorrow,
> June 28, late morning US East coast time. I will be following the
> procedures laid out in
Bharath Rupireddy writes:
> On Thu, Jun 24, 2021 at 12:04 PM Michael Paquier wrote:
>> On top of that, not reacting on signals can be
>> interesting to keep as a behavior for developers?
> Yeah, it can be useful at times as it enables debugging even when the
> postmaster dies.
Dunno ... I
Andrew Dunstan writes:
> On 6/28/21 10:44 AM, Tom Lane wrote:
>> Wait ... I did already, at 5a0f1c8c0. Are you sure you were indenting
>> current HEAD?
> No, see revised patch. I posted at 10.13
Right, new version looks better.
regards, tom lane
On Thu, Jun 24, 2021 at 12:04 PM Michael Paquier wrote:
>
> On Tue, Apr 20, 2021 at 07:36:39AM +0530, Bharath Rupireddy wrote:
> > I'm attaching 3 patches that replace pg_usleep with WaitLatch: 0001 in
> > lazy_truncate_heap, 0002 in do_pg_stop_backup and 0003 for Pre and
> > Post Auth Delay.
On 6/28/21 10:44 AM, Tom Lane wrote:
> I wrote:
>> Andrew Dunstan writes:
>>> I'll let Tom speak for himself, but I somewhat doubt he meant the code
>>> to stay badly indented for more than a short period of time.
>> I did not. If you can give me an hour or so, I'll get the patch
>> I
> On 28 Jun 2021, at 16:02, Tom Lane wrote:
> Ugh. Shouldn't we instead modify the format to read not more than
> two characters? Even if this is safe on non-malicious input, it
> doesn't seem like good style.
No disagreement, I was only basing it on what is in the tree. I would propose
that
I wrote:
> Andrew Dunstan writes:
>> I'll let Tom speak for himself, but I somewhat doubt he meant the code
>> to stay badly indented for more than a short period of time.
> I did not. If you can give me an hour or so, I'll get the patch
> I previously proposed [1] committed, and then this
Andrew Dunstan writes:
> On 6/28/21 8:52 AM, David Rowley wrote:
>> I wasn't too sure about the status of this one. Michael did mention it
>> in [1], but Tom mentioned that was on purpose to ease backpatching.
>> I'm not too clear on if Tom intended it should stay unindented until
>> "rewriting
Peter Eisentraut writes:
> There are certain parts of code that laboriously initialize every field
> of a struct to (some spelling of) zero, even though the whole struct was
> just zeroed (by makeNode() or memset()) a few lines earlier.
FWIW, I think that it's an intentional style choice to
On 6/28/21 8:29 AM, Andrew Dunstan wrote:
> Here's the diff from a pgindent run. The results look kosher to me - I
> had to do a little surgery on queryjumble.h due to it having an unused
> typedef.
>
>
This time run against the right branch ..
cheers
andrew
--
Andrew Dunstan
EDB:
Le 27/06/2021 à 17:14, Tom Lane a écrit :
Julien Rouhaud writes:
On Sun, Jun 27, 2021 at 10:34:52AM -0400, Tom Lane wrote:
It's not very hard to imagine someday moving view
expansion into the planner on efficiency grounds, leaving the rewriter
handling only the rare uses of
Daniel Gustafsson writes:
> I happened to spot the below call in src/bin/pg_basebackup/streamutil.c which
> has an unbounded %s in the format.
> /* fetch xlog value and unit from the result */
> if (sscanf(PQgetvalue(res, 0, 0), "%d%s", _val, xlog_unit) != 2)
> There is no risk of
Fabien COELHO writes:
> A possible trick is to add ccp flags such as: -Dexit=exit_BAD
> -Dabort=abort_BAD.
Not really going to work, at least not without a lot of fragile
kluges, because the main problem here is to prevent libpq from
*indirectly* calling those functions via stuff it imports
Michael Paquier writes:
> On Sat, Jun 26, 2021 at 05:29:29PM -0400, Tom Lane wrote:
>> I'll stick this into the CF list to see if the cfbot agrees that
>> it finds the abort() problems...
> The CF Bot is finding those problems.
>> +# Check for functions that libpq must not call.
>> +# (If nm
On Mon, 2021-06-28 at 23:46 +1200, David Rowley wrote:
> On Sat, 26 Jun 2021 at 16:41, Justin Pryzby wrote:
> > On Thu, Jun 24, 2021 at 10:27:06AM +1200, David Rowley wrote:
> > > I think the reasons for doing operations directly on partitions are
> > > being reduced with each release. What
On 6/28/21 8:52 AM, David Rowley wrote:
> On Tue, 29 Jun 2021 at 00:29, Andrew Dunstan wrote:
>> Here's the diff from a pgindent run.
> --- a/src/backend/commands/policy.c
> +++ b/src/backend/commands/policy.c
> @@ -587,65 +587,65 @@ RemoveRoleFromObjectPolicy(Oid roleid, Oid
> classid, Oid
I happened to spot the below call in src/bin/pg_basebackup/streamutil.c which
has an unbounded %s in the format.
/* fetch xlog value and unit from the result */
if (sscanf(PQgetvalue(res, 0, 0), "%d%s", _val, xlog_unit) != 2)
There is no risk of overflow as the unit is defined to be at
Alvaro Herrera writes:
> I forgot to mention:
>
> > + /* XXX useless without a flush ...? */
> > + pqFlush(conn);
> > +
> > + return 1;
> > +}
>
> I'm not sure if it's a good idea for PQrequestFlush to itself flush
> libpq's buffer. We can just document that PQflush is required ...
>
On Tue, 29 Jun 2021 at 00:29, Andrew Dunstan wrote:
> Here's the diff from a pgindent run.
--- a/src/backend/commands/policy.c
+++ b/src/backend/commands/policy.c
@@ -587,65 +587,65 @@ RemoveRoleFromObjectPolicy(Oid roleid, Oid
classid, Oid policy_id)
/* If any roles remain, update the policy
On 6/28/21 2:39 AM, Peter Geoghegan wrote:
> On Sun, Jun 27, 2021 at 4:23 PM Andrew Dunstan wrote:
>
>> In practical terms, there is an awful lot of head room between the
>> default for autovacuum_freeze_max_age and any danger of major
>> anti-wraparound measures. Say you increase it to 1bn
Here's the diff from a pgindent run. The results look kosher to me - I
had to do a little surgery on queryjumble.h due to it having an unused
typedef.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
diff --git a/src/backend/access/heap/hio.c b/src/backend/access/heap/hio.c
On Mon, 28 Jun 2021 at 15:59, Amit Langote wrote:
>
> On Fri, Jun 25, 2021 at 10:26 AM David Rowley wrote:
> > I wonder, since we can't delay taking locks until after run-time
> > pruning due to being unable to invalidate cached plans, maybe instead
> > we could tag on any PartitionPruneInfo
> On 28 Jun 2021, at 11:59, Peter Eisentraut
> wrote:
>
> There are certain parts of code that laboriously initialize every field of a
> struct to (some spelling of) zero, even though the whole struct was just
> zeroed (by makeNode() or memset()) a few lines earlier. Besides being
>
On Sat, 26 Jun 2021 at 16:41, Justin Pryzby wrote:
>
> On Thu, Jun 24, 2021 at 10:27:06AM +1200, David Rowley wrote:
> > I think the reasons for doing operations directly on partitions are
> > being reduced with each release. What operations do people really
> > need to do on partitions now?
On Mon, 28 Jun 2021 at 21:59, Peter Eisentraut
wrote:
>
> There are certain parts of code that laboriously initialize every field
> of a struct to (some spelling of) zero, even though the whole struct was
> just zeroed (by makeNode() or memset()) a few lines earlier. Besides
> being redundant, I
On Mon, 28 Jun 2021 at 21:16, Dean Rasheed wrote:
> So the second patch fixes this by adding new numericvar_send/recv()
> functions capable of sending the full precision NumericVar's from each
> worker, without rounding. The first test case in this patch is an
> example that would round the wrong
Em seg., 28 de jun. de 2021 às 00:29, Michael Paquier
escreveu:
> On Mon, Jun 28, 2021 at 10:17:55AM +1000, Peter Smith wrote:
> > IIUC for the case ALTER_SUBSCRIPTION_DROP_PUBLICATION it looks like
> > the uninitialized copy_data local stack var would remain uninitialized
> > (undefined) still
Em dom., 27 de jun. de 2021 às 21:18, Peter Smith
escreveu:
> On Fri, Jun 25, 2021 at 11:55 PM Ranier Vilela
> wrote:
> >
> >
> >
> https://github.com/postgres/postgres/commit/3af10943ce21450e299b3915b9cad47cd90369e9
> > fixes some issues with subscriptioncmds.c, but IMHO still lack this
>
> On 18 May 2021, at 15:50, Heikki Linnakangas wrote:
> The reason is that if you specify multiple --rmgr options, only the last one
> takes effect.
That's in line with how options are handled for most binaries, so this will go
against that. That being said, I don't think thats a problem here
Hi!
From: Zhihong Yu
Sent: Saturday, June 26, 2021 20:32
Subject: Re: Rename of triggers for partitioned tables
> Hi, Arne:
> It seems the patch no longer applies cleanly on master branch.
> Do you mind updating the patch ?
>
> Thanks
Thank you for having a look! Please let me know if the
On Fri, Jun 18, 2021 at 6:35 PM Bharath Rupireddy
wrote:
> > PSA v5 patch set.
>
> PSA v6 patch set rebased onto the latest master.
PSA v7 patch set rebased onto the latest master.
With Regards,
Bharath Rupireddy.
v7-0001-Refactor-parse_subscription_options.patch
Description: Binary data
On Mon, Jun 21, 2021 at 4:40 PM houzj.f...@fujitsu.com
wrote:
>
> To be honest, I didn't find a cheap way to invalidate partitioned table's
> parallel safety automatically.
>
I also don't see the feasibility for doing parallelism checks for
partitioned tables both because it is expensive due to
I found a couple of places where numeric multiplication suffers from
overflow errors for inputs that aren't necessarily very large in
magnitude.
The first is with the numeric * operator, which attempts to always
produce the exact result, even though the numeric type has a maximum
of 16383 digits
On Mon, Jun 28, 2021 at 5:36 AM Peter Geoghegan wrote:
>
> The wraparound failsafe mechanism added by commit 1e55e7d1 had minimal
> documentation -- just a basic description of how the GUCs work. I
> think that it certainly merits some discussion under "25.1. Routine
> Vacuuming" -- more
On Tue, Jun 22, 2021 at 9:18 AM osumi.takami...@fujitsu.com
wrote:
>
> On Tuesday, June 22, 2021 11:08 AM Japin Li wrote:
> > > Your patch appears to be on the lines we discussed but I would prefer
> > > to get it done after Beta2 as this is just a minor code improvement.
> > > Can you please
On 2019-11-29 05:32, Michael Paquier wrote:
These comments are unanswered for more than 2 months, so I am marking
this entry as returned with feedback.
I'd like to revive this patch. To make further work easier, attaching a
rebased version of the latest patch by Alexander.
As for having yet
+# Check for functions that libpq must not call.
+# (If nm doesn't exist or doesn't work on shlibs, this test will silently
+# do nothing, which is fine.)
+.PHONY: check-libpq-refs
+check-libpq-refs: $(shlib)
+ @! nm -A -g -u $< 2>/dev/null | grep -e abort -e exit
"abort" and "exit"
Hello Tom,
moonjelly just reported an interesting failure [1].
I noticed. I was planning to have a look at it, thanks for digging!
It seems that with the latest bleeding-edge gcc, this code is
misoptimized:
else if (imax - imin < 0 || (imax - imin) + 1 < 0)
> 28 июня 2021 г., в 12:36, Michael Paquier написал(а):
>
> Removing "allows_streaming => 1" in 011_crash_recovery.pl is enough to
> make the test fail on HEAD. And the test fails equally without or
> without any changes related to wal_compression, so adding or removing
> options to
On Mon, Jun 28, 2021 at 04:36:42PM +0900, Michael Paquier wrote:
> Is this issue different than the XID problem not matching when using
> wal_level = minimal in test 011_crash_recovery.pl? I am not sure to
> understand if you are
(This paragraph has been cut in half)
referring to a different
On Sat, Jun 26, 2021 at 05:29:29PM -0400, Tom Lane wrote:
> I'll stick this into the CF list to see if the cfbot agrees that
> it finds the abort() problems...
The CF Bot is finding those problems.
> +# Check for functions that libpq must not call.
> +# (If nm doesn't exist or doesn't work on
On Sat, Jun 26, 2021 at 06:11:26PM -0500, Justin Pryzby wrote:
> Curious. I found that before a4d75c86bf, there was an issue without the
> "extra" patches.
Is this issue different than the XID problem not matching when using
wal_level = minimal in test 011_crash_recovery.pl? I am not sure to
On Sun, Jun 27, 2021 at 4:23 PM Andrew Dunstan wrote:
> AIUI, actual wraparound (i.e. an xid crossing the event horizon so it
> appears to be in the future) is no longer possible. But it once was a
> very real danger. Maybe the docs haven't quite caught up.
This was added a few years after
On Mon, Jun 28, 2021 at 9:50 AM Amit Langote wrote:
>
> On Thu, Jun 24, 2021 at 7:27 AM David Rowley wrote:
> > On Wed, 23 Jun 2021 at 21:07, Amit Kapila wrote:
> > > I noticed that while inserting directly into a partition table we
> > > compute the PartitionCheckExpr by traversing all the
On Mon, Jun 28, 2021 at 12:58 PM Amit Langote wrote:
> On Fri, Jun 25, 2021 at 10:26 AM David Rowley wrote:
> > On Thu, 24 Jun 2021 at 12:32, David Rowley wrote:
> > > The overhead of taking these locks is pretty significant for
> > > partitioned tables with lots of partitions where only 1 of
On Sun, Jun 27, 2021 at 6:47 PM Justin Pryzby wrote:
> I've just realized that this VM has a strange storage configuration.
>
> It's using LVM thin pools, which I don't use anywhere else.
> Someone else set this up, and I think I've literally never used pools before.
> Some time ago, the pool ran
82 matches
Mail list logo
