Peter Eisentraut writes:
> On mån, 2012-05-14 at 15:11 -0400, Tom Lane wrote:
>> (In any case, my primary beef at the moment is not with whether it's a
>> good idea to change age()'s behavior going forward, but rather with
>> having back-patched such a change.)
> Certainly we should leave it alo
On 14 May 2012 20:05, Peter Eisentraut wrote:
> On lör, 2012-05-12 at 12:59 -0400, Tom Lane wrote:
>> Now it's entirely likely that there is nobody out there relying on
>> such a thing, but nonetheless this is a compatibility break, and an
>> unnecessary one IMO. You haven't shown any convincing
On mån, 2012-05-14 at 15:11 -0400, Tom Lane wrote:
> Hm. Interesting argument, but why exactly would you expect that age()
> would work differently from, say, wall clock time? And how likely is
> it that a database that requires monitoring is going to have exactly
> zero transactions over a signi
Peter Eisentraut writes:
> On lör, 2012-05-12 at 12:59 -0400, Tom Lane wrote:
>> Now it's entirely likely that there is nobody out there relying on
>> such a thing, but nonetheless this is a compatibility break, and an
>> unnecessary one IMO. You haven't shown any convincing reason why we
>> nee
On lör, 2012-05-12 at 12:59 -0400, Tom Lane wrote:
> Now it's entirely likely that there is nobody out there relying on
> such a thing, but nonetheless this is a compatibility break, and an
> unnecessary one IMO. You haven't shown any convincing reason why we
> need to change the behavior of age()
On 12 May 2012 17:59, Tom Lane wrote:
> Simon Riggs writes:
>> On 12 May 2012 15:55, Tom Lane wrote:
>>> Simon Riggs writes:
Case (2) is more complex than described. If we use XID always, then
the so-say stable value could change mid way through a scan when the
XID is assigned an
Simon Riggs writes:
> On 12 May 2012 15:55, Tom Lane wrote:
>> Simon Riggs writes:
>>> Case (2) is more complex than described. If we use XID always, then
>>> the so-say stable value could change mid way through a scan when the
>>> XID is assigned and would provide neither a stable, sensible nor
On 12 May 2012 15:55, Tom Lane wrote:
> Simon Riggs writes:
>> Case (2) is more complex than described. If we use XID always, then
>> the so-say stable value could change mid way through a scan when the
>> XID is assigned and would provide neither a stable, sensible nor a
>> backwards compatible
Simon Riggs writes:
> Case (2) is more complex than described. If we use XID always, then
> the so-say stable value could change mid way through a scan when the
> XID is assigned and would provide neither a stable, sensible nor a
> backwards compatible response.
No, that's entirely wrong. The or
On 11 May 2012 19:17, Tom Lane wrote:
> Robert Haas writes:
>
> It's arguable that what we should do is "use XID if on master, capture
> ReadNewTransactionId if on slave", which would avoid any backwards
> incompatibility for the first two cases while still fixing the case that
> everybody agrees
On Fri, May 11, 2012 at 2:17 PM, Tom Lane wrote:
> The merit would be in keeping the function's definition simple.
True. It's not *much* simpler, but it is simpler.
> Anyway, let's see if breaking this down by cases clarifies anything.
> As I see it, there are three possible cases:
>
> 1. On ma
Robert Haas writes:
> ... I don't really see any particular merit in removing our own
> XID from the picture entirely: that changes the behavior more
> significantly for no particular benefit.
The merit would be in keeping the function's definition simple.
Anyway, let's see if breaking this down
On Fri, May 11, 2012 at 1:28 PM, Tom Lane wrote:
> I'm not convinced this is the best thing, and I'm definitely not happy
> with changing the behavior of working cases (ie, behavior on the master)
> in the back branches.
>
> Anybody else have an opinion on this?
I agree with you. Essentially, if
Simon Riggs writes:
> On 11 May 2012 17:13, Tom Lane wrote:
>> Hm. This fixes the stability-within-transaction problem, but it's also
>> introduced a change in the definition of age(), no?
> Yeh, I thought about that.
> The likely difference between the old and the new result is likely to
> be
On 11 May 2012 17:13, Tom Lane wrote:
> Simon Riggs writes:
>> Ensure age() returns a stable value rather than the latest value
>
> Hm. This fixes the stability-within-transaction problem, but it's also
> introduced a change in the definition of age(), no? Previously, in an
> xact that had an X
15 matches
Mail list logo
