Re: pageinspect's infomask and infomask2 as smallint
От | Robert Haas |
---|---|
Тема | Re: pageinspect's infomask and infomask2 as smallint |
Дата | |
Msg-id | AANLkTi=+Yykx1Kj59vkoNF+XOonyCP=2bySr37UFi7jp@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pageinspect's infomask and infomask2 as smallint (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pageinspect's infomask and infomask2 as smallint
|
Список | pgsql-hackers |
On Tue, Feb 15, 2011 at 10:42 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: >> On 14.02.2011 21:49, Alvaro Herrera wrote: >>> Thanks to Noah Misch's review of the keylock patch I noticed that >>> pageinspect's heap_page_items(bytea) function returns infomask and >>> infomask2 as smallint (signed). But the fields in the tuple header are >>> 16 bits unsigned, so if the high (16th) bit is set, it returns negative >>> values which seem hard to handle. Not a problem for infomask, because >>> the high bit is used for a VACUUM FULL-era flag; but in infomask2 it is >>> used. >>> >>> This seems hard to fix for existing installations with the unpackaged >>> module already loaded -- IIRC it's not acceptable to drop a function, >>> which is what would need to be done here. > >> pageinspect is just a debugging aid, so I think we should change it from >> smallint to int4 in 9.1, and not bother backporting. > > I don't see any reason that the old version of the function couldn't be > dropped in the upgrade script. It's not likely anything would be > depending on it, is it? I don't see much point in taking the risk. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: