On Mon, Mar 30, 2020 at 9:56 PM Justin Pryzby wrote:
>
> On Mon, Mar 30, 2020 at 02:31:53PM +0530, Amit Kapila wrote:
> > The v37-0003-Avoid-some-calls-to-RelationGetRelationName.patch looks
> > good to me. I have added the commit message in the patch.
>
> I realized the 0003 patch has an error i
On Sat, Mar 28, 2020 at 06:05:51PM +0300, Alexander Korotkov wrote:
> On Wed, Mar 18, 2020 at 3:28 AM Nikita Glukhov
> wrote:
> > Attached new version of reordered patches.
>
> I'm going to push this if no objections.
Find attached patch with editorial corrections to docs for this commit.
--wo
On Mon, Mar 30, 2020 at 9:59 AM Tom Lane wrote:
>
> Amit Kapila writes:
> > On Sat, Mar 28, 2020 at 8:02 PM James Coleman wrote:
> >> I'm curious if Tom's objection is mostly on the grounds that we should
> >> be consistent in what's displayed, or that he thinks the information
> >> is likely to
[ not a review, just some drive-by comments on David's comments ]
David Rowley writes:
> 2. The following change does not seem like it should be part of this
> patch. I understand you perhaps have done as you think it will
> improve the performance of checking if an expression is in a list of
>
On 2020/03/31 3:16, Julien Rouhaud wrote:
On Mon, Mar 30, 2020 at 6:36 PM Fujii Masao wrote:
On 2020/03/30 17:03, Julien Rouhaud wrote:
On Mon, Mar 30, 2020 at 01:56:43PM +0900, Fujii Masao wrote:
On 2020/03/29 15:15, Julien Rouhaud wrote:
On Fri, Mar 27, 2020 at 03:42:50PM +0100, Juli
On Tue, Mar 31, 2020 at 07:50:45AM +0530, Amit Kapila wrote:
> On Mon, Mar 30, 2020 at 9:56 PM Justin Pryzby wrote:
> >
> > On Mon, Mar 30, 2020 at 02:31:53PM +0530, Amit Kapila wrote:
> > > The v37-0003-Avoid-some-calls-to-RelationGetRelationName.patch looks
> > > good to me. I have added the co
On Sat, 28 Mar 2020 at 22:22, David Rowley wrote:
> I'm unsure yet if this has caused an instability on lousyjack's run in
> [1].
pogona has just joined in on the fun [1], so, we're not out the woods
on this yet. I'll start having a look at this in more detail.
[1]
https://buildfarm.postgresql.
On Mon, Mar 30, 2020 at 12:31 PM Masahiko Sawada
wrote:
>
> The patch for vacuum conflicts with recent changes in vacuum. So I've
> attached rebased one.
>
+ /*
+ * Next, accumulate buffer usage. (This must wait for the workers to
+ * finish, or we might get incomplete data.)
+ */
+ for (i = 0;
On Tue, 31 Mar 2020 at 09:36, Cary Huang wrote:
>
> Hi
> I had a look on kms_v9 patch and have some comments
>
> --> pg_upgrade.c
> keys are copied correctly, but as pg_upgrade progresses further, it will try
> to start the new_cluster from "issue_warnings_and_set_wal_level()" function,
> which
On Tue, 31 Mar 2020 at 12:58, Amit Kapila wrote:
>
> On Mon, Mar 30, 2020 at 12:31 PM Masahiko Sawada
> wrote:
> >
> > The patch for vacuum conflicts with recent changes in vacuum. So I've
> > attached rebased one.
> >
>
> + /*
> + * Next, accumulate buffer usage. (This must wait for the workers
Thank you for looking this and trouble rebasing!
At Mon, 30 Mar 2020 20:03:27 -0300, Alvaro Herrera
wrote in
> I rebased this patch; it's failing to apply due to minor concurrent
> changes in PostgresNode.pm. I squashed the patches in a series that
> made the most sense to me.
>
> I have a qu
Hello,
As I wrote about an earlier version of the patch, ISTM that instead of
reinventing, extending, adapting various ls variants (with/without
metadata, which show only files, which shows target of links, which shows
directory, etc.) we would just need *one* postgres "ls" implementation
which
On Mon, Mar 30, 2020 at 12:16:31PM -0700, Andres Freund wrote:
> On 2020-03-30 15:04:55 -0400, Robert Haas wrote:
> > I guess I'd like to be clear here that I have no fundamental
> > disagreement with taking this tool in any direction that people would
> > like it to go. For me it's just a question
On Tue, Mar 31, 2020 at 12:21:43PM +0900, Fujii Masao wrote:
>
> On 2020/03/31 3:16, Julien Rouhaud wrote:
> > On Mon, Mar 30, 2020 at 6:36 PM Fujii Masao
> > wrote:
> > >
> > > While testing the patched pgss, I found that the patched version
> > > may track the statements that the original ver
On Mon, Mar 30, 2020 at 04:43:00PM +0900, Michael Paquier wrote:
> On Sun, Mar 29, 2020 at 09:41:01PM -0700, Noah Misch wrote:
> > I think attached v41nm is ready for commit. Would anyone like to vote
> > against
> > back-patching this? It's hard to justify lack of back-patch for a data-loss
> >
Hi,
On 2020-03-30 23:28:54 -0700, Noah Misch wrote:
> On Mon, Mar 30, 2020 at 04:43:00PM +0900, Michael Paquier wrote:
> > On Sun, Mar 29, 2020 at 09:41:01PM -0700, Noah Misch wrote:
> > > I think attached v41nm is ready for commit. Would anyone like to vote
> > > against
> > > back-patching thi
On Mon, Mar 30, 2020 at 05:00:01PM +0300, Alexey Kondratov wrote:
> What do think about adding following sanity check into xlogarchive.c?
>
> +#ifdef FRONTEND
> +#error "This file is not expected to be compiled for frontend code"
> +#endif
>
> It would prevent someone from adding typedefs and any
On Tue, Mar 31, 2020 at 10:44 AM Masahiko Sawada
wrote:
>
> On Tue, 31 Mar 2020 at 12:58, Amit Kapila wrote:
> >
> > On Mon, Mar 30, 2020 at 12:31 PM Masahiko Sawada
> > wrote:
> > >
> > > The patch for vacuum conflicts with recent changes in vacuum. So I've
> > > attached rebased one.
> > >
> >
On 2020-03-27 17:58, Vik Fearing wrote:
On 3/27/20 9:33 AM, Dean Rasheed wrote:
On Fri, 27 Mar 2020 at 11:29, Peter Eisentraut
wrote:
I have re-read everything and
expanded your patch a bit with additional documentation and comments in
the tests.
I looked that over, and it all looks good to
On Mon, Mar 30, 2020 at 6:14 PM Julien Rouhaud wrote:
>
> On Mon, Mar 30, 2020 at 03:52:38PM +0530, Amit Kapila wrote:
> >
> > I think the right place to compute this information is
> > XLogRecordAssemble even though we update it at the place where you
> > have it in the patch. You can probably c
101 - 120 of 120 matches
Mail list logo
