| From: | Bernd Helmle <mailings(at)oopsware(dot)de> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | 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:42:19 |
| Message-ID: | c6c4e23b84db8ef211318021a4995d8089f264d0.camel@oopsware.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
Bernd
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2019-12-19 12:56:43 | Re: Read Uncommitted |
| Previous Message | Peter Eisentraut | 2019-12-19 12:38:19 | Re: Read Uncommitted |