Обсуждение: Re: [pgsql-patches] [GENERAL] Corrupt database? 8.1/FreeBSD6.0

Alvaro Herrera wrote:
> Tom Lane wrote:
> > Alvaro Herrera <alvherre@commandprompt.com> writes:
>
> > > Maybe we could forcibly activate the freeze mode on a template database?
> >
> > Might not be a bad idea.  And even more to the point, forcibly disable
> > analyze.
>
> Patch implementing this (albeit untested!) attached.  I'll try to
> reproduce the problem without the patch, and then test with the patch
> applied.

Ok, it does what it's intended to do.  But in testing it I also
confirmed that a database-wide vacuum creates a pgstat entry for it and
for all tables in it.  Is this something we want to prevent?

I'll apply this patch later today to the 8.1 branch unless somebody
objects.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Ok, it does what it's intended to do.  But in testing it I also
> confirmed that a database-wide vacuum creates a pgstat entry for it and
> for all tables in it.  Is this something we want to prevent?

That's odd, because I didn't see any such thing when I tested in CVS tip
the other day.  Or did you have stats_block_level turned on?

            regards, tom lane

Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > Ok, it does what it's intended to do.  But in testing it I also
> > confirmed that a database-wide vacuum creates a pgstat entry for it and
> > for all tables in it.  Is this something we want to prevent?
>
> That's odd, because I didn't see any such thing when I tested in CVS tip
> the other day.  Or did you have stats_block_level turned on?

Yes, I turned it on for this test.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Tom Lane wrote:
>> Alvaro Herrera <alvherre@commandprompt.com> writes:
>>> Ok, it does what it's intended to do.  But in testing it I also
>>> confirmed that a database-wide vacuum creates a pgstat entry for it and
>>> for all tables in it.  Is this something we want to prevent?
>>
>> That's odd, because I didn't see any such thing when I tested in CVS tip
>> the other day.  Or did you have stats_block_level turned on?

> Yes, I turned it on for this test.

Well, the vacuums certainly accounted for I/O, so I suppose this is
reasonable behavior.

            regards, tom lane