Re: [HACKERS] Checksums by default?

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] Checksums by default?
Дата
Msg-id CA+TgmobBchynDJr1TLyBuqHN7HpFgQzhO5j9spCsKhAt=d7G6Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Checksums by default?  (Andres Freund <andres@anarazel.de>)
Ответы Re: [HACKERS] Checksums by default?  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
On Wed, Jan 25, 2017 at 7:37 PM, Andres Freund <andres@anarazel.de> wrote:
> On 2017-01-25 19:30:08 -0500, Stephen Frost wrote:
>> * Peter Geoghegan (pg@heroku.com) wrote:
>> > On Wed, Jan 25, 2017 at 3:30 PM, Stephen Frost <sfrost@snowman.net> wrote:
>> > > As it is, there are backup solutions which *do* check the checksum when
>> > > backing up PG.  This is no longer, thankfully, some hypothetical thing,
>> > > but something which really exists and will hopefully keep users from
>> > > losing data.
>> >
>> > Wouldn't that have issues with torn pages?
>>
>> No, why would it?  The page has either been written out by PG to the OS,
>> in which case the backup s/w will see the new page, or it hasn't been.
>
> Uh. Writes aren't atomic on that granularity.  That means you very well
> *can* see a torn page (in linux you can e.g. on 4KB os page boundaries
> of a 8KB postgres page). Just read a page while it's being written out.

Yeah.  This is also why backups force full page writes on even if
they're turned off in general.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)