On 21 March 2014 23:36, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On 21 March 2014 20:58, Noah Misch n...@leadboat.com 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
On 21 March 2014 16:11, Simon Riggs si...@2ndquadrant.com 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
On 21 March 2014 03:45, Noah Misch n...@leadboat.com wrote:
On Sat, Mar 08, 2014 at 11:14:30AM +, Simon Riggs wrote:
On 7 March 2014 09:04, Simon Riggs si...@2ndquadrant.com wrote:
The right thing to do here is to not push to the extremes. If we mess
too much with the ruleutil stuff it
On Fri, Mar 21, 2014 at 04:11:12PM +, Simon Riggs wrote:
On 21 March 2014 03:45, Noah Misch n...@leadboat.com 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
On 21 March 2014 17:49, Noah Misch n...@leadboat.com 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
On 21 March 2014 03:45, Noah Misch n...@leadboat.com 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
On Fri, Mar 21, 2014 at 06:53:27PM +, Simon Riggs wrote:
On 21 March 2014 17:49, Noah Misch n...@leadboat.com 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
On 21 March 2014 20:58, Noah Misch n...@leadboat.com wrote:
On Fri, Mar 21, 2014 at 06:53:27PM +, Simon Riggs wrote:
On 21 March 2014 17:49, Noah Misch n...@leadboat.com wrote:
alter table information_schema.triggers set (security_barrier = true);
I find it hard to justify why we
Simon Riggs si...@2ndquadrant.com writes:
On 21 March 2014 20:58, Noah Misch n...@leadboat.com 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
On 03/18/2014 11:39 AM, Simon Riggs wrote:
On 8 March 2014 11:14, Simon Riggs si...@2ndquadrant.com wrote:
On 7 March 2014 09:04, Simon Riggs si...@2ndquadrant.com 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
On Sat, Mar 08, 2014 at 11:14:30AM +, Simon Riggs wrote:
On 7 March 2014 09:04, Simon Riggs si...@2ndquadrant.com 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
On 18 March 2014 21:21, Noah Misch n...@leadboat.com wrote:
On Tue, Mar 18, 2014 at 10:39:03AM +, Simon Riggs wrote:
On 8 March 2014 11:14, Simon Riggs si...@2ndquadrant.com wrote:
Implemented in attached patch, v22
I commend this patch to you for final review; I would like to commit
On 8 March 2014 11:14, Simon Riggs si...@2ndquadrant.com wrote:
On 7 March 2014 09:04, Simon Riggs si...@2ndquadrant.com 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
On Tue, Mar 18, 2014 at 10:39:03AM +, Simon Riggs wrote:
On 8 March 2014 11:14, Simon Riggs si...@2ndquadrant.com 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
On 6 March 2014 22:43, Noah Misch n...@leadboat.com 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 robertmh...@gmail.com writes: I think this is all too
late for 9.4, though.
I agree with the feeling that a
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 robertmh...@gmail.com 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
On 6 March 2014 22:43, Noah Misch n...@leadboat.com 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.
On 2014-03-04 11:40:10 -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
Andres Freund and...@2ndquadrant.com 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
On Tue, Mar 4, 2014 at 8:08 PM, Tom Lane t...@sss.pgh.pa.us 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
Greg Stark st...@mit.edu writes:
On Tue, Mar 4, 2014 at 8:08 PM, Tom Lane t...@sss.pgh.pa.us 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
21 matches
Mail list logo
