Cann't we remove this param?
We can rewrite like this:
1.XLogReadBuffer:
* remove init;
* everytime we cann't read a block, just log_invalid_page it, and return
InvalidBuffer;
2.Also rewrite all functions calling XLogReadBuffer with init=true: skip
current block if XLogReadBuffer return
Tom Lane [EMAIL PROTECTED] дÈëÓʼþ
news:[EMAIL PROTECTED]
Jacky Leng [EMAIL PROTECTED] writes:
Cann't we remove this param?
No.
We can rewrite like this:
1.XLogReadBuffer:
* remove init;
* everytime we cann't read a block, just log_invalid_page it, and
return
InvalidBuffer
Oh, I am wrong!
Jacky Leng [EMAIL PROTECTED] дÈëÓʼþ
news:[EMAIL PROTECTED]
Tom Lane [EMAIL PROTECTED] дÈëÓʼþ
news:[EMAIL PROTECTED]
Jacky Leng [EMAIL PROTECTED] writes:
Cann't we remove this param?
No.
We can rewrite like this:
1.XLogReadBuffer:
* remove init
As the README for xlog says: There're two kinds of WAL records:
* WAL record that contains enough information to re-generate the entire
contents of a page;
during recovery of these records, blocks are read with:
buffer = XLogReadBuffer(reln, blkno, true);
so it can be sure that the block will
Shouldn't we write xlog record before we do a physical operation?
An test case:
1. set full_page_writes off;
2. startup database; create a table; insert 10 rows in it; shutdown
database;
3. startup database again; delete all rows from this table;
4. vacuum this table, and it will come into
If I run the database under non-archiving mode, and execute the following
command:
alter table t set tablespace tblspc1;
Isn't it possible that the new t cann't be recovered?
---(end of broadcast)---
TIP 4: Have you searched our list
Jacky Leng wrote:
If I run the database under non-archiving mode, and execute the following
command:
alter table t set tablespace tblspc1;
Isn't it possible that the new t cann't be recovered?
No. At the end of copy_relation_data we call smgrimmedsync, which fsyncs
the new relation
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
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
Heikki Linnakangas [EMAIL PROTECTED] writes:
I tend to agree that truncating the file, and extending the fsync
request mechanism to actually delete it after the next checkpoint,
is the most reasonable route to a fix.
How about just allowing to use wal even WAL archiving is disabled?
It
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
Hi,
When I read function EvalPlanQual, I found the following code:
if (heap_fetch(relation, SnapshotDirty, tuple, buffer, true, NULL))
{
/*
* If xmin isn't what we're expecting, the slot must have been
* recycled and reused for an unrelated tuple. This implies that
* the
Tuples with an aborted xmin can be vacuumed right away. When we're
following the update chain in EvalPlanQual, it's possible that the updater
has aborted, the updated dead tuple is vacuumed away, and the slot is
reused for another unrelated tuple.
But if the updater aborted, how can
Asserts on data-consistency checks aren't really a good idea.
(IOW this is can't happen only as long as your database isn't
corrupt...)
Then why not change this to an ereport(PANIC ...)?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
After all, re-initdb is much easier than re-build the whole package.
And there seems nothing diffcult to implement this. Is that true?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Considering the following sequence:
create table t(a int primary key);
alter table t drop constraint t_pkey;
insert into t values(null);
ERROR: null value in column a violates not-null constraint
My question is, why null is not allowed to be inserted after primary key
constraint
Recently, when I was running my application on 8.3.7, my data got
corrupted. The scene was like this: invalid memory alloc request size
I invested the error data, and found that one sector of a db-block became
all-zero (I confirmed the reason later, it was because that my disk got
I think the reasoning is that if those functions reported a PANIC the
chance you could recover your data is zero, because you need the
database system to read the other (good) data.
I do not see why PANIC reduced the chance to recover my data. AFAICS,
my data has already corrupted(because of
20 matches
Mail list logo
