On Mon, Aug 5, 2013 at 05:22:28PM +0200, Andres Freund wrote:
> On 2013-08-05 11:17:08 -0400, Bruce Momjian wrote:
> > One interesting aspect of this patch is that the backend code is no
> > longer even checking HEAP_MOVED_OFF and HEAP_MOVED_IN. However, we
> > can't reuse those bits because they
On 2013-08-05 11:17:08 -0400, Bruce Momjian wrote:
> One interesting aspect of this patch is that the backend code is no
> longer even checking HEAP_MOVED_OFF and HEAP_MOVED_IN. However, we
> can't reuse those bits because they could be set from pre-9.0 rows.
The other tqual.c .satisfies routines
On Thu, Jul 25, 2013 at 07:24:53PM -0400, Robert Haas wrote:
> - /* Used by pre-9.0 binary upgrades */
> - if (tuple->t_infomask & HEAP_MOVED_OFF)
> - {
> - TransactionId xvac = HeapTupleHeaderGetXvac(tuple);
> -
> - if (Tr
On Fri, Jul 26, 2013 at 10:16 AM, Andres Freund wrote:
> I am more concerned about the care needed when placing
> CommandCounterIncrement()'s somewhere though. It seems more than likely
> that this will get repeatedly broken, even if it's not atm (which I
> doubt). E.g. inheritance handling seems
On 2013-07-26 09:50:32 -0400, Robert Haas wrote:
> sepgsql is using SnapshotSelf to find the old version of a tuple that
> was updated by the core code just before. That should be safe in the
> sense that there can't be a currently-committing transaction somewhere
> else that's updated that tuple,
Robert Haas writes:
> On Fri, Jul 26, 2013 at 9:18 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> Well, that's still used in _bt_check_unique, unique_key_recheck
>>> (trigger function to do a deferred uniqueness check), RI_FKey_check,
>>> and rather extensively by sepgsql. I don't really have m
On Fri, Jul 26, 2013 at 9:18 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jul 26, 2013 at 8:49 AM, Tom Lane wrote:
>>> What about SnapshotSelf?
>
>> Well, that's still used in _bt_check_unique, unique_key_recheck
>> (trigger function to do a deferred uniqueness check), RI_FKey_check,
>>
Robert Haas writes:
> On Fri, Jul 26, 2013 at 8:49 AM, Tom Lane wrote:
>> What about SnapshotSelf?
> Well, that's still used in _bt_check_unique, unique_key_recheck
> (trigger function to do a deferred uniqueness check), RI_FKey_check,
> and rather extensively by sepgsql. I don't really have mu
On Fri, Jul 26, 2013 at 8:49 AM, Tom Lane wrote:
> Robert Haas writes:
>> OK. I've taken care of all remaining uses of SnapshotNow in the code
>> base. I think we can go ahead and remove it, now. Patch attached.
>
>> (And there was, hopefully, much rejoicing.)
>
> What about SnapshotSelf?
Wel
On 2013-07-25 19:24:53 -0400, Robert Haas wrote:
> (And there was, hopefully, much rejoicing.)
Definitely! Thanks.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers
On 2013-07-26 08:49:38 -0400, Tom Lane wrote:
> Robert Haas writes:
> > OK. I've taken care of all remaining uses of SnapshotNow in the code
> > base. I think we can go ahead and remove it, now. Patch attached.
>
> > (And there was, hopefully, much rejoicing.)
>
> What about SnapshotSelf?
I
Robert Haas writes:
> OK. I've taken care of all remaining uses of SnapshotNow in the code
> base. I think we can go ahead and remove it, now. Patch attached.
> (And there was, hopefully, much rejoicing.)
What about SnapshotSelf?
regards, tom lane
--
Sent via pgsql
On Tue, Jul 23, 2013 at 2:53 PM, Tom Lane wrote:
> Works for me.
OK. I've taken care of all remaining uses of SnapshotNow in the code
base. I think we can go ahead and remove it, now. Patch attached.
(And there was, hopefully, much rejoicing.)
--
Robert Haas
EnterpriseDB: http://www.enterpr
Robert Haas writes:
> OK, so GetActiveSnapshot()?
Works for me.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Jul 23, 2013 at 2:24 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jul 23, 2013 at 12:28 PM, Tom Lane wrote:
>>> As far as get_actual_variable_range() is concerned, an MVCC snapshot
>>> would probably be the thing to use anyway;
>
>> That surprises me, though. I really thought th
Robert Haas writes:
> On Tue, Jul 23, 2013 at 12:28 PM, Tom Lane wrote:
>> As far as get_actual_variable_range() is concerned, an MVCC snapshot
>> would probably be the thing to use anyway;
> That surprises me, though. I really thought the point was to cost the
> index scan, and surely that wil
On Tue, Jul 23, 2013 at 12:28 PM, Tom Lane wrote:
> Robert Haas writes:
>>> 2. snapshot-self-not-now-v1.patch changes several uses of SnapshotNow
>>> to use SnapshotSelf instead. These include pgrowlocks(),
>>> pgstat_heap(), and get_actual_variable_range().
>
>> Tom proposed that we use Snapsho
Robert Haas writes:
>> 2. snapshot-self-not-now-v1.patch changes several uses of SnapshotNow
>> to use SnapshotSelf instead. These include pgrowlocks(),
>> pgstat_heap(), and get_actual_variable_range().
> Tom proposed that we use SnapshotDirty for this case; let me just ask
> whether there are
On Thu, Jul 18, 2013 at 8:46 AM, Robert Haas wrote:
> There seems to be a consensus that we should try to get rid of
> SnapshotNow entirely now that we have MVCC catalog scans, so I'm
> attaching two patches that together come close to achieving that goal:
>
> 1. snapshot-error-v1.patch introduces
On Fri, Jul 19, 2013 at 1:20 PM, Alvaro Herrera
wrote:
>> 4. If we use GetActiveSnapshot, all the comments about about a fresh
>> MVCC snapshot still apply. However, the snapshot in question could be
>> even more stale, especially in repeatable read or serializable mode.
>> However, this might be
(2013/07/20 1:11), Tom Lane wrote:
> Andres Freund writes:
>> On 2013-07-20 00:49:11 +0900, Hiroshi Inoue wrote:
>>> Using SnapshotSelf instead of SnapshotNow for currtid_ () wouldn't
>>> matter.
>
>> I think it actually might. You could get into dicey situations if you
>> use currtid_ in a query
Robert Haas escribió:
> 4. If we use GetActiveSnapshot, all the comments about about a fresh
> MVCC snapshot still apply. However, the snapshot in question could be
> even more stale, especially in repeatable read or serializable mode.
> However, this might be thought a more consistent behavior t
On Fri, Jul 19, 2013 at 12:51 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Fri, Jul 19, 2013 at 12:29 PM, Alvaro Herrera
>> wrote:
>
>> > I think seeing otherwise invisible rows is useful in pgrowlocks. It
>> > helps observe the effects on tuples written by concurrent transactions
>>
Robert Haas escribió:
> On Fri, Jul 19, 2013 at 12:29 PM, Alvaro Herrera
> wrote:
> > I think seeing otherwise invisible rows is useful in pgrowlocks. It
> > helps observe the effects on tuples written by concurrent transactions
> > during experimentation. But then, maybe this functionality bel
On Fri, Jul 19, 2013 at 12:29 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Fri, Jul 19, 2013 at 1:27 AM, Tom Lane wrote:
>
>> > Why not tell people to use SnapshotDirty if they need a
>> > not-guaranteed-consistent result? At least then it's pretty obvious
>> > that you're getting som
Robert Haas escribió:
> On Fri, Jul 19, 2013 at 1:27 AM, Tom Lane wrote:
> > Why not tell people to use SnapshotDirty if they need a
> > not-guaranteed-consistent result? At least then it's pretty obvious
> > that you're getting some randomness in with your news.
> On further reflection, I thin
On 2013-07-20 00:49:11 +0900, Hiroshi Inoue wrote:
> (2013/07/18 21:46), Robert Haas wrote:
> >There seems to be a consensus that we should try to get rid of
> >SnapshotNow entirely now that we have MVCC catalog scans, so I'm
> >attaching two patches that together come close to achieving that goal:
(2013/07/18 21:46), Robert Haas wrote:
There seems to be a consensus that we should try to get rid of
SnapshotNow entirely now that we have MVCC catalog scans, so I'm
attaching two patches that together come close to achieving that goal:
...
With that done, the only remaining uses of Snapshot
Andres Freund writes:
> On 2013-07-20 00:49:11 +0900, Hiroshi Inoue wrote:
>> Using SnapshotSelf instead of SnapshotNow for currtid_ () wouldn't
>> matter.
> I think it actually might. You could get into dicey situations if you
> use currtid_ in a query performing updates or inserts because it wo
On 2013-07-19 01:27:41 -0400, Tom Lane wrote:
> Noah Misch writes:
> > To me, the major advantage of removing SnapshotNow is to force all
> > third-party code to reevaluate. But that could be just as well
> > achieved by renaming it to, say, SnapshotImmediate. If there are
> > borderline-legitim
On Fri, Jul 19, 2013 at 1:27 AM, Tom Lane wrote:
> Noah Misch writes:
>> To me, the major advantage of removing SnapshotNow is to force all
>> third-party code to reevaluate. But that could be just as well
>> achieved by renaming it to, say, SnapshotImmediate. If there are
>> borderline-legitim
Noah Misch writes:
> To me, the major advantage of removing SnapshotNow is to force all
> third-party code to reevaluate. But that could be just as well
> achieved by renaming it to, say, SnapshotImmediate. If there are
> borderline-legitimate SnapshotNow uses in our code base, I'd lean
> toward
On Thu, Jul 18, 2013 at 08:46:48AM -0400, Robert Haas wrote:
> 1. snapshot-error-v1.patch introduces a new special snapshot, called
> SnapshotError. In the cases where we set SnapshotNow as a sort of
> default snapshot, this patch changes the code to use SnapshotError
> instead. This affects scan
There seems to be a consensus that we should try to get rid of
SnapshotNow entirely now that we have MVCC catalog scans, so I'm
attaching two patches that together come close to achieving that goal:
1. snapshot-error-v1.patch introduces a new special snapshot, called
SnapshotError. In the cases w
34 matches
Mail list logo
