You need to set $PGDATA before running the script. And psql,pg_ctl and
pg_resetxlog need to be in $PATH. After running the script, restart
postmaster and run SELECT * FROM t2. There should be one row in the
table, but it's empty.
I've tried this script, and superisingly found that T2 is not
Sorry, send the mail wrongly just now.
You need to set $PGDATA before running the script. And psql,pg_ctl and
pg_resetxlog need to be in $PATH. After running the script, restart
postmaster and run SELECT * FROM t2. There should be one row in the
table, but it's empty.
I've tried this script
You need to set $PGDATA before running the script. And psql,pg_ctl and
pg_resetxlog need to be in $PATH. After running the script, restart
postmaster and run SELECT * FROM t2. There should be one row in the
table, but it's empty.
I've tried this script on postgres (PostgreSQL) 8.3devel, and
You need to set $PGDATA before running the script. And psql,pg_ctl and
pg_resetxlog need to be in $PATH. After running the script, restart
postmaster and run SELECT * FROM t2. There should be one row in the
table, but it's empty.
I've tried this script on postgres (PostgreSQL) 8.3devel, and
Simon Riggs wrote:
On Wed, 2007-10-17 at 17:18 +0800, Jacky Leng wrote:
Second, suppose that no checkpoint has occured during the upper
series--authough not quite possible;
That part is irrelevant. It's forced out to disk and doesn't need
recovery, with or without the checkpoint.
On Wed, 2007-10-17 at 17:18 +0800, Jacky Leng wrote:
Second, suppose that no checkpoint has occured during the upper
series--authough not quite possible;
That part is irrelevant. It's forced out to disk and doesn't need
recovery, with or without the checkpoint.
There's no hole that I can
Forgot to attach the script I promised..
You need to set $PGDATA before running the script. And psql,pg_ctl and
pg_resetxlog need to be in $PATH. After running the script, restart
postmaster and run SELECT * FROM t2. There should be one row in the
table, but it's empty.
Heikki Linnakangas wrote:
I wrote:
Unfortunately I don't see any easy way to fix it. One approach would be
to avoid reusing the relfilenodes until next checkpoint, but I don't see
any nice place to keep track of OIDs that have been dropped since last
checkpoint.
Ok, here's one idea:
Instead of deleting the file
Heikki Linnakangas wrote:
I wrote:
Unfortunately I don't see any easy way to fix it. One approach would be
to avoid reusing the relfilenodes until next checkpoint, but I don't see
any nice place to keep track of OIDs that have been dropped since last
checkpoint.
Ok, here's one idea:
Instead
On Wed, 2007-10-17 at 12:11 +0100, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Wed, 2007-10-17 at 17:18 +0800, Jacky Leng wrote:
Second, suppose that no checkpoint has occured during the upper
series--authough not quite possible;
That part is irrelevant. It's forced out to disk
Simon Riggs wrote:
On Wed, 2007-10-17 at 12:11 +0100, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Wed, 2007-10-17 at 17:18 +0800, Jacky Leng wrote:
Second, suppose that no checkpoint has occured during the upper
series--authough not quite possible;
That part is irrelevant. It's forced out
Florian G. Pflug wrote:
Heikki Linnakangas wrote:
I wrote:
Unfortunately I don't see any easy way to fix it. One approach would be
to avoid reusing the relfilenodes until next checkpoint, but I don't see
any nice place to keep track of OIDs that have been dropped since last
checkpoint.
Ok,
12 matches
Mail list logo
