2017-01-11 15:08 GMT+01:00 Marko Tiikkaja :
> On Wed, Jan 11, 2017 at 2:54 PM, Pavel Stehule
> wrote:
>
>> 1. strict_multi_assignment - checks the number of target variables and
>> source values.
>>
>
> I've proposed this before (maybe around a year ago), except the checks
> were done at parse ti
Jesper Pedersen wrote:
> + /*
> + * We copy the page into local storage to avoid holding pin on
> the
> + * buffer longer than we must, and possibly failing to release
> it at
> + * all if the calling query doesn't fetch all rows.
> +
On Mon, Dec 5, 2016 at 8:01 AM, Haribabu Kommi wrote:
> Moved to next CF with "needs review" status.
I have started reviewing the patch, Some initial comments.
$ git apply ../pg_stat_sql_row_mode_2.patch
error: patch failed: src/include/catalog/pg_proc.h:2893
error: src/include/catalog/pg_proc.h
> +itup = (IndexTuple) PageGetItem(uargs->page, id);
> +
> +MemSet(nulls, 0, sizeof(nulls));
> +
> +j = 0;
> +values[j++] = UInt16GetDatum(uargs->offset);
> +values[j++] = CStringGetTextDatum(psprintf("(%u,%u)",
> +
> BlockIdGetBlockNumber(&(itup->t_tid.ip_bl
On 11 Jan. 2017 21:29, "Andrew Dunstan"
wrote:
On 01/10/2017 09:25 PM, Bruce Momjian wrote:
> I am not saying we shouldn't do it, but I am afraid that the complexity
> in figuring out when to use indirect indexes, combined with the number
> of users who will try them, really hurts its inclusio
On Wed, Jan 11, 2017 at 2:54 PM, Pavel Stehule
wrote:
> 1. strict_multi_assignment - checks the number of target variables and
> source values.
>
I've proposed this before (maybe around a year ago), except the checks were
done at parse time, rather than runtime. I much prefer that approach. If
Hi
I am starting new thread for this patch (related to merging some ideas from
plpgsql2 project thread).
Here is simple patch with two new extra_warnings, extra_errors checks
1. strict_multi_assignment - checks the number of target variables and
source values.
2. too_many_rows - checks if return
On 11 Jan. 2017 16:29, "Fabien COELHO" wrote:
> I'm lost. This is precisely what I had in mind above with "read-only
transaction" which is "warranted not to fail". I do not understand about
which point you write "No".
I misread. We agree.
>>
Are you "voting" for or against [Pavel's] propos
Hello,
On Wed, Jan 11, 2017 t 6:06 PM, Beena Emerson
wrote:
>
>
> On Fri, Jan 6, 2017 at 11:54 AM, Ryan Murphy
> wrote:
>
>> The following review has been posted through the commitfest application:
>> make installcheck-world: tested, failed
>> Implements feature: tested, passed
>> Spec c
On 01/10/2017 09:25 PM, Bruce Momjian wrote:
I am not saying we shouldn't do it, but I am afraid that the complexity
in figuring out when to use indirect indexes, combined with the number
of users who will try them, really hurts its inclusion.
I think you're making this out to be far more c
On Wed, Jan 11, 2017 at 7:36 PM, Simon Riggs wrote:
> The specification of the recovery target parameters should be different, IMHO.
>
> If the user is performing a recovery and the target of the recovery is
> incorrectly specified then it is clear that the recovery cannot
> continue with an impre
Bruce Momjian wrote:
> My point is that anything you add must be weighed against the value it
> gives to users who use it, and the percentage of users who will use it.
> Against that benefit, you have to look at the cost of exposing that API
> to users, code complexity, maintenance, etc.
I agree.
Pavan Deolasee wrote:
> I was going to ask if we could implement indirect indexes as a separate
> IndexAM. But I re-read this thread and found that you'd in fact done it
> that way in the first version but then discarded it for performance
> reasons. Is there a merit in evaluating that path for in
=?UTF-8?B?6auY5aKe55Cm?= writes:
> In transformDeleteStmt:
> qry->hasWindowFuncs = pstate->p_hasWindowFuncs;
> qry->hasAggs = pstate->p_hasAggs;
> if (pstate->p_hasAggs)
> parseCheckAggregates(pstate, qry);
> Do we support using agg or window function in delete statement?
> O
Rafia Sabih writes:
> Approach:
> A token for query string is created in the shared memory, this token is
> populated with the query string using the global string --
> debug_query_string. Now, for each of the worker when
> ExecGetParallelQueryDesc is called, we retrieve the query text from shared
On Fri, Jan 6, 2017 at 11:54 AM, Ryan Murphy wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, failed
> Implements feature: tested, passed
> Spec compliant: tested, passed
> Documentation:tested, passe
On 2017/01/05 21:38, Ashutosh Bapat wrote:
On Thu, Jan 5, 2017 at 5:51 PM, Etsuro Fujita
wrote:
On 2017/01/05 21:11, Ashutosh Bapat wrote:
On 2017/01/03 17:28, Ashutosh Bapat wrote:
Also, in this function, if fpinfo->tlist is already set, why do we want
to
build it again?
IIUC, for a rel
Hello,
The attached patch adds backslash-return (well newline really) continuations
to all pgbench backslash-commands.
The attached test uses continuations on all such commands (sleep set
setshell and shell).
I think that adding continuations to psql should be a distinct patch.
The patch do
On 01/10/2017 05:16 PM, Dilip Kumar wrote:
Please try attached patch and confirm from your
side.
Thanks,issue seems to be fixed now.
--
regards,tushar
EnterpriseDB https://www.enterprisedb.com/
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
On Mon, Jan 9, 2017 at 11:26 PM, Antonin Houska wrote:
> Attached is a draft patch that lets partial aggregation happen at base
> relation level. If the relations contain relatively small number of groups,
> the number of input rows of the aggregation at the query level can be reduced
> this way.
On 2017/01/11 19:26, Ashutosh Bapat wrote:
On Wed, Jan 11, 2017 at 3:30 PM, Etsuro Fujita
wrote:
On 2017/01/11 17:51, Ashutosh Bapat wrote:
On Wed, Jan 11, 2017 at 1:15 PM, Etsuro Fujita
wrote:
On 2017/01/11 13:40, Ashutosh Bapat wrote:
Or it can
have foreign paths in there, which will need
On 11 January 2017 at 09:51, Fujii Masao wrote:
>> 5. recovery.conf parameters are all moved to postgresql.conf, with these
>> changes
>
> In current design of the patch, when recovery parameters are misconfigured
> (e.g., set recovery_target_timeline to invalid timeline id) and
> the configurat
On 9 January 2017 at 19:50, Peter Eisentraut
wrote:
> On 1/1/17 4:14 PM, Simon Riggs wrote:
>> OK, so here's the patch, plus doc cleanup patch.
>
> I don't think this patch is likely to succeed if we throw in more ideas
> in every round.
>
> I think we have or are approaching agreement on moving r
On Wed, Jan 11, 2017 at 3:30 PM, Etsuro Fujita
wrote:
> On 2017/01/11 17:51, Ashutosh Bapat wrote:
>>
>> On Wed, Jan 11, 2017 at 1:15 PM, Etsuro Fujita
>> wrote:
>>>
>>> On 2017/01/11 13:40, Ashutosh Bapat wrote:
CreateLocalJoinPath tries to construct a nestloop path for the given
On Tue, Jan 10, 2017 at 7:28 PM, Amit Kapila wrote:
> On Mon, Jan 9, 2017 at 11:47 PM, Robert Haas wrote:
>>
>> Yes, something like this can be done. You don't really need any new
>> page-level header data, because you can get the XIDs from the TPD
>> entry (or from the page itself if there's on
On 2017/01/11 17:51, Ashutosh Bapat wrote:
On Wed, Jan 11, 2017 at 1:15 PM, Etsuro Fujita
wrote:
On 2017/01/11 13:40, Ashutosh Bapat wrote:
CreateLocalJoinPath tries to construct a nestloop path for the given
join relation because it wants to avoid merge/hash join paths which
require expensive
On Tue, Jan 10, 2017 at 4:50 AM, Peter Eisentraut
wrote:
> On 1/1/17 4:14 PM, Simon Riggs wrote:
>> OK, so here's the patch, plus doc cleanup patch.
>
> I don't think this patch is likely to succeed if we throw in more ideas
> in every round.
>
> I think we have or are approaching agreement on mov
On Mon, Jan 2, 2017 at 6:14 AM, Simon Riggs wrote:
> On 20 December 2016 at 15:11, Simon Riggs wrote:
>> On 20 December 2016 at 15:03, Fujii Masao wrote:
>>
>>> API for crash recovery will never be changed. That is, crash recovery needs
>>> neither recovery.trigger nor standby.trigger. When the
Amit Kapila wrote:
> On Wed, Jan 11, 2017 at 2:44 AM, David Rowley
> wrote:
>> It has come to my attention that when a user has a CONNECTION LIMIT
>> set, and they make use of parallel query, that their queries can fail
>> due to the connection limit being exceeded.
>>
>> Simple test case:
>>
>> p
On Wed, Jan 11, 2017 at 8:28 AM, Masahiko Sawada
wrote:
> Hi,
>
> Attached fixes comment typos in dsa.c.
>
Thanks, pushed!
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Wed, Jan 11, 2017 at 1:15 PM, Etsuro Fujita
wrote:
> On 2017/01/11 13:40, Ashutosh Bapat wrote:
>>
>> CreateLocalJoinPath tries to construct a nestloop path for the given
>> join relation because it wants to avoid merge/hash join paths which
>> require expensive setup not required for EPQ. But
On 10/01/17 15:06, Peter Eisentraut wrote:
> On 1/3/17 5:23 PM, Petr Jelinek wrote:
>> I got this remark about IsCatalogClass() from Andres offline as well,
>> but it's not true, it only checks for FirstNormalObjectId for objects in
>> pg_catalog and toast schemas, not anywhere else.
>
> I see you
Hello Craig.
I'm not so sure about Craig precise opinion, but I cannot talk in his name.
I think that I understood that he points out that there exists a situation
where the use case is okay despite an untransactional variable: if the
containing transaction is warranted not to fail, and probabl
On 10/01/17 14:52, Peter Eisentraut wrote:
> On 1/2/17 8:32 AM, Petr Jelinek wrote:
>> On 02/01/17 05:23, Steve Singer wrote:
>>> but I can't drop the subscription either
>>>
>>>
>>> test_b=# drop subscription mysub;
>>> ERROR: could not drop replication origin with OID 1, in use by PID 24996
>>>
101 - 134 of 134 matches
Mail list logo
