On Mon, Nov 11, 2013 at 4:34 PM, Andres Freund wrote:
>>I'm pretty sure that the current coding, which blows away the whole
>>relation, is used in other places, and I really don't see why it
>>should be fundamentally flawed, or why we should change it to clear
>>the cache entries out one by one in
Robert Haas schrieb:
>On Mon, Nov 11, 2013 at 4:00 PM, Robert Haas
>wrote:
>> On Thu, Nov 7, 2013 at 12:18 PM, Andres Freund
> wrote:
>>> On 2013-11-07 10:10:34 -0500, Tom Lane wrote:
Andres Freund writes:
> On 2013-11-07 06:49:58 -0800, Kevin Grittner wrote:
>> It's up to the c
On Mon, Nov 11, 2013 at 4:00 PM, Robert Haas wrote:
> On Thu, Nov 7, 2013 at 12:18 PM, Andres Freund wrote:
>> On 2013-11-07 10:10:34 -0500, Tom Lane wrote:
>>> Andres Freund writes:
>>> > On 2013-11-07 06:49:58 -0800, Kevin Grittner wrote:
>>> >> It's up to the committer whether to indent
>>> >
On Thu, Nov 7, 2013 at 12:18 PM, Andres Freund wrote:
> On 2013-11-07 10:10:34 -0500, Tom Lane wrote:
>> Andres Freund writes:
>> > On 2013-11-07 06:49:58 -0800, Kevin Grittner wrote:
>> >> It's up to the committer whether to indent
>> >> after review and make both substantive and whitespace chan
On 2013-11-07 10:10:34 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-11-07 06:49:58 -0800, Kevin Grittner wrote:
> >> It's up to the committer whether to indent
> >> after review and make both substantive and whitespace changes
> >> together, but I have definitely seen those done sepa
On 11/07/2013 09:59 AM, Andres Freund wrote:
On 2013-11-07 06:49:58 -0800, Kevin Grittner wrote:
It's up to the committer whether to indent
after review and make both substantive and whitespace changes
together, but I have definitely seen those done separately, or even
left for the next global
Andres Freund writes:
> On 2013-11-07 06:49:58 -0800, Kevin Grittner wrote:
>> It's up to the committer whether to indent
>> after review and make both substantive and whitespace changes
>> together, but I have definitely seen those done separately, or even
>> left for the next global pgindent run
On 2013-11-07 06:49:58 -0800, Kevin Grittner wrote:
> It's up to the committer whether to indent
> after review and make both substantive and whitespace changes
> together, but I have definitely seen those done separately, or even
> left for the next global pgindent run to fix.
Hm. I don't remembe
On 2013-11-07 09:55:55 -0500, Tom Lane wrote:
> Kevin Grittner writes:
> > I think it is pretty much SOP for committers to prefer a patch that
> > adds a new pair of braces around 50 lines of code and only changes
> > non-whitespace of a few lines within that block to leave the block
> > at its ol
Kevin Grittner writes:
> I think it is pretty much SOP for committers to prefer a patch that
> adds a new pair of braces around 50 lines of code and only changes
> non-whitespace of a few lines within that block to leave the block
> at its old indentation.
Yes. It's much easier to review a patch
Andres Freund wrote:
> On 2013-11-07 06:23:13 -0800, Kevin Grittner wrote:
>> I think this is one of those cases where the large
>> chunk of code inside the new "else" block should not be indented
>> with the initial patch -- a pgindent-based whitespace-only patch
>> should follow so that the s
On 2013-11-07 06:23:13 -0800, Kevin Grittner wrote:
> Andres Freund wrote:
>
> > Ok, I've attached a fix for this, which unfortunately is not all
> > that small.
> > Could either of you commit it?
>
> Unfortunately, I don't feel I have a good enough grasp of the
> caching/invalidation mechanism
Andres Freund wrote:
> Ok, I've attached a fix for this, which unfortunately is not all
> that small.
> Could either of you commit it?
Unfortunately, I don't feel I have a good enough grasp of the
caching/invalidation mechanism to be a committer for this
particular patch, but I think you could m
On 2013-11-07 00:30:55 +0100, Andres Freund wrote:
> On 2013-11-07 00:17:34 +0100, Andres Freund wrote:
> > On 2013-11-06 17:00:40 -0300, Alvaro Herrera wrote:
> > > Kevin Grittner wrote:
> > >
> > > > That makes for a pretty simple test for git bisect, even if
> > > > everything including initdb
On 2013-11-07 00:17:34 +0100, Andres Freund wrote:
> On 2013-11-06 17:00:40 -0300, Alvaro Herrera wrote:
> > Kevin Grittner wrote:
> >
> > > That makes for a pretty simple test for git bisect, even if
> > > everything including initdb is painfully slow with
> > > CLOBBER_CACHE_ALWAYS.
> >
> > Mos
On 2013-11-06 17:00:40 -0300, Alvaro Herrera wrote:
> Kevin Grittner wrote:
>
> > That makes for a pretty simple test for git bisect, even if
> > everything including initdb is painfully slow with
> > CLOBBER_CACHE_ALWAYS.
>
> Most likely culprit is f01d1ae3a104019d6d68aeff85c4816a275130b3
Well,
Kevin Grittner wrote:
> That makes for a pretty simple test for git bisect, even if
> everything including initdb is painfully slow with
> CLOBBER_CACHE_ALWAYS.
Most likely culprit is f01d1ae3a104019d6d68aeff85c4816a275130b3
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQ
Kevin Grittner wrote:
> In checking things out with CLOBBER_CACHE_ALWAYS, I was getting
> this problem, which seems to be unrelated to my changes:
On a CLOBBER_CACHE_ALWAYS build I did a fresh initdb, started the
cluster, and immediately tested this query on both the postgres and
template1 datab
Hi,
Kevin Grittner schrieb:
>In checking things out with CLOBBER_CACHE_ALWAYS, I was getting
>this problem, which seems to be unrelated to my changes:
>... with this result:
>
> mapped_oid | oid
>+--
> 2139062143 | 2619
>(1 row)
>
>2619 is the oid for pg_statistic, and the mapp
19 matches
Mail list logo
