#x27;s yanked the proposal. I'd like to have some way to peek
at the contents of individual uncommited xacts, but it's clearly not going
to be anything called READ UNCOMMITTED that applies to all uncommitted
xacts at once...
> > I think the suggestions for a SRF based approach might mak
no interlock that would prevent its generated
data from being removed out from under you at any moment after that.
So there's a race condition, and as Robert observed, the window isn't
necessarily small.
> The bigger issue, and the one that IMO makes it impractical to spell this
&g
in may also be seen as not in-progress if they're absent
in the shmem xact arrays and there's no overflow.
But that's OK so long as the only xacts that some sort of read-uncommitted
feature allows to become visible are ones that
satisfy TransactionIdIsInProgress(); they cannot hav
Hi,
On 2019-12-19 07:08:06 -0800, Mark Dilger wrote:
> > As soon as a transaction aborts, the TOAST rows can be vacuumed
> > away, but the READ UNCOMMITTED transaction might've already seen the
> > main tuple. This is not even a particularly tight race, necessarily,
&g
Hi,
On 2019-12-19 09:50:44 +, Simon Riggs wrote:
> On Thu, 19 Dec 2019 at 02:22, Andres Freund wrote:
>
> > Hi,
> >
> > On 2019-12-18 18:06:21 +, Simon Riggs wrote:
> > > On Wed, 18 Dec 2019 at 17:35, Robert Haas wrote:
> > >
> > > > On Wed, Dec 18, 2019 at 10:18 AM Simon Riggs
> > > >
On 12/19/19 7:08 AM, Mark Dilger wrote:
and instead get NULLs for all such rows
To clarify, I mean the toasted column is null for rows
where the value was stored in the toast table rather
than stored inline. I'd prefer some special value
that means "this datum unavailable" so that it could
27;t be resubmitting.
Oh, I'm sorry to hear that. I thought this feature sounded useful, and
we were working out what its limitations were. What I gathered from
the discussion so far was:
- It should be called something other than READ UNCOMMITTED
- It should only be available to sup
On Thu, 19 Dec 2019 at 12:42, Bernd Helmle wrote:
> Am Donnerstag, den 19.12.2019, 00:13 + 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 uncom
Am Donnerstag, den 19.12.2019, 00:13 + 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
On 2019-12-18 16:14, Simon Riggs wrote:
On Wed, 18 Dec 2019 at 12:11, Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> wrote:
As far as I understand with "read uncommitted" policy we can see two
versions of the same tuple if it was updated by two transactions
On Thu, 19 Dec 2019 at 02:22, Andres Freund wrote:
> Hi,
>
> On 2019-12-18 18:06:21 +, Simon Riggs wrote:
> > On Wed, 18 Dec 2019 at 17:35, Robert Haas wrote:
> >
> > > On Wed, Dec 18, 2019 at 10:18 AM Simon Riggs
> > > wrote:
> > > > This was my first concern when I thought about it, but I
On 12/18/19 2:17 PM, Tom Lane wrote:
Mark Dilger writes:
The one in src/test/isolation doesn't look very comprehensive. I'd
at least expect a test that verifies you don't get a syntax error
when you request READ UNCOMMITTED isolation from SQL.
The attached patch set ad
Hi,
On 2019-12-18 18:06:21 +, Simon Riggs wrote:
> On Wed, 18 Dec 2019 at 17:35, Robert Haas wrote:
>
> > On Wed, Dec 18, 2019 at 10:18 AM Simon Riggs
> > wrote:
> > > This was my first concern when I thought about it, but I realised that
> > by taking a snapshot and then calculating xmin n
On Wed, 18 Dec 2019 at 19:29, Heikki Linnakangas wrote:
> On 18/12/2019 20:46, Mark Dilger wrote:
> > On 12/18/19 10:06 AM, Simon Riggs wrote:
> >> Just consider this part of the recovery toolkit.
> >
> > In that case, don't call it "read uncommitted&
want to compute SUM(sales) by
> salesperson, region for the past 5 years, and don't care very much if some
> concurrent transaction aborted in the middle of computing this result.
>
> It's fairly questionable whether there's any real advantage to be gained
> by READ UNCOMMITTE
On 12/18/19 2:29 PM, Heikki Linnakangas wrote:
On 18/12/2019 20:46, Mark Dilger wrote:
On 12/18/19 10:06 AM, Simon Riggs wrote:
Just consider this part of the recovery toolkit.
In that case, don't call it "read uncommitted". Call it some other
thing entirely. Users co
Mark Dilger writes:
>> The one in src/test/isolation doesn't look very comprehensive. I'd
>> at least expect a test that verifies you don't get a syntax error
>> when you request READ UNCOMMITTED isolation from SQL.
> The attached patch set adds a modicum of
Over in [1], I became concerned that, although postgres supports
Read Uncommitted transaction isolation (by way of Read Committed
mode), there was very little test coverage for it:
On 12/18/19 10:46 AM, Mark Dilger wrote:
Looking at the regression tests, I'm surprised read uncommitted ge
On Wed, Dec 18, 2019 at 2:29 PM Heikki Linnakangas wrote:
> I agree that if we have a user-exposed READ UNCOMMITTED isolation level,
> it shouldn't be just a recovery tool. For a recovery tool, I think a
> set-returning function as part of contrib/pageinspect, for example,
&
the past 5 years, and don't care very much if some
> concurrent transaction aborted in the middle of computing this result.
It's fairly questionable whether there's any real advantage to be gained
by READ UNCOMMITTED in that sort of scenario --- almost all the tuples
you'
part of the recovery toolkit.
>
> I agree that it would be useful to have a recovery toolkit for reading
> uncommitted data, but I think a lot more thought needs to be given to
> how such a thing should be designed. If you just add something called
> READ UNCOMMITTED
more thought needs to be given to
> how such a thing should be designed. If you just add something called
> READ UNCOMMITTED, people are going to expect it to have *way* saner
> semantics than this will. They'll use it routinely, not just as a
> last-ditch mechanism to recover otherw
On 18/12/2019 20:46, Mark Dilger wrote:
On 12/18/19 10:06 AM, Simon Riggs wrote:
Just consider this part of the recovery toolkit.
In that case, don't call it "read uncommitted". Call it some other
thing entirely. Users coming from other databases may request
"read un
're not following any pointers as a result of this. The output
is just rows.
> This seems possible, for example, if you can get a transaction to read
> uncommitted data that was written according to some other rowtype than
> what the reading transaction thinks the table rowtype is. C
se
cases; this is not some magic discovery that goes faster - the user
has absolutely no reason to run this whatsoever unless they want to
see uncommitted data. There is a very explicit warning advising
against using it for anything else.
Just consider this part of the recovery toolkit.
In that case
ying to read invalid data, resulting
in either crashes or exploitable security breaches (in the usual vein of
what can go wrong if you can get the C code to follow an invalid pointer).
This seems possible, for example, if you can get a transaction to read
uncommitted data that was written accor
would be useful to have a recovery toolkit for reading
uncommitted data, but I think a lot more thought needs to be given to
how such a thing should be designed. If you just add something called
READ UNCOMMITTED, people are going to expect it to have *way* saner
semantics than this will. They'll
On Wed, 18 Dec 2019 at 17:35, Robert Haas wrote:
> On Wed, Dec 18, 2019 at 10:18 AM Simon Riggs
> wrote:
> > This was my first concern when I thought about it, but I realised that
> by taking a snapshot and then calculating xmin normally, this problem would
> go away.
>
> Why? As soon as a trans
away, but the READ UNCOMMITTED transaction might've already seen the
main tuple. This is not even a particularly tight race, necessarily,
since for example the table might be scanned, feeding tuples into a
tuplesort, and then the detoating might happen further up in the query
tree after the sort
On Wed, 18 Dec 2019 at 14:06, Tom Lane wrote:
> Simon Riggs writes:
> > I present a patch to allow READ UNCOMMITTED that is simple, useful and
> > efficient.
>
> Won't this break entirely the moment you try to read a tuple containing
> toasted-out-of-line values?
On Wed, 18 Dec 2019 at 12:11, Konstantin Knizhnik
wrote:
As far as I understand with "read uncommitted" policy we can see two
> versions of the same tuple if it was updated by two transactions both of
> which were started before us and committed during table traversal by
> tra
Simon Riggs writes:
> I present a patch to allow READ UNCOMMITTED that is simple, useful and
> efficient.
Won't this break entirely the moment you try to read a tuple containing
toasted-out-of-line values? There's no guarantee that the toast-table
entries haven't been vacu
On 18.12.2019 13:01, Simon Riggs wrote:
I present a patch to allow READ UNCOMMITTED that is simple, useful and
efficient. This was previously thought to have no useful definition
within PostgreSQL, though I have identified a use case for diagnostics
and recovery that merits adding a short
I present a patch to allow READ UNCOMMITTED that is simple, useful and
efficient. This was previously thought to have no useful definition within
PostgreSQL, though I have identified a use case for diagnostics and
recovery that merits adding a short patch to implement it.
My docs for this are
34 matches
Mail list logo
