Re: Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes
От | Tom Lane |
---|---|
Тема | Re: Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes |
Дата | |
Msg-id | 22393.1410461893@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Re: BUG #10329: Could not read block 0 in file
"base/56100265/57047884": read only 0 of 8192 bytes
|
Список | pgsql-bugs |
Andres Freund <andres@2ndquadrant.com> writes: > On 2014-09-11 13:41:37 -0400, Bruce Momjian wrote: >> And practically, how would we implement this for upgrades? Would we have >> pg_dump emit UNLOGGED for any hash creation command? > That seems like an almost trivial problem in comparison to the actual > difficulty of implementing UNLOGGED indexed on LOGGED tables. Yeah, we'd need to somehow mark such indexes as INVALID during crash recovery, which sounds pretty messy. We've stayed away from the whole idea of automatically-applied catalog updates during recovery, for good reasons. > Yes, I > think forbidding unlogged hash tables + teaching pg_dump a heuristic to > treat any < 9.x hash index as unlogged would be ok. My own opinion, if we had the infrastructure, is that "CREATE INDEX ... USING hash" should result in (1) automatically adding the UNLOGGED attribute and (2) issuing a NOTICE or WARNING stating that we've done so. Throwing an error, when we do not do so today, is just being a nag. This approach also eliminates the need to do anything special in pg_dump, which is a good thing since we have no way to retroactively fix existing dump files. regards, tom lane
В списке pgsql-bugs по дате отправления: