On Fri, Nov 18, 2011 at 3:18 PM, Tom Lane wrote:
>> So the correct number of WAL records is emitted and I see no bug there.
>
> What Thom's complaining about is that the buffer may be marked dirty
> unnecessarily, ie when there has been no actual data change.
Based upon both your feedback, I mad
On Fri, Nov 18, 2011 at 3:18 PM, Tom Lane wrote:
> What Thom's complaining about is that the buffer may be marked dirty
> unnecessarily, ie when there has been no actual data change.
OK, I'll patch it.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
Simon Riggs writes:
> On Fri, Nov 18, 2011 at 2:47 PM, Tom Lane wrote:
>> Well, it's expected given the current coding in the btree vacuum logic.
>> It's not clear to me why it was written like that, though.
> The code works as designed.
> _bt_delitems_vacuum() is only ever called with nitems =
On Fri, Nov 18, 2011 at 2:47 PM, Tom Lane wrote:
> Thom Brown writes:
>>> On 11 November 2011 23:28, Tom Lane wrote:
I observe that _bt_delitems_vacuum() unconditionally dirties the page
and writes a WAL record, whether it has anything to do or not; and that
if XLogStandbyInfoActi
On Fri, Nov 18, 2011 at 2:47 PM, Tom Lane wrote:
> Thom Brown writes:
>>> On 11 November 2011 23:28, Tom Lane wrote:
I observe that _bt_delitems_vacuum() unconditionally dirties the page
and writes a WAL record, whether it has anything to do or not; and that
if XLogStandbyInfoActi
Thom Brown writes:
>> On 11 November 2011 23:28, Tom Lane wrote:
>>> I observe that _bt_delitems_vacuum() unconditionally dirties the page
>>> and writes a WAL record, whether it has anything to do or not; and that
>>> if XLogStandbyInfoActive() then btvacuumscan will indeed call it despite
>>> t
On 12 November 2011 00:08, Thom Brown wrote:
> On 11 November 2011 23:28, Tom Lane wrote:
>> Thom Brown writes:
>>> On 11 November 2011 00:55, Tom Lane wrote:
Thom Brown writes:
> I just noticed that the VACUUM process touches a lot of relations
> (affects mtime) but for one file
On 11 November 2011 23:28, Tom Lane wrote:
> Thom Brown writes:
>> On 11 November 2011 00:55, Tom Lane wrote:
>>> Thom Brown writes:
I just noticed that the VACUUM process touches a lot of relations
(affects mtime) but for one file I looked at, it didn't change. This
doesn't alw
Thom Brown writes:
> On 11 November 2011 00:55, Tom Lane wrote:
>> Thom Brown writes:
>>> I just noticed that the VACUUM process touches a lot of relations
>>> (affects mtime) but for one file I looked at, it didn't change. This
>>> doesn't always happen, and many relations aren't touched at al
On 11 November 2011 00:55, Tom Lane wrote:
> Thom Brown writes:
>> On 14 October 2011 12:12, Thom Brown wrote:
>>> I just noticed that the VACUUM process touches a lot of relations
>>> (affects mtime) but for one file I looked at, it didn't change. This
>>> doesn't always happen, and many relat
Thom Brown writes:
> On 14 October 2011 12:12, Thom Brown wrote:
>> I just noticed that the VACUUM process touches a lot of relations
>> (affects mtime) but for one file I looked at, it didn't change. This
>> doesn't always happen, and many relations aren't touched at all.
No immmediate ideas a
On 14 October 2011 12:12, Thom Brown wrote:
> Hi,
>
> I just noticed that the VACUUM process touches a lot of relations
> (affects mtime) but for one file I looked at, it didn't change. This
> doesn't always happen, and many relations aren't touched at all.
>
> I had the following relation:
>
> -
Hi,
I just noticed that the VACUUM process touches a lot of relations
(affects mtime) but for one file I looked at, it didn't change. This
doesn't always happen, and many relations aren't touched at all.
I had the following relation:
-rw--- 1 thom staff 40960 13 Oct 16:06 11946
Ran
13 matches
Mail list logo
