Re: Protecting against unexpected zero-pages: proposal

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: Protecting against unexpected zero-pages: proposal
Дата
Msg-id 4CD9A2E1.8090708@agliodbs.com
обсуждение исходный текст
Ответ на Re: Protecting against unexpected zero-pages: proposal  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Protecting against unexpected zero-pages: proposal  (Greg Stark <gsstark@mit.edu>)
Список pgsql-hackers
> PostgreSQL
> isn't the only database product that uses MVCC - not by a long shot -
> and the problem of detecting whether an XID is visible to the current
> snapshot can't be ours alone.  So what do other people do about this?
> They either don't cache the information about whether the XID is
> committed in-page (in which case, are they just slower or do they have
> some other means of avoiding the performance hit?) or they cache it in
> the page (in which case, they either WAL log it or they don't checksum
> it).

Well, most of the other MVCC-in-table DBMSes simply don't deal with
large, on-disk databases.  In fact, I can't think of one which does,
currently; while MVCC has been popular for the New Databases, they're
all focused on "in-memory" databases.  Oracle and InnoDB use rollback
segments.

Might be worth asking the BDB folks.

Personally, I think we're headed inevitably towards having a set of
metadata bitmaps for each table, like we do currently for the FSM.

--                                  -- Josh Berkus                                    PostgreSQL Experts Inc.
                        http://www.pgexperts.com
 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: TODO Alter Table Rename Constraint
Следующее
От: Merlin Moncure
Дата:
Сообщение: Re: proposal: plpgsql - iteration over fields of rec or row variable