On Thu, 19 Dec 2019 at 12:42, Bernd Helmle <maili...@oopsware.de> wrote:
> Am Donnerstag, den 19.12.2019, 00:13 +0000 schrieb Simon Riggs: > > So the consensus is for a more-specifically named facility. > > > > I was aiming for something that would allow general SELECTs to run > > with a > > snapshot that can see uncommitted xacts, so making it a SRF wouldn't > > really > > allow that. > > There's pg_dirtyread() [1] around for some while, implementing a SRF > for debugging usage on in normal circumstances disappeared data. Its > nice to not have worrying about anything when you faced with such kind > of problems, but for such use cases i think a SRF serves quite well. > > [1] https://github.com/df7cb/pg_dirtyread As an example of an SRF for debugging purposes, sure, but then we already had the example of pageinspect, which I wrote BTW, so wasn't unfamiliar with the thought. Note that pg_dirtyread has got nothing to do with the use cases I described. -- Simon Riggs http://www.2ndQuadrant.com/ <http://www.2ndquadrant.com/> PostgreSQL Solutions for the Enterprise
