On Sun, Aug 13, 2017 at 3:05 PM, Tom Lane wrote:
> Not having heard anyone arguing against that, I'll go make it so,
> ie AtEOXact_CatCache is toast in all branches.
Great, thanks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-ha
Robert Haas writes:
> On Tue, Aug 8, 2017 at 10:48 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Tue, Aug 8, 2017 at 4:34 PM, Tom Lane wrote:
In the meantime, I think my vote would be to remove AtEOXact_CatCache.
>>> In all supported branches?
>> Whatever we do about this issue, I do
Andreas Seltenreich writes:
> Tom Lane writes:
>> I wonder if Andreas would be interested in trying the randomly-timed-
>> SIGTERM thing with sqlsmith.
> So far, most of the core dumps generated are Jeevan's assertion failing
> with backtraces through SearchCatCacheList. The rest is failing this
Tom Lane writes:
> I wonder if Andreas would be interested in trying the randomly-timed-
> SIGTERM thing with sqlsmith.
So far, most of the core dumps generated are Jeevan's assertion failing
with backtraces through SearchCatCacheList. The rest is failing this
assertion:
TRAP: FailedAssertio
On Thu, Aug 10, 2017 at 9:00 PM, Robert Haas wrote:
> On Thu, Aug 10, 2017 at 2:50 AM, Andreas Seltenreich
> wrote:
>> Will do. Won't miss this chance to try out discostu's extension
>> pg_rage_terminator[1] :-)
>> [1] https://github.com/disco-stu/pg_rage_terminator
>
> Oh, that's *awesome*.
On Tue, Aug 8, 2017 at 10:48 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Aug 8, 2017 at 4:34 PM, Tom Lane wrote:
>>> In the meantime, I think my vote would be to remove AtEOXact_CatCache.
>
>> In all supported branches?
>
> Whatever we do about this issue, I don't feel a need to do it f
On Thu, Aug 10, 2017 at 2:50 AM, Andreas Seltenreich wrote:
> Will do. Won't miss this chance to try out discostu's extension
> pg_rage_terminator[1] :-)
> [1] https://github.com/disco-stu/pg_rage_terminator
Oh, that's *awesome*.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The En
Tom Lane writes:
> I wonder if Andreas would be interested in trying the randomly-timed-
> SIGTERM thing with sqlsmith.
Will do. Won't miss this chance to try out discostu's extension
pg_rage_terminator[1] :-)
regards,
Andreas
Footnotes:
[1] https://github.com/disco-stu/pg_rage_terminator
Robert Haas writes:
> On Tue, Aug 8, 2017 at 4:34 PM, Tom Lane wrote:
>> In the meantime, I think my vote would be to remove AtEOXact_CatCache.
> In all supported branches?
Whatever we do about this issue, I don't feel a need to do it further
back than HEAD. It's a non-problem except in an ass
On Tue, Aug 8, 2017 at 4:34 PM, Tom Lane wrote:
> In the meantime, I think my vote would be to remove AtEOXact_CatCache.
In all supported branches?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers
Robert Haas writes:
> On Tue, Aug 8, 2017 at 12:26 PM, Tom Lane wrote:
>> Yeah, I thought about weakening the assertions too, but I couldn't
>> see a fix of that kind that didn't seem mighty ad-hoc.
> More concretely, the present example seems no different than the
> ResourceOwner stuff emitting
On Tue, Aug 8, 2017 at 12:26 PM, Tom Lane wrote:
> Yeah, I thought about weakening the assertions too, but I couldn't
> see a fix of that kind that didn't seem mighty ad-hoc.
I don't really see what's ad-hoc about skipping it in the case where a
FATAL is in progress. I mean, skipping a sanity ch
Robert Haas writes:
> On Tue, Aug 8, 2017 at 11:36 AM, Tom Lane wrote:
>> We could respond to this by using PG_ENSURE_ERROR_CLEANUP there instead
>> of plain PG_TRY. But I have an itchy feeling that there may be a lot
>> of places with similar issues. Should we be revisiting the basic way
>> th
On Tue, Aug 8, 2017 at 11:36 AM, Tom Lane wrote:
>> By looking at the stack-trace, and as discussed it with my team members;
>> what we have observed that in SearchCatCacheList(), we are incrementing
>> refcount and then decrementing it at the end. However for some reason, if
>> we are in TRY() bl
Jeevan Chalke writes:
> We have observed a random server crash (FailedAssertion), while running few
> tests at our end. Stack-trace is attached.
> By looking at the stack-trace, and as discussed it with my team members;
> what we have observed that in SearchCatCacheList(), we are incrementing
> r
Hi,
We have observed a random server crash (FailedAssertion), while running few
tests at our end. Stack-trace is attached.
By looking at the stack-trace, and as discussed it with my team members;
what we have observed that in SearchCatCacheList(), we are incrementing
refcount and then decrementin
16 matches
Mail list logo
