On Mon, Dec 5, 2016 at 11:35 AM, Haribabu Kommi
wrote:
> Moved to next CF with "needs review" status.
Same, this time to CF 2017-03.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-
On Sat, Dec 31, 2016 at 7:35 AM, Alvaro Herrera
wrote:
> Attached is v4, which fixes a couple of relatively minor bugs. There
> are still things to tackle before this is committable, but coding review
> of the new executor node would be welcome.
Moved to CF 2017-03 because of a lack of reviews.
On Fri, Jan 13, 2017 at 12:23 PM, Amit Kapila wrote:
> On Fri, Jan 13, 2017 at 1:04 AM, Jesper Pedersen
> wrote:
>> On 12/27/2016 01:58 AM, Amit Kapila wrote:
>>>
>>> After recent commit's 7819ba1e and 25216c98, this patch requires a
>>> rebase. Attached is the rebased patch.
>>>
>>
>> This need
On Sat, Jan 28, 2017 at 8:02 PM, Amit Kapila wrote:
> On Fri, Jan 27, 2017 at 5:15 PM, Ashutosh Sharma
> wrote:
>>>
>>> Don't you think we should try to identify the reason of the deadlock
>>> error reported by you up thread [1]? I know that you and Ashutosh are
>>> not able to reproduce it, bu
On Wed, Feb 1, 2017 at 12:57 AM, Vitaly Burovoy
wrote:
> Hello,
>
> I've reviewed the patch[1].
>
Noting to add from my side as well.
--
Thanks & Regards,
Kuntal Ghosh
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
On Wed, Jan 11, 2017 at 10:42 PM, Craig Ringer wrote:
> There is no code yet. Code review and testing is where things get firmer.
>
> My personal stance right now is that I'd like to see catalog-decared typed
> variables. I would prefer them to be transactional and would at least oppose
> anything
On Wed, Jan 11, 2017 at 11:55 PM, Pavel Stehule wrote:
> I'll mark this patch as ready for commiter
Moved to CF 2017-03.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Jan 31, 2017 at 12:45 PM, Kyotaro HORIGUCHI
wrote:
> I noticed that this patch is conflicting with 665d1fa (Logical
> replication) so I rebased this. Only executor/Makefile
> conflicted.
The patches still apply, moved to CF 2017-03. Be aware of that:
$ git diff HEAD~6 --check
contrib/post
On Wed, Jan 25, 2017 at 2:44 AM, Peter Eisentraut
wrote:
> On 1/15/17 5:53 AM, Pavel Stehule wrote:
>> the regress test fails
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x007bbc2b in pattern_char_isalpha (locale_is_c=0 '\000',
>> locale=0x1a73220, is_multibyte=1 '\001',
On Tue, Jan 31, 2017 at 7:21 PM, Alvaro Herrera
wrote:
>
> > > +#define HeapTupleHeaderGetNextTid(tup, next_ctid) \
> > > +do { \
> > > + AssertMacro(!((tup)->t_infomask2 & HEAP_LATEST_TUPLE)); \
> > > + ItemPointerCopy(&(tup)->t_ctid, (next_ctid)); \
> > > +} while (0)
> >
> > > Actually
On Tue, Jan 24, 2017 at 6:32 PM, Peter Moser wrote:
> [reviews and discussions]
The patch proposed has rotten. Please provide a rebase. By the way, I
am having a hard time applying your patches with patch or any other
methods... I am moving it to CF 2017-03 because of the lack of
reviews.
--
Mic
On Tue, Jan 31, 2017 at 11:05 AM, Claudio Freire wrote:
> Updated and rebased v7 attached.
Moved to CF 2017-03.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sun, Jan 29, 2017 at 6:13 PM, Mithun Cy wrote:
>> HashMetaPage _hash_getcachedmetap(Relation rel, Buffer *metabuf, bool
>> force_refresh);
>>
>> If the cache is initialized and force_refresh is not true, then this
>> just returns the cached data, and the metabuf argument isn't used.
>> Otherwis
2017-02-01 6:05 GMT+01:00 Michael Paquier :
> On Wed, Jan 11, 2017 at 10:42 PM, Craig Ringer
> wrote:
> > There is no code yet. Code review and testing is where things get firmer.
> >
> > My personal stance right now is that I'd like to see catalog-decared
> typed
> > variables. I would prefer th
On Thu, Jan 26, 2017 at 6:49 AM, Tom Lane wrote:
> Nikita Glukhov writes:
>> On 25.01.2017 23:58, Tom Lane wrote:
>>> I think you need to take a second look at the code you're producing
>>> and realize that it's not so clean either. This extract from
>>> populate_record_field, for example, is pr
On Tue, Jan 31, 2017 at 9:36 PM, Robert Haas wrote:
> On Thu, Jan 5, 2017 at 12:54 AM, Kuntal Ghosh
> wrote:
>> I've attached the patch with the modified changes. PFA.
Thanks Robert for taking your time for the review. I'll update the
patch with the changes suggested by you.
--
Thanks & Regar
On Mon, Jan 23, 2017 at 6:51 PM, Kuntal Ghosh
wrote:
> On Wed, Jan 18, 2017 at 11:31 AM, Rushabh Lathia
> wrote:
>>
> The patch needs a rebase after the commit 69f4b9c85f168ae006929eec4.
Is an update going to be provided? I have moved this patch to next CF
with "waiting on author" as status.
--
On Tue, Jan 31, 2017 at 5:53 PM, Rahila Syed wrote:
> Hello,
>
>>Agreed, that it makes sense to consider only the number of pages to
>>scan for computation of parallel workers. I think for index scan we
>>should consider both index and heap pages that need to be scanned
>>(costing of index scan c
Thank you.
At Wed, 1 Feb 2017 14:11:58 +0900, Michael Paquier
wrote in
> On Tue, Jan 31, 2017 at 12:45 PM, Kyotaro HORIGUCHI
> wrote:
> > I noticed that this patch is conflicting with 665d1fa (Logical
> > replication) so I rebased this. Only executor/Makefile
> > conflicted.
>
> The patches s
On Thu, Jan 26, 2017 at 8:16 AM, Tom Lane wrote:
> [ in the service of closing out this thread... ]
>
> Peter Geoghegan writes:
>> Finally, 0003-* is a Valgrind suppression borrowed from my parallel
>> CREATE INDEX patch. It's self-explanatory.
>
> Um, I didn't find it all that self-explanatory.
On Tue, Jan 17, 2017 at 2:40 PM, Amit Langote
wrote:
> Hi Amit,
>
> On 2016/12/23 14:21, Amit Khandekar wrote:
>> Currently an Append plan node does not execute its subplans in
>> parallel. There is no distribution of workers across its subplans. The
>> second subplan starts running only after the
On Wed, Jan 25, 2017 at 4:02 PM, Craig Ringer wrote:
> If we want to save the 4 bytes per xmin advance (probably not worth
> caring) we can instead skip setting it on the standby, in which case
> it'll be potentially wrong until the next checkpoint. I'd rather make
> sure it stays correct.
Those
On Tue, Jan 24, 2017 at 7:37 AM, Craig Ringer wrote:
> Rebased series attached, on top of current master (which includes
> logical replicaiton).
>
> I'm inclined to think I should split out a few of the changes from
> 0005, roughly along the lines of the bullet points in its commit
> message. Anyo
On Fri, Jan 20, 2017 at 3:03 AM, Petr Jelinek
wrote:
> Okay, here is v3 with some small fixes and rebased on top of rename.
> Also it's rebased without the
> 0005-Add-separate-synchronous-commit-control-for-logical--v18.patch as I
> don't expect that one to go further for now.
>
> Thanks for testi
On Wed, Jan 25, 2017 at 7:20 PM, Etsuro Fujita
wrote:
> Attached is the new version of the patch. I also addressed other comments
> from you: moved rewriting the fdw_scan_tlist to postgres_fdw.c,
> added/revised comments, and added regression tests for the case where a
> pushed down UPDATE/DELETE
On Fri, Dec 30, 2016 at 12:55 PM, Haribabu Kommi
wrote:
> Any Comments on the approach?
I have moved this patch to CF 2017-03.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hacker
On Fri, Dec 2, 2016 at 9:20 PM, Haribabu Kommi wrote:
> Moved to next CF with "needs review" status.
There has not been much interest in this patch, moved again, this time
to CF 2017-03.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your s
Hello, thank you for moving this to the next CF.
At Wed, 1 Feb 2017 13:09:51 +0900, Michael Paquier
wrote in
> On Tue, Jan 24, 2017 at 4:58 PM, Kyotaro HORIGUCHI
> wrote:
> > Six new syscaches in 665d1fa was conflicted and 3-way merge
> > worked correctly. The new syscaches don't seem to be ta
On Thu, Jan 19, 2017 at 9:07 PM, Rafia Sabih
wrote:
> Please find the attached file rebased patch of parallel index-only
> scan on the latest Parallel index-scan patch [1].
Moved to CF 2017-03.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
At Wed, 01 Feb 2017 12:13:04 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20170201.121304.267734380.horiguchi.kyot...@lab.ntt.co.jp>
> > > I tried a committed Logical Replication environment. I found
> > > that replication between databases of different encodings did
> > > not con
On Wed, Feb 1, 2017 at 8:01 AM, Michael Paquier
wrote:
> On Wed, Feb 1, 2017 at 1:06 AM, Robert Haas wrote:
>> +/*
>> + * Leave if no masking functions defined, this is possible in the case
>> + * resource managers generating just full page writes, comparing an
>> + * image to it
At Tue, 31 Jan 2017 14:38:39 +0300, Nikita Glukhov
wrote in <1622dc9f-cecf-cee3-b71e-b2bf34649...@postgrespro.ru>
> On 31.01.2017 13:04, Kyotaro HORIGUCHI wrote:
> > The following comment,
> >
> >> /* Can any range from range_box to be overlower than this argument? */
> >
> > This might be better
On Wed, Feb 1, 2017 at 5:37 PM, Michael Paquier
wrote:
> On Tue, Jan 31, 2017 at 2:15 PM, Peter Geoghegan wrote:
>> On Mon, Jan 30, 2017 at 8:46 PM, Thomas Munro
>> wrote:
>>> On Wed, Jan 4, 2017 at 12:53 PM, Peter Geoghegan wrote:
Attached is V7 of the patch.
>>>
>>> I am doing some testi
Hello Robert,
>I am a bit mystified about how this manages to work with array keys.
>_bt_parallel_done() won't set btps_pageStatus to BTPARALLEL_DONE
>unless so->arrayKeyCount >= btscan->btps_arrayKeyCount, but
>_bt_parallel_advance_scan() won't do anything unless btps_pageStatus
>is already BTPAR
Hello, I'll add the rebased version to the next CF.
At Fri, 20 Jan 2017 11:07:29 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20170120.110729.107284864.horiguchi.kyot...@lab.ntt.co.jp>
> > > > - Delaying recycling a segment until the last partial record on it
> > > > completes. Th
On Tue, Jan 31, 2017 at 11:23 PM, Thomas Munro
wrote:
> 2. All participants: parallel sequential scan, sort, spool to disk;
> barrier; leader: merge spooled tuples and build btree.
>
> This patch is doing the 2nd thing. My understanding is that some
> systems might choose to do that if they don'
101 - 136 of 136 matches
Mail list logo
