Re: BUG #16285: bt_metap fails with value is out of range for type integer
От | Peter Geoghegan |
---|---|
Тема | Re: BUG #16285: bt_metap fails with value is out of range for type integer |
Дата | |
Msg-id | CAH2-Wz=xdRzKHok80zc9agdDhLPWZEoj0Lx_HmA2j9CrWgY0MQ@mail.gmail.com обсуждение исходный текст |
Ответ на | BUG #16285: bt_metap fails with value is out of range for type integer (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #16285: bt_metap fails with value is out of range for type integer
|
Список | pgsql-bugs |
On Mon, Mar 2, 2020 at 2:40 PM PG Bug reporting form <noreply@postgresql.org> wrote: > Looking at the sources of both extensions, I can see, that pgstatindex() is > using psprintf(INT64_FORMAT) for page counters and psprintf("%u") for root > page, while bt_metap() is using only psprintf("%d"); > > I assume psprintf("%u") should be used at least for metad->btm_root and > metad->btm_fastroot in the bt_metap(PG_FUNCTION_ARGS) function. While this has been wrong forever, the immediate problem here is probably not metad->btm_root. In practice, the root block number is usually fairly low. Very large indexes tend to have a root page that only has a small number of tuples, because the root page was created relatively early in the lifetime of the index. Past a certain point, the root page receives new tuples so infrequently that it almost never happens. I think it's more likely that the problem here is the relatively new column returned by bt_metap(), oldest_xact. That has only been around since Postgres v11. I'm not sure how we should handle this in the backbranches, since only a change in the CREATE FUNCTION declaration of bt_metap() can truly fix the problem. I suppose that we could work around the problem with some kind of kludge, but come up with a real fix for v13. -- Peter Geoghegan
В списке pgsql-bugs по дате отправления: