Re: [HACKERS] Releasing in September

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

Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex

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

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

> > 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

Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex

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

Re: [HACKERS] custom function for converting human readable sizes to bytes

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:

Re: [HACKERS] Extracting fields from 'infinity'::TIMESTAMP[TZ]

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

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

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

Re: [HACKERS] Minor code improvements to create_foreignscan_plan/ExecInitForeignScan

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

Re: Odd behavior in foreign table modification (Was: Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW)

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;

Re: [HACKERS] [PoC] Asynchronous execution again (which is not parallel)

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

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

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.

Re: [HACKERS] [PoC] Asynchronous execution again (which is not parallel)

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

Re: [HACKERS] Releasing in September

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

Re: [HACKERS] Patch: Implement failover on libpq connect level.

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 >

Re: [HACKERS] checkpointer continuous flushing

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

Re: Odd behavior in foreign table modification (Was: Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW)

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

Re: [HACKERS] Expanded Objects and Order By

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

Re: [HACKERS] Inconsistent error handling in START_REPLICATION command

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

Re: [HACKERS] Inconsistent error handling in START_REPLICATION command

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

Re: [HACKERS] WIP: Failover Slots

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

Re: [HACKERS] removal of unused argument in ginInsertCleanup()

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

Re: [HACKERS] Batch update of indexes

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.

Re: [HACKERS] Batch update of indexes

On 21.01.2016 10:14, Simon Riggs wrote: On 21 January 2016 at 06:41, konstantin knizhnik > 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

Re: [HACKERS] Re: pglogical_output - a general purpose logical decoding output plugin

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

Re: [HACKERS] Combining Aggregates

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

Re: [HACKERS] Combining Aggregates

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,

Re: [HACKERS] Batch update of indexes

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

Re: [HACKERS] custom function for converting human readable sizes to bytes

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, >

Re: [HACKERS] WIP: Failover Slots

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

Re: [HACKERS] Set search_path + server-prepared statements = cached plan must not change result type

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

Re: [HACKERS] Re: pglogical_output - a general purpose logical decoding output plugin

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

Re: [HACKERS] Parallel Aggregate

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.

Re: [HACKERS] Set search_path + server-prepared statements = cached plan must not change result type

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

Re: [HACKERS] Combining Aggregates

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

Re: [HACKERS]WIP: Covering + unique indexes.

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

Re: [HACKERS] proposal: PL/Pythonu - function ereport

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

Re: [HACKERS] Combining Aggregates

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 >>

[HACKERS] Re: pglogical_output - a general purpose logical decoding output plugin

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:

Re: [HACKERS]WIP: Covering + unique indexes.

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

Re: [HACKERS] log_checkpoint's "0 transaction log file(s) added" is extremely misleading

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.

Re: [HACKERS] Extracting fields from 'infinity'::TIMESTAMP[TZ]

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

Re: [HACKERS] Re: pglogical_output - a general purpose logical decoding output plugin

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

Re: [HACKERS] Parallel Aggregate

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

Re: [HACKERS] log_checkpoint's "0 transaction log file(s) added" is extremely misleading

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

[HACKERS] log_checkpoint's "0 transaction log file(s) added" is extremely misleading

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

Re: [HACKERS] Releasing in September

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

Re: [HACKERS] custom function for converting human readable sizes to bytes

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

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

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 > -

Re: [HACKERS] Extracting fields from 'infinity'::TIMESTAMP[TZ]

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

Re: [HACKERS] Declarative partitioning

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

Re: [HACKERS] Releasing in September

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

Re: [HACKERS] silent data loss with ext4 / all current versions

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,

Re: [HACKERS] custom function for converting human readable sizes to bytes

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.

Re: [HACKERS] WIP: Failover Slots

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

Re: [HACKERS] count_nulls(VARIADIC "any")

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