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
Jacky Leng wrote:
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 ...)?
If you have a corrupted database, you want to be able to read it, not
panic. If
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
Jacky Leng wrote:
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
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
Jacky Leng wrote:
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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Now that think about this more, I don't see either how that check in
EvalPlanQual could ever be true.
It's there primarily to make the tuple chain chasing code the same
as in other places. Whether it happens to be dead code today
Tom Lane wrote:
(I'm unconvinced that it is dead code, but even if it is it'd be folly
to remove it.)
Agreed, it's a useful safeguard, even it it's a can't happen scenario.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list
On 2/19/09, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
Tom Lane wrote:
(I'm unconvinced that it is dead code, but even if it is it'd be folly
to remove it.)
Agreed, it's a useful safeguard, even it it's a can't happen scenario.
if it is a can't happen scenario then why
Jaime Casanova jcasa...@systemguards.com.ec writes:
if it is a can't happen scenario then why not make it an assert?
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...)
regards, tom lane
10 matches
Mail list logo
