Alvaro Herrera writes:
> Tom Lane wrote:
>> Will look into that too. I'm not sure that adding extra expected
>> outputs is sane, though --- might be best to just force the intended
>> isolation level within those tests.
> As I recall (not much, admittedly) that was one of the options we
> consid
Tom Lane wrote:
> *** /home/postgres/pgsql/src/test/isolation/expected/lock-update-delete_1.out
> Mon Feb 12 14:53:46 2018
> ---
> /home/postgres/pgsql/src/test/isolation/output_iso/results/lock-update-delete.out
>Wed Apr 18 11:30:23 2018
> ***
> *** 150,156
>
> t
I wrote:
>>> (A couple of the other isolation tests do fail reliably under this
>>> scenario; is it worth hardening them?)
>> Yes, I think it's worth making them pass somehow -- see commits
>> f18795e7b74c, a0eae1a2eeb6.
> Will look into that too. I'm not sure that adding extra expected
> output
Tom Lane wrote:
> Anyway, at this point I'm going to give up on the debug logging, revert
> 9.4 to its prior state, and then see if the transaction-restart patch
> makes the problem go away.
Agreed, thanks.
> >> (A couple of the other isolation tests do fail reliably under this
> >> scenario; is
I wrote:
>> It's still not entirely clear what's happening on okapi, ...
okapi has now passed two consecutive runs with elog(LOG) messages in place
between DefineIndex's snapmgr calls. Considering that it had failed 37 of
44 test runs since 47a3a13 went in, I think two successive passes is
suffic
Tom Lane wrote:
> It's still not entirely clear what's happening on okapi, but in the
> meantime I've thought of an easily-reproducible way to cause similar
> failures in any branch. That is to run CREATE INDEX CONCURRENTLY
> with default_transaction_isolation = serializable. Then, snapmgr.c
> w
I wrote:
> So we can now refine the problem statement to "SnapshotResetXmin isn't
> doing what it's supposed to". No idea why yet. 9.4 is using a simple
> RegisteredSnapshots counter which 9.5 has replaced with a pairing heap,
> so you'd think the newer code would be *more* likely to have bugs...
I wrote:
> As an investigative measure, I propose that we insert
> Assert(MyPgXact->xmin == InvalidTransactionId);
> into 9.4's DefineIndex, just after its InvalidateCatalogSnapshot call.
Well, isn't this interesting:
TRAP: FailedAssertion("!(MyPgXact->xmin == ((TransactionId) 0))", File:
Awhile back, Alvaro Herrera wrote:
>> Pushed to all affected branches, along with a somewhat lame
>> isolationtester test for the condition (since we've already broken this
>> twice and not noticed for long).
> Buildfarm member okapi just failed this test in 9.4:
okapi has continued to fail that
Alvaro Herrera wrote:
> Pushed to all affected branches, along with a somewhat lame
> isolationtester test for the condition (since we've already broken this
> twice and not noticed for long).
Buildfarm member okapi just failed this test in 9.4:
2018-01-04 02:44:43.481 PST [5a4e059a.3af1:6] ERRO
Andres Freund wrote:
> On 2017-12-26 13:31:03 -0300, Alvaro Herrera wrote:
> > It's strange that this has gone undetected for so long. I wonder if
> > there's an interaction with logical decoding and its historical
> > snapshot stuff here.
>
> I can't see how - did you have a vague theory you cou
Jeff Janes wrote:
> c3d09b3bd23f5f6 fixed it so concurrent CIC would not deadlock (or at least
> not as reliably as before) by dropping its own snapshot before waiting for
> all the other ones to go away.
>
> With commit 8aa3e47510b969354ea02a, concurrent CREATE INDEX CONCURRENTLY on
> different t
On 2017-12-26 13:31:03 -0300, Alvaro Herrera wrote:
> It's strange that this has gone undetected for so long. I wonder if
> there's an interaction with logical decoding and its historical
> snapshot stuff here.
I can't see how - did you have a vague theory you could share?
Greetings,
Andres Fre
>
> Since the purpose of CIC is to build an index with minimal impact on other
> users, I think wanting to use it in concurrent cases might be rather rare.
> In a maintenance window, I wouldn't want to use CIC because it is slower
> and I'd rather just hold the stronger lock and do it fast, and as
On Wed, Dec 27, 2017 at 8:50 AM, Jeremy Finzel wrote:
> I was able to get this compiled, and ran the test before on stock 9.6.6,
> then on this patched version. I indeed reproduced it on 9.6.6, but on the
> patched version, it indeed fixes my issue.
>
> Let me know if I can be of further help.
Jeff Janes writes:
> On Tue, Dec 26, 2017 at 8:31 AM, Alvaro Herrera <
> alvhe...@alvh.no-ip.org> wrote:
>
> Jeff Janes wrote:
> > c3d09b3bd23f5f6 fixed it so concurrent CIC would not deadlock
> (or at least
> > not as reliably as before) by dropping its own snapshot before
>
On Tue, Dec 26, 2017 at 11:23 AM, Jeff Janes wrote:
> On Tue, Dec 26, 2017 at 8:31 AM, Alvaro Herrera
> wrote:
>
>> Jeff Janes wrote:
>> > c3d09b3bd23f5f6 fixed it so concurrent CIC would not deadlock (or at
>> least
>> > not as reliably as before) by dropping its own snapshot before waiting
>>
On Tue, Dec 26, 2017 at 8:31 AM, Alvaro Herrera
wrote:
> Jeff Janes wrote:
> > c3d09b3bd23f5f6 fixed it so concurrent CIC would not deadlock (or at
> least
> > not as reliably as before) by dropping its own snapshot before waiting
> for
> > all the other ones to go away.
> >
> > With commit 8aa3e
Jeff Janes wrote:
> c3d09b3bd23f5f6 fixed it so concurrent CIC would not deadlock (or at least
> not as reliably as before) by dropping its own snapshot before waiting for
> all the other ones to go away.
>
> With commit 8aa3e47510b969354ea02a, concurrent CREATE INDEX CONCURRENTLY on
> different t
c3d09b3bd23f5f6 fixed it so concurrent CIC would not deadlock (or at least
not as reliably as before) by dropping its own snapshot before waiting for
all the other ones to go away.
With commit 8aa3e47510b969354ea02a, concurrent CREATE INDEX CONCURRENTLY on
different tables in the same database sta
20 matches
Mail list logo
