On Sun, Jul 4, 2010 at 9:48 AM, Tom Lane wrote:
> Sure. What you'd need is for HeapTupleSatisfiesVacuum to observe that
> (a) the tuple's xmin and xmax are equal,
> (b) they're equal to my own transaction's XID,
> (c) none of the live snapshots in my backend can see cmin but not cmax,
> (d) cmax
On Monday 05 July 2010 12:11:38 Pierre C wrote:
> > The problem can generally be written as "tuples seeing multiple
> > updates in the same transaction"?
> >
> > I think that every time PostgreSQL is used with an ORM, there is
> > a certain amount of multiple updates taking place. I have actually
On 2010-07-05 12:11, Pierre C wrote:
> The problem can generally be written as "tuples seeing multiple
> updates in the same transaction"?
>
> I think that every time PostgreSQL is used with an ORM, there is a
> certain amount of multiple updates taking place. I have actually
> been reworking cl
The problem can generally be written as "tuples seeing multiple
updates in the same transaction"?
I think that every time PostgreSQL is used with an ORM, there is
a certain amount of multiple updates taking place. I have actually
been reworking clientside to get around multiple updates, since t
On 2010-07-04 06:11, Tom Lane wrote:
Robert Haas writes:
CREATE OR REPLACE FUNCTION update_tab() RETURNS void AS $$
BEGIN
INSERT INTO tab VALUES (0);
FOR i IN 1..10 LOOP
UPDATE tab SET x = x + 1;
END LOOP;
END
$$ LANGUAGE plpgsql;
I believe
Robert Haas writes:
> On Sun, Jul 4, 2010 at 12:11 AM, Tom Lane wrote:
>> I believe that none of the dead row versions can be vacuumed during this
>> test.
> Yep, you seem to be right. The table grows to 802 pages. But why is
> it that we can't vacuum them as we go along?
Sure. What you'd ne
Am 04.07.2010 06:11, wrote Tom Lane:
... but is it representative of real-world cases?
regards, tom lane
Hi Tom,
we do run an application in productive use that suffered from a similar effect.
We did not have 100 updates per row, but 10-100 updates per row on abo
On Sun, Jul 4, 2010 at 12:11 AM, Tom Lane wrote:
> Robert Haas writes:
>> CREATE OR REPLACE FUNCTION update_tab() RETURNS void AS $$
>> BEGIN
>> INSERT INTO tab VALUES (0);
>> FOR i IN 1..10 LOOP
>> UPDATE tab SET x = x + 1;
>> END LOOP;
>> END
>> $$ LANGUAGE p
Robert Haas writes:
> CREATE OR REPLACE FUNCTION update_tab() RETURNS void AS $$
> BEGIN
> INSERT INTO tab VALUES (0);
> FOR i IN 1..10 LOOP
> UPDATE tab SET x = x + 1;
> END LOOP;
> END
> $$ LANGUAGE plpgsql;
I believe that none of the dead row versions can be
