Thread: cmin increments by 2 except in 7.4?

I've noticed that in PostgreSQL 7.4, successive commands in a
transaction get cmin values that increment by 1, but in other
versions cmin increments by 2.  Example:

CREATE TABLE foo (x integer);
BEGIN;
INSERT INTO foo VALUES (1);
INSERT INTO foo VALUES (2);
INSERT INTO foo VALUES (3);
COMMIT;

Results in 8.0.1 (same in 8.1devel, 7.3.9, 7.2.7):

SELECT xmin, cmin, x FROM foo;
 xmin | cmin | x
------+------+---
 7112 |    1 | 1
 7112 |    3 | 2
 7112 |    5 | 3
(3 rows)

Results in 7.4.7:

SELECT xmin, cmin, x FROM foo;
 xmin | cmin | x
------+------+---
  856 |    1 | 1
  856 |    2 | 2
  856 |    3 | 3
(3 rows)

What is 7.4 doing differently than the other versions?

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

Michael Fuhr <mike@fuhr.org> writes:
> I've noticed that in PostgreSQL 7.4, successive commands in a
> transaction get cmin values that increment by 1, but in other
> versions cmin increments by 2.  Example:

Not sure about pre-7.4, but 8.0 is doing this because of a faulty
translation of list-munging stuff.  PortalRunMulti contains

        /*
         * Increment command counter between queries, but not after the
         * last one.
         */
        if (planlist_item != NULL)
            CommandCounterIncrement();

but planlist_item will *never* be NULL here.  Should be testing
lnext(planlist_item), I think.  Neil?

            regards, tom lane

On Tue, 2005-02-01 at 01:53 -0500, Tom Lane wrote:
>         /*
>          * Increment command counter between queries, but not after the
>          * last one.
>          */
>         if (planlist_item != NULL)
>             CommandCounterIncrement();
>
> but planlist_item will *never* be NULL here.  Should be testing
> lnext(planlist_item), I think.  Neil?

Indeed :( One-liner attached, and applied to HEAD and REL8_0_STABLE.

-Neil

Neil Conway <neilc@samurai.com> writes:
> On Tue, 2005-02-01 at 01:53 -0500, Tom Lane wrote:
>> but planlist_item will *never* be NULL here.  Should be testing
>> lnext(planlist_item), I think.  Neil?

> Indeed :( One-liner attached, and applied to HEAD and REL8_0_STABLE.

Do you think it's worth groveling through the other uses of forboth()
for the same type of error?

            regards, tom lane

On Tue, 2005-02-01 at 18:37 -0500, Tom Lane wrote:
> Do you think it's worth groveling through the other uses of forboth()
> for the same type of error?

I just checked the other uses of forboth(), and didn't notice any
errors.

-Neil