From: | Radoslaw Zielinski <radek(at)pld-linux(dot)org> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: 8.4.0 data loss / HOT-related bug |
Date: | 2009-08-21 17:38:00 |
Message-ID: | 20090821173800.GC2645@bzium |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Greg Stark <gsstark(at)mit(dot)edu> [2009-08-21 18:55]:
[...]
> Is this, perchance, new hardware? Did you test the memory in it?
It's a "virtual private server"; the hosting provider is swearing
everything's fine. I can't vouch for it myself, obviously.
> Do you have other records that have "disappeared"?
I haven't found any (yet). So far, verified with:
create function exec(text) returns void language plpgsql as $f$ begin execute $1; end; $f$;
select exec(
'select log_id, id from ( select distinct ''' || relname || ''', case first_value(trigger_mode) over w when ''DELETE'' then null else id end as log_id, first_value(last_modified) over w as lm from log.' || relname || ' window w as (partition by id order by id desc,trigger_id desc ) )x left join public.' || relname || ' on id=log_id where ( id is null or last_modified <> x.lm ) and log_id is not null'
) from pg_stat_user_tables where schemaname = 'log';
(Looks at the log.* table, finds the largest last_modified of the
non-deleted rows, joins the public.* table on id, compares
last_modified).
--
Radosław Zieliński <radek(at)pld-linux(dot)org>
From | Date | Subject | |
---|---|---|---|
Next Message | Radoslaw Zielinski | 2009-08-21 17:46:07 | Re: 8.4.0 data loss / HOT-related bug |
Previous Message | Greg Stark | 2009-08-21 16:55:44 | Re: 8.4.0 data loss / HOT-related bug |