On Fri, Mar 06, 2020 at 01:36:48PM +0100, Julien Rouhaud wrote:
> Ah I see, thanks for the clarification. I guess there's room for improvement
> in the comments about that, since the ERRCODE_FEATURE_NOT_SUPPORTED usage is
> quite misleading there.
>
> v4 attached, which doesn't prevent a REINDEX
On Fri, 6 Mar 2020 at 20:02, Arseny Sher wrote:
>
> I wrote:
>
> > It looks good to me now.
>
> After lying for some time in my head it reminded me that
> CreateInitDecodingContext not only pegs the LSN, but also xmin, so
> attached makes a minor comment correction.
>
> While taking a look at the
Dear Kuroda-san, Fujii-san
Thank you for review and commit!
#Oops.. Sorry..This mail thread has been spammed in Gmail.
I'll go to submit a new discussion after found which case could leak
about the GUC parameters related to ssl_*.
Please wait a bit.
Best regards.
Moon.
On Mon, Mar 9, 2020 at
On Sun, Mar 8, 2020 at 10:13 PM Kyotaro Horiguchi
wrote:
>
> At Fri, 6 Mar 2020 09:54:09 -0800, Magnus Hagander
> wrote in
> > On Fri, Mar 6, 2020 at 1:51 AM Fujii Masao
> > wrote:
> > > I believe that the time required to estimate the backup size is not so
> > > large
> > > in most cases,
On Sun, Mar 8, 2020 at 7:58 AM Masahiko Sawada <
masahiko.saw...@2ndquadrant.com> wrote:
> On Mon, 24 Feb 2020 at 19:08, Amit Kapila wrote:
> >
> > On Thu, Feb 20, 2020 at 8:06 AM Andres Freund
> wrote:
> > >
> > > Hi,
> > >
> > > On 2020-02-19 11:12:18 +0530, Amit Kapila wrote:
> > > > I think
At Fri, 6 Mar 2020 09:54:09 -0800, Magnus Hagander wrote
in
> On Fri, Mar 6, 2020 at 1:51 AM Fujii Masao
> wrote:
> > I believe that the time required to estimate the backup size is not so large
> > in most cases, so in the above idea, most users don't need to specify more
> > option for the
On Mon, 9 Mar 2020 at 13:24, Fujii Masao wrote:
>
>
>
> On 2020/03/08 13:52, Masahiko Sawada wrote:
> > On Thu, 5 Mar 2020 at 20:16, Fujii Masao
> > wrote:
> >>
> >>
> >>
> >> On 2020/03/05 16:58, Masahiko Sawada wrote:
> >>> On Wed, 4 Mar 2020 at 15:21, Fujii Masao
> >>> wrote:
>
>
At Sat, 7 Mar 2020 01:46:16 +0900, Fujii Masao
wrote in
> > (It seems retroverting to the first patch when I started this...)
> > The second place covers wider cases so I reverted the first place.
>
> Thanks for updating the patch that way.
> Not sure which patch you're mentioning, though.
On 2020/03/08 13:52, Masahiko Sawada wrote:
On Thu, 5 Mar 2020 at 20:16, Fujii Masao wrote:
On 2020/03/05 16:58, Masahiko Sawada wrote:
On Wed, 4 Mar 2020 at 15:21, Fujii Masao wrote:
On 2020/03/04 14:31, Masahiko Sawada wrote:
On Wed, 4 Mar 2020 at 13:48, Fujii Masao wrote:
On Sun, Mar 8, 2020 at 9:24 PM James Coleman wrote:
>
> On Saturday, March 7, 2020, Dilip Kumar wrote:
>>
>> On Sat, Mar 7, 2020 at 9:59 AM Dilip Kumar wrote:
>> >
>> > On Sat, Mar 7, 2020 at 12:30 AM Andres Freund wrote:
>> > >
>> > > Hi,
>> > >
>> > > On 2020-01-08 18:06:52 +0530, Dilip
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
I have tested the feature and it shows great performance in queries
On 2020/03/06 16:20, keisuke kuroda wrote:
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
I tested the
On 2020/02/14 10:31, Moon, Insung wrote:
Dear Hackers.
Thank you for an response.
I registered this entry in commifest of 2020-03.
# I registered in the security part, but if it is wrong, sincerely
apologize for this.
And I'd like to review show authority to ssl_ * later and discuss it
in a
On Sat, Mar 07, 2020 at 10:09:23AM +0900, Michael Paquier wrote:
> Thanks to both of you for the reviews. Please note that I will
> mention the business with pg_ctl and logging in a new thread and
> remove the diff of pg_ctl.c from the previous patch, and that the doc
> changes could be
On Sun, Mar 08, 2020 at 03:12:11PM -0400, Tom Lane wrote:
> After thinking more I concluded that the extra expected files would
> just be a waste of tarball space, at least till such time as we make
> a push to fix all the regression tests to be blocksize-independent.
Makes sense.
> Pushed it
Hi David,
On Sun, Mar 8, 2020 at 11:34 AM David Fetter wrote:
>
> On Mon, Mar 02, 2020 at 12:45:21PM -0800, Jesse Zhang wrote:
> > Hi David,
>
> Per discussion on IRC with Andrew (RhodiumToad) Gierth:
>
> The runtime detection means there's always an indirect call overhead
> and no way to inline.
I recently noticed while setting up a test environment that attempting to
connect to a standby running without hot_standby=on results in a fairly
generic error (I believe "the database system is starting up"). I don't
have my test setup running right now, so can't confirm with a repro case at
the
On Mon, Mar 09, 2020 at 01:01:57AM +0100, Tomas Vondra wrote:
On Sun, Mar 08, 2020 at 07:17:10PM +, Dean Rasheed wrote:
On Fri, 6 Mar 2020 at 12:58, Tomas Vondra wrote:
Here is a rebased version of this patch series. I've polished the first
two parts a bit - estimation of OR clauses and
On Sun, Mar 08, 2020 at 07:17:10PM +, Dean Rasheed wrote:
On Fri, 6 Mar 2020 at 12:58, Tomas Vondra wrote:
Here is a rebased version of this patch series. I've polished the first
two parts a bit - estimation of OR clauses and (Var op Var) clauses.
Hi,
I've been looking over the first
Hi John,
Oops this email has been sitting in my outbox for 3 days...
On Wed, Mar 4, 2020 at 1:46 AM John Naylor wrote:
> On Tue, Mar 3, 2020 at 4:46 AM Jesse Zhang wrote:
> > I've quickly put together a PoC patch on top of yours, which
> > re-implements ceil_log2 using LZCNT coupled with a
Jeff Janes writes:
> I've seen a few requests on how to make FTS search on the absolute value of
> integers. This question is usually driven by the fact that the text search
> parser interprets a separating hyphen ("partnumber-987") as a minus sign.
> There is currently no good answer for this
On Sun, Mar 8, 2020 at 6:03 PM Tom Lane wrote:
> James Coleman writes:
> > So just to confirm I understand, that implies that the issue is solely
> that
> > only the utf8 tr_TR set is installed by default on this machine, and the
> > iso-8859-9 set is a hard requirement (that is, the test is
James Coleman writes:
> So just to confirm I understand, that implies that the issue is solely that
> only the utf8 tr_TR set is installed by default on this machine, and the
> iso-8859-9 set is a hard requirement (that is, the test is explicitly
> testing a codepath that generates utf8 results
Hi, Peter!
On Tue, Mar 3, 2020 at 3:04 AM Peter Geoghegan wrote:
> Apologies for the delayed response. I was a little tired from the
> deduplication project.
No problem. Apologies for the delayed revision as well.
> I taught pageinspect to display a "htid" field for pivot tuples
> recently,
On Sun, Mar 8, 2020 at 2:19 PM Tom Lane wrote:
> I wrote:
> > James Coleman writes:
> >> I'm still interested in understanding why we're using the ISO locale
> >> instead of the utf8 one in a utf8-labeled test though.
>
> > We are not. My understanding of the rules about this is that the
> >
On Mon, 9 Mar 2020 at 03:21, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> >
> > I've been looking over v32 of the patch and have a few comments
> > regarding the planner changes.
>
> Thanks for the commentaries!
>
> > I think the changes in create_distinct_paths() need more work. The
> > way
On Sun, Mar 8, 2020 at 5:13 PM James Coleman wrote:
>
> I realized I didn't previously add this to the CF; since it's not a new
> patch I've added it to the current CF, but if this is incorrect please let
> me know.
>
Hmm, looks like I can't add it to the current one. I added it to the next
On Tue, Sep 17, 2019 at 9:41 PM Michael Paquier wrote:
> On Tue, Sep 17, 2019 at 08:38:18AM -0400, James Coleman wrote:
> > I don't agree that that's a valid equivalency. I myself spent a lot of
> > time trying to understand how this could possibly be true a while
> > back, and even looked at
On Mon, Mar 9, 2020 at 10:00 AM Marina Polyakova
wrote:
> On 2018-11-16 22:59, Alvaro Herrera wrote:
> > On 2018-Sep-05, Marina Polyakova wrote:
> >
> >> v11-0001-Pgbench-errors-use-the-RandomState-structure-for.patch
> >> - a patch for the RandomState structure (this is used to reset a
> >>
I wrote:
> I've just finished scanning the source code and concluding that all
> of these functions are similarly broken:
> pg_ls_dir
> pg_ls_dir_files
> pg_tablespace_databases
> pg_logdir_ls_internal
> pg_timezone_names
> pgrowlocks
BTW, another thing I noticed while looking around is that some
Justin Pryzby writes:
> On Sun, Mar 08, 2020 at 02:37:49PM -0400, Tom Lane wrote:
>> I guess we ought to change that function to use returns-a-tuplestore
>> protocol instead of thinking it can hold a directory open across calls.
>> It's not hard to think of use-cases where the existing behavior
On Fri, 6 Mar 2020 at 12:58, Tomas Vondra wrote:
>
> Here is a rebased version of this patch series. I've polished the first
> two parts a bit - estimation of OR clauses and (Var op Var) clauses.
>
Hi,
I've been looking over the first patch (OR list support). It mostly
looks reasonable to me,
On Sun, Mar 08, 2020 at 02:37:49PM -0400, Tom Lane wrote:
> Justin Pryzby writes:
> > While working on a patch, I noticed this pre-existing behavior, which seems
> > to
> > be new since v11, maybe due to changes to SRF.
>
> > |postgres=# SELECT pg_ls_dir('.') LIMIT 1;
> > |WARNING: 1 temporary
Michael Paquier writes:
> Thanks for the computations with big-endian! I would have just gone
> down to the 8kB page for the expected results by seeing three other
> tests blowing up, but no objection to what you have here either. I
> have checked the computations with little-endian from your
Justin Pryzby writes:
> While working on a patch, I noticed this pre-existing behavior, which seems to
> be new since v11, maybe due to changes to SRF.
> |postgres=# SELECT pg_ls_dir('.') LIMIT 1;
> |WARNING: 1 temporary files and directories not closed at end-of-transaction
Hmm, actually it
On Mon, Mar 02, 2020 at 12:45:21PM -0800, Jesse Zhang wrote:
> Hi David,
>
> On Wed, Feb 26, 2020 at 9:56 PM David Fetter wrote:
> >
> > On Wed, Feb 26, 2020 at 09:12:24AM +0100, David Fetter wrote:
> > > On Fri, Jan 31, 2020 at 04:59:18PM +0100, David Fetter wrote:
> > > > On Wed, Jan 15, 2020
Peter Eisentraut writes:
> I noticed that catalog/objectaddress.h includes utils/acl.h for no
> apparent reason. It turns out this used to be needed but not anymore.
> So removed it and cleaned up the fallout. Patch attached.
Seems reasonable. One thing I noticed is that if you are
I wrote:
> James Coleman writes:
>> I'm still interested in understanding why we're using the ISO locale
>> instead of the utf8 one in a utf8-labeled test though.
> We are not. My understanding of the rules about this is that the
> active LC_CTYPE setting determines the encoding that libc uses,
before. It is only STMT_PLAN_UTILITY statement.
>
I did some cleaning - I mainly replaced CMD_PLAN_UTILITY by CMD_LET because
there is not another similar statement in queue.
Regards
Pavel
> Regards
>
> Pavel
>
schema-variables-20200308.patch.gz
Description: application/gzip
While working on a patch, I noticed this pre-existing behavior, which seems to
be new since v11, maybe due to changes to SRF.
|postgres=# SELECT pg_ls_dir('.') LIMIT 1;
|WARNING: 1 temporary files and directories not closed at end-of-transaction
|pg_ls_dir | pg_dynshmem
|postgres=# SELECT
On Fri, Dec 20, 2019 at 10:43 AM Alvaro Herrera
wrote:
> I took the liberty of rebasing this series on top of recent branch
> master.
>
In the tests there is:
+select '{[a,a],[b,b]}'::textmultirange;
+ textmultirange
+
+ {[a,a],[b,b]}
+(1 row)
+
+-- without canonicalization, we
Isaac Morland writes:
>> so 7. 3. 2020 v 22:20 odesílatel Tom Lane napsal:
>>> Actually ... have you given any thought to just deciding that ranges and
>>> multiranges are the same type? That is, any range can now potentially
>>> contain multiple segments?
> Definitely agreed that range and
James Coleman writes:
> Since sudo dpkg-reconfigure locales opens up an ncurses gui on my machine,
> I tried selecting the tr_TR.ISO-8859-9 option there and removed the
> /var/lib/locales/supported.d/local file. Now I get:
> $ locale -a | grep tr_TR
> tr_TR
> tr_TR.iso88599
> tr_TR.utf8
> And
On Sun, Mar 8, 2020 at 10:42 AM James Coleman wrote:
> On Sun, Mar 8, 2020 at 7:17 AM Juan José Santamaría Flecha <
> juanjo.santama...@gmail.com> wrote:
>
>>
>>
>> On Sun, Mar 8, 2020 at 3:48 AM Tom Lane wrote:
>>
>>> James Coleman writes:
>>> > On Sat, Mar 7, 2020 at 9:31 PM Tom Lane wrote:
On Saturday, March 7, 2020, Dilip Kumar wrote:
> On Sat, Mar 7, 2020 at 9:59 AM Dilip Kumar wrote:
> >
> > On Sat, Mar 7, 2020 at 12:30 AM Andres Freund
> wrote:
> > >
> > > Hi,
> > >
> > > On 2020-01-08 18:06:52 +0530, Dilip Kumar wrote:
> > > > On Wed, 8 Jan 2020 at 5:28 PM, Heikki
On Sun, Mar 8, 2020 at 7:17 AM Juan José Santamaría Flecha <
juanjo.santama...@gmail.com> wrote:
>
>
> On Sun, Mar 8, 2020 at 3:48 AM Tom Lane wrote:
>
>> James Coleman writes:
>> > On Sat, Mar 7, 2020 at 9:31 PM Tom Lane wrote:
>> >> Looks like you may not have Turkish locale installed? Try
On Fri, Jun 28, 2019 at 11:49:53AM -0700, Peter Geoghegan wrote:
> On Tue, Mar 19, 2019 at 12:38 PM legrand legrand
> wrote:
> > Would it make sense to add it in auto explain ?
> > I don't know for explain itself, but maybe ...
>
> I think that it should appear in EXPLAIN. pg_stat_statements
> On Wed, Mar 04, 2020 at 11:32:00AM +1300, David Rowley wrote:
>
> I've been looking over v32 of the patch and have a few comments
> regarding the planner changes.
Thanks for the commentaries!
> I think the changes in create_distinct_paths() need more work. The
> way I think this should work
On Sat, Mar 7, 2020 at 9:48 PM Tom Lane wrote:
> James Coleman writes:
> > On Sat, Mar 7, 2020 at 9:31 PM Tom Lane wrote:
> >> Looks like you may not have Turkish locale installed? Try
> >> locale -a | grep tr_TR
>
> > Hmm, when I grep the locales I see `tr_TR.utf8` in the output. I assume
>
> Attached is v5, which inlines in a targeted fashion, pretty much in the same
> way as the earliest version. This is the same as v4 in every other way.
> Perhaps you can test this.
>
Thank you for the new patch. With the new one I am indeed able to reproduce a
performance increase. It is very
On Sun, Mar 8, 2020 at 3:48 AM Tom Lane wrote:
> James Coleman writes:
> > On Sat, Mar 7, 2020 at 9:31 PM Tom Lane wrote:
> >> Looks like you may not have Turkish locale installed? Try
> >> locale -a | grep tr_TR
>
> > Hmm, when I grep the locales I see `tr_TR.utf8` in the output. I assume
>
On Fri, Mar 6, 2020 at 11:46 AM Alexander Korotkov
wrote:
> On Fri, Mar 6, 2020 at 7:10 AM vignesh C wrote:
> > I feel your explanation sounds fair to me.
>
> Thanks.
>
> I've also revised tab-completion code. I'm going to push this if no
> objections.
So, pushed!
--
Alexander Korotkov
Hello Justin,
Patch series applies cleanly. The last status compiles and passes "make
check". A few more comments:
* v8.[123] ok.
* v8.4
Avoid using the type name as a field name? "enum dir_action dir_action;"
-> "enum dir_action action", or maybe rename "dir_action" enum
53 matches
Mail list logo
