On Sun, Aug 7, 2016 at 5:46 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Aug 7, 2016 at 2:03 PM, Tom Lane wrote:
>>> What I suggested just now in <2850.1470592...@sss.pgh.pa.us> might
>>> be implementable with a couple hours' work, though. Do you have a
>>> reason to think it'd be insuf
Robert Haas writes:
> On Sun, Aug 7, 2016 at 2:03 PM, Tom Lane wrote:
>> What I suggested just now in <2850.1470592...@sss.pgh.pa.us> might
>> be implementable with a couple hours' work, though. Do you have a
>> reason to think it'd be insufficient?
> No - if you can implement that quickly, I t
Robert Haas writes:
> On Sun, Aug 7, 2016 at 2:03 PM, Tom Lane wrote:
>> What I suggested just now in <2850.1470592...@sss.pgh.pa.us> might
>> be implementable with a couple hours' work, though. Do you have a
>> reason to think it'd be insufficient?
> No - if you can implement that quickly, I t
On Sun, Aug 7, 2016 at 2:03 PM, Tom Lane wrote:
> Robert Haas writes:
>> So I think in the short term what we should do about this is just fix
>> it so it doesn't crash.
>
> Well, we clearly need to fix GetOldestSnapshot so it won't crash,
> but I do not think that having RETURNING queries random
On Sun, Aug 7, 2016 at 1:57 PM, Tom Lane wrote:
> Andrew Gierth writes:
>> In a similar case in the past involving holdable cursors, the solution
>> was to detoast _before_ storing in the tuplestore (see
>> PersistHoldablePortal). I guess the question now is, under what
>> circumstances is it now
Robert Haas writes:
> So I think in the short term what we should do about this is just fix
> it so it doesn't crash.
Well, we clearly need to fix GetOldestSnapshot so it won't crash,
but I do not think that having RETURNING queries randomly returning
"ERROR: no known snapshots" is acceptable eve
On Sat, Aug 6, 2016 at 9:00 AM, Andrew Gierth
wrote:
> Hmm.
>
> So this happens because RETURNING queries run to completion immediately
> and populate a tuplestore with the results, and the portal then fetches
> from the tuplestore to send to the destination. The assumption is that
> the tuplestor
Andrew Gierth writes:
> In a similar case in the past involving holdable cursors, the solution
> was to detoast _before_ storing in the tuplestore (see
> PersistHoldablePortal). I guess the question now is, under what
> circumstances is it now allowable to detoast a datum with no active
> snapshot
> "Amit" == Amit Kapila writes:
Amit> Sure, that is the reason of crash, but even if we do that it will
Amit> lead to an error "no known snapshots". Here, what is going on is
Amit> that we initialized toast snapshot when there is no active
Amit> snapshot in the backend, so GetOldestSnaps
On Sat, Aug 6, 2016 at 5:51 PM, Andrew Gierth
wrote:
>> "Andreas" == Andreas Seltenreich writes:
>
> 418 if (OldestActiveSnapshot != NULL)
> 419 ActiveLSN = OldestActiveSnapshot->as_snap->lsn;
> 420
> 421 if (XLogRecPtrIsInvalid(RegisteredLSN) || RegisteredLSN > ActiveLSN)
> 422
> "Andreas" == Andreas Seltenreich writes:
418 if (OldestActiveSnapshot != NULL)
419 ActiveLSN = OldestActiveSnapshot->as_snap->lsn;
420
421 if (XLogRecPtrIsInvalid(RegisteredLSN) || RegisteredLSN > ActiveLSN)
422 return OldestActiveSnapshot->as_snap;
This second conditional
On Sat, Aug 6, 2016 at 6:32 PM, Andreas Seltenreich wrote:
> since updating master from c93d873..fc509cd, I see crashes in
> GetOldestSnapshot() on update/delete returning statements.
>
> I reduced the triggering statements down to this:
>
> update clstr_tst set d = d returning d;
>
> Backtrac
Hi,
since updating master from c93d873..fc509cd, I see crashes in
GetOldestSnapshot() on update/delete returning statements.
I reduced the triggering statements down to this:
update clstr_tst set d = d returning d;
Backtrace below.
regards,
Andreas
Program received signal SIGSEGV, Segment
13 matches
Mail list logo
