Thread: pgsql: Clamp last_anl_tuples to n_live_tuples, in case we vacuum a table

Log Message:
-----------
Clamp last_anl_tuples to n_live_tuples, in case we vacuum a table without
analyzing, so that future analyze threshold calculations don't get confused.
Also, make sure we correctly track the decrease of live tuples cause by
deletes.

Per report from Dylan Hansen, patches by Tom Lane and me.

Tags:
----
REL8_1_STABLE

Modified Files:
--------------
    pgsql/src/backend/postmaster:
        pgstat.c (r1.111.2.3 -> r1.111.2.4)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/postmaster/pgstat.c.diff?r1=1.111.2.3&r2=1.111.2.4)

Alvaro Herrera wrote:

>Log Message:
>-----------
>Clamp last_anl_tuples to n_live_tuples, in case we vacuum a table without
>analyzing, so that future analyze threshold calculations don't get confused.
>Also, make sure we correctly track the decrease of live tuples cause by
>deletes.
>
>Per report from Dylan Hansen, patches by Tom Lane and me.
>
>Tags:
>----
>REL8_1_STABLE
>
>Modified Files:
>--------------
>    pgsql/src/backend/postmaster:
>        pgstat.c (r1.111.2.3 -> r1.111.2.4)
>
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/postmaster/pgstat.c.diff?r1=1.111.2.3&r2=1.111.2.4)
>
>
>

This appears to have broken 8.1 on every platform. See buildfarm.

cheers

andrew

Andrew Dunstan wrote:
> Alvaro Herrera wrote:
>
> >Log Message:
> >-----------
> >Clamp last_anl_tuples to n_live_tuples, in case we vacuum a table without
> >analyzing, so that future analyze threshold calculations don't get
> >confused.
> >Also, make sure we correctly track the decrease of live tuples cause by
> >deletes.

Ugh, sorry.  Consequence of having to copy patches from a CVSup tree and
a "commit tree" :-(  Eventually I was bound to make such a mistake.

Tom beat me to committing the fix though.

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

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Ugh, sorry.  Consequence of having to copy patches from a CVSup tree and
> a "commit tree" :-(  Eventually I was bound to make such a mistake.

Hm, don't you have things set up so that you commit directly from a
tested source tree?  I don't think I've ever committed a patch without
having at least made sure it compiled.  I also suggest using diff+patch
to transfer patches across branches ... this one looks like it was
transcribed into 8.1 manually, and that's what got ya.

            regards, tom lane

Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > Ugh, sorry.  Consequence of having to copy patches from a CVSup tree and
> > a "commit tree" :-(  Eventually I was bound to make such a mistake.
>
> Hm, don't you have things set up so that you commit directly from a
> tested source tree?

No.  I have two trees for each release; one comes from CVSup and is
where I do the development and test stuff.  The other one comes from the
SSH backed CVS at postgresql.org.  What I do is develop the patch in the
CVSup tree, test it there, and then copy it to the other repo by
diff+patch.  What happened here was that I produced the fat-fingered
patch in the CVSup branch, and copied it to the other tree _before_
testing; then I compiled, found that mistake and corrected it but forgot
to copy the correction to the other tree :-(

I don't use the CVS trees directly because it's very slow to get diffs
that way (latency is way too high), and also out of fear of committing
unwanted stuff.

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