> 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"
> 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"
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 sc
> 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
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
>>> che
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
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 o
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 o
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 im
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
> 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 th
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.
>
12 matches
Mail list logo
