On 27 September 2014 23:23, Peter Geoghegan wrote:
> On Thu, Sep 25, 2014 at 1:48 PM, Simon Riggs wrote:
>> I hate the fact
>> that you have written no user facing documentation for this feature.
>
> Attached patch adds a commit to the existing patchset. For the
> convenience of reviewers, I've u
Hi all,
Recent commit 491c029 introducing RLS has broken a bit the verbose logs of
pg_dump, one message missing a newline:
+ if (g_verbose)
+ write_msg(NULL, "reading row-security enabled for
table \"%s\"",
+ tbinfo->dobj.
On Fri, Sep 26, 2014 at 12:36 AM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> On 09/16/2014 01:20 PM, David Rowley wrote:
>
>> + /*
>> +* We mustn't allow any joins to be removed if there are any
>> pending
>> +* foreign key triggers in the queue. This could happen
All,
On Saturday, September 27, 2014, Andrew Dunstan wrote:
>
> On 09/27/2014 10:52 PM, Tom Lane wrote:
>
>> Andrew Dunstan writes:
>>
>>> On 09/27/2014 06:27 PM, Tom Lane wrote:
>>>
So my vote is for a separate function and no optional arguments.
>>> You mean like row_to_json_no_null
On 09/27/2014 10:52 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 09/27/2014 06:27 PM, Tom Lane wrote:
So my vote is for a separate function and no optional arguments.
You mean like row_to_json_no_nulls() and json_agg_no_nulls()?
I thought you were proposing that we should revert the commit
Andrew Dunstan writes:
> On 09/27/2014 06:27 PM, Tom Lane wrote:
>> So my vote is for a separate function and no optional arguments.
> You mean like row_to_json_no_nulls() and json_agg_no_nulls()?
I thought you were proposing that we should revert the committed patch
lock-stock-n-barrel, and ins
On Thu, Sep 25, 2014 at 1:48 PM, Simon Riggs wrote:
> At this stage, poll the Django and Rails communities for acceptance
> and early warning of these features. Listen.
FYI, I have asked for input from the Django developers here:
https://groups.google.com/forum/#!topic/django-developers/hdzkoLYV
On 9/27/14, 4:18 AM, Heikki Linnakangas wrote:
add latency limit to pgbench throttling (--rate)
---
Rukh: Are you planning to review the latest patch version?
Rukh is free to jump onto this ASAP, but if it's still there next week I
already had my eye on picking that up and taking it out for a
On 9/26/14, 3:22 PM, Tom Lane wrote:
We could alternatively try to split up these cases into multiple GUCs,
which I guess is what you're imagining as a "multi-year battle".
No, I was just pointing out that even the cleanest major refactoring
possible here is going to result in broken config fi
On 09/27/2014 06:27 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 09/27/2014 08:00 AM, Stephen Frost wrote:
Yeah, I don't see adding this option to all json generator functions as
making a lot of sense but rather just to the select few things which it
really makes sense for and then having a
On Sat, Sep 27, 2014 at 1:18 AM, Heikki Linnakangas
wrote:
> Sort support for text with strxfrm() poor man's keys
> ---
>
> Peter: Are you waiting for Robert to review this? Robert, could you review
> the latest patch, please? Peter: Could you try to get rid of the extra
> SortSupport object that
Andrew Dunstan writes:
> On 09/27/2014 08:00 AM, Stephen Frost wrote:
>> Yeah, I don't see adding this option to all json generator functions as
>> making a lot of sense but rather just to the select few things which it
>> really makes sense for and then having a function which can be used by
>> u
On Thu, Sep 25, 2014 at 1:48 PM, Simon Riggs wrote:
> I hate the fact
> that you have written no user facing documentation for this feature.
Attached patch adds a commit to the existing patchset. For the
convenience of reviewers, I've uploaded and made publicly accessible a
html build of the docu
Jeff Janes writes:
> under HASH_STATISTICS, the output reporting "this HTAB" upon destruction is
> pretty useless. Which HTAB would this one be? It is not necessarily the
> most recently created one.
> This makes it output the %p to the actual HTAB, so it can be matched up
> with the logging of
under HASH_STATISTICS, the output reporting "this HTAB" upon destruction is
pretty useless. Which HTAB would this one be? It is not necessarily the
most recently created one.
This makes it output the %p to the actual HTAB, so it can be matched up
with the logging of the creation.
I'm not sure wh
Hi,
On 9/25/14, 3:56 PM, I wrote:
On 9/25/14 3:50 PM, Heikki Linnakangas wrote:
Are you planning to post the main patch rebased on top of this soon? As
in the next day or two? Otherwise I'll mark this as "Returned with
feedback" for this commitfest.
Yes. With good luck I'll get you a rebased
HEADS UP.
PGCon 2015 will be in June. That’s a few weeks later than in previous years.
—
Dan Langille
signature.asc
Description: Message signed with OpenPGP using GPGMail
On 2014-09-03 15:09:54 +0300, Heikki Linnakangas wrote:
> On 09/03/2014 12:23 AM, Andres Freund wrote:
> >On 2014-09-02 17:21:03 -0400, Tom Lane wrote:
> >>Heikki Linnakangas writes:
> >>>I was going to suggest using WaitLatchOrSocket instead of sleeping in 1
> >>>second increment, but I see that
On 09/27/2014 08:00 AM, Stephen Frost wrote:
Andrew, all,
* Andrew Dunstan (and...@dunslane.net) wrote:
I should have been paying a bit more attention to the recent work on
adding an ignore_nulls option to row_to_json(). Here are some
belated thought. I apologize to Pavel and Stephen for not h
On 27 September 2014 14:33, Stephen Frost wrote:
>> Yeah, I take that back. If there is a composite key involved then you
>> can run into the same issue- you update one of the columns to a
>> conflicting value and get back the entire key, including columns you
>> shouldn't be allowed to see.
>
>
On 09/26/2014 10:21 AM, Andres Freund wrote:
On 2014-09-26 09:53:09 -0400, Robert Haas wrote:
On Fri, Sep 26, 2014 at 5:05 AM, Andres Freund wrote:
Let me try to summarize the information requirements for each of these
things. For #1, you need to know, after crash recovery, for each
standby,
On 09/26/2014 06:05 PM, Andres Freund wrote:
On 2014-09-26 14:57:12 -0400, Robert Haas wrote:
Sure, it'll possibly not be trivial to move them elsewhere. On the other
hand, the padding bytes have been unused for 8+ years without somebody
laying "claim" on them but "me". I don't think it's a good
On 2014-09-27 10:12:03 -0400, Tom Lane wrote:
> > Escaping from blocked send() by pg_terminate_backend().
>
> > I've had a look, but I'd like to have a second opinion on this.
>
> I concur with your opinion that this is scary as heck. We need multiple
> pairs of eyeballs if we're going to do any
Heikki Linnakangas writes:
> [ unreviewed patches ]
> Grouping Sets
> There has been a lot of discussion, but no decisions. See
> http://www.postgresql.org/message-id/87vbodhtvb@news-spur.riddles.org.uk.
> Would a committer be interested to take responsibility of this? If not,
> this will
Dean Rasheed writes:
> Rather than (or perhaps as well as) marking all these leakproof,
> perhaps we should teach contain_leaky_functions() to automatically
> treat any no-arg function as leakproof, so that we allow user-defined
> functions too. Taking that one step further, perhaps what it should
* Stephen Frost (sfr...@snowman.net) wrote:
> > Looks like there is an issue here with CHECK constraints and NOT NULL
> > constraints, yes. The uniqueness check complains about the key already
> > existing and returns the key, but I don't think that's actually a
> > problem- to get that to happen
Andrew, all,
* Andrew Dunstan (and...@dunslane.net) wrote:
> I should have been paying a bit more attention to the recent work on
> adding an ignore_nulls option to row_to_json(). Here are some
> belated thought. I apologize to Pavel and Stephen for not having
> commented earlier.
No problem at a
> Thanks. Overall, my impression of this patch is that it works very
> well. But damned if I understood *how* it works :-). There's a lot
> of statistics involved, and it's not easy to see why something is
> multiplied by something else. I'm adding comments as I read through
> it.
Thank you for lo
On 09/27/2014 11:31 AM, Andres Freund wrote:
On 2014-09-27 11:18:26 +0300, Heikki Linnakangas wrote:
pg_receivexlog: addition of --create/--drop to create/drop repslots
---
Magnus has promised to review this, but hasn't had the time for weeks. Does
anyone else want to pick this up? I'm OK to wa
On 2014-09-27 11:18:26 +0300, Heikki Linnakangas wrote:
> pg_receivexlog: addition of --create/--drop to create/drop repslots
> ---
>
> Magnus has promised to review this, but hasn't had the time for weeks. Does
> anyone else want to pick this up? I'm OK to wait for Magnus to handle this -
> I exp
On 2014-09-27 10:23:33 +0300, Heikki Linnakangas wrote:
> This patch has gotten a fair amount of review, and has been rewritten once
> during the commitfest. I think it's pretty close to being committable, the
> only remaining question seems to be what to do with system catalogs. I'm
> marking this
We are down to 13 patch in Needs Review state. Many of these are
stragglers that no-one's really even looked at yet.
If we want to finish the commitfest, we'll soon have to decide what to
do to patches that no-one cares enough about to review them.
pg_receivexlog: addition of --create/--dro
On 26 September 2014 15:48, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Wed, Sep 24, 2014 at 5:34 PM, Tom Lane wrote:
>> > ISTM that the most appropriate solution here is to insist that all or none
>> > of the members of an operator class be marked leakproof. (Possi
On 09/05/2014 08:51 AM, furu...@pm.nttdata.co.jp wrote:
Thanks for the review!
I understand the attention message wasn't appropriate.
To report the write location, even If you do not specify a replication
slot.
So the fix only appended messages.
There was a description of the flush location
Part of this patch was already committed, and the overall patch has had
its fair share of review for this commitfest, so I'm marking this as
"Returned with feedback". The benchmark results for the bgreclaimer
showed a fairly small improvement, so it doesn't seem like anyone's
going to commit th
This patch has gotten a fair amount of review, and has been rewritten
once during the commitfest. I think it's pretty close to being
committable, the only remaining question seems to be what to do with
system catalogs. I'm marking this as "Returned with feedback", I take it
that Simon can proce
On 09/24/2014 05:22 AM, Etsuro Fujita wrote:
(2014/09/17 1:58), Robert Haas wrote:
On Tue, Sep 16, 2014 at 11:31 AM, Kevin Grittner wrote:
Etsuro Fujita wrote:
(2014/08/15 6:18), Rukh Meski wrote:
Based on the feedback on my previous patch, I've separated only the
LIMIT part into its own fe
37 matches
Mail list logo
