>> 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(becaus
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
b
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
constra
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
> 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 yo
> 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 Eva
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 l
> 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
> 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?
I
> 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
> 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 t
> 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_re
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 archi
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 smg
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 be
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
"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;
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 Inv
20 matches
Mail list logo
