Re: btree_gist valgrind warnings about uninitialized memory
От | Andres Freund |
---|---|
Тема | Re: btree_gist valgrind warnings about uninitialized memory |
Дата | |
Msg-id | 20140604232537.GP785@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: btree_gist valgrind warnings about uninitialized memory (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: btree_gist valgrind warnings about uninitialized memory
|
Список | pgsql-hackers |
On 2014-05-14 12:20:55 -0400, Tom Lane wrote: > Andres Freund <andres@2ndquadrant.com> writes: > > On 2014-05-14 10:07:18 -0400, Tom Lane wrote: > >> I think that's an OK restriction as long as we warn people about it > >> (you could update a replication pair as long as you shut them both > >> down cleanly at the same time, right?). Can the WAL replay routine > >> be made to detect incompatible records? > > > We could just bump the wal version. Somewhat surprisingly that works if > > both nodes are shutdown cleanly (primary first)... But the errors about > > it are really ugly (will moan about unusable checkpoints), so it's > > probably not a good idea. Especially as it'll make it an issue for all > > users, not just the ones creating spgist indexes. > > Yeah, I don't think we want to bump the WAL version code post-beta1. > > Probably better to assign the modified spgist record a new xl_info ID > number, so that a beta1 slave would throw an error for it. Since that ship has now sailed...? It's imo bad form to release a new version that overwrites the stack and heap, even if we can't see a concrete danger. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: