e 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 make sense.
>
> Yeah, I'd rather do it tha
ock 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
> as "READ UNC
ss 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 have been vacuumed.
The bigger issue, and the one that IM
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,
>
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
.
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 superusers, at least
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
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
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
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 adds a modicum
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
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 UNCOMMITTED in that sort of sc
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 coming
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 test coverage
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 gets
so
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,
> w
ast 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'd be looking at would be
he 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, people a
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 otherwise-l
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 uncommi
we'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. Castin
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, don't call it
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
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 use it rout
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
umed
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 has
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 value
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 vacuumed away.
I s
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
34 matches
Mail list logo
