not(t_xmax = 0)
Hi,
I need to filter xid != 0. I tried this "not(t_xmax = 0)" but I dont sure that this work ok
How I do it?
Create or replace function obtener_info_reg(tabla varchar, buscareliminado boolean, curs refcursor) returns void as
$$
declare
query_string varchar;
strwhere varchar;
strsql varchar;
blocksize integer := 8192;
begin
query_string:='delete from result_pag';
EXECUTE query_string;
for p in 0..pg_relpages(tabla)-1 loop
query_string:= '';
strsql:='insert into result_pag SELECT '||p||' page,*,
('||p||'*'|| blocksize ||') + lp_off posini_reg,
('||p||'*'|| blocksize ||') + lp_off + 17 posini_infomask,
(t_infomask-1024) t_infomask_old, to_hex(t_infomask) t_infomask_hex,
to_hex(t_infomask-1024) t_infomask_old
FROM heap_page_items(get_raw_page(''' || tabla || ''', '||p||'))';
strwhere:='';
if buscareliminado= true then
--add where t_max != 0 to query
strwhere:= ' where not(t_xmax = 0)';
end if;
query_string:= query_string || strsql || strwhere;
EXECUTE query_string;
end loop;
OPEN curs FOR EXECUTE 'select * from result_pag ';
end;
$$ language plpgsql;
Alejandro Carrillo wrote:
I need to filter xid != 0. I tried this "not(t_xmax = 0)" but I
dont sure that this work okHow I do it?
Please give a high-level description of what you are trying to
accomplish and why. I didn't find it at all clear from your sample
function,
-Kevin
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Import Notes
Resolved by subject fallback
I try to do a function that let know which rows are deleted in a table using the xmax !=0
Show quoted text
________________________________
De: Kevin Grittner <kgrittn@mail.com>
Para: Alejandro Carrillo <fasterzip@yahoo.es>; pgsql-general@postgresql.org
Enviado: Domingo 20 de enero de 2013 12:19
Asunto: Re: [GENERAL] not(t_xmax = 0)Alejandro Carrillo wrote:
I need to filter xid != 0. I tried this "not(t_xmax = 0)" but I
dont sure that this work okHow I do it?
Please give a high-level description of what you are trying to
accomplish and why. I didn't find it at all clear from your sample
function,-Kevin
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Alejandro Carrillo wrote:
De: Kevin Grittner <kgrittn@mail.com>
Please give a high-level description of what you are trying to
accomplish and why.
I try to do a function that let know which rows are deleted in a
table using the xmax !=0
That's not something you're going to have much luck with by using
plpgsql to try to parse heap pages. If you explain why you want to
do this, it might help in suggesting alternative techniques. Maybe
there is already a tool written that you could use.
-Kevin
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Import Notes
Resolved by subject fallback
"Kevin Grittner" <kgrittn@mail.com> writes:
Alejandro Carrillo wrote:
I try to do a function that let know which rows are deleted in a
table using the xmax !=0
That's not something you're going to have much luck with by using
plpgsql to try to parse heap pages.
No, because xmax being nonzero doesn't prove much: the row might be
updated/deleted, or it might only have been locked by SELECT FOR UPDATE,
or it might be perfectly fine because the updating transaction rolled
back. You could get a limited amount of information by checking the
hint bits in t_infomask, but if the hint bits aren't set you won't know
what the row's state is.
You'd really need to do this in C using the tqual.c functions for the
results to be trustworthy.
I'm a bit surprised that contrib/pageinspect doesn't have a mechanism
for pulling out only committed-good heap tuples...
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
this function didn't work to know if a row can surely dead?
http://doxygen.postgresql.org/tqual_8c_source.html#l01236
Show quoted text
________________________________
De: Tom Lane <tgl@sss.pgh.pa.us>
Para: Kevin Grittner <kgrittn@mail.com>
CC: Alejandro Carrillo <fasterzip@yahoo.es>; pgsql-general@postgresql.org
Enviado: Domingo 20 de enero de 2013 15:30
Asunto: Re: [GENERAL] not(t_xmax = 0)"Kevin Grittner" <kgrittn@mail.com> writes:
Alejandro Carrillo wrote:
I try to do a function that let know which rows are deleted in a
table using the xmax !=0That's not something you're going to have much luck with by using
plpgsql to try to parse heap pages.No, because xmax being nonzero doesn't prove much: the row might be
updated/deleted, or it might only have been locked by SELECT FOR UPDATE,
or it might be perfectly fine because the updating transaction rolled
back. You could get a limited amount of information by checking the
hint bits in t_infomask, but if the hint bits aren't set you won't know
what the row's state is.You'd really need to do this in C using the tqual.c functions for the
results to be trustworthy.I'm a bit surprised that contrib/pageinspect doesn't have a mechanism
for pulling out only committed-good heap tuples...regards, tom lane
Alejandro Carrillo wrote:
this function didn't work to know if a row can surely dead?
Sure, as long as you call it after HeapTupleSatisfiesMVCC(), as the
comment specifies. Also note that not all deleted or updated tuples
will be retained for very long; HOT pruning and autovacuum can
clean up dead tuples at unpredictable times. But if you want to
know which among the old tuples that are still in the heap will go
away when the next vacuum against the table runs, that would be one
way to do it.
-Kevin
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Import Notes
Resolved by subject fallback