On Mon, Dec 23, 2013 at 6:53 AM, Andres Freund wrote:
> On 2013-12-22 20:45:02 -0500, Robert Haas wrote:
>> I suspect we ought to extend this to rewriting variants of ALTER TABLE
>> as well, but a little thought is needed there. ATRewriteTables()
>> appears to just call heap_insert() for each upd
On 2013-12-22 20:45:02 -0500, Robert Haas wrote:
> I suspect we ought to extend this to rewriting variants of ALTER TABLE
> as well, but a little thought is needed there. ATRewriteTables()
> appears to just call heap_insert() for each updated row, which if I'm
> not mistaken is an MVCC violation -
On Sun, Dec 8, 2013 at 10:51 AM, Peter Eisentraut wrote:
> On Tue, 2013-11-19 at 18:24 +0100, Andres Freund wrote:
>> On 2013-11-19 12:23:30 -0500, Robert Haas wrote:
>> > On Mon, Nov 18, 2013 at 11:45 AM, Andres Freund
>> > wrote:
>> > >> Yes, we probably should make a decision, unless Robert's
On Tue, 2013-11-19 at 18:24 +0100, Andres Freund wrote:
> On 2013-11-19 12:23:30 -0500, Robert Haas wrote:
> > On Mon, Nov 18, 2013 at 11:45 AM, Andres Freund
> > wrote:
> > >> Yes, we probably should make a decision, unless Robert's idea can be
> > >> implemented. We have to balance the ease of
On Tue, Nov 19, 2013 at 11:35 PM, David Rowley wrote:
> I think that the patch should include some sort of notes in the documents
> to say that cluster performs freezing of tuples. I've attached a patch
> which adds something there, but I'm not 100% sure it is the right thing.
> Perhaps it should
On 2013-11-19 12:23:30 -0500, Robert Haas wrote:
> On Mon, Nov 18, 2013 at 11:45 AM, Andres Freund
> wrote:
> >> Yes, we probably should make a decision, unless Robert's idea can be
> >> implemented. We have to balance the ease of debugging MVCC failures
> >> with the interface we give to the us
On Mon, Nov 18, 2013 at 11:45 AM, Andres Freund wrote:
>> Yes, we probably should make a decision, unless Robert's idea can be
>> implemented. We have to balance the ease of debugging MVCC failures
>> with the interface we give to the user community.
>
> Imo that patch really doesn't need too muc
On Sat, Oct 26, 2013 at 11:19 AM, Thomas Munro wrote:
> On 25 October 2013 01:17, Josh Berkus wrote:
>
>> On 10/24/2013 04:55 PM, Robert Haas wrote:
>> > I wonder if we should go so far as to make this the default behavior,
>> > instead of just making it an option.
>>
>> +1 from me. Can you thi
Josh Berkus wrote:
> On 11/18/2013 08:39 AM, Bruce Momjian wrote:
>> If we do add FREEZE, all we would be doing is delaying the time
>> when all CLUSTER operations will use FREEZE, and hence debugging
>> will be just as difficult. My point is that will full
>> knowledge, everyone would use FREEZE
On 11/18/2013 08:39 AM, Bruce Momjian wrote:
> If we do add FREEZE, all we would be doing is delaying the time when all
> CLUSTER operations will use FREEZE, and hence debugging will be just as
> difficult. My point is that will full knowledge, everyone would use
> FREEZE unless they expect MVCC b
On 2013-11-18 11:39:44 -0500, Bruce Momjian wrote:
> On Mon, Nov 18, 2013 at 09:22:58PM +1300, David Rowley wrote:
> > So now I'm wondering what the next move should be for this patch?
> >
> > a. Are we waiting on Robert's patch to be committed before we can apply
> > Thomas's
> > cluster with fr
On Mon, Nov 18, 2013 at 09:22:58PM +1300, David Rowley wrote:
> So now I'm wondering what the next move should be for this patch?
>
> a. Are we waiting on Robert's patch to be committed before we can apply
> Thomas's
> cluster with freeze as default?
> b. Are we waiting on me reviewing one or bot
On Wed, Oct 30, 2013 at 3:32 AM, Andres Freund wrote:
> On 2013-10-25 09:26:29 -0400, Robert Haas wrote:
> > > In any case, it's very far from obvious to me that CLUSTER ought
> > > to throw away information by default, which is what you're proposing.
> >
> > I find it odd to referring to this as
On Tue, Oct 29, 2013 at 11:37 AM, Andres Freund wrote:
> On 2013-10-29 11:29:24 -0400, Robert Haas wrote:
>> On Tue, Oct 29, 2013 at 10:32 AM, Andres Freund
>> wrote:
>> > On 2013-10-25 09:26:29 -0400, Robert Haas wrote:
>> >> > In any case, it's very far from obvious to me that CLUSTER ought
>>
On 2013-10-29 11:29:24 -0400, Robert Haas wrote:
> On Tue, Oct 29, 2013 at 10:32 AM, Andres Freund
> wrote:
> > On 2013-10-25 09:26:29 -0400, Robert Haas wrote:
> >> > In any case, it's very far from obvious to me that CLUSTER ought
> >> > to throw away information by default, which is what you'r
On Tue, Oct 29, 2013 at 10:32 AM, Andres Freund wrote:
> On 2013-10-25 09:26:29 -0400, Robert Haas wrote:
>> > In any case, it's very far from obvious to me that CLUSTER ought
>> > to throw away information by default, which is what you're proposing.
>>
>> I find it odd to referring to this as thr
On 2013-10-25 09:26:29 -0400, Robert Haas wrote:
> > In any case, it's very far from obvious to me that CLUSTER ought
> > to throw away information by default, which is what you're proposing.
>
> I find it odd to referring to this as throwing away information. I
> know that you have a general con
On 10/26/2013 01:20 AM, Josh Berkus wrote:
> On 10/24/2013 07:19 PM, Tom Lane wrote:
>> In any case, it's very far from obvious to me that CLUSTER ought
>> to throw away information by default, which is what you're proposing.
>
> The problem here is that you're thinking of the 1/10 of 1% of our us
On 25 October 2013 01:17, Josh Berkus wrote:
> On 10/24/2013 04:55 PM, Robert Haas wrote:
> > I wonder if we should go so far as to make this the default behavior,
> > instead of just making it an option.
>
> +1 from me. Can you think of a reason you *wouldn't* want to freeze?
Ok, I attach an
On 10/24/2013 07:19 PM, Tom Lane wrote:
> In any case, it's very far from obvious to me that CLUSTER ought
> to throw away information by default, which is what you're proposing.
The problem here is that you're thinking of the 1/10 of 1% of our users
who have a serious PostgreSQL failure and post
On Thu, Oct 24, 2013 at 10:19 PM, Tom Lane wrote:
> Robert Haas writes:
>> I wonder if we should go so far as to make this the default behavior,
>> instead of just making it an option.
>
> In that case you'd have to invent a NOFREEZE keyword, no? Ick.
Only if we think anyone would ever NOT want
On 2013-10-25 09:13:20 -0400, Robert Haas wrote:
> On Fri, Oct 25, 2013 at 2:12 AM, Andres Freund wrote:
> > On 2013-10-24 17:17:22 -0700, Josh Berkus wrote:
> >> On 10/24/2013 04:55 PM, Robert Haas wrote:
> >> > On Thu, Oct 24, 2013 at 1:09 PM, Josh Berkus wrote:
> >> >> On 10/23/2013 09:58 PM,
On Fri, Oct 25, 2013 at 2:12 AM, Andres Freund wrote:
> On 2013-10-24 17:17:22 -0700, Josh Berkus wrote:
>> On 10/24/2013 04:55 PM, Robert Haas wrote:
>> > On Thu, Oct 24, 2013 at 1:09 PM, Josh Berkus wrote:
>> >> On 10/23/2013 09:58 PM, Amit Kapila wrote:
>> >>> I wonder why anyone would like to
On 2013-10-24 17:17:22 -0700, Josh Berkus wrote:
> On 10/24/2013 04:55 PM, Robert Haas wrote:
> > On Thu, Oct 24, 2013 at 1:09 PM, Josh Berkus wrote:
> >> On 10/23/2013 09:58 PM, Amit Kapila wrote:
> >>> I wonder why anyone would like to freeze during CLUSTER command when
> >>> they already have s
On Fri, Oct 25, 2013 at 4:29 AM, Thomas Munro wrote:
> On 24 October 2013 05:58, Amit Kapila wrote:
>>
>> On Thu, Oct 24, 2013 at 4:58 AM, Thomas Munro wrote:
>> > Hi
>> > I noticed that CLUSTER doesn't have a FREEZE option. Here is a patch to
>> > add
>> > that, for consistency with VACUUM. I
On Thu, Oct 24, 2013 at 10:39 PM, Josh Berkus wrote:
> On 10/23/2013 09:58 PM, Amit Kapila wrote:
>> I wonder why anyone would like to freeze during CLUSTER command when
>> they already have separate way (VACUUM FREEZE) to achieve it, do you
>> know or can think of any case where user wants to do
Robert Haas writes:
> I wonder if we should go so far as to make this the default behavior,
> instead of just making it an option.
In that case you'd have to invent a NOFREEZE keyword, no? Ick.
In any case, it's very far from obvious to me that CLUSTER ought
to throw away information by default
On 10/24/2013 04:55 PM, Robert Haas wrote:
> On Thu, Oct 24, 2013 at 1:09 PM, Josh Berkus wrote:
>> On 10/23/2013 09:58 PM, Amit Kapila wrote:
>>> I wonder why anyone would like to freeze during CLUSTER command when
>>> they already have separate way (VACUUM FREEZE) to achieve it, do you
>>> know
On Thu, Oct 24, 2013 at 1:09 PM, Josh Berkus wrote:
> On 10/23/2013 09:58 PM, Amit Kapila wrote:
>> I wonder why anyone would like to freeze during CLUSTER command when
>> they already have separate way (VACUUM FREEZE) to achieve it, do you
>> know or can think of any case where user wants to do i
On 24 October 2013 05:58, Amit Kapila wrote:
> On Thu, Oct 24, 2013 at 4:58 AM, Thomas Munro wrote:
> > Hi
> > I noticed that CLUSTER doesn't have a FREEZE option. Here is a patch to
> add
> > that, for consistency with VACUUM. Is it useful?
>
> I wonder why anyone would like to freeze during
On 10/23/2013 09:58 PM, Amit Kapila wrote:
> I wonder why anyone would like to freeze during CLUSTER command when
> they already have separate way (VACUUM FREEZE) to achieve it, do you
> know or can think of any case where user wants to do it along with
> Cluster command?
"If I'm rewriting the tab
On Thu, Oct 24, 2013 at 10:28:43AM +0530, Amit Kapila wrote:
> On Thu, Oct 24, 2013 at 4:58 AM, Thomas Munro wrote:
> > Hi
> > I noticed that CLUSTER doesn't have a FREEZE option. Here is a patch to add
> > that, for consistency with VACUUM. Is it useful?
>
> I wonder why anyone would like to f
Hi,
On 2013-10-24 00:28:44 +0100, Thomas Munro wrote:
> I noticed that CLUSTER doesn't have a FREEZE option. Here is a patch to
> add that, for consistency with VACUUM. Is it useful?
I think you'd need to prevent that form from working on system catalogs
- xmin has a meaning there sometimes (e.
On 24 October 2013 05:58, Amit Kapila wrote:
> On Thu, Oct 24, 2013 at 4:58 AM, Thomas Munro wrote:
>> Hi
>> I noticed that CLUSTER doesn't have a FREEZE option. Here is a patch to add
>> that, for consistency with VACUUM. Is it useful?
>
> I wonder why anyone would like to freeze during CLUSTE
On Thu, Oct 24, 2013 at 4:58 AM, Thomas Munro wrote:
> Hi
> I noticed that CLUSTER doesn't have a FREEZE option. Here is a patch to add
> that, for consistency with VACUUM. Is it useful?
I wonder why anyone would like to freeze during CLUSTER command when
they already have separate way (VACUUM
35 matches
Mail list logo
