Justin Pryzby writes:
> Thanks. Here's the remainder, with some new ones.
LGTM. I tweaked one or two places a bit more, and pushed it.
regards, tom lane
On Thu, Sep 10, 2020 at 03:58:31PM +0900, Michael Paquier wrote:
> On Wed, Sep 09, 2020 at 09:37:42AM -0500, Justin Pryzby wrote:
> > I've added a few more.
>
> I have done an extra round of review on this patch series, and applied
> what looked obvious to me (basically the points already discusse
On Wed, Sep 09, 2020 at 09:37:42AM -0500, Justin Pryzby wrote:
> I've added a few more.
I have done an extra round of review on this patch series, and applied
what looked obvious to me (basically the points already discussed
upthread). Some parts applied down to 9.6 for the docs.
--
Michael
sig
I've added a few more.
--
Justin
>From 137321a0d476f66b5e5f21c2f627c407330e50b1 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Mon, 30 Mar 2020 19:43:22 -0500
Subject: [PATCH v8 01/14] doc: btree deduplication
commit 0d861bbb702f8aa05c2a4e3f1650e7e8df8c8c27
Author: Peter Geoghegan
---
doc
On Mon, Aug 31, 2020 at 08:42:08AM -0500, Justin Pryzby wrote:
> On Mon, Aug 31, 2020 at 04:28:20PM +0900, Michael Paquier wrote:
>> Wouldn't it be more simple to use "to prepare for a base backup" here?
>
> I think it's useful to say "prepare to take" since it's more specific.. It's
> not "prepa
On Tue, Aug 18, 2020 at 12:17:03PM -0500, Justin Pryzby wrote:
> The WAL sender process is currently performing
> - pg_start_backup to set up for
> - taking a base backup, and waiting for backup start
> + pg_start_backup to prepare to
> + take a base backup, and wait
I stand by these changes which I proposed handful of times since April, but not
yet included by Michael's previous commits.
--
Justin
>From f029efd79c4ad14ae003ed1a1c692931cdc33f1e Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Mon, 30 Mar 2020 19:43:22 -0500
Subject: [PATCH v6 01/10] doc: b
On Fri, Jun 12, 2020 at 09:13:02PM +0900, Michael Paquier wrote:
> I have merged 0003 and 0004 together and applied them. 0005 seems to
> have a separate issue as mentioned upthread, and I have not really
> looked at 0001 and 0002. Thanks.
And committed 0001 and 0002 after some tiny adjustments
On Thu, Jun 11, 2020 at 09:37:09PM -0500, Justin Pryzby wrote:
> Some new bits,
> And some old ones.
I have merged 0003 and 0004 together and applied them. 0005 seems to
have a separate issue as mentioned upthread, and I have not really
looked at 0001 and 0002. Thanks.
--
Michael
signature.asc
On Thu, Jun 11, 2020 at 09:37:09PM -0500, Justin Pryzby wrote:
> Some new bits,
> And some old ones.
I was looking at this patch set, and 0005 has attracted my attention
here:
> --- a/src/backend/utils/cache/relcache.c
> +++ b/src/backend/utils/cache/relcache.c
> @@ -4240,7 +4240,6 @@ AttrDefault
Some new bits,
And some old ones.
--
Justin
>From b74bef6f9d36a2fac71045ab707ed4be65730ba7 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Wed, 29 Apr 2020 13:13:29 -0500
Subject: [PATCH v5 1/5] Fix comments for WITH OIDs, removed at 578b22971
Previously mentioned here:
https://www.postgresq
On Mon, Apr 27, 2020 at 03:03:05PM +0900, Michael Paquier wrote:
> Hm, okay. There are still pieces in those patches about which I am
> not sure, so I have let that aside for the time being.
>
> Anyway, I have applied patch 12, and reported the typos from imath.c
Thank you.
I will leave this he
On Sun, Apr 26, 2020 at 08:59:05PM -0400, Tom Lane wrote:
> James Coleman writes:
>> On Sun, Apr 26, 2020 at 12:13 PM Justin Pryzby wrote:
>>> I think my text is correct. This would *also* be correct:
>>> | If any CHECK constraint on the table being
>>> | attached is marked NO INHERI
James Coleman writes:
> On Sun, Apr 26, 2020 at 12:13 PM Justin Pryzby wrote:
>> I think my text is correct. This would *also* be correct:
>> | If any CHECK constraint on the table being
>> | attached is marked NO INHERIT, the command will
>> fail;
>> But not the hybrid: "If any OF
On Sun, Apr 26, 2020 at 12:13 PM Justin Pryzby wrote:
>
> On Tue, Apr 14, 2020 at 02:47:54PM +0900, Michael Paquier wrote:
> > On Sun, Apr 12, 2020 at 04:35:45PM -0500, Justin Pryzby wrote:
> > > Added a few more.
> > > And rebased on top of dbc60c5593f26dc777a3be032bff4fb4eab1ddd1
> >
> > Thanks
On Tue, Apr 14, 2020 at 02:47:54PM +0900, Michael Paquier wrote:
> On Sun, Apr 12, 2020 at 04:35:45PM -0500, Justin Pryzby wrote:
> > Added a few more.
> > And rebased on top of dbc60c5593f26dc777a3be032bff4fb4eab1ddd1
>
> Thanks for the patch set, I have applied the most obvious parts (more
> or
On Sun, Apr 12, 2020 at 04:35:45PM -0500, Justin Pryzby wrote:
> Added a few more.
> And rebased on top of dbc60c5593f26dc777a3be032bff4fb4eab1ddd1
Thanks for the patch set, I have applied the most obvious parts (more
or less 1/3) to reduce the load. Here is a review of the rest.
> @@ -2829,7 +2
Added a few more.
And rebased on top of dbc60c5593f26dc777a3be032bff4fb4eab1ddd1
--
Justin
>From 37b796862eb8c08dbe0d1a6947a8212d1c515491 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Sun, 29 Mar 2020 19:51:32 -0500
Subject: [PATCH v3 01/20] doc: psql opclass/opfamily
commit b0b5e20cd8d1a5
On Thu, Apr 09, 2020 at 10:01:51PM -0500, Justin Pryzby wrote:
> On Fri, Apr 10, 2020 at 11:27:46AM +0900, Michael Paquier wrote:
>> required pages to remove both downlink and rightlink are already locked.
>> That
>> -evades potential right to left page locking order, which could deadlock with
On Fri, Apr 10, 2020 at 11:27:46AM +0900, Michael Paquier wrote:
> On Wed, Apr 08, 2020 at 11:56:53AM -0500, Justin Pryzby wrote:
> > I previously mailed separately about a few individual patches, some of which
> > have separate, ongoing discussion and aren't included here (incr sort,
> > parallel
On Wed, Apr 08, 2020 at 11:56:53AM -0500, Justin Pryzby wrote:
> I previously mailed separately about a few individual patches, some of which
> have separate, ongoing discussion and aren't included here (incr sort,
> parallel
> vacuum).
I have gone through your changes, and committed what looked
21 matches
Mail list logo
