I wrote:
> * Given that the idea is to ignore already-committed entries, it makes
> sense that if LISTEN is called inside a serializable transaction block
> then the cutoff ought to be the transaction's snapshot. Otherwise we'd
> be dropping notifications from transactions that the calling session
Mark Dilger writes:
> On 11/22/19 3:25 PM, Tom Lane wrote:
>> An alternative idea is to use some other way of getting a snapshot
>> in asyncQueueReadAllNotifications, one that always gets a current
>> snapshot and doesn't enter predicate.c. But that might have semantic
>> consequences on the timi
On 11/22/19 3:25 PM, Tom Lane wrote:
I wrote:
Mark Dilger writes:
`git bisect` shows the problem occurs earlier than that, and by
chance the first bad commit was one of yours. I'm not surprised
that your commit was regarding LISTEN/NOTIFY, as the error is
always triggered with a LISTEN sta
I wrote:
> Mark Dilger writes:
>> `git bisect` shows the problem occurs earlier than that, and by
>> chance the first bad commit was one of yours. I'm not surprised
>> that your commit was regarding LISTEN/NOTIFY, as the error is
>> always triggered with a LISTEN statement. (I've now hit this
>>
On 11/22/19 11:22 AM, Mark Dilger wrote:
predicate.c was changed a few times after REL_12_STABLE was
branched from master but before Thomas's change that you
initially thought might be to blame. I checked whether
rolling back the changes in predicate.c while keeping your
LISTEN/NOTIFY changes
On 11/22/19 11:07 AM, Tom Lane wrote:
Mark Dilger writes:
On 11/21/19 8:03 PM, Tom Lane wrote:
I also confirm that it only happens in HEAD, not v12. I've not
actually bisected, but a look at the git history for predicate.c
sure makes it look like db2687d1f ("Optimize PredicateLockTuple")
m
Mark Dilger writes:
> On 11/21/19 8:03 PM, Tom Lane wrote:
>> I also confirm that it only happens in HEAD, not v12. I've not
>> actually bisected, but a look at the git history for predicate.c
>> sure makes it look like db2687d1f ("Optimize PredicateLockTuple")
>> must be to blame.
> `git bisect
On 11/21/19 8:03 PM, Tom Lane wrote:
Mark Dilger writes:
I have winnowed down the test a bit further. The attached
smaller patch still triggers the same assertion as the prior
patch did.
FWIW, I can reproduce the assertion failure with your first test,
but not with this simplified one.
Mark Dilger writes:
> I have winnowed down the test a bit further. The attached
> smaller patch still triggers the same assertion as the prior
> patch did.
FWIW, I can reproduce the assertion failure with your first test,
but not with this simplified one.
I also confirm that it only happens in
On 11/21/19 6:20 PM, Mark Dilger wrote:
Hackers,
I stumbled upon an assertion while testing master for possible
bugs. I am reporting it here in the hope that this report will
be useful. The attached small regression test patch consistently
triggers an assert in predicate.c:
TRAP: FailedA
Hackers,
I stumbled upon an assertion while testing master for possible
bugs. I am reporting it here in the hope that this report will
be useful. The attached small regression test patch consistently
triggers an assert in predicate.c:
TRAP: FailedAssertion("!isCommit ||
SxactIsPrepared(MySe
11 matches
Mail list logo
