On Sun, Feb 04, 2007 at 03:18:07PM -0200, Jorge Godoy wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Jorge Godoy <[EMAIL PROTECTED]> writes:
> >> I'm using PostgreSQL 8.1.4 and psql 8.1.4 as well.
> >
> > This was fixed in 8.1.5 ... or at least the only known cause was
> > fixed.
>
> Thanks
Tomas Vondra <[EMAIL PROTECTED]> writes:
> As I already said - it works until I create a rule for the next
> partition (not used yet) - then is suddenly stops working.
Suddenly stops working, or continues doing exactly what it did before?
I'm wondering if you are relying on a cached plan that does
> Looks to me as though you have forgottent the table inheritance part of the
> table partitioning trick. Are you sure that sessions_90 inherit from
> the sessions table? Does a direct count from the table referenced by the
> rule return a non-zero count? In other words:
>
> SELECT count(*) FR
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> db=> INSERT INTO sessions(... non-pk columns ...) VALUES (... data ...);
> INSERT 0 0
> db=> SELECT * FROM sessions WHERE id = currval('sessions_id_seq');
> (0 rows)
>
> which seems really strange to me. We're using sequence to generate the
>
Hi,
we're running PostgreSQL 8.1.4 and I've encountered some strange
problems with partitioning / rules, and I really don't know how to
fix it.
We have a table 'sessions' partitioned along the 'id' column which is a
primary key. Each partition holds at most 500.000 rows, i.e. partition
'sessions_
On Wed, Jan 31, 2007 at 10:37:34AM -0800, Jeff Davis wrote:
> I know this is off-topic for this list, but is there a place I can get
> some details about linux OOM killer, and the conditions that cause this
> OS hang when you turn off the OOM killer? I'd like to really know what's
> happening, and
Tom Lane <[EMAIL PROTECTED]> writes:
> Jorge Godoy <[EMAIL PROTECTED]> writes:
>> I'm using PostgreSQL 8.1.4 and psql 8.1.4 as well.
>
> This was fixed in 8.1.5 ... or at least the only known cause was fixed.
Thanks! I'll bug OpenSuSE guys to release an 8.1.5 package ;-)
--
Jorge Godoy <
Jorge Godoy <[EMAIL PROTECTED]> writes:
> I'm using PostgreSQL 8.1.4 and psql 8.1.4 as well.
This was fixed in 8.1.5 ... or at least the only known cause was fixed.
2006-10-06 14:23 tgl
* src/: backend/utils/cache/catcache.c,
backend/utils/cache/syscache.c, include/utils/catcac
Hi!
There was a discussion with this same subject last week that seemed to be
caused by dump/restore with a wrong phpPgAdmin version.
I'm seeing the same error message for a development database where I always
use psql directly to make the maintenance and I had no dump/restore before it
started
