On 22 January 2016 at 00:31, Robert Haas wrote:
> On Fri, Jan 1, 2016 at 7:50 PM, Simon Riggs wrote:
> > Failover Slots
> > In the current patch, any slot defined on a master will generate WAL,
> > leading to a pending-slot being present on all standby nodes. When a
> standby
> > is promoted, th
2016-01-22 7:03 GMT+01:00 Vitaly Burovoy :
> On 1/20/16, Pavel Stehule wrote:
> > ...
> > New version is attached
> >
> > Regards
> > Pavel
>
> Hello!
>
> 1. Why the function is marked as VOLATILE? It depends only on input
> value, it does change nothing in the DB.
> I guess it should be IMMUTABL
On 1/21/16, Tom Lane wrote:
> Vik Fearing writes:
>> I looked around for other places where this code should be used and
>> didn't find any. I am marking this patch Ready for Committer.
>
> I pushed this with some adjustments, mainly to make sure that the
> erroneous-units errors exactly match t
On Mon, Dec 21, 2015 at 4:45 PM, Michael Paquier
wrote:
> As this thread is stalling a bit, please find attached a series of
> patch gathering all the pending issues for this thread:
> - 0001, fix config_default.pl for MSVC builds to take into account TAP tests
> - 0002, append a node name in get_
On 1/20/16, Pavel Stehule wrote:
> ...
> New version is attached
>
> Regards
> Pavel
Hello!
1. Why the function is marked as VOLATILE? It depends only on input
value, it does change nothing in the DB.
I guess it should be IMMUTABLE for efficient caching its result.
2.
> text*a
On Tue, Jan 19, 2016 at 4:20 PM, Tomas Vondra
wrote:
>
>
> On 01/19/2016 08:03 AM, Michael Paquier wrote:
>>
>> On Tue, Jan 19, 2016 at 3:58 PM, Tomas Vondra
>> wrote:
>>>
>>>
> ...
Tomas, I am planning to have a look at that, because it seems to be
important. In case it becomes lo
On Wed, Jan 20, 2016 at 06:58:24PM +, Simon Riggs wrote:
> The main problem is the length of the integration phase, which is mostly
> where nothing happens.
The open items wiki page saw steady change from 30 April to 28 December[1];
the two longest quiet periods were an eleven-day gap from 21
On Wed, Jan 20, 2016 at 12:40:04PM -0500, Tom Lane wrote:
> I think it might also be a good idea if we could somehow distinguish
> "nobody had time for that yet" from "nobody is interested", with an eye
> to flat-out rejecting patches that no one cares enough about to review.
> Maybe we could reduc
Hi,
On 2016/01/17 9:47, Corey Huinker wrote:
>> If we have a CREATE statement for each partition, how do we generalize
>> that to partitions at different levels? For example, if we use something
>> like the following to create a partition of parent_name:
>>
>> CREATE PARTITION partition_name OF p
On Fri, Jan 22, 2016 at 7:44 AM, David Rowley
wrote:
> On 21 January 2016 at 18:26, Haribabu Kommi wrote:
>> Here I attached update parallel aggregate patch on top of recent commits
>> of combine aggregate and parallel join patch. It still lacks of cost
>> comparison
>> code to compare both para
Vik Fearing writes:
> I looked around for other places where this code should be used and
> didn't find any. I am marking this patch Ready for Committer.
I pushed this with some adjustments, mainly to make sure that the
erroneous-units errors exactly match those that would be thrown in
the main
On 22 January 2016 at 06:13, Tomasz Rybak wrote:
> + data stream. The output stream is designed to be compact and fast to
> decode,
> + and the plugin supports upstream filtering of data so that only the
> required
> + information is sent.
>
> plugin supports upstream filtering of data through h
On January 22, 2016 3:29:44 AM GMT+01:00, Simon Riggs
wrote:
>On 22 January 2016 at 01:12, Andres Freund wrote:
>
>> Hi,
>>
>> While in theory correct, I think $subject is basically meaningless
>> because other backends may have added thousands of new segments. Yes,
>it
>> wasn't the checkpointe
On 22 January 2016 at 01:12, Andres Freund wrote:
> Hi,
>
> While in theory correct, I think $subject is basically meaningless
> because other backends may have added thousands of new segments. Yes, it
> wasn't the checkpointer, but that's not particularly relevant
> imo. Additionally, afaics, it
Hi,
While in theory correct, I think $subject is basically meaningless
because other backends may have added thousands of new segments. Yes, it
wasn't the checkpointer, but that's not particularly relevant
imo. Additionally, afaics, it will only ever be 0 or 1.
I think we should either remove tha
On Thu, Jan 21, 2016 at 3:52 PM, David Rowley
wrote:
> On 21 January 2016 at 15:53, Haribabu Kommi
> wrote:
>>
>> On Thu, Jan 21, 2016 at 1:33 PM, Haribabu Kommi
>> wrote:
>> >
>> > Here I attached updated patch of parallel aggregate based on the latest
>> > changes in master. Still it lack of c
2016-01-14 17:16 GMT+01:00 Catalin Iacob :
> On Wed, Jan 13, 2016 at 7:40 PM, Jim Nasby
> wrote:
> > On 1/12/16 11:25 AM, Catalin Iacob wrote:
> >> They're similar but not really the same thing. raise Error and
> >> plpy.error are both ways to call ereport(ERROR, ...) while SPIError is
> >> raise
On 20 January 2016 at 06:08, Anastasia Lubennikova
wrote:
>
>
>
> 18.01.2016 01:02, David Rowley пишет:
>
> On 14 January 2016 at 08:24, David Rowley
> wrote:
>>
>> I will try to review the omit_opclass_4.0.patch soon.
>
>
> Hi, as promised, here's my review of the omit_opclass_4.0.patch patch.
On Tue, Jan 19, 2016 at 9:08 AM, Anastasia Lubennikova
wrote:
>
>
> 18.01.2016 01:02, David Rowley пишет:
>
> On 14 January 2016 at 08:24, David Rowley
> wrote:
>>
>> I will try to review the omit_opclass_4.0.patch soon.
>
>
> Hi, as promised, here's my review of the omit_opclass_4.0.patch patch.
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Documentation - although I haven't yet went through protocol documentation:
On 22 January 2016 at 06:56, Robert Haas wrote:
> On Wed, Jan 20, 2016 at 8:32 PM, David Rowley
> wrote:
>> The other two usages which I have thought of are;
>>
>> 1) Aggregating before UNION ALL, which might be fairly simple after the
>> grouping planner changes, as it may just be a matter of co
Robert>Are you really seeing the same behavior in all versions?
I do not have "pre 9.1" at hand, however all 9.1, 9.2, 9.3, 9.4, and
9.5 are affected.
9.1 just silently executes "old statement" as if search_path was not
modified at all.
9.2, 9.3, 9.4, and 9.5 all fail with "cached plan must not c
On 21 January 2016 at 18:26, Haribabu Kommi wrote:
> Here I attached update parallel aggregate patch on top of recent commits
> of combine aggregate and parallel join patch. It still lacks of cost
> comparison
> code to compare both parallel and normal aggregates.
Thanks for the updated patch.
Hi
2016-01-17 8:43 GMT+01:00 Pavel Stehule :
>
>
> 2016-01-12 17:27 GMT+01:00 Marko Tiikkaja :
>
>> On 03/01/16 22:49, Jim Nasby wrote:
>>
>>> In the unit test, I'd personally prefer just building a table with the
>>> test cases and the expected NULL/NOT NULL results, at least for all the
>>> cal
On 21 January 2016 at 16:31, Robert Haas wrote:
> On Fri, Jan 1, 2016 at 7:50 PM, Simon Riggs wrote:
> > Failover Slots
> > In the current patch, any slot defined on a master will generate WAL,
> > leading to a pending-slot being present on all standby nodes. When a
> standby
> > is promoted, th
2016-01-21 11:51 GMT+01:00 Vitaly Burovoy :
> On 1/20/16, Pavel Stehule wrote:
> > ...
> > New version is attached
> >
> > Regards
> > Pavel
>
> I'm sorry I'll do a review only tonight.
>
ook :)
Thank you
Pavel
> --
> Best regards,
> Vitaly Burovoy
>
On Wed, Jan 20, 2016 at 9:33 PM, Haribabu Kommi
wrote:
> Here I attached updated patch of parallel aggregate based on the latest
> changes in master. Still it lack of cost comparison of normal aggregate to
> parallel aggregate because of difficulty. This cost comparison is required
> in parallel a
On Wed, Jan 20, 2016 at 8:32 PM, David Rowley
wrote:
> At the moment I think everything which will use this is queued up behind the
> pathification of the grouping planner which Tom is working on. I think
> naturally Parallel Aggregate makes sense to work on first, given all the
> other parallel s
On 21.01.2016 19:09, Anastasia Lubennikova wrote:
What I meant is more like a BRIN-like combination of an index scan and
heap scan.
Maybe it could be called "deferred inserts" or "temporary read-only
index"
Maybe it's similar with mysql insert buffer
http://dev.mysql.com/doc/refman/5.7/en/inn
On 21.01.2016 10:14, Simon Riggs wrote:
On 21 January 2016 at 06:41, konstantin knizhnik
mailto:k.knizh...@postgrespro.ru>> wrote:
Certainly for B-Tree we can organize insert buffer (or pending
list) as sorted array or also as a tree.
But in both case complexity of search in this
On Wed, Jan 20, 2016 at 12:54 AM, Craig Ringer wrote:
> The idea here is that we want downwards compatibility as far as possible and
> maintainable but we can't really be upwards compatible for breaking protocol
> revisions. So the output plugin's native protocol version is inherently the
> max pr
On Wed, Jan 20, 2016 at 8:04 PM, Craig Ringer wrote:
> itself is an abbreviation of its self.
I do not think this is true.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Thu, Jan 21, 2016 at 9:15 AM, Michael Paquier
wrote:
> On Wed, Jan 20, 2016 at 11:32 PM, Fujii Masao wrote:
>> I found the unused argument "vac_delay" in ginInsertCleanup().
>> I think that we should remove it. Patch attached.
>
> Visibly an oversight of dc943ad, +1 for nuking it.
Ok, pushed!
On Wed, Jan 20, 2016 at 10:23 AM, Vladimir Sitnikov
wrote:
>> I believe, and the conclusion was that
>>if you think you need this, you're doing it wrong
>
> So what is the recommended approach to use server-prepared statements
> at the client side (I mean at JDBC driver side)?
>
> Currently "prep
On Fri, Jan 1, 2016 at 7:50 PM, Simon Riggs wrote:
> Failover Slots
> In the current patch, any slot defined on a master will generate WAL,
> leading to a pending-slot being present on all standby nodes. When a standby
> is promoted, the slot becomes usable and will have the properties as of the
>
20.01.2016 17:55, Konstantin Knizhnik:
Hi,
Hi, I glad to see that you interested in that too.
I think this is a good feature and I think it will be very useful to
have.
I have already mentioned some related problems and possible
improvements in my presentation.
http://www.slideshare.net/Anas
Paul Ramsey writes:
> Thank the Maker, it is reproduceable: returning an expanded header in the _in
> function is not appreciated in a very narrow number of cases.
BTW, on further poking around: if you'd had RANDOMIZE_ALLOCATED_MEMORY
enabled, returning an expanded object from an input function
On Thu, Jan 21, 2016 at 3:25 PM, Robert Haas wrote:
> On Wed, Jan 20, 2016 at 2:28 AM, Craig Ringer
> wrote:
> > It enters COPY BOTH mode before it invokes the startup callback. The
> client
> > has no way to unilaterally terminate COPY BOTH mode and return to the
> normal
> > walsender protocol
On Wed, Jan 20, 2016 at 2:28 AM, Craig Ringer wrote:
> It enters COPY BOTH mode before it invokes the startup callback. The client
> has no way to unilaterally terminate COPY BOTH mode and return to the normal
> walsender protocol. The server doesn't do it when there's an ERROR. So the
> only opti
30.12.2015 16:01, Aleksander Alekseev:
Here is a clean version of the patch. Step 1 is an optimization. Step 2
refactors this:
HTAB *
ShmemInitHash(const char *name, /* table string name for shmem index */
- long init_size, /* initial table size */
+ long init_size,
> > In such a
> > case, which userid should be stored in UserMapping structure?It might
> look
> > like setting GetUserId() as userid in UserMapping is wise, but not
> really.
> > All the foreign tables might have different effective userids, each
> > different from GetUserId() and what GetUserId()
On 01/05/2016 09:07 AM, Vitaly Burovoy wrote:
> On 1/4/16, Alvaro Herrera wrote:
>> It seems we got majority approval on the design of this patch, and no
>> disagreement; the last submitted version appears to implement that.
>> There's no documentation change in the patch though. I'm marking it a
On Thu, Jan 21, 2016 at 3:03 AM, Robert Haas wrote:
> On Mon, Jan 18, 2016 at 6:47 AM, Ashutosh Bapat
> wrote:
> > 2. pg_fdw_join_v2.patch: postgres_fdw changes for supporting join
> pushdown
>
> The very first hunk of this patch contains annoying whitespace
> changes. Even if the result is wha
On Tue, Jan 12, 2016 at 1:50 PM, Aleksander Alekseev <
a.aleks...@postgrespro.ru> wrote:
>
> increasing number of lock partitions (see columns "no locks", "lwlock"
> and "spinlock array"). Previously it couldn't help us (see "master"
> column) because of a bottleneck.
>
> If you have any other que
On Wed, Jan 20, 2016 at 4:40 PM, Bruce Momjian wrote:
> Many people where happy with our consistent releasing major releases in
> September, e.g. 9.0 to 9.3:
>
> Not sure why the commitfest process should be synchronized with the
release process. What if, when the release date comes, the currentl
On 2016/01/21 7:04, Alvaro Herrera wrote:
Etsuro Fujita wrote:
On second thought, I noticed that detecting whether we see a system column
that way needs more cycles in cases where the reltargetlist and the
restriction clauses don't contain any system columns. ISTM that such cases
are rather com
On 1/20/16, Pavel Stehule wrote:
> ...
> New version is attached
>
> Regards
> Pavel
I'm sorry I'll do a review only tonight.
--
Best regards,
Vitaly Burovoy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/m
Hi!
On 2016/01/21 18:26, Kyotaro HORIGUCHI wrote:
>>> Then, suppose we add a function bool ExecStartAsync(PlanState *target,
>>> ExecCallback callback, PlanState *cb_planstate, void *cb_context).
>>> For non-async-aware plan nodes, this just returns false. async-aware
>>> plan nodes should initi
On 2016/01/19 19:04, Thom Brown wrote:
On 12 January 2016 at 11:49, Etsuro Fujita wrote:
On 2016/01/12 20:36, Thom Brown wrote:
On 8 January 2016 at 05:08, Etsuro Fujita
wrote:
On 2016/01/06 20:37, Thom Brown wrote:
I've run into an issue:
*# UPDATE master_customers SET id = 22 WHERE
On 2016/01/20 19:57, Rushabh Lathia wrote:
Overall I am quite done with the review of this patch. Patch is in good
shape and covered most of the things which been discussed earlier
or been mentioned during review process. Patch pass through the
make check and also includes good test coverage.
T
On Tue, 19 Jan 2016 14:34:54 +
Thom Brown wrote:
> The segfault issue I originally reported now appears to be resolved.
>
> But now I have another one:
>
> psql
> 'postgresql://thom@127.0.0.1:5530,127.0.0.1:5531,127.0.0.1:5532,127.0.0.1:5533/postgres?hostorder=random&readonly=1&failover_tim
Hello,
I put some consideration and trial on callbacks as a means to
async(early)-execution.
> > Suppose we equip each EState with the ability to fire "callbacks".
> > Callbacks have the signature:
> >
> > typedef bool (*ExecCallback)(PlanState *planstate, TupleTableSlot
> > *slot, void *context
On 2016/01/21 5:06, Robert Haas wrote:
On Wed, Jan 20, 2016 at 4:50 AM, Etsuro Fujita
wrote:
My concern about that is that would make the code in deparseTargetList()
complicated.
Essentially, I think your propossal needs a two-pass algorithm for
deparseTargetList; (1) create an integer List of
On Thu, Jan 21, 2016 at 10:11 AM, Michael Paquier
wrote:
>
> On Thu, Jan 21, 2016 at 1:32 PM, Michael Paquier
> wrote:
> > On Thu, Jan 21, 2016 at 12:59 AM, Bruce Momjian
wrote:
> >> On Wed, Jan 20, 2016 at 10:55:07AM -0500, Robert Haas wrote:
> >>> On Wed, Jan 20, 2016 at 10:48 AM, Andres Freun
On 2016-01-21 11:33:15 +0530, Amit Kapila wrote:
> On Wed, Jan 20, 2016 at 9:07 PM, Andres Freund wrote:
> > I don't think it's strongly related - the contention here is on read
> > access to the clog, not on write access.
>
> Aren't reads on clog contended with parallel writes to clog?
Sure. Bu
55 matches
Mail list logo