Re: Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes
От | Andres Freund |
---|---|
Тема | Re: Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes |
Дата | |
Msg-id | 20140911174637.GD15099@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884":
read only 0 of 8192 bytes
Re: Re: BUG #10329: Could not read block 0 in file "base/56100265/57047884": read only 0 of 8192 bytes |
Список | pgsql-bugs |
On 2014-09-11 13:41:37 -0400, Bruce Momjian wrote: > > > I agree there - implementing CREATE UNLOGGED INDEX and use THAT for hash > > > indexes seems like a fairly clean thing to me, hash indexes _are_ > > > unlogged so lets reflect that directly. > > > I could even envision pg_dump doing that conversion automatically... > > > > I think this did came up as a solution before. It's just that nobody > > found a reasonably easy and clean way to do unlogged indexes on logged > > tables so far. It's far from trivial. > > 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. Yes, I think forbidding unlogged hash tables + teaching pg_dump a heuristic to treat any < 9.x hash index as unlogged would be ok. > That seems to defeat the purpose of this. Why? It makes hash indexes usable for the cases where it's safe to do so. Great! It also adds a feature which is really interesting for other types of indexes. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-bugs по дате отправления: