| From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | Bernd Helmle <mailings(at)oopsware(dot)de> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Mark Dilger <hornschnorter(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Read Uncommitted |
| Date: | 2019-12-19 12:56:43 |
| Message-ID: | CANP8+jKFE1h8ULbU3VLnLM86pPYCFMuOKmti2W8sPph+ji-8BQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 19 Dec 2019 at 12:42, Bernd Helmle <mailings(at)oopsware(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jehan-Guillaume de Rorthais | 2019-12-19 13:14:10 | Re: segmentation fault when cassert enabled |
| Previous Message | Bernd Helmle | 2019-12-19 12:42:19 | Re: Read Uncommitted |