Thanks for looking over this and my apologies for the delay in my
response. I've been on leave and out of range of the internet for most
of that time.
On 23 November 2017 at 02:30, Ashutosh Bapat
wrote:
>
> @@ -597,15 +615,25 @@
On Thu, Nov 30, 2017 at 2:53 PM, Andrey Borodin wrote:
> I want to move also "Covering B-tree indexes (aka INCLUDE)" . Seems like we
> have common view with Peter Geoghegan and Anastasia that found drawback will
> be fixed before next CF.
>
> If there is no objections,
On 30 November 2017 at 07:40, Petr Jelinek
wrote:
> Hi,
>
> On 24/11/17 07:41, Craig Ringer wrote:
> > On 24 November 2017 at 13:44, Nikhil Sontakke >
> >
> > > How practical is adding a lock class?
> >
> > Am open to suggestions.
Michael, thank you for your hard work!
> 30 нояб. 2017 г., в 10:39, Michael Paquier
> написал(а):
>
> On Thu, Nov 30, 2017 at 2:29 PM, Tsunakawa, Takayuki
> wrote:
>> Now I tried that, successfully marking it as "waiting on author",
From: Michael Paquier [mailto:michael.paqu...@gmail.com]
> If you have a patch "waiting on author" that you would like to move to the
> next commit fest, just switch its status back temporarily to "needs review",
> and then do the move. Yes, that's unnecessary complication but I am not
> going to
On 2017/11/30 14:29, Tsunakawa, Takayuki wrote:
> From: Michael Paquier [mailto:michael.paqu...@gmail.com]
>> All patches not marked as ready for committer have been classified, by either
>> being marked as returned with feedback or moved to the next CF.
>> I may have made some mistakes of course,
On Thu, Nov 30, 2017 at 2:29 PM, Tsunakawa, Takayuki
wrote:
> Now I tried that, successfully marking it as "waiting on author", but the
> patch doesn't move to the next CF when I then change the status as "Move to
> next CF." How can I move the patch to next CF?
On Wed, Nov 29, 2017 at 1:04 AM, Peter Eisentraut
wrote:
> On 11/22/17 21:08, Michael Paquier wrote:
>> Yes, agreed. This patch looks good to me. In fe-auth-scram.c, it would
>> be also nice to add a comment to keep in sync the logics in
>>
From: Michael Paquier [mailto:michael.paqu...@gmail.com]
> All patches not marked as ready for committer have been classified, by either
> being marked as returned with feedback or moved to the next CF.
> I may have made some mistakes of course, hence if you feel that the status
> of your patch is
Hello,
On Wed, Nov 29, 2017 at 7:11 AM, Michael Paquier
wrote:
> On Wed, Nov 15, 2017 at 3:53 PM, Beena Emerson
> wrote:
>> Thank you for your suggestion. I am looking into this and will post a
>> patch soon.
>
> It has been two weeks since
On Wed, Nov 1, 2017 at 1:20 PM, Andreas Karlsson wrote:
> Here is a rebased version of the patch.
The patch does not apply, and needs a rebase. I am moving it to next
CF with waiting on author as status.
--
Michael
On Thu, Nov 30, 2017 at 1:34 PM, Tom Lane wrote:
> Noah Misch writes:
>> On Thu, Aug 17, 2017 at 12:15:58PM -0400, Tom Lane wrote:
>>> ... it's now looking to me like we should do the above with X = 5.13.4.
>>> That won't be a perfect solution, but it's
On Wed, Nov 29, 2017 at 11:34:56PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > On Thu, Aug 17, 2017 at 12:15:58PM -0400, Tom Lane wrote:
> >> ... it's now looking to me like we should do the above with X = 5.13.4.
> >> That won't be a perfect solution, but it's about the
On Wed, Nov 29, 2017 at 8:34 PM, Michael Paquier
wrote:
> The patch does not currently apply. I am noticing as well that Peter
> Geoghegan has registered himself as a reviewer a couple of hours back,
> so moved to next CF with waiting on author as status.
Marko
On Thu, Nov 16, 2017 at 8:27 PM, Daniel Verite wrote:
> Peter Eisentraut wrote:
>
>> There is also one need error that needs further investigation.
>
> I've looked at this bit in the regression tests about \gexec:
>
> --- a/src/test/regress/expected/psql.out
> +++
On Mon, Nov 27, 2017 at 11:41 AM, Jing Wang wrote:
> Hi All,
>
> This is a patch for current_database working on ALTER ROLE/GRANT/REVOKE
> statements which should be applied after the previous patch
> "comment_on_current_database_no_pgdump_v4.4.patch".
>
> By using the
On Tue, Sep 5, 2017 at 3:28 AM, Marko Tiikkaja wrote:
> On Mon, Sep 4, 2017 at 7:46 PM, Peter Geoghegan wrote:
>>
>> On Mon, Sep 4, 2017 at 10:05 AM, Marko Tiikkaja wrote:
>>
>> > But I'm generally against
>> > interfaces which put arbitrary
On Wed, Jun 21, 2017 at 11:37 PM, Alex K wrote:
>> On 16 Jun 2017, at 21:30, Alexey Kondratov
>> wrote:
>
>> > On 13 Jun 2017, at 01:44, Peter Geoghegan wrote:
>
>
>> > Speculative insertion has the following special entry
On Tue, Nov 21, 2017 at 6:36 PM, Peter Moser wrote:
> 2017-11-14 18:42 GMT+01:00 Tom Lane :
>> You might consider putting the rewriting into, um, the rewriter.
>> It could be a separate pass after view expansion, if direct integration
>> with the existing
On Tue, Nov 7, 2017 at 3:18 PM, Aleksandr Parfenov
wrote:
> On Mon, 6 Nov 2017 18:05:23 +1300
> Thomas Munro wrote:
>
>> On Sat, Oct 21, 2017 at 1:39 AM, Aleksandr Parfenov
>> wrote:
>> > In attachment updated
On Sun, Nov 19, 2017 at 5:45 AM, Tomas Vondra
wrote:
> Apparently there was some minor breakage due to duplicate OIDs, so here
> is the patch series updated to current master.
Moved to CF 2018-01.
--
Michael
On Thu, Nov 30, 2017 at 8:30 AM, Tomas Vondra
wrote:
> On 11/28/2017 02:29 PM, Ildus Kurbangaliev wrote:
>> On Mon, 27 Nov 2017 18:20:12 +0100
>> Tomas Vondra wrote:
>>
>>> I guess the trick might be -DRANDOMIZE_ALLOCATED_MEMORY (I
On Wed, Nov 22, 2017 at 6:06 AM, Masahiko Sawada wrote:
> After investigation, I found out that my previous patch was wrong
> direction. I should have changed XLogSendLogical() so that we can
> check the read LSN and set WalSndCaughtUp = true even after read a
> record
On Tue, Oct 31, 2017 at 9:42 PM, Ants Aasma wrote:
> Robert made a good point that people will still rely on the token
> being an LSN, but perhaps they will be slightly less angry when we
> explicitly tell them that this might change in the future.
This thread has stalled, I
On Thu, Nov 30, 2017 at 7:32 AM, Tom Lane wrote:
> [snip]
Moving to next CF per the hotness of the topic.
--
Michael
On Thu, Nov 30, 2017 at 12:32 PM, Robert Haas wrote:
> On Wed, Nov 29, 2017 at 8:25 PM, Michael Paquier
> wrote:
>> On Tue, Oct 31, 2017 at 6:46 PM, Kyotaro HORIGUCHI
>> wrote:
>>> This is a rebased version of
On Fri, Sep 15, 2017 at 4:36 AM, Alexander Korotkov
wrote:
> +1,
> FDW looks OK for prototyping pluggable storage, but it doesn't seem suitable
> for permanent implementation.
> BTW, Hadi, could you visit "Pluggable storage" thread and check how suitable
> upcoming
On Wed, Nov 29, 2017 at 8:25 PM, Michael Paquier
wrote:
> On Tue, Oct 31, 2017 at 6:46 PM, Kyotaro HORIGUCHI
> wrote:
>> This is a rebased version of the patch.
>
> As far as I can see, the patch still applies, compiles, and got no
>
On Fri, Aug 18, 2017 at 2:09 PM, Masahiko Sawada wrote:
> On Thu, Aug 17, 2017 at 8:17 PM, Masahiko Sawada
> wrote:
>> On Thu, Aug 17, 2017 at 9:10 AM, Peter Eisentraut
>> wrote:
>>> On 8/8/17 05:58, Masahiko
On Tue, Nov 28, 2017 at 6:41 AM, Alexander Korotkov
wrote:
> On Mon, Nov 27, 2017 at 10:56 PM, Robert Haas wrote:
>>
>> On Fri, Nov 24, 2017 at 5:33 AM, Alexander Korotkov
>> wrote:
>> > pg_prune_xid makes sense only
On Mon, Oct 2, 2017 at 7:52 AM, Tom Lane wrote:
> I wrote:
>> This patch no longer applies cleanly on HEAD, so here's a rebased version
>> (no substantive changes). As before, I think the most useful review task
>> would be to quantify whether it makes planning noticeably
On Fri, Mar 24, 2017 at 10:50 PM, Tom Lane wrote:
> Ashutosh Bapat writes:
>>> Do you have test case, which can reproduce the issue you
>>> explained above?
>
>> No. It would require some surgery in standard_planner() to measure the
>> memory
On Wed, Nov 29, 2017 at 7:42 PM, Stephen Frost wrote:
> Ashutosh,
>
> * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
>> On Wed, Nov 29, 2017 at 4:56 AM, Stephen Frost wrote:
>> > The "global rethink" being contemplated seems to be more about
>>
Ashutosh Bapat writes:
> On Fri, Jul 21, 2017 at 4:10 AM, Thomas Munro
> wrote:
>> Please find attached a new version, and a test script I used, which
>> shows a bunch of interesting cases. I'll add this to the commitfest.
> I
On 30 November 2017 at 15:34, Michael Paquier
wrote:
> On Wed, Nov 15, 2017 at 3:17 PM, David Rowley
> wrote:
> > The remove_singleton_appends_examples_of_differences_2017-11-15.patch
> > which I've attached applies changes to the
On Wed, Sep 13, 2017 at 12:51 PM, Pavel Stehule wrote:
>
>
> 2017-09-13 1:42 GMT+02:00 Daniel Gustafsson :
>>
>> > On 08 Apr 2017, at 15:46, David Steele wrote:
>> >
>> >> On 1/13/17 6:55 AM, Marko Tiikkaja wrote:
>> >>> On Fri, Jan
On Wed, Nov 22, 2017 at 10:30 PM, Ashutosh Bapat
wrote:
> On Wed, Nov 1, 2017 at 5:39 AM, David Rowley
> wrote:
>
>> In this case, the join *can* cause row duplicates, but the distinct or
>> group by would filter these out again
On Mon, Nov 20, 2017 at 4:49 PM, Antonin Houska wrote:
> One more idea:
>
> I think the metadata (ALIGN_GAP) should be stored separate from the actual
> data so that you can use memcpy() instead of this loop:
>
> while (i < j)
> {
> charc =
On Thu, Nov 2, 2017 at 11:35 AM, Robert Haas wrote:
> On Thu, Nov 2, 2017 at 8:01 AM, Craig Ringer wrote:
>> That forces materialization, and I'm guessing part of Tomas's goal
>> here is to prevent the need to materialize into a temp table /
>>
On Fri, Sep 22, 2017 at 9:03 AM, Nikita Glukhov wrote:
> Should I start a separate thread for this issue and add patches to
> commitfest?
Yes, please. It would be nice if you could spawn a separate thread for
what looks like a bug, and separate topics should have their
On 2017-11-30 14:17:51 +1300, Thomas Munro wrote:
> On Mon, Nov 27, 2017 at 10:25 PM, Thomas Munro
> wrote:
> > On Thu, Nov 23, 2017 at 12:36 AM, Thomas Munro
> > wrote:
> >> Here's a new patch set with responses to the last batch of
On 2017/11/30 11:18, Michael Paquier wrote:
> On Thu, Nov 30, 2017 at 10:43 AM, Amit Langote
> wrote:
>> I'm working on a revised version of these patches to address recent
>> comments by Horiguchi-san. I will also consider the points above before
>> sending the
On Thu, Nov 9, 2017 at 12:33 PM, Ashutosh Bapat
wrote:
> Looking at order_qual_clauses(), we can say that a set of quals q1
> qn are ordered the same irrespective of the set of clauses they
> are subset of. E.g. if {q1 .. qn} is subset of Q (ordered as Qo)
On Tue, Aug 22, 2017 at 9:17 PM, Sokolov Yura
wrote:
> Simplified a bit and more commented patch version is in attach.
>
> Algorithm were switched to linear probing, it makes code simpler and
> clearer.
> Flag usages were toggled: now it indicates that hash table were
On Tue, Nov 28, 2017 at 5:50 PM, Jeevan Chalke
wrote:
> [snip]
This is still a hot topic so I am moving it to next CF.
--
Michael
On Tue, Oct 24, 2017 at 5:54 AM, Masahiko Sawada wrote:
> Yeah, I was thinking the commit is relevant with this issue but as
> Amit mentioned this error is emitted by DROP SCHEMA CASCASE.
> I don't find out the cause of this issue yet. With the previous
> version patch,
From: Michael Paquier [mailto:michael.paqu...@gmail.com]
> This patch does not apply, and did not get any reviews. So I am moving it
> to next CF with waiting on author as status. Please provide a rebased version.
> Tsunakawa-san, you are listed as a reviewer of this patch. If you are not
>
On Thu, Sep 14, 2017 at 2:23 PM, Ashutosh Bapat
wrote:
> Are you referring to rounding errors? We should probably add some fuzz
> factor to cover the rounding errors and cause a diff when difference
> in expected and reported plan rows is beyond that fuzz factor.
On Thu, Nov 30, 2017 at 10:52 AM, Michael Paquier
wrote:
> On Wed, Nov 29, 2017 at 5:33 AM, Robert Haas wrote:
>> On Sun, Nov 26, 2017 at 9:33 PM, Masahiko Sawada
>> wrote:
>>> Attached latest patch incorporated all
On Sun, Nov 26, 2017 at 5:15 PM, Amit Kapila wrote:
> Yeah and I think something like that can happen after your patch
> because now the memory for tuples returned via TupleQueueReaderNext
> will be allocated in ExecutorState and that can last for long. I
> think it is
On Wed, Sep 13, 2017 at 2:11 AM, Konstantin Knizhnik
wrote:
> One more patch passing all regression tests with autoprepare_threshold=1.
> I still do not think that it should be switch on by default...
This patch does not apply, and did not get any reviews. So I am
On 2017/11/30 7:15, Robert Haas wrote:
> On Wed, Nov 29, 2017 at 3:28 PM, Robert Haas wrote:
>> On Wed, Nov 22, 2017 at 3:59 AM, Amit Langote
>> wrote:
>>> It seems I wrote an Assert in the code to support hash partitioning that
>>> wasn't
On 2017/11/30 5:28, Robert Haas wrote:
> On Wed, Nov 22, 2017 at 3:59 AM, Amit Langote
> wrote:
>> It seems I wrote an Assert in the code to support hash partitioning that
>> wasn't based on a valid assumption. I was wrongly assuming that all hash
>> partitions for
On Mon, Mar 20, 2017 at 6:33 PM, Alexander Korotkov
wrote:
> Thank you for the report.
> Please, find rebased patch in the attachment.
This patch cannot be applied. Please provide a rebased version. I am
moving it to next CF with waiting on author as status.
--
On Tue, Sep 12, 2017 at 9:48 PM, Tom Lane wrote:
> Jim Nasby writes:
>> I've verified that the patch still applies and make check-world is clean.
>
> Not any more :-(. Here's a v3 rebased over HEAD. No substantive
> change from v2.
Patch applies and
On Thu, Nov 30, 2017 at 2:20 PM, Michael Paquier
wrote:
> This patch does not apply. And the thread has stalled for three months
> now but I cannot see a review for what has been submitted. I am moving
> it to next CF with waiting on author. Please provide a rebased
>
On Wed, Jun 28, 2017 at 9:58 AM, Thomas Munro
wrote:
> Rebased for the recent re-indent and shm_toc API change; no functional
> changes in this version.
>
> (I have a new patch set in the pipeline adding the skew optimisation
> and some other things, more on that
On Mon, Nov 27, 2017 at 10:25 PM, Thomas Munro
wrote:
> On Thu, Nov 23, 2017 at 12:36 AM, Thomas Munro
> wrote:
>> Here's a new patch set with responses to the last batch of review comments.
>
> Rebased on top of the recent SGML->XML
On 2017/11/30 10:11, Amit Langote wrote:
> in the attached updated version.
Oops, I messed up taking the diff and mistakenly added noise to the patch.
Fixed in the attached.
Thanks,
Amit
diff --git a/src/backend/executor/execPartition.c
b/src/backend/executor/execPartition.c
index
On Fri, Aug 25, 2017 at 6:25 PM, David Rowley
wrote:
> I just had a quick glance over this and wondered about 2 things.
>
> 1. Why a GUC and not a new per user option so it can be configured
> differently for different users? Something like ALTER USER ... WORKER
>
Hi Michael.
On 2017/11/30 9:07, Michael Paquier wrote:
> Hi all,
>
> Since commit 4e5fe9ad (committer Robert Haas and author Amit Langote),
> coverity has been complaining that the new code of ExecFindPartition()
> may use a set of values and isnull values which never get initialized.
> This is
On Wed, Nov 29, 2017 at 1:53 PM, Michael Paquier
wrote:
> On Wed, Nov 29, 2017 at 8:12 AM, Tom Lane wrote:
>> IIRC, this issue was debated at great length back when we first put
>> in foreign tables, because early drafts of postgres_fdw did what you
Hi all,
Since commit 4e5fe9ad (committer Robert Haas and author Amit Langote),
coverity has been complaining that the new code of ExecFindPartition()
may use a set of values and isnull values which never get initialized.
This is a state which can be easily reached with the following SQLs of
a
On 2017-11-30 00:45:44 +0100, Petr Jelinek wrote:
> I don't understand. I mean sure the SnapBuildWaitSnapshot() can live
> with it, but the problematic logic happens inside the
> XactLockTableInsert() and SnapBuildWaitSnapshot() has no way of
> detecting the situation short of reimplementing the
>
On 30/11/17 00:40, Andres Freund wrote:
> On 2017-11-30 00:25:58 +0100, Petr Jelinek wrote:
>> Yes that helps thanks. Now that I reproduced it I understand, I was
>> confused by the backtrace that said xid was 0 on the input to
>> XactLockTableWait() but that's not the case, it's what xid is
On 2017-11-30 00:25:58 +0100, Petr Jelinek wrote:
> Yes that helps thanks. Now that I reproduced it I understand, I was
> confused by the backtrace that said xid was 0 on the input to
> XactLockTableWait() but that's not the case, it's what xid is changed to
> in the inner loop.
> So what happens
Hi,
On 24/11/17 07:41, Craig Ringer wrote:
> On 24 November 2017 at 13:44, Nikhil Sontakke
>
> > How practical is adding a lock class?
>
> Am open to suggestions. This looks like it could work decently.
>
>
> It looks amazingly simple from here. Which
On 2017-11-29 18:23:40 -0500, Chapman Flack wrote:
> On 11/29/2017 05:54 PM, Michael Paquier wrote:
>
> > Yes. That's actually what the autovacuum launcher does. It connects
> > using InitPostgres(NULL, InvalidOid, NULL, NULL), and then scans
> > pg_database to fetch a list (see
On 29/11/17 20:11, Stas Kelvich wrote:
>
>> On 29 Nov 2017, at 18:46, Petr Jelinek wrote:
>>
>> What I don't understand is how it leads to crash (and I could not
>> reproduce it using the pgbench file attached in this thread either) and
>> moreover how it leads to 0
On 11/29/2017 05:54 PM, Michael Paquier wrote:
> Yes. That's actually what the autovacuum launcher does. It connects
> using InitPostgres(NULL, InvalidOid, NULL, NULL), and then scans
> pg_database to fetch a list (see get_database_list).
Thanks! It looks like if get_database_list were not
On Thu, Nov 30, 2017 at 7:48 AM, Chapman Flack wrote:
> For the "master" one, what capabilities will it need to simply
> enumerate the current names of known databases? I suppose I could
> have it connect to the null dbname and query pg_database. Would
> that be the
I'm thinking of writing a background worker that will enumerate
the databases present, and spin off, for each one, another BGW
that will establish a connection and do stuff.
For the "master" one, what capabilities will it need to simply
enumerate the current names of known databases? I suppose I
> On 29 Nov 2017, at 04:29, Michael Paquier wrote:
>
> On Tue, Nov 28, 2017 at 10:07 AM, Michael Paquier
> wrote:
>> I was just looking at the tsearch code which uses pg_strcmpcase, and
>> those are defined with makeDefElem() so you should
Andres Freund writes:
> On 2017-11-29 16:39:14 -0500, Tom Lane wrote:
>> Andres Freund writes:
>>> FWIW, I think that's a perfectly reasonable choice. Adding complications
>>> in making static assertions work for random archaic compilers when
>>> compiling
On Wed, Nov 29, 2017 at 3:28 PM, Robert Haas wrote:
> On Wed, Nov 22, 2017 at 3:59 AM, Amit Langote
> wrote:
>> It seems I wrote an Assert in the code to support hash partitioning that
>> wasn't based on a valid assumption. I was wrongly
Andres Freund writes:
> On 2017-11-29 09:41:15 -0500, Robert Haas wrote:
>> +/* not worth providing a workaround */
> FWIW, I think that's a perfectly reasonable choice. Adding complications
> in making static assertions work for random archaic compilers when
> compiling with
On Wed, Nov 22, 2017 at 3:59 AM, Amit Langote
wrote:
> It seems I wrote an Assert in the code to support hash partitioning that
> wasn't based on a valid assumption. I was wrongly assuming that all hash
> partitions for a given modulus (largest modulus) must exist
The following test
-- Input relation to aggregate push down hook is not safe to pushdown and thus
-- the aggregate cannot be pushed down to foreign server.
explain (verbose, costs off)
select count(t1.c3) from ft1 t1, ft1 t2 where t1.c1 = postgres_fdw_abs(t1.c2);
produces the following plan
On 2017-11-29 09:41:15 -0500, Robert Haas wrote:
> On Wed, Nov 29, 2017 at 9:26 AM, Peter Eisentraut
> wrote:
> > I'd still like a review of this patch.
>
> I don't think there's much to review apart from this one issue.
> Neither Tom nor I seem to be convinced
On November 29, 2017 8:50:31 AM PST, Stephen Frost wrote:
>As for conflicting snapshots, isn't the lock we're taking already
>AccessExclusive..?
Doesn't help if e.g. the current xact is repeatable read or if your own xact
deleted things (other xacts with snapshots could
Here is new patch with check only existed valid constraints and without SPI at
all.
Thanksdiff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index d979ce2..7ab7580 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -370,6 +370,8
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I did not look at the patch yet, but TBH if it uses SPI for sub-operations
>> of ALTER TABLE I think that is sufficient reason to reject it out of hand.
> You mean like what ALTER TABLE ... ADD FOREIGN KEY
On Wed, Nov 29, 2017 at 10:52 AM, Sergei Kornilov wrote:
> I agree this. Thinking a little about idea of index scan i can not give
> reasonable usecase which required index. My target problem of adding NOT NULL
> to big relation without long downtime can be done with ADD
Hi,
On 17/11/17 08:35, Kyotaro HORIGUCHI wrote:
>
> Moving around the code allow us to place ps_is_send_pending() in
> the while condition, which seems to be more proper place to do
> that. I haven't added test for this particular case.
>
> I tested this that
>
> - cleanly applies on the
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Isn't the first concern addressed by using SPI..?
>
> I did not look at the patch yet, but TBH if it uses SPI for sub-operations
> of ALTER TABLE I think that is sufficient reason to reject it out of
Hi,
(sorry for not being active here, I am still catching up after being
away for some family issues)
On 16/11/17 21:12, Robert Haas wrote:
> On Thu, Nov 16, 2017 at 2:41 PM, Andres Freund wrote:
>>> To me, it seems like SnapBuildWaitSnapshot() is fundamentally
>>>
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Nov 28, 2017 at 1:59 PM, Sergei Kornilov wrote:
> > I write patch to speed up ALTER TABLE SET NOT NULL by check existed check
> > constraints or indexes. Huge phase 3 with verify table data will be skipped
> > if
On Wed, Nov 29, 2017 at 7:30 AM, Thomas Munro
wrote:
> While reviewing commit c6755e23 I realised that es_query_dsa is
> broken. It might have made some kind of sense as a name and a concept
> in an earlier version of the proposal to add a DSA area for parallel
>
On 2017-11-29 17:56, Victor Drobny wrote:
Sorry, forgot to attach new version of the patch.
On 2017-11-28 17:57, Aleksander Alekseev wrote:
Hi Aleksander,
Thank you for review. I have tried to fix all of your comments.
However i want to mention that the absence of comments for functions
in
[...] Yeah, that sort of style would be OK with me. But I wouldn't
like:
struct blah {
#ifdef FOO
int doohicky;
#else
char *doohicky;
};
Indeed. Me neither.
--
Fabien.
Ashutosh,
* Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
> On Wed, Nov 29, 2017 at 4:56 AM, Stephen Frost wrote:
> > The "global rethink" being contemplated seems to be more about
> > authentication forwarding than it is about this specific change. If
> > there's
On Wed, Nov 29, 2017 at 3:40 AM, Fabien COELHO wrote:
> ever is best. Not sure that "pfds" is the right name. If the two variables
> means the same thing, they should have the same name, although possibly
> different types.
Although I agree with a good bit of what you say
On Wed, Nov 29, 2017 at 7:59 PM, Alexander Korotkov
wrote:
> Sure, patch got some review. I've no objection against moving this to the
> next commitfest though.
Please note that as this is qualified as a bug fix, I was not going to
mark it as returned with feedback or
On 11/29/17 12:46 AM, Michael Paquier wrote:> On Wed, Nov 1, 2017 at
5:58 PM, Chris Travers wrote:
>
> Please note that I am still -1 for using a methodology different than
> what is used for base backups with an inclusive method, and would much
> prefer an exclusive
Hi!
On Wed, Nov 29, 2017 at 2:32 PM, Andrey Borodin
wrote:
> 29 нояб. 2017 г., в 15:59, Alexander Korotkov
> написал(а):
>
>
> Sure, patch got some review. I've no objection against moving this to the
> next commitfest though.
> Since, these
On 28 November 2017 at 23:17, Peter Geoghegan wrote:
> BTW, a good short term solution for you might be to change the vacuum
> cost delay settings. They're pretty conservative by default.
>
> There is a good chance that your indexes are mostly in memory even on
> large tables, and
Hello,
On Wed, Nov 15, 2017 at 4:43 AM, David Rowley
wrote:
> On 15 November 2017 at 01:57, David Rowley
> wrote:
>> I think to do this you're going to have to store some sort of array
>> that maps the partition index to the subpath
On Tue, Nov 14, 2017 at 6:27 PM, David Rowley
wrote:
> On 14 November 2017 at 19:16, Beena Emerson wrote:
>> PFA the updated patches.
>
> Hi Beena,
>
> Thanks for working on this. I've had a look at the patch to try to
> understand how it is
Hello,
PFA the new version of the patch which can be applied over v11 patches
of Amit Langote [1]. The patch has been completely modified and the
0001 patch of previous series is no longer required. As mentioned
above, I have used the PartitionDispatchInfo and an array to which
holds the actual
Hello Rajkumar,
On Tue, Nov 14, 2017 at 2:22 PM, Rajkumar Raghuwanshi
wrote:
> On Tue, Nov 14, 2017 at 11:46 AM, Beena Emerson
> wrote:
>>
>> PFA the updated patches.
>
>
> Hi,
>
> I have started testing this along with fast
1 - 100 of 108 matches
Mail list logo