From: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Florian Pflug <fgp(at)phlo(dot)org>, Joachim Wieland <joe(at)mcknight(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Snapshot synchronization, again... |
Date: | 2010-12-31 09:42:14 |
Message-ID: | 4D1DA576.1030504@kaltenbrunner.cc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/30/2010 10:45 PM, Heikki Linnakangas wrote:
> On 30.12.2010 16:49, Florian Pflug wrote:
>> On Dec30, 2010, at 13:31 , Joachim Wieland wrote:
>>> We return snapshot information as a chunk of data to the client. At
>>> the same time however, we set a checksum in shared memory to protect
>>> against modification of the snapshot. A publishing backend can revoke
>>> its snapshot by deleting the checksum and a backend that is asked to
>>> install a snapshot can verify that the snapshot is correct and current
>>> by calculating the checksum and comparing it with the one in shared
>>> memory.
>>
>> We'd still have to stream these checksums to the standbys though,
>> or would they be exempt from the checksum checks?
>>
>> I still wonder whether these checks are worth the complexity. I
>> believe we'd only allow snapshot modifications for read-only queries
>> anyway, so what point is there in preventing clients from setting
>> broken snapshots?
>
> Hmm, our definition of "read-only" is a bit fuzzy. While a transaction
> doesn't modify the database itself, it could still send NOTIFYs or call
> a PL function to do all sorts of things outside the database. Imagine
> that you're paranoid about data integrity, and have a security definer
> function that runs cross checks on the data. If it finds any
> anomalities, it wakes up the operator or forces shutdown or similar.
are people actually doing that in reality? I'm also having a hard time
picturing a realistic example of what that "data integrity check"
function would actually being able to check with default isolation mode
and concurrent activity...
>
> Now a malicious user could set a snapshot that passes the basic validity
> checks, ie. xmin >= GlobalXmin, but contains a combination of still
> in-progress that never existed in reality. If he then calls the
> paranoia-function, it would see an inconsistent state of committed
> tuples and get upset.
sure but I would expect being able to set a snapshot requiring either
superuser or some sort of "WITH SNAPSHOT" grant thingy - and in general
there are much more trivial and not that obscure scenarios a "normal"
user can cause the admin to get paged :)
>
> Maybe that's a bit far-stretched, but it's not entirely clear that
> running with an inconsistent snapshot is harmless.
well there has been some discussion with to the SSI stuff that we might
want to reconsider our definition of "read-only" maybe that would be the
right way to approach the problem?
Stefan
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2010-12-31 09:58:34 | Re: Old git repo |
Previous Message | Stefan Kaltenbrunner | 2010-12-31 08:27:29 | Re: Sync Rep Design |