Re: partitioning / rules - strange behavior - Mailing list pgsql-general

From tv@fuzzy.cz
Subject Re: partitioning / rules - strange behavior
Date
Msg-id 1170667665.45c6f891a8962@mail.fuzzy.cz
Whole thread Raw
In response to Re: partitioning / rules - strange behavior  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: partitioning / rules - strange behavior  (Tomas Vondra <tv@fuzzy.cz>)
List pgsql-general
> Suddenly stops working, or continues doing exactly what it did before?
> I'm wondering if you are relying on a cached plan that doesn't include
> the new rule.
>
>             regards, tom lane
>

If there´s only the insert_8500000 RULE then everything works as expected - the
insert prints "INSERT 0 0", the row is inserted into the correct partition
which is sessions_8500000 - I can fetch it using either

SELECT * FROM sessions WHERE id = currval('sessions_id_seq');

or direcly by

SELECT * FROM sessions_8500000 WHERE id = currval('sessions_id_seq');

When I create the next next rule (insert_9000000 for ids between 9000000 and
9499999) it stops working - it prints "INSERT 0 0" just as before, everything
seems fine, but the row disappears - it's not available .

I'm not sure about the query plans, but I think I've checked that and everything
seemed ok - all the partitions were used as far as I remember. But this
shouldn't be a problem as we have not reached the 9000000 limit yet (so the new
partition is not used at all). And we've tried to restart the PostgreSQL as the
last hope, yesterday, so there really should be no old plans.

I don't have an access to the production database (I have not been able to
simulate this on the development/testing system) - I'll play with that at night
(european time). I'll try to drop / recreate the partition (I've tried to
recreate only the RULEs, not the partitions).

Tomas

pgsql-general by date:

Previous
From: 许文清
Date:
Subject: ff
Next
From: Martijn van Oosterhout
Date:
Subject: Re: 8.2.1 Compiling Error