On 2018/01/19 23:55, Alvaro Herrera wrote:
> Local partitioned indexes
>
> Modified Files
> --
> doc/src/sgml/catalogs.sgml| 23 +
> doc/src/sgml/ref/alter_index.sgml | 14 +
> doc/src/sgml/ref/alter_table.sgml | 8 +-
> doc/src/sgml/ref/create_index.sgm
On Tue, Jan 16, 2018 at 05:56:22PM +1100, Haribabu Kommi wrote:
> Without PQhostaddr() function, for the connections where the host is not
> specified, it will be difficult to find out to remote server.
That's true as well, but hostaddr should be used with host only to save
IP lookups... There are
On Thu, Jan 25, 2018 at 5:53 PM, Abinaya k wrote:
> Thanks for your response.
>
> Hope those stats will be used by Query Planner.
>
> So, just for my understanding, if i don't return stats (returning NULL from
> index_bulk_delete and index_vacuum_cleanup functions), Query Planner will
> not consid
On 2018/01/29 16:28, Amit Langote wrote:
> create table p (a int, b int) partition by list (a);
> create table p1 partition of p for values in (1) partition by range (b);
> create table p11 partition of p1 for values from (1) to (10);
> create table p2 partition of p for values in (2);
>
> create
Robert Haas wrote:
> On Fri, Jan 26, 2018 at 8:04 AM, Antonin Houska wrote:
> > So one problem is that the grouping expression can be inappropriate for
> > partial aggregation even if there's no type change during the
> > translation. What I consider typical for this case is that the equality
>
On Sat, Jan 27, 2018 at 1:35 AM, Robert Haas wrote:
> On Thu, Jan 18, 2018 at 8:55 AM, Jeevan Chalke
> wrote:
> > Attached patch with other review points fixed.
>
> Committed 0001 and 0002 together, with some cosmetic changes,
> including fixing pgindent damage.
Thanks Robert.
> Please pg
Hello.
At Wed, 24 Jan 2018 10:30:39 +0100, Pavel Stehule
wrote in
> Hi
>
> 2018-01-23 8:13 GMT+01:00 Kyotaro HORIGUCHI > I have three comments on the behavior and one on documentation.
> >
> > 1. Lack of syntax handling.
> >
> > ["'" [^'] "'"] is also a string literal, but getXPathToken is
>
On 28.01.2018 03:40, Bruce Momjian wrote:
On Mon, Jan 22, 2018 at 06:51:08PM +0100, Tomas Vondra wrote:
Yes, external connection pooling is more flexible. It allows to
perform pooling either at client side either at server side (or even
combine two approaches).>
Also external connection poolin
Hello Doug,
I'm not sure why you do the following trick, could you explain?
+#undef USE_SELECT
+#define USE_SELECT
This was due to compiler complaint about USE_SELECT being redefined.
Have replaced that "trick" with a new #define POLL_USING_SELECT which is used
elsewhere in pgb
Hello. I reviewed this and think that this is in Ready for
Committer stage.
The patch is available here.
https://www.postgresql.org/message-id/CAFj8pRBVUVvG1CXxgrs0UipTziUX6M788z-%3DL9gQvwAB4UGLeg%40mail.gmail.com
The following list consists of the same items in upthread message
as confirmation.
Hi,
On 2018-01-27 22:06:59 -0800, Jeff Davis wrote:
> > infeasible because quite freuquently both non-JITed code and JITed code
> > need adjustments. That'd solve your concern about
>
> Can you explain further?
There's already a *lot* of integration points in the patchseries. Error
handling need
Hi Fabien,
On 28.01.2018 11:10, Fabien COELHO wrote:
Hello Ildar,
I did everything you mention here and attached a new version on the
patch.
Patch applies, compiles, runs ok.
Alas, I still have a few more very minor comments about the doc, sorry
again:
No problem : )
+defaul
Hi,
On 2018-01-28 23:02:56 +0100, Pierre Ducroquet wrote:
> I have fixed the build issues with LLVM 3.9 and 4.0. The LLVM documentation
> is
> really lacking when it comes to porting from version x to x+1.
> The only really missing part I found is that in 3.9, GlobalValueSummary has
> no
> fla
Hi,
On 2018-01-23 23:20:38 -0800, Andres Freund wrote:
> == Code ==
>
> As the patchset is large (500kb) and I'm still quickly evolving it, I do
> not yet want to attach it. The git tree is at
> https://git.postgresql.org/git/users/andresfreund/postgres.git
> in the jit branch
>
> https://gi
On 28 January 2018 at 12:00, Tomas Vondra wrote:
> On 01/27/2018 10:45 PM, Tom Lane wrote:
>> David Rowley writes:
>>> I'd offer to put it back to the order of the enum, but I want to
>>> minimise the invasiveness of the patch. I'm not sure yet if it should
>>> be classed as a bug fix or a new fe
On 28 January 2018 at 10:45, Tom Lane wrote:
> David Rowley writes:
>> I'd offer to put it back to the order of the enum, but I want to
>> minimise the invasiveness of the patch.
>
> I think the ordering of these items suffers greatly from "add new stuff
> at the end no matter what" syndrome. Fe
On Monday, January 29, 2018 10:46:13 AM CET Andres Freund wrote:
> Hi,
>
> On 2018-01-28 23:02:56 +0100, Pierre Ducroquet wrote:
> > I have fixed the build issues with LLVM 3.9 and 4.0. The LLVM
> > documentation is really lacking when it comes to porting from version x
> > to x+1.
> > The only re
On 29 January 2018 at 07:15, Nikhil Sontakke wrote:
>> Having this as responsibility of plugin sounds interesting. It certainly
>> narrows the scope for which we need to solve the abort issue. For 2PC
>> that may be okay as we need to somehow interact with transaction manager
>> as Simon noted. I
Thank you for kindly noticing me of that.
At Mon, 29 Jan 2018 11:07:31 +1300, Thomas Munro
wrote in
> On Thu, Jan 11, 2018 at 7:59 PM, Kyotaro HORIGUCHI
> wrote:
> > [new patch set]
>
> FYI this is still broken:
>
> test ddl ... FAILED
>
> You could see that like this:
On Fri, Jan 26, 2018 at 4:58 AM, David Steele wrote:
> On 1/25/18 12:31 AM, Masahiko Sawada wrote:
>> On Thu, Jan 25, 2018 at 3:25 AM, David Steele wrote:
Here is the first review comments.
+ unloggedDelim = strrchr(path, '/');
I think it doesn't work fine on w
On 23 January 2018 at 19:17, Petr Jelinek wrote:
> I am not sure if this helps streaming use-case though as
> there is not going to be any external transaction management involved there.
So, I think we need some specific discussion of what to do in that case.
Streaming happens only with big tra
Hello,
At Mon, 29 Jan 2018 19:26:34 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20180129.192634.217484965.horiguchi.kyot...@lab.ntt.co.jp>
> While rechecking the patch, I fixed the message issued on losing
> segments in 0001, revised the TAP test since I found that it was
> unstabl
On Fri, 26 Jan 2018 21:30:49 +0900
Yugo Nagata wrote:
> On Thu, 25 Jan 2018 20:51:41 +1300
> Thomas Munro wrote:
>
> > On Sun, Dec 31, 2017 at 11:57 PM, Yugo Nagata wrote:
> > > On Fri, 29 Dec 2017 23:39:39 +0900 (JST)
> > > Tatsuo Ishii wrote:
> > >> Your addition to the doc:
> > >> + Auto
Hello Ildar,
Fixed the doc, attached the patch. Thanks!
Patch applies, compiles, pgbench & global "make check" ok, doc built ok.
Ok for me, switched to "Ready".
--
Fabien.
On 26.01.2018 22:38, Andres Freund wrote:
And without it perf is not able to unwind stack trace for generated
code.
You can work around that by using --call-graph lbr with a sufficiently
new perf. That'll not know function names et al, but at least the parent
will be associated correctly.
W
On Mon, Jan 29, 2018 at 09:45:15AM +0200, Hannu Krosing wrote:
> ...
> I see two possibilities
>
> 1) add a third "ARG" to the CREATE OPERATOR syntax, maybe VALUEARG
> 2) use composite types - so for
>
> jsonb1[int1] = jsonb2
>
> the operator would be defined by first defining a
>
> CREATE
On 29.01.2018 15:03, Fabien COELHO wrote:
Patch applies, compiles, pgbench & global "make check" ok, doc built ok.
Ok for me, switched to "Ready".
Thank you for the thorough review!
--
Ildar Musin
i.mu...@postgrespro.ru
On Mon, Jan 29, 2018 at 07:28:22PM +0900, Masahiko Sawada wrote:
> Thank you for updating the patch! The patch looks good to me. But I
> have a question; can we exclude temp tables as well? The pg_basebackup
> includes even temp tables. But I don't think that it's necessary for
> backups.
They are
Hi Amit,
On 01/26/2018 04:17 AM, Amit Langote wrote:
I made a few of those myself in the updated patches.
Thanks a lot again for your work on this.
This needs a rebase.
Best regards,
Jesper
On 29.01.2018 07:34, Thomas Munro wrote:
On Sat, Jan 20, 2018 at 5:41 AM, Konstantin Knizhnik
wrote:
On 19.01.2018 16:14, Antonin Houska wrote:
you should test the operator B-tree strategy: BTLessStrategyNumber,
BTLessEqualStrategyNumber, etc. The operator string alone does not tell
enough
abo
Hi,
On 01/29/2018 11:23 AM, Simon Riggs wrote:
> On 29 January 2018 at 07:15, Nikhil Sontakke wrote:
>
>>> Having this as responsibility of plugin sounds interesting. It
>>> certainly narrows the scope for which we need to solve the abort
>>> issue. For 2PC that may be okay as we need to somehow
Hi,
On Sun, Jan 28, 2018 at 06:26:56PM +0100, Dmitry Dolgov wrote:
>
> Here is a new version of the patch:
>
> * rebased to the latest master
>
> * fixed issues I mentioned above
>
> * updated an example from the tutorial part
I have a few comments.
0002-Base-implementation-of-subscripting-m
On 29 January 2018 at 13:34, Tomas Vondra wrote:
> The important detail is that we only really care
> about aborts in transactions that modified catalogs in some way (e.g. by
> doing DDL). But we can safely decode (and stream) changes up to the
> point when the catalogs get modified, so we can do
On 01/29/18 03:32, Antonin Houska wrote:
> Robert Haas wrote:
>>> only take place if we had a special equality operator which distinguishes
>>> the
>>> *binary* values (I don't know yet how to store this operator the catalog ---
...
>> We don't have an operator that tests for binary equality, bu
On 01/29/2018 02:49 PM, Simon Riggs wrote:
> On 29 January 2018 at 13:34, Tomas Vondra
> wrote:
>
>> The important detail is that we only really care
>> about aborts in transactions that modified catalogs in some way (e.g. by
>> doing DDL). But we can safely decode (and stream) changes up to t
On 1/29/18 5:28 AM, Masahiko Sawada wrote:
> On Fri, Jan 26, 2018 at 4:58 AM, David Steele wrote:
>>
>> Attached is a new patch that uses stat() to determine if the init fork
>> for a relation file exists. I decided not to build a hash table as it
>> could use considerable memory and I didn't thi
On 29 January 2018 at 14:13, Tomas Vondra wrote:
> 4) inspect the new row (which we still have in reorderbuffer)
>
> 5) Kabooom! The row has column "c" which we don't see in the catalog.
We don't use caches? Why does a cache miss cause it to explode?
--
Simon Riggshttp://www.2n
Hi
2018-01-29 15:11 GMT+01:00 Simon Riggs :
> On 26 January 2018 at 11:25, Simon Riggs wrote:
> > On 24 January 2018 at 04:12, Simon Riggs wrote:
> >> On 24 January 2018 at 01:35, Peter Geoghegan wrote:
> >>>
> >> Please rebase, and post a new version.
> >>
> >> Will do, though I'm sure that's
Hello Ildus,
On 29.01.2018 14:44, Ildus Kurbangaliev wrote:
Thanks! Attached new version of the patch.
Patch applies cleanly, builds without any warnings, documentation builds
ok, all tests pass.
A remark for the committers. The patch is quite big, so I really wish
more reviewers looked
On Mon, Jan 29, 2018 at 4:12 AM, Masahiko Sawada wrote:
> On Sat, Jul 29, 2017 at 9:42 AM, Claudio Freire
> wrote:
>> Introduce a tree pruning threshold to FreeSpaceMapVacuum that avoids
>> recursing into branches that already contain enough free space, to
>> avoid having to traverse the whole F
On 29 January 2018 at 14:19, Pavel Stehule wrote:
>> The concurrency rules are very simple:
>> If a MATCHED row is concurrently updated/deleted
>> 1. We run EvalPlanQual
>> 2. If the updated row is gone EPQ returns NULL slot or EPQ returns a
>> row with NULL values, then
>> {
>>if NOT MATCHED
On Mon, Jan 29, 2018 at 3:32 AM, Antonin Houska wrote:
> I think of a variant of this: implement an universal function that tests the
> binary values for equality (besides the actual arguments, caller would have to
> pass info like typlen, typalign, typbyval for each argument, and cache these
> fo
On Sat, Jan 27, 2018 at 10:45 PM, Andres Freund wrote:
> Hi Peter (and others who mucked around with related code),
>
> While testing another patch I found that cancelling a parallel query on
> master segfaults the leader in an interesting manner:
...
> It's clearly not OK to recurse back into the
>
> >What I propose is in fact a server command, >which at least three of
> >the other popular RDBMSs already have.
>
Well to actually implement it, it would probably be a client command,
because that's what \d* are. We would most likely want them implemented
the same, to avoid needless complexity
On Sat, Jan 27, 2018 at 3:14 AM, Amit Kapila wrote:
> During the recent development of parallel operation (parallel create
> index)[1], a need has been arised for $SUBJECT. The idea is to allow
> leader backend to rely on number of workers that are successfully
> started. This API allows leader
2018-01-29 15:40 GMT+01:00 Simon Riggs :
> On 29 January 2018 at 14:19, Pavel Stehule
> wrote:
>
> >> The concurrency rules are very simple:
> >> If a MATCHED row is concurrently updated/deleted
> >> 1. We run EvalPlanQual
> >> 2. If the updated row is gone EPQ returns NULL slot or EPQ returns a
On Mon, Jan 29, 2018 at 02:51:53PM +, Ryan Murphy wrote:
> >
> > >What I propose is in fact a server command, >which at least three of
> > >the other popular RDBMSs already have.
> >
> Well to actually implement it, it would probably be a client command,
> because that's what \d* are.
Why shou
On Tue, Jan 23, 2018 at 8:51 AM, Simon Riggs wrote:
> This is complete and pretty clean now. 1200 lines of code, plus docs and
> tests.
>
> I'm expecting to commit this and then come back for the Partitioning &
> RLS later, but will wait a few days for comments and other reviews.
I agree with Pe
On 29 January 2018 at 14:55, Pavel Stehule wrote:
> My note was not against MERGE or INSERT ON CONFLICT. If I understand to this
> topic, I agree so these commands should be implemented separately. But if we
> use two commands with some intersection, there can be nice to have
> documentation abou
On 29 January 2018 at 15:07, Robert Haas wrote:
> Moreover, the patch should have had meaningful review from people not
> involved in writing it, and that is a process that generally takes a
> few months or at least several weeks, not a few days.
The code is about 1200 lines and has extensive do
On Mon, Jan 29, 2018 at 11:57:36AM +0300, Konstantin Knizhnik wrote:
> Right now, if you hit max_connections, we start rejecting new
> connections. Would it make sense to allow an option to exit idle
> connections when this happens so new users can connect?
>
> It will require changes
Hannu Krosing writes:
> I started looking at the thread about "Generic type subscripting" and am
> wondering, why does it take the approach of modifying pg_type and
> modifying lots of internal functions, when instead it could be defined
> in a much lighter and less intrusive way as an operator, p
On Mon, Jan 29, 2018 at 03:12:23PM +, Simon Riggs wrote:
> On 29 January 2018 at 14:55, Pavel Stehule wrote:
>
> > My note was not against MERGE or INSERT ON CONFLICT. If I understand to this
> > topic, I agree so these commands should be implemented separately. But if we
> > use two commands
Bruce>Yes, it would impact applications and you are right most applications
could not handle that cleanly.
I would disagree here.
We are discussing applications that produce "lots of idle" connections,
aren't we? That typically comes from an application-level connection pool.
Most of the connectio
On Mon, 29 Jan 2018 17:29:29 +0300
Ildar Musin wrote:
>
> Patch applies cleanly, builds without any warnings, documentation
> builds ok, all tests pass.
>
> A remark for the committers. The patch is quite big, so I really wish
> more reviewers looked into it for more comprehensive review. Also
Simon Riggs writes:
> On 29 January 2018 at 15:07, Robert Haas wrote:
>> An argument could be made that this patch is already too late for PG
>> 11, because it's a major feature that was not submitted in relatively
>> complete form before the beginning of the penultimate CommitFest.
> Overall, I
On Mon, Jan 29, 2018 at 04:02:22PM +, Vladimir Sitnikov wrote:
> Bruce>Yes, it would impact applications and you are right most applications
> could not handle that cleanly.
>
> I would disagree here.
> We are discussing applications that produce "lots of idle" connections, aren't
> we? That t
On 29 January 2018 at 15:44, Bruce Momjian wrote:
> On Mon, Jan 29, 2018 at 03:12:23PM +, Simon Riggs wrote:
>> On 29 January 2018 at 14:55, Pavel Stehule wrote:
>>
>> > My note was not against MERGE or INSERT ON CONFLICT. If I understand to
>> > this
>> > topic, I agree so these commands sh
On 01/29/2018 11:13 AM, Simon Riggs wrote:
> On 29 January 2018 at 15:44, Bruce Momjian wrote:
>> Uh, if we know we are going to get question on this, the patch had
>> better have an explanation of when to use it. Pushing the problem to
>> later doesn't seem helpful.
>
> What problem are you ref
On 29 January 2018 at 16:06, Tom Lane wrote:
> Simon Riggs writes:
>> On 29 January 2018 at 15:07, Robert Haas wrote:
>>> An argument could be made that this patch is already too late for PG
>>> 11, because it's a major feature that was not submitted in relatively
>>> complete form before the be
On Mon, Jan 29, 2018 at 04:34:48PM +, Simon Riggs wrote:
> I agree with all of the above.
>
> In terms of timing of commits, I have marked the patch Ready For
> Committer. To me that signifies that it is ready for review by a
> Committer prior to commit.
>
> In case of doubt, I would not even
On 29.01.2018 16:24, Konstantin Knizhnik wrote:
On 29.01.2018 07:34, Thomas Munro wrote:
On Sat, Jan 20, 2018 at 5:41 AM, Konstantin Knizhnik
wrote:
On 19.01.2018 16:14, Antonin Houska wrote:
you should test the operator B-tree strategy: BTLessStrategyNumber,
BTLessEqualStrategyNumber, etc.
Bruce Momjian writes:
> On Mon, Jan 29, 2018 at 04:34:48PM +, Simon Riggs wrote:
>> ... If unfinished means it has caveats
>> that is different to unfinished meaning crappy, risky, contentious
>> etc..
> I think the question is how does it handle cases it doesn't support?
> Does it give wron
On 29 January 2018 at 16:44, Bruce Momjian wrote:
> I think the question is how does it handle cases it doesn't support?
> Does it give wrong answers? Does it give a helpful error message? Can
> you summarize that?
I'm happy to report that it gives correct answers to every known MERGE
test, ex
Hi,
On 2018-01-29 15:45:56 +0300, Konstantin Knizhnik wrote:
> On 26.01.2018 22:38, Andres Freund wrote:
> > And without it perf is not able to unwind stack trace for generated
> > > code.
> > You can work around that by using --call-graph lbr with a sufficiently
> > new perf. That'll not know fun
On 29 January 2018 at 16:50, Tom Lane wrote:
> Bruce Momjian writes:
>> On Mon, Jan 29, 2018 at 04:34:48PM +, Simon Riggs wrote:
>>> ... If unfinished means it has caveats
>>> that is different to unfinished meaning crappy, risky, contentious
>>> etc..
>
>> I think the question is how does it
On 01/29/2018 03:17 PM, Simon Riggs wrote:
> On 29 January 2018 at 14:13, Tomas Vondra
> wrote:
>
>> 4) inspect the new row (which we still have in reorderbuffer)
>>
>> 5) Kabooom! The row has column "c" which we don't see in the catalog.
>
> We don't use caches? Why does a cache miss cause i
On 29 January 2018 at 16:23, Chapman Flack wrote:
> On 01/29/2018 11:13 AM, Simon Riggs wrote:
>> On 29 January 2018 at 15:44, Bruce Momjian wrote:
>>> Uh, if we know we are going to get question on this, the patch had
>>> better have an explanation of when to use it. Pushing the problem to
>>>
2018-01-29 18:08 GMT+01:00 Simon Riggs :
> On 29 January 2018 at 16:23, Chapman Flack wrote:
> > On 01/29/2018 11:13 AM, Simon Riggs wrote:
> >> On 29 January 2018 at 15:44, Bruce Momjian wrote:
> >>> Uh, if we know we are going to get question on this, the patch had
> >>> better have an explana
On Mon, Jan 29, 2018 at 8:44 AM, Bruce Momjian wrote:
> On Mon, Jan 29, 2018 at 04:34:48PM +, Simon Riggs wrote:
>> The only discussion would be about the word "unfinished". I'm not
>> clear why this patch, which has current caveats all clearly indicated
>> in the docs, differs substantially f
On Mon, Jan 29, 2018 at 8:51 AM, Simon Riggs wrote:
> On 29 January 2018 at 16:44, Bruce Momjian wrote:
>
>> I think the question is how does it handle cases it doesn't support?
>> Does it give wrong answers? Does it give a helpful error message? Can
>> you summarize that?
>
> I'm happy to repo
On 29 January 2018 at 17:35, Peter Geoghegan wrote:
> On Mon, Jan 29, 2018 at 8:51 AM, Simon Riggs wrote:
>> On 29 January 2018 at 16:44, Bruce Momjian wrote:
>>
>>> I think the question is how does it handle cases it doesn't support?
>>> Does it give wrong answers? Does it give a helpful error
On 1/29/18 9:13 AM, David Steele wrote:
> On 1/29/18 5:28 AM, Masahiko Sawada wrote:
>> But I
>> have a question; can we exclude temp tables as well? The pg_basebackup
>> includes even temp tables. But I don't think that it's necessary for
>> backups
> Thank you for having another look at the patch
On Mon, Jan 29, 2018 at 1:36 AM, Andres Freund wrote:
> There's already a *lot* of integration points in the patchseries. Error
> handling needs to happen in parts of code we do not want to make
> extensible, the defintion of expression steps has to exactly match, the
> core code needs to emit the
Hi,
On 2018-01-29 10:28:18 -0800, Jeff Davis wrote:
> OK. How about this: are you open to changes that move us in the
> direction of extensibility later? (By this I do *not* mean imposing a
> bunch of requirements on you... either small changes to your patches
> or something part of another commit
Bruce>Well, we could have the connection pooler disconnect those, right?
I agree. Do you think we could rely on all the applications being
configured in a sane way?
A fallback configuration at DB level could still be useful to ensure the DB
keeps running in case multiple applications access it. It
On 1/23/18 17:10, Alvaro Herrera wrote:
> The main question is this: when running the trigger function, it is
> going to look as it is running in the context of the partition, not in
> the context of the parent partitioned table (TG_RELNAME etc). That
> seems mildly ugly: some users may be expecti
On Mon, Jan 29, 2018 at 6:11 AM, Simon Riggs wrote:
> New patch attached that correctly handles all known concurrency cases,
> with expected test output.
This revision, v13, seems much improved in this area.
> This means MERGE will work just fine for "normal" UPDATEs, but it will
> often fail (d
On Mon, Jan 29, 2018 at 1:17 PM, David Steele wrote:
> On 1/29/18 9:13 AM, David Steele wrote:
>> On 1/29/18 5:28 AM, Masahiko Sawada wrote:
>>> But I
>>> have a question; can we exclude temp tables as well? The pg_basebackup
>>> includes even temp tables. But I don't think that it's necessary for
Hi,
On 2017-10-04 11:36:56 +0200, Alvaro Herrera wrote:
> Andrew Dunstan wrote:
> > On 10/03/2017 04:43 PM, Tom Lane wrote:
> > > I like the new-header-file idea because it will result in minimal code
> > > churn and thus minimal back-patching hazards.
I'm not sure it's that little code churn, an
Oliver Ford writes:
> [ 0001-window-frame-v9.patch ]
I've started to go through this in some detail, and I'm wondering why
you invented a FRAMEOPTION_EXCLUDE_NO_OTHERS option bit rather than
just representing that choice as default (0). As you have it, a
window definition that explicitly specifi
On 1/19/18 4:43 PM, Peter Eisentraut wrote:
> On 1/19/18 14:07, David Steele wrote:
>> I have yet to add tests for pg_rewindwal and pg_upgrade. pg_rewindwal
>> doesn't *have* any tests as far as I can tell and pg_upgrade has tests
>> in a shell script -- it's not clear how I would extend it or reu
On 29 January 2018 at 20:41, Peter Geoghegan wrote:
> On Mon, Jan 29, 2018 at 6:11 AM, Simon Riggs wrote:
>> New patch attached that correctly handles all known concurrency cases,
>> with expected test output.
>
> This revision, v13, seems much improved in this area.
>
>> This means MERGE will wo
Hi,
In contrast to most other nodes, nodeValuescan.c does expression
initialization at "runtime" rather than in initialization:
/*
* Get rid of any prior cycle's leftovers. We use
ReScanExprContext
* not just ResetExprContext because we want any
On 01/24/2018 08:20 AM, Andres Freund wrote:
> Hi,
>
> I've spent the last weeks working on my LLVM compilation patchset. In
> the course of that I *heavily* revised it. While still a good bit away
> from committable, it's IMO definitely not a prototype anymore.
>
> There's too many small chang
Hi,
On 2018-01-29 22:51:38 +0100, Tomas Vondra wrote:
> Hi, I wanted to look at this, but my attempts to build the jit branch
> fail with some compile-time warnings (uninitialized variables) and
> errors (unknown types, incorrect number of arguments). See the file
> attached.
Which git hash are y
On Sun, Jan 28, 2018 at 10:13 PM, Amit Kapila wrote:
> If we want to get rid of Gather (Merge) checks in
> apply_projection_to_path(), then we need some way to add a projection
> path to the subpath of gather node even if that is capable of
> projection as we do now. I think changing the order of
On 01/29/2018 10:57 PM, Andres Freund wrote:
> Hi,
>
> On 2018-01-29 22:51:38 +0100, Tomas Vondra wrote:
>> Hi, I wanted to look at this, but my attempts to build the jit branch
>> fail with some compile-time warnings (uninitialized variables) and
>> errors (unknown types, incorrect number of argu
On Monday, 29 January 2018, Tom Lane wrote:
> Oliver Ford writes:
> > [ 0001-window-frame-v9.patch ]
>
> I've started to go through this in some detail, and I'm wondering why
> you invented a FRAMEOPTION_EXCLUDE_NO_OTHERS option bit rather than
> just representing that choice as default (0). As
On 2018-01-29 23:01:14 +0100, Tomas Vondra wrote:
> On 01/29/2018 10:57 PM, Andres Freund wrote:
> > Hi,
> >
> > On 2018-01-29 22:51:38 +0100, Tomas Vondra wrote:
> >> Hi, I wanted to look at this, but my attempts to build the jit branch
> >> fail with some compile-time warnings (uninitialized var
On Mon, Jan 29, 2018 at 1:34 PM, Simon Riggs wrote:
>> The way that routines like ExecUpdate() interact with MERGE for WHEN
>> qual + EPQ handling seems kind of convoluted. I hope for something
>> cleaner in the next revision.
>
> Cleaner?
Yeah, cleaner. The fact that when quals kind of participa
On 01/29/2018 11:17 PM, Andres Freund wrote:
> On 2018-01-29 23:01:14 +0100, Tomas Vondra wrote:
>> On 01/29/2018 10:57 PM, Andres Freund wrote:
>>> Hi,
>>>
>>> On 2018-01-29 22:51:38 +0100, Tomas Vondra wrote:
Hi, I wanted to look at this, but my attempts to build the jit branch
fail w
Oliver Ford writes:
> On Monday, 29 January 2018, Tom Lane wrote:
>> I've started to go through this in some detail, and I'm wondering why
>> you invented a FRAMEOPTION_EXCLUDE_NO_OTHERS option bit rather than
>> just representing that choice as default (0).
> My guess is that it's a little like
On Monday, 29 January 2018, Tom Lane wrote:
> Oliver Ford writes:
> > On Monday, 29 January 2018, Tom Lane wrote:
> >> I've started to go through this in some detail, and I'm wondering why
> >> you invented a FRAMEOPTION_EXCLUDE_NO_OTHERS option bit rather than
> >> just representing that choic
Hi,
On 2018-01-29 23:49:14 +0100, Tomas Vondra wrote:
> On 01/29/2018 11:17 PM, Andres Freund wrote:
> > On 2018-01-29 23:01:14 +0100, Tomas Vondra wrote:
> >> $ llvm-config --version
> >> 5.0.0svn
> >
> > Is thta llvm-config the one in /usr/local/include/ referenced by the
> > error message above
On 01/29/2018 11:49 PM, Tomas Vondra wrote:
>
> ...
>
> and that indeed changes the failure to this:
>
> Writing postgres.bki
> Writing schemapg.h
> Writing postgres.description
> Writing postgres.shdescription
> llvmjit_error.cpp: In function ‘void llvm_enter_fatal_on_oom()’:
> llvmjit_error.c
Hi,
On 2018-01-30 00:16:46 +0100, Tomas Vondra wrote:
> FWIW I've installed llvm 5.0.1 from distribution package, and now
> everything builds fine (I don't even need the configure tweak).
>
> I think I had to build the other binaries because there was no 5.x llvm
> back then, but it's too far bac
On 1/22/18 16:04, Chapman Flack wrote:
>> PostgreSQL only allows a trigger action of "call this function", so in
>> the SQL standard context that would mean we'd need to check the EXECUTE
>> privilege of the owner of the trigger. The trick is figuring out who
>> the owner is. If it's the owner
On Sat, Jan 27, 2018 at 12:20 AM, Amit Kapila wrote:
> I have posted the patch for the above API and posted it on a new
> thread [1]. Do let me know either here or on that thread if the patch
> suffices your need?
I've responded to you over on that thread. Thanks again for helping me.
I already
On Mon, Jan 29, 2018 at 04:34:48PM +, Simon Riggs wrote:
> In terms of timing of commits, I have marked the patch Ready For
> Committer. To me that signifies that it is ready for review by a
> Committer prior to commit.
My understanding of this meaning is different than yours. It should not
b
1 - 100 of 124 matches
Mail list logo
