On Wed, Jun 6, 2018 at 11:32 AM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> Thanks Rajkumar for starting a new thread. Please update the
> commitfest entry as well.
>
I have attached new thread in commitfest and detached the old one.
Thanks & Regards,
Rajkumar Raghuwanshi
QMG, Ent
On 2018/06/06 14:10, David Rowley wrote:
> I then decided that
> I didn't like the way we need to check which params are in the Expr
> each time we call partkey_datum_from_expr. It seems better to prepare
> this in advance when building the pruning steps. I started work on
> that, but soon realised
Thanks Rajkumar for starting a new thread. Please update the
commitfest entry as well.
I have marked this entry as ready for committer, so expecting a
committer to take a look at the patch and commit it.
On Wed, Jun 6, 2018 at 11:26 AM, Rajkumar Raghuwanshi
wrote:
> Hi,
>
> As of now partition_j
On Wed, Jun 6, 2018 at 9:21 AM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> On Wed, Jun 6, 2018 at 8:11 AM, Thomas Munro
> wrote:
> > On Mon, Mar 5, 2018 at 8:13 PM, Rajkumar Raghuwanshi
> > wrote:
> >> On Wed, Feb 7, 2018 at 2:00 PM, Ashutosh Bapat
> >> Changed partition-wise sta
On 5 June 2018 at 16:44, Ashutosh Bapat wrote:
> I think the idea is brilliant. I do not have objections for trying
> something in that direction. I am suggesting that we take this a bit
> forward and try to eliminate append_rel_list altogether.
I was trying to be realistic for something we can d
Hi,
As of now partition_join.sql is not having test cases covering cases
where partition table have default partition, attaching a small test
case patch to cover those.
Here is a link of previous discussion :
https://www.postgresql.org/message-id/CAKcux6%3DLO-
XK9G0yLe634%2B0SP2UOn5ksVnmF-OntTBOE
On 6 June 2018 at 03:07, David Rowley wrote:
> Please see the attached patch. I've only just finished with it and
> it's not fully done yet as there's still an XXX comment where I've not
> quite thought about Exprs with Vars from higher levels. These might
> always be converted to Params, so the c
Andres Freund writes:
> In my understanding FunctionCallInfoData is basically per-call data,
> whereas FmgrInfo is information about the function. It makes some sense
> that ->context is in FunctionCallInfoData, after all it's used for
> per-row data like the trigger context. But we don't really
On Wed, Jun 6, 2018 at 4:48 PM, Michael Paquier wrote:
> On Wed, Jun 06, 2018 at 09:58:34AM +0530, Amit Kapila wrote:
>> I think we need to explore a bit, if we want to remove that, for example
>> some of the frontend modules (like pg_receivewal, pg_recvlogical) call two
>> argument open which wou
On Wed, Jun 06, 2018 at 09:58:34AM +0530, Amit Kapila wrote:
> On Wed, Jun 6, 2018 at 8:28 AM, Michael Paquier wrote:
>> Ouch. Including directly c.h as you do here is against project policy
>> code. See recent commit a72f0365 for example. pgwin32_open() is
>> visibly able to handle frontend co
On Wed, Jun 6, 2018 at 8:28 AM, Michael Paquier wrote:
> On Tue, Jun 05, 2018 at 04:15:00PM +0200, Laurenz Albe wrote:
>
> > --- a/src/bin/pg_test_fsync/pg_test_fsync.c
> > +++ b/src/bin/pg_test_fsync/pg_test_fsync.c
> > @@ -3,6 +3,8 @@
> > * tests all supported fsync() methods
> >
On Wed, Jun 6, 2018 at 8:11 AM, Thomas Munro
wrote:
> On Mon, Mar 5, 2018 at 8:13 PM, Rajkumar Raghuwanshi
> wrote:
>> On Wed, Feb 7, 2018 at 2:00 PM, Ashutosh Bapat
>> Changed partition-wise statement to partitionwise.
>> Attached re-based patch.
>>
>>> The patch looks good to me. I don't think
On Tue, Jun 5, 2018 at 10:04 PM, MauMau wrote:
> From: Ashutosh Bapat
>> In order to normalize parse trees, we need to at
>> least replace various OIDs in parse-tree with something that the
>> foreign server will understand correctly like table name on the
>> foreign table pointed to by local fore
On Wed, Jun 6, 2018 at 4:09 AM, Andrew Dunstan
wrote:
> At my talk at pgcon last Friday [1] I presented some ideas for how people
> could run a full buildfarm run against their code, including a 4 line recipe
> using some Docker recipes I had created. Thomas Munro suggested it would be
> even nice
On Wed, Jun 06, 2018 at 01:14:04AM +0900, MauMau wrote:
> I don't think an immediate server like the coordinators in XL is
> necessary. That extra hop can be eliminated by putting both the
> coordinator and the data node roles in the same server process. That
> is, the node to which an applicatio
On Tue, Jun 5, 2018 at 7:49 PM, Ashutosh Sharma
wrote:
> Hi,
>
> I am not able to reproduce this issue on HEAD. Seems like the
> following git-commit fixes it,
>
> commit 01deec5f8ae64b5120cc8c93d54fe0e19e477b02
> Author: Andrew Dunstan
> Date: Mon May 28 16:44:13 2018 -0400
>
> Return a v
On Tue, Jun 05, 2018 at 04:15:00PM +0200, Laurenz Albe wrote:
> The attached patch makes pg_test_fsync use pgwin32_open on Windows, which is
> what
> we use elsewhere.
Well, pg_upgrade may benefit from that as one example, as any other
tools.
> That should fix the problem.
> Ist there a better w
On Mon, Mar 5, 2018 at 8:13 PM, Rajkumar Raghuwanshi
wrote:
> On Wed, Feb 7, 2018 at 2:00 PM, Ashutosh Bapat
> Changed partition-wise statement to partitionwise.
> Attached re-based patch.
>
>> The patch looks good to me. I don't think we can reduce it further.
>> But we need some tests to test PW
On Tue, Jun 05, 2018 at 01:00:30PM +0200, Petr Jelinek wrote:
> I didn't say anything about CreateDecodingContext though. I am talking
> about the fact that we then use the same variable as input to
> XLogReadRecord later in the logical slot code path. The whole point of
> having restart_lsn for lo
On 5 June 2018 at 17:34, Ozz Nixon wrote:
> Sorry...
>
> > 1) CoC might result in developers leaving projects
>
>
> I know this on going regurgitation is going to cause my team to
> leave the project, right around 100 posts on this off topic topic it
> was bad enough when the original
Hello Hackers!
My name is Kefan Yang, and I am working on my Google Summer of Code 2018
project. For the first evaluation, I should be able to hand in:
1. the benchmark implementations of introsort, timsort, dual-pivot quicksort
and radixsort.
2. Phase 1(random array) and 2(worst case) of the b
On Wed, Jun 6, 2018 at 2:06 AM, Konstantin Knizhnik
wrote:
> Thank you for review. Updated version of the patch fixing all reported
> problems is attached.
Small problem on Windows[1]:
C:\projects\postgresql\src\include\common/zpq_stream.h(17): error
C2143: syntax error : missing ')' before '*
On Tue, Jun 05, 2018 at 11:20:57AM -0400, Peter Eisentraut wrote:
> On 6/5/18 09:12, Andres Freund wrote:
>> I'd rather create a new 2018-07, and just manually move old patches to
>> it.
>
> My concern is whether the commitfest app will handle that well. There
> is no "move to previous commit fes
On Wed, Jun 6, 2018 at 12:29 AM, Michael Paquier
wrote:
> On Tue, Jun 05, 2018 at 11:03:33AM -0400, Stephen Frost wrote:
> > Let's keep the tech side of this simple and just do the rename as
> > suggested and then we can encourage committers to review the
> > smaller/older patches by providing in
On Tue, Jun 05, 2018 at 11:03:33AM -0400, Stephen Frost wrote:
> Let's keep the tech side of this simple and just do the rename as
> suggested and then we can encourage committers to review the
> smaller/older patches by providing information about the objective size
> and age of them, which will l
> On Jun 5, 2018, at 15:20, Peter Geoghegan wrote:
> I don't follow. Practically any organized group has rules around
> conduct, with varying degrees of formality, means of enforcement, etc.
I believe the objection is to setting up a separate CoC committee, rather than
using the core team as t
On Tue, Jun 5, 2018 at 2:06 PM, Sven R. Kunze wrote:
> 1) CoC might result in developers leaving projects
> http://lists.llvm.org/pipermail/llvm-dev/2018-May/122922.html
This guy left LLVM for several reasons. The pertinent reason for us
was that he had to agree to a code of conduct in order to a
Teodor Sigaev wrote:
Ah, I think this is the missing, essential component:
CREATE INDEX ON t(right(i::text,1)) WHERE i::text LIKE '%1';
Finally, I reproduce it with attached script.
In attachment simplified version of script. psql uses ordinary sql query
to get info about index with usual tra
Sorry...
> 1) CoC might result in developers leaving projects
I know this on going regurgitation is going to cause my team to leave
the project, right around 100 posts on this off topic topic it was bad
enough when the original idea came up (2 years ago I think). It used to be
exc
> "Matthew" == Matthew Woodcraft writes:
Matthew> A few days ago there was a suggestion on this list to add a
Matthew> .editorconfig file specifying tab width:
Matthew>
https://www.postgresql.org/message-id/87efhuz9be.fsf%40news-spur.riddles.org.uk
Matthew> The .editorconfig format also
> "Peter" == Peter Eisentraut writes:
>> + (lambda () (add-to-list 'write-file-functions
>> 'delete-trailing-whitespace)
Peter> dir-locals doesn't work this way. It's not a general lisp file.
Right. The correct approach is
+ (eval add-hook 'before-save-hook
On June 5, 2018 9:47 PM, Paul A Jungwirth p...@illuminatedcomputing.com wrote:
> On Sat, May 26, 2018 at 1:56 PM, Vik Fearing vik.fear...@protonmail.com wrote:
>
>> SQL:2011 introduced the concept of a "period". It takes two existing columns
>> and basically does the same thing as our range types
On 2018-06-05 18:22, David Fetter wrote:
> Folks,
>
> Here's my attempt to $subject. I've tested with vim, but I'm much less
> certain I got the EMACS code right.
>
> Is there any interest in such a feature?
A few days ago there was a suggestion on this list to add a
.editorconfig file specifyin
On 06/05/2018 05:14 PM, Daniel Gustafsson wrote:
This comment should say “perlcheck/..” and not “pgperlcritic/.." I assume:
Thanks. will fix.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
> On 5 Jun 2018, at 16:31, Andrew Dunstan
> wrote:
> The patch contains a simple script to run the checks. The code that finds
> perl files is put in a function in a single file that is sourced by the three
> locations that need it.
+1 on centralizing the find-files function.
> The directory
On 06/05/2018 04:57 PM, Andres Freund wrote:
> But we don't really change the
> collation of function invocations per-call.
Is that true? (Not a rhetorical question; I'm unsure.)
Is your argument that the expression's collation is determined once
for each call /site/, and thereafter doesn't chan
Hi PostgreSQL Community,
some points I like to make mainly because of observations of how other
open source projects handle this topic:
1) CoC might result in developers leaving projects
http://lists.llvm.org/pipermail/llvm-dev/2018-May/122922.html
2) CoC might result in not so equal peers a
Hi,
In my understanding FunctionCallInfoData is basically per-call data,
whereas FmgrInfo is information about the function. It makes some sense
that ->context is in FunctionCallInfoData, after all it's used for
per-row data like the trigger context. But we don't really change the
collation of f
On Mon, Jun 4, 2018 at 9:46 AM, Fujii Masao wrote:
> Generally the recovery performance of DROP DATABASE is not critical
> for many users. But unfortunately my colleague's project might need to
> sometimes drop the database using multiple tablespaces, for some reasons.
> So, if the fix is not so
On 6/5/18 13:37, Tom Lane wrote:
> I note that Peter E. seems to have a recipe for finding such issues,
> which I suspect is grounded in some obscure git feature or other.
> That might be easier to work with, since you'd only need one fix
> not one per editor.
I have a git alias:
check-whitespace
On 6/5/18 13:22, David Fetter wrote:
> diff --git a/.dir-locals.el b/.dir-locals.el
> index 9525d6b604..858461e6bd 100644
> --- a/.dir-locals.el
> +++ b/.dir-locals.el
> @@ -4,7 +4,8 @@
> (c-file-style . "bsd")
> (fill-column . 78)
> (indent-tabs-mode . t)
> -
On 5 June 2018 at 13:06, Peter Eisentraut
wrote:
> On 6/5/18 03:09, Michael Paquier wrote:
> > I just had a quick look at this patch, lured by the smell of your latest
> > messages... And it seems to me that this patch needs a heavy amount of
> > work as presented. There are a couple of things
On Tue, Jun 5, 2018 at 12:47 PM, Paul A Jungwirth
wrote:
> Also, this may not be very helpful, but I started an extension to
> support temporal foreign keys here:
>
> https://github.com/pjungwir/time_for_keys
>
> It uses intervals, not periods, but maybe you can steal some ideas.
Sorry for two em
Hi,
On 2018-06-05 15:08:33 -0400, Peter Eisentraut wrote:
> On 6/5/18 13:29, Andres Freund wrote:
> > Besides the change here, I think we should also go much further with the
> > conversion to NullableDatum. There's two main areas of change: I want
> > to move the execExpr.c related code so steps
On Sat, May 26, 2018 at 1:56 PM, Vik Fearing wrote:
> SQL:2011 introduced the concept of a "period". It takes two existing columns
> and basically does the same thing as our range types except there is no new
> storage. I believe if Jeff Davis had given us range types a few years later
> than he
On Fri, May 11, 2018 at 4:48 AM, Paul A Jungwirth
wrote:
> I'm traveling and can't write much more at the moment, but I'll try to
> reply more fully in a week or two.
Sorry it took awhile to continue this discussion! If people are
interested in implementing temporal features in Postgres, I wrote
On 6/5/18 13:29, Andres Freund wrote:
> Besides the change here, I think we should also go much further with the
> conversion to NullableDatum. There's two main areas of change: I want
> to move the execExpr.c related code so steps return data into
> NullableDatums - that removes a good chunk of p
Thomas Munro writes:
> On Sat, May 26, 2018 at 6:58 AM, Robbie Harwood wrote:
>> Me and the bot are having an argument. This should green Linux but I
>> dunno about Windows.
>
> BTW if you're looking for a way to try stuff out on Windows exactly
> the way cfbot does it without posting a new pat
I use FileStly plugin to vim [1]. But I slightly modify it, see in attachment.
FileStyle, sorry.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
I once tried to have vim highlight trailing whitespace, spaces before
tabs, and overlength lines (>80 chars), and while I could do each thing
in isolation, I wasn't able to get it to highlight the three of them at
the same time. If you have a recipe for that, I welcome it.
I use FileStly plugin
Thanks for the patch. This (missing) optimization popped-up repeatedly recently,
and I was planning to look into it for PG12. So now I don't have to, because
you've done all the hard work ;-)
You are welcome. Actually one of out customers faced the problem with GROUP BY
column order and exactly
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Tue, Jun 5, 2018 at 4:45 PM, Chris Travers
> wrote:
> > If I may suggest: The committee should be international as well and
> > include people from around the world. The last thing we want is for it to
> > be dominated by people fro
Yeah, our approach had to mergeable. You can rip that bandaid.
From: Simon Riggs
On 1 June 2018 at 16:56, Ashutosh Bapat
wrote:
>> I think partitioning + FDW provide basic infrastructure for
>> distributing data, planning queries working with such data. We need
>> more glue to support node management, cluster configuration. So, I
>> agree with your statement.
Hi,
On 2018-06-05 10:47:49 -0700, Jeff Davis wrote:
> The thing I don't like about it is that it requires running two memory-
> hungry operations at once. How much of work_mem do we use for sorted
> runs, and how much do we use for the hash table?
Is that necessarily true? I'd assume that we'd us
On Tue, Jun 05, 2018 at 01:28:54PM -0400, Alvaro Herrera wrote:
> On 2018-Jun-05, David Fetter wrote:
> Hi David
>
> > Here's my attempt to $subject. I've tested with vim, but I'm much less
> > certain I got the EMACS code right.
> >
> > Is there any interest in such a feature?
>
> I'd rather ha
On Tue, 2018-06-05 at 05:42 -0700, Andres Freund wrote:
> That's an interesting idea, but it seems simpler to stick to
> > hashing
> > rather than using a combination strategy. It also seems like it
> > would
> > take less CPU effort.
> Isn't the locality of access going to considerably better with
Hi,
On 2018-06-05 10:40:22 -0700, se...@rielau.com wrote:
> Big +1 on this one.
Cool.
> Here is what we did. It's very crude, but minimized the amount of pain:
I think I'd rather go for my approach in core though. Needlessly
carrying around a bunch of pointers, and adding the necessary
indirec
Big +1 on this one.
Here is what we did. It's very crude, but minimized the amount of pain:
It helps that the C compiler treats arrays and pointers the same.
I can dig for the complete patch if you want...
Cheers
Serge
/*
* This struct is the data actually passed to an fmgr-called function
On Tue, Jun 05, 2018 at 01:27:01PM -0400, Tom Lane wrote:
> David Fetter writes:
> > On Tue, Jun 05, 2018 at 02:56:23PM +1200, David Rowley wrote:
> >> True. Although not all built in aggregates have those defined.
>
> > Just out of curiosity, which ones don't? As of
> > 3f85c62d9e825eedd1315d249
Alvaro Herrera writes:
> On 2018-Jun-05, David Fetter wrote:
>> Is there any interest in such a feature?
> I'd rather have the editor warn me (highlight) such things rather than
> fix them silently (I wonder if it'd cause a mess with regression .out
> files for example, which I do edit on occasio
> On Jun 5, 2018, at 10:14 AM, Tom Lane wrote:
>
> Michael Paquier writes:
>> Okay. If we tend toward this direction, I propose to do this switch in
>> two days my time (Thursday afternoon in Tokyo) if there are no
>> objections, so as anybody has hopefully time to argue back.
>
> I think we
On Tue, 2018-06-05 at 05:57 -0700, Andres Freund wrote:
> But I think my proposal to continue use a hashtable for the already
> known groups, and sorting for additional groups would largely address
> that largely, right? We couldn't deal with groups becoming too
> large,
> but easily with the numb
Hi,
While prototyping codegen improvements for JITed expression evaluation,
I once more hit the issue that the FunctionCallInfoData structs are
really large (936 bytes), despite arguments beyond the fourth barely
every being used. I think we should fix that.
What I think we should do is convert
On Tue, 2018-06-05 at 08:39 -0700, se...@rielau.com wrote:
> Strange. We don't see this overeahd and measure a lot more than just
> a single metric:
Let's investigate again. I wasn't able to repro the overhead on x86;
Robert saw it on a POWER machine, and it was somewhat noisy. I don't
think we we
On 2018-Jun-05, David Fetter wrote:
Hi David
> Here's my attempt to $subject. I've tested with vim, but I'm much less
> certain I got the EMACS code right.
>
> Is there any interest in such a feature?
I'd rather have the editor warn me (highlight) such things rather than
fix them silently (I wo
David Fetter writes:
> On Tue, Jun 05, 2018 at 02:56:23PM +1200, David Rowley wrote:
>> True. Although not all built in aggregates have those defined.
> Just out of curiosity, which ones don't? As of
> 3f85c62d9e825eedd1315d249ef1ad793ca78ed4, pg_aggregate has both of
> those as NOT NULL.
NOT NU
Folks,
Here's my attempt to $subject. I've tested with vim, but I'm much less
certain I got the EMACS code right.
Is there any interest in such a feature?
Best,
David.
---
.dir-locals.el| 3 ++-
src/tools/editors/vim.samples | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
On 2018-06-05 19:04:11 +0200, David Fetter wrote:
> On Tue, Jun 05, 2018 at 02:56:23PM +1200, David Rowley wrote:
> > On 5 June 2018 at 06:52, Andres Freund wrote:
> > > That part has gotten a bit easier since, because we have serialize
> > > / deserialize operations for aggregates these days.
> >
From: Merlin Moncure
> FWIW, Distributed analytical queries is the right market to be in.
> This is the field in which I work, and this is where the action is
at.
> I am very, very, sure about this. My view is that many of the
> existing solutions to this problem (in particular hadoop class
> solt
On Tue, Jun 05, 2018 at 02:56:23PM +1200, David Rowley wrote:
> On 5 June 2018 at 06:52, Andres Freund wrote:
> > That part has gotten a bit easier since, because we have serialize
> > / deserialize operations for aggregates these days.
>
> True. Although not all built in aggregates have those de
On 2018-Jun-05, Amit Langote wrote:
> On 2018/06/05 16:41, Ashutosh Bapat wrote:
> > On Tue, Jun 5, 2018 at 1:07 PM, Amit Langote
> > wrote:
> >> On 2018/06/05 1:25, Alvaro Herrera wrote:
> >>> In the meantime, my inclination is to fix the documentation to point out
> >>> that AFTER triggers are
On 6/5/18 03:09, Michael Paquier wrote:
> I just had a quick look at this patch, lured by the smell of your latest
> messages... And it seems to me that this patch needs a heavy amount of
> work as presented. There are a couple of things which are not really
> nice, like forcing the presentation
From: Ashutosh Bapat
> Each node need to be confiugred and maintained. That requires
efforts.
> So we need to keep the number of nodes to a minimum. With a
> coordinator and worker node segregation, we require at least two
nodes
> in a cluster and just that configuration doesn't provide much
> scal
From: Ashutosh Bapat
> In order to normalize parse trees, we need to at
> least replace various OIDs in parse-tree with something that the
> foreign server will understand correctly like table name on the
> foreign table pointed to by local foreign table OR (schema
qualified)
> function names and
From: Ashutosh Bapat
> In order to normalize parse trees, we need to at
> least replace various OIDs in parse-tree with something that the
> foreign server will understand correctly like table name on the
> foreign table pointed to by local foreign table OR (schema
qualified)
> function names and
> Those underscore-prefixed names are defined in Microsoft's
> [3][4]. So now I'm wondering if win32_port.h needs to
> #include if (_MSC_VER < 1800).
I don't have the C experience to decide the correct way. There are
currently many .c files that are including float.h conditionally or
unconditio
On 06/05/2018 12:09 PM, Andrew Dunstan wrote:
notice at lines 36 and 34 or the Appveyor output, (from lines 16 and
19 of the recipe appveyor.yml) that this recipe does make a couple of
adjustments.
Of course that's lines 36 and 43. I seem to be getting more dyslectic as
I get older ...
From: Robert Haas
On Thu, May 31, 2018 at 8:12 AM, MauMau wrote:
>> Oh, I didn't know you support FDW approach mainly for analytics. I
>> guessed the first target was OLTP read-write scalability.
>
> That seems like a harder target to me, because you will have an
extra
> hop involved -- SQL from
At my talk at pgcon last Friday [1] I presented some ideas for how
people could run a full buildfarm run against their code, including a 4
line recipe using some Docker recipes I had created. Thomas Munro
suggested it would be even nicer if you could just point something like
Appveypr at the co
On Tue, Jun 5, 2018 at 4:45 PM, Chris Travers
wrote:
>
>
> On Mon, Jun 4, 2018 at 6:59 PM, Joshua D. Drake
> wrote:
>
>> On 06/03/2018 04:08 PM, Gavin Flower wrote:
>>
>> My comments:
1) Reiterate my contention that this is a solution is search of
problem. Still it looks like it i
On 05.06.2018 10:09, Michael Paquier wrote:
On Tue, Jun 05, 2018 at 06:04:21PM +1200, Thomas Munro wrote:
On Thu, May 17, 2018 at 3:54 AM, Konstantin Knizhnik
Speaking of configuration, are you planning to support multiple
compression libraries at the same time? It looks like the current
pat
On Tue, Jun 05, 2018 at 02:56:23PM +1200, David Rowley wrote:
> On 5 June 2018 at 06:52, Andres Freund wrote:
> > That part has gotten a bit easier since, because we have serialize /
> > deserialize operations for aggregates these days.
>
> True. Although not all built in aggregates have those de
O.K,
Remember my Country Please.
El 2018-06-05 11:29, Joshua D. Drake escribió:
On 06/05/2018 07:45 AM, Chris Travers wrote:
It is my hope that PostgreSQL.Org -Core chooses members for that
committee that are exceedingly diverse otherwise it is just an
echo
chamber for a sin
Strange. We don't see this overeahd and measure a lot more than just a single
metric:
Of the grab below only the context->stats += size is need.
Could easily be a macro.
We also track overall backend size to cap it, and track memory contexts in
shared memory (plan cache, function cache, messag
2018-06-05 17:07 GMT+02:00 David Rowley :
> On 5 June 2018 at 22:31, Amit Langote
> wrote:
> > Maybe, David (added to cc) has something to say about all this,
> especially
> > whether he considers this a feature and not a bug fix.
>
> Thanks, Amit. I had missed this thread.
>
> Yeah. I admit if I
On 06/05/2018 07:45 AM, Chris Travers wrote:
It is my hope that PostgreSQL.Org -Core chooses members for that
committee that are exceedingly diverse otherwise it is just an echo
chamber for a single ideology and that will destroy this community.
If I may suggest: The committee sho
Right now, when a TAP test reports a failure, it looks something like this:
# Failed test 'creating a replication slot'
# at
/../postgresql/src/bin/pg_basebackup/../../../src/test/perl/TestLib.pm
line 371.
That file location is where we call out to the test function provided by
Test::Mo
On 6 June 2018 at 03:17, Andres Freund wrote:
> On 2018-06-06 03:14:58 +1200, David Rowley wrote:
>> On 6 June 2018 at 02:20, Tom Lane wrote:
>> > I thought the idea was to clear out the underbrush of small, ready-to-go
>> > patches. How old they are doesn't enter into that.
>>
>> I don't recall
On 6/5/18 09:12, Andres Freund wrote:
> I'd rather create a new 2018-07, and just manually move old patches to
> it.
My concern is whether the commitfest app will handle that well. There
is no "move to previous commit fest" button. So you'd have to do it in
some evil way, possibly confusing the
On 2018-06-06 03:14:58 +1200, David Rowley wrote:
> On 6 June 2018 at 02:20, Tom Lane wrote:
> > I thought the idea was to clear out the underbrush of small, ready-to-go
> > patches. How old they are doesn't enter into that.
>
> I don't recall a 'fest where small ready to go patches getting
> an
On 6 June 2018 at 02:20, Tom Lane wrote:
> I thought the idea was to clear out the underbrush of small, ready-to-go
> patches. How old they are doesn't enter into that.
I don't recall a 'fest where small ready to go patches getting
anything but priority.
--
David Rowley http
On 5 June 2018 at 22:31, Amit Langote wrote:
> Maybe, David (added to cc) has something to say about all this, especially
> whether he considers this a feature and not a bug fix.
Thanks, Amit. I had missed this thread.
Yeah. I admit if I'd thought about this case when I wrote the code,
then I'd
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Joe Conway writes:
> > On 06/05/2018 10:43 AM, Andres Freund wrote:
> >> I think we've not fully agreed on that. I'd argue we should manually
> >> filter things into the next CF. And both small patches and older things
> >> should qualify.
>
>
On 06/05/2018 10:43 AM, Andres Freund wrote:
On 2018-06-05 10:20:55 -0400, Tom Lane wrote:
Andres Freund writes:
I'd rather create a new 2018-07, and just manually move old patches to
it. Otherwise we'll not really focus on the glut of old things, but
everyone just restarts working on their
From: Simon Riggs
> Passing detailed info between servers is exactly what XL does.
>
> It requires us to define a cluster, exactly as XL does.
>
> And yes, its a good idea to replicate some tables to all nodes, as
XL does.
>
> So it seems we have at last some agreement that some of the things
XL
>
El 2018-06-05 10:54, gilberto.casti...@etecsa.cu escribió:
Hello,
Maybe must include policy of money support from several at member from
country less earnings.
El 2018-06-05 10:45, Chris Travers escribió:
On Mon, Jun 4, 2018 at 6:59 PM, Joshua D. Drake
wrote:
On 06/03/2018 04:08 PM, Gavin
Joe Conway writes:
> On 06/05/2018 10:43 AM, Andres Freund wrote:
>> I think we've not fully agreed on that. I'd argue we should manually
>> filter things into the next CF. And both small patches and older things
>> should qualify.
> Would it work to rename 2018-09 to 2018-07 and then make a pas
Hello,
Maybe must include policy of money support from several at member from
country less earnings. For examplo Cuba.
El 2018-06-05 10:45, Chris Travers escribió:
On Mon, Jun 4, 2018 at 6:59 PM, Joshua D. Drake
wrote:
On 06/03/2018 04:08 PM, Gavin Flower wrote:
My comments:
1) Reiterat
On 06/05/2018 10:43 AM, Andres Freund wrote:
> On 2018-06-05 10:20:55 -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> I'd rather create a new 2018-07, and just manually move old patches to
>>> it. Otherwise we'll not really focus on the glut of old things, but
>>> everyone just restarts workin
1 - 100 of 153 matches
Mail list logo