On 23.02.2011 03:00, Joachim Wieland wrote:
> On Tue, Feb 22, 2011 at 3:34 PM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
>> Yes, that's the point I was trying to make. I believe the idea of a hash was
>> that it takes less memory than storing the whole snapshot (and more
>> importantly, a fixed amount of memory per snapshot). But I'm not convinced
>> either that dealing with a hash is any less troublesome.
>
> Both Tom and Robert voted quite explicitly against the
> store-in-shared-memory idea. Others don't want to allow people request
> arbitrary snapshots and again others wanted to pass the snapshot
> through the client so that in the future we could also request
> snapshots from standby servers. The hash idea seemed to at least make
> nobody unhappy.
>
> For easier review, here are a few links to the previous discusion:
>
> http://archives.postgresql.org/pgsql-hackers/2010-12/msg00361.php
> http://archives.postgresql.org/pgsql-hackers/2010-12/msg00383.php
> http://archives.postgresql.org/pgsql-hackers/2010-12/msg00481.php
> http://archives.postgresql.org/pgsql-hackers/2010-12/msg02454.php
>
> Why exactly, Heikki do you think the hash is more troublesome?
It just feels wrong to rely on cryptography just to save some shared memory.
I realize that there are conflicting opinions on this, but from user
point-of-view the hash is just a variant of the idea of passing the
snapshot through shared memory, just implemented in an indirect way.
> And how
> could we validate/invalidate snapshots without the checksum (assuming
> the through-the-client approach instead of storing the whole snapshot
> in shared memory)?
Either you accept anything that passes sanity checks, or you store the
whole snapshot in shared memory (or a temp file). I'm not sure which is
better, but they both seem better than the hash.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com