Re: Getting rows in statement-level triggers
От | Artacus |
---|---|
Тема | Re: Getting rows in statement-level triggers |
Дата | |
Msg-id | 48E646A7.90907@comcast.net обсуждение исходный текст |
Ответ на | Re: Getting rows in statement-level triggers (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Getting rows in statement-level triggers
|
Список | pgsql-general |
>> SELECT * >> FROM strand_scores >> WHERE xmin::text = txid_current()::text >> > > This will not work, or at least it will stop working after your > installation passes 4 billion transactions. > > The traditional way to find out your own XID is to insert a dummy row > somewhere (perhaps in a temp table) and see what its xmin is. I'm not > sure why we don't expose a more convenient way --- maybe just that > there's not been any demand for it. > > regards, tom lane Well the good news there is that it won't break during the period we have to provide free bug fixes :) Inserting a row to get the xid seems pretty kludgy. If you wouldn't mind answering a few more questions Tom: * So what exactly happens at the 4 billion mark? * Why can't I cast an xid to int or bigint? * The table in question is the largest in the db. How performative is it to query based on xmin? Is xmin indexed? Can it be? BTW, if there were no demand for a convenient way to get your xid, then there shouldn't be a "traditional" way :) Artacus
В списке pgsql-general по дате отправления: