On 21 March 2014 16:11, Simon Riggs wrote:
>>> + * Be careful to ensure this function is called for Tables and Indexes
>>> only.
>>> + * It is not currently safe to be called for Views because security_barrier
>>> + * is listed as an option and so would be allowed to be set at a level
>>> lower
On 21 March 2014 23:36, Tom Lane wrote:
> Simon Riggs writes:
>> On 21 March 2014 20:58, Noah Misch wrote:
>>> It's not the behavior I would choose for a new product, but I can't see
>>> benefits sufficient to overturn previous decisions to keep it.
>
>> Speechless
>
> The key argument for not "
Simon Riggs writes:
> On 21 March 2014 20:58, Noah Misch wrote:
>> It's not the behavior I would choose for a new product, but I can't see
>> benefits sufficient to overturn previous decisions to keep it.
> Speechless
The key argument for not "fixing" this is that it would break existing
pg_dum
On 21 March 2014 20:58, Noah Misch wrote:
> On Fri, Mar 21, 2014 at 06:53:27PM +, Simon Riggs wrote:
>> On 21 March 2014 17:49, Noah Misch wrote:
>>
>> >> > alter table information_schema.triggers set (security_barrier = true);
>> >>
>> >> I find it hard to justify why we accept such a stat
On Fri, Mar 21, 2014 at 06:53:27PM +, Simon Riggs wrote:
> On 21 March 2014 17:49, Noah Misch wrote:
>
> >> > alter table information_schema.triggers set (security_barrier = true);
> >>
> >> I find it hard to justify why we accept such a statement. Surely its a
> >> bug when the named table
On 21 March 2014 03:45, Noah Misch wrote:
>> + * Note that Hot Standby only knows about AccessExclusiveLocks on the master
>> + * so any changes that might affect SELECTs running on standbys need to use
>> + * AccessExclusiveLocks even if you think a lesser lock would do, unless you
>> + * have a
On 21 March 2014 17:49, Noah Misch wrote:
>> >> + * Be careful to ensure this function is called for Tables and Indexes
>> >> only.
>> >> + * It is not currently safe to be called for Views because
>> >> security_barrier
>> >> + * is listed as an option and so would be allowed to be set at a le
On Fri, Mar 21, 2014 at 04:11:12PM +, Simon Riggs wrote:
> On 21 March 2014 03:45, Noah Misch wrote:
> > On Sat, Mar 08, 2014 at 11:14:30AM +, Simon Riggs wrote:
> Thanks for the review. I'll respond to each point on a later email but
> looks nothing much major, apart from the point raise
On 21 March 2014 03:45, Noah Misch wrote:
> On Sat, Mar 08, 2014 at 11:14:30AM +, Simon Riggs wrote:
>> On 7 March 2014 09:04, Simon Riggs wrote:
>> > The right thing to do here is to not push to the extremes. If we mess
>> > too much with the ruleutil stuff it will just be buggy. A more
>> >
On Sat, Mar 08, 2014 at 11:14:30AM +, Simon Riggs wrote:
> On 7 March 2014 09:04, Simon Riggs wrote:
> > The right thing to do here is to not push to the extremes. If we mess
> > too much with the ruleutil stuff it will just be buggy. A more
> > considered analysis in a later release is requir
On 03/18/2014 11:39 AM, Simon Riggs wrote:
> On 8 March 2014 11:14, Simon Riggs wrote:
>> On 7 March 2014 09:04, Simon Riggs wrote:
>>
>>> The right thing to do here is to not push to the extremes. If we mess
>>> too much with the ruleutil stuff it will just be buggy. A more
>>> considered analys
On 18 March 2014 21:21, Noah Misch wrote:
> On Tue, Mar 18, 2014 at 10:39:03AM +, Simon Riggs wrote:
>> On 8 March 2014 11:14, Simon Riggs wrote:
>> > Implemented in attached patch, v22
>
>> > I commend this patch to you for final review; I would like to commit
>> > this in a few days.
>>
>>
On Tue, Mar 18, 2014 at 10:39:03AM +, Simon Riggs wrote:
> On 8 March 2014 11:14, Simon Riggs wrote:
> > Implemented in attached patch, v22
> > I commend this patch to you for final review; I would like to commit
> > this in a few days.
>
> I'm planning to commit this today at 1500UTC barrin
On 8 March 2014 11:14, Simon Riggs wrote:
> On 7 March 2014 09:04, Simon Riggs wrote:
>
>> The right thing to do here is to not push to the extremes. If we mess
>> too much with the ruleutil stuff it will just be buggy. A more
>> considered analysis in a later release is required for a full and
>
On 6 March 2014 22:43, Noah Misch wrote:
> On Tue, Mar 04, 2014 at 06:50:17PM +0100, Andres Freund wrote:
>> On 2014-03-04 11:40:10 -0500, Tom Lane wrote:
>> > Robert Haas writes: > I think this is all too
>> > late for 9.4, though.
>> >
>> > I agree with the feeling that a meaningful fix for pg_
On 6 March 2014 22:43, Noah Misch wrote:
> Good analysis. The hazards arise when pg_dump uses one of the ruleutils.c
> deparse worker functions.
Ah, good. We're thinking along the same lines. I was already working
on this analysis also. I'll complete mine and then compare notes.
> One thing no
On Tue, Mar 04, 2014 at 06:50:17PM +0100, Andres Freund wrote:
> On 2014-03-04 11:40:10 -0500, Tom Lane wrote:
> > Robert Haas writes: > I think this is all too
> > late for 9.4, though.
> >
> > I agree with the feeling that a meaningful fix for pg_dump isn't going
> > to get done for 9.4. So th
Greg Stark writes:
> On Tue, Mar 4, 2014 at 8:08 PM, Tom Lane wrote:
>> CREATE INDEX CONCURRENTLY, otoh, already did break pg_dump,
>> and we had to hack things to fix it; see commit
>> 683abc73dff549e94555d4020dae8d02f32ed78b.
> Well pg_dump was only broken in that there was a new catalog state
On Tue, Mar 4, 2014 at 8:08 PM, Tom Lane wrote:
> CREATE INDEX CONCURRENTLY, otoh, already did break pg_dump,
> and we had to hack things to fix it; see commit
> 683abc73dff549e94555d4020dae8d02f32ed78b.
Well pg_dump was only broken in that there was a new catalog state to
deal with. But the comm
Andres Freund writes:
> On 2014-03-04 11:40:10 -0500, Tom Lane wrote:
>> I don't care for (2). I'd like to have lock strength reduction as
>> much as anybody, but it can't come at the price of reduction of
>> reliability.
> I am sorry, but I think this is vastly overstating the scope of the
> pg
On 2014-03-04 11:40:10 -0500, Tom Lane wrote:
> Robert Haas writes: > I think this is all too
> late for 9.4, though.
>
> I agree with the feeling that a meaningful fix for pg_dump isn't going
> to get done for 9.4. So that leaves us with the alternatives of (1)
> put off the lock-strength-reduc
21 matches
Mail list logo
