On Fri, Oct 2, 2020 at 8:14 AM Kyotaro Horiguchi
wrote:
>
> At Thu, 1 Oct 2020 12:55:34 +, "k.jami...@fujitsu.com"
> wrote in
> > On Thursday, October 1, 2020 4:52 PM, Tsunakawa-san wrote:
> >
>
> (I'm still mildly opposed to the function name, which seems exposing
> detail too much.)
>
On Mon, Oct 5, 2020 at 3:37 AM Tomas Vondra
wrote:
Thanks, Tomas for your feedback.
> 9) attcompression ...
>
> The main issue I see is what the patch does with attcompression. Instead
> of just using it to store a the compression method, it's also used to
> store the preserved compression
On Mon, 5 Oct 2020 at 11:21, Robert Haas wrote:
>
> On Sat, Oct 3, 2020 at 9:25 AM Masahiko Sawada
> wrote:
> > To make the behavior of parallel vacuum more consistent with other
> > parallel maintenance commands (i.g., only parallel INDEX CREATE for
> > now), as a second idea, can we make use
At Sun, 4 Oct 2020 18:36:05 +0900, Etsuro Fujita
wrote in
> On Fri, Oct 2, 2020 at 3:39 PM Kyotaro Horiguchi
> wrote:
> > At Fri, 2 Oct 2020 09:00:53 +0900, Etsuro Fujita
> > wrote in
> > > I think we should avoid changing the ExecProcNode() API.
>
> > Could you explain about what the
On 2020/10/03 20:40, Bharath Rupireddy wrote:
On Fri, Oct 2, 2020 at 11:30 PM Fujii Masao wrote:
Attaching v8 patch, please review it.. Both make check and make
check-world passes on v8.
Thanks for updating the patch! It basically looks good to me.
I tweaked the patch as follows.
+
On Wed, Sep 16, 2020 at 9:58 PM Bharath Rupireddy
wrote:
>
> Attaching v6 patch, rebased because of a recent commit
> 3d65b0593c5578014f62e09d4008006f1783f64d. Please consider this for
> further review.
>
Few comments:
==
1.
+ /* Report error with names of the missing localrel
At Sat, 3 Oct 2020 22:25:14 +0900, Masahiko Sawada
wrote in
> On Sat, 3 Oct 2020 at 20:03, Amit Kapila wrote:
> >
> > On Wed, Sep 30, 2020 at 9:23 PM Robert Haas wrote:
> > >
> > > On Tue, Sep 22, 2020 at 3:20 AM David Rowley wrote:
> > > > It would be good if we were consistent with these
On Sat, Oct 3, 2020 at 6:55 PM Masahiko Sawada
wrote:
>
> On Sat, 3 Oct 2020 at 20:03, Amit Kapila wrote:
> >
> > On Wed, Sep 30, 2020 at 9:23 PM Robert Haas wrote:
> > >
> > > On Tue, Sep 22, 2020 at 3:20 AM David Rowley wrote:
> > > > It would be good if we were consistent with these
On Sat, Oct 3, 2020 at 9:25 AM Masahiko Sawada
wrote:
> To make the behavior of parallel vacuum more consistent with other
> parallel maintenance commands (i.g., only parallel INDEX CREATE for
> now), as a second idea, can we make use of parallel_workers reloption
> in parallel vacuum case as
On Sat, Oct 3, 2020 at 7:03 AM Amit Kapila wrote:
> But the same is true for the 'Create Index' operation as well where we
> follow the same thing. We will use the number of workers as specified
> in reloption (parallel_workers) which is then limited by
> max_parallel_maintenance_workers.
Well,
On Sat, Oct 3, 2020 at 10:10 PM James Coleman wrote:
>
> On Sat, Oct 3, 2020 at 5:44 PM Tomas Vondra
> wrote:
> >
> > On Sat, Oct 03, 2020 at 10:50:06AM -0400, James Coleman wrote:
> > >On Fri, Oct 2, 2020 at 11:16 PM James Coleman wrote:
> > >>
> > >> On Fri, Oct 2, 2020 at 7:07 PM James
On Wed, Sep 9, 2020 at 3:49 PM Thomas Munro wrote:
> On Thu, Sep 3, 2020 at 11:30 AM Thomas Munro wrote:
> > On Wed, May 27, 2020 at 12:31 AM Craig Ringer wrote:
> > > On Tue, 12 May 2020, 08:42 Paul Guo, wrote:
> > >> 1. StartupXLOG() does fsync on the whole data directory early in the
> >
On Friday, October 2, 2020 11:45 AM, Horiguchi-san wrote:
> Thaks for the new version.
Thank you for your thoughtful reviews!
I've attached an updated patch addressing the comments below.
1.
> The following description is found in the comment for FlushRelationBuffers.
>
> > * XXX
At Fri, 2 Oct 2020 22:55:45 -0400, Bruce Momjian wrote in
> On Fri, Sep 25, 2020 at 09:33:48AM +0900, Kyotaro Horiguchi wrote:
> > At Thu, 24 Sep 2020 11:43:40 -0400, Bruce Momjian wrote
> > in
> > > On Thu, Sep 24, 2020 at 12:44:01PM +0900, Michael Paquier wrote:
> > > > On Tue, Sep 01, 2020
Michael Paquier writes:
> +1. (log_line_prefix includes %p in its default configuration for the
> TAP tests).
Right, but of course you don't get log_line_prefix on Assert messages.
regards, tom lane
If you run the core regression tests with geqo_threshold = 2
(injected, say, via ALTER SYSTEM SET), you will notice the
earlier tests showing some join ordering differences, which
is unsurprising ... but when it gets to partition_join, that
test just dumps core.
Investigation shows that the crash
On Sat, Oct 03, 2020 at 11:42:52PM +0200, Rémi Lapeyre wrote:
> Here’s a new version of the patches that report an error when the options are
> set multiple time.
Please note that I have applied a fix for the redundant option
handling as of 10c5291, though I have missed that you sent a patch.
On Mon, Oct 05, 2020 at 10:20:01AM +1300, Thomas Munro wrote:
> On Mon, Oct 5, 2020 at 10:08 AM Tom Lane wrote:
>> In these days when we run almost all test cases in parallel, it's
>> frequently not that easy to tie a "TRAP: ..." message in the log
>> to nearby log messages. (The postmaster's
On Tue, Sep 29, 2020 at 09:35:39AM +0200, Pavel Stehule wrote:
> +1
Thanks. I have applied this one. We may rework the handling of
redundant options for all commands to be more consistent in the
future, though it does not prevent fixing this issue until it
happens.
--
Michael
signature.asc
Hi,
I took a look at this patch after a long time, and done a bit of a
review+testing. I haven't re-read the whole thread since 2017 so some of
the following comments might be mistaken - sorry about that :-(
1) The "cmapi.h" naming seems unnecessarily short. I'd suggest using
simply
On Mon, Oct 5, 2020 at 10:08 AM Tom Lane wrote:
> In these days when we run almost all test cases in parallel, it's
> frequently not that easy to tie a "TRAP: ..." message in the log
> to nearby log messages. (The postmaster's subsequent complaint
> often helps, but it could be some distance
On Mon, 5 Oct 2020 at 06:29, Tom Lane wrote:
>
> While hacking on a patch that touches equivclass.c, I came across
> a couple of things that seemed wrong, and are fixed by the attached
> proposed patch.
>
> First, get_eclass_for_sort_expr() computes expr_relids and nullable_relids
> too soon.
In these days when we run almost all test cases in parallel, it's
frequently not that easy to tie a "TRAP: ..." message in the log
to nearby log messages. (The postmaster's subsequent complaint
often helps, but it could be some distance away in the log; and
good luck untangling things if more
John Naylor writes:
> On Thu, Oct 1, 2020 at 11:19 AM Tom Lane wrote:
>> In short: maybe instead of what you have here, leave GUC_scanstr()
>> alone except for a possible rename; make bootscanner.l use that;
>> and drop the now-unused scanstr().
> v2 done that way.
Pushed with very minor
While hacking on a patch that touches equivclass.c, I came across
a couple of things that seemed wrong, and are fixed by the attached
proposed patch.
First, get_eclass_for_sort_expr() computes expr_relids and nullable_relids
too soon. This is a waste of a not-really-trivial number of cycles in
> +extern const char *get_procsignal_reason_desc(ProcSignalReason reason)
> + {
> + const char *reasonDesc = "unknown reason";
> +
> + switch (reason)
> + {
> + case PROCSIG_RECOVERY_CONFLICT_BUFFERPIN:
> +
On Fri, Oct 2, 2020 at 3:39 PM Kyotaro Horiguchi
wrote:
> At Fri, 2 Oct 2020 09:00:53 +0900, Etsuro Fujita
> wrote in
> > I think we should avoid changing the ExecProcNode() API.
> Could you explain about what the "change" you are mentioning is?
It’s the contract of the ExecProcNode() API: if
On Sun, Oct 4, 2020 at 12:33 AM Andres Freund wrote:
>
> To get to this point heap_page_prune() has to have been called for the
> page. That removes all tuple [versions] that are DEAD. But not
> RECENTLY_DEAD. But RECENTLY_DEAD can only happen for tuples that are
> newere than OldestXmin. Thus
>
>
>
> Now, in my experience, the current system for custom plans vs. generic
> plans doesn't approach the problem in this way at all, and in my
> experience that results in some pretty terrible behavior. It will do
> things like form a custom plan every time because the estimated cost
> of the
29 matches
Mail list logo
