Re: Snapshot synchronization, again...
От | Stefan Kaltenbrunner |
---|---|
Тема | Re: Snapshot synchronization, again... |
Дата | |
Msg-id | 4D1DA576.1030504@kaltenbrunner.cc обсуждение исходный текст |
Ответ на | Re: Snapshot synchronization, again... (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: