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
> 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
Jaime Casanova 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
--
Sent via pgsql-hac
On 2/19/09, Heikki Linnakangas 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 not make it an assert?
--
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 (pgsql-hac
Heikki Linnakangas 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 because of
arcane details of the u
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 aborted,
> 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
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 t
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
10 matches
Mail list logo