From: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17368: Assert failed in GetSafeSnapshot() for SERIALIZABLE READ ONLY DEFERRABLE transaction |
Date: | 2023-03-09 09:00:00 |
Message-ID: | 77a67fa9-9c69-d1e8-2b83-15b27e11ccf7@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
09.03.2023 07:39, Thomas Munro wrote:
> Pushed, without that test.
>
> I realised that the test would not be stable in the build farm. If we
> made the lock timeout high, the test would be slow, but if we made it
> low, then there would be two possible outputs depending on a race, and
> 10ms as you had it seems -- I guess? -- likely to be unstable under
> valgrind or an RPi2 or something. There is probably some clever way
> to write a different test schedule, but the new code is exercised by
> existing tests, and the assertion has been failing once every couple
> of days on CI since I started collecting that data a few weeks ago, so
> we have some kind of coverage, at least for master.
I had thought that we can use the same timeout that can be seen in
a couple of other tests, but now I see that those tests don't depend
on it directly/have outweighing timeouts, so I completely agree, that
the test proposed is not elaborated enough to be committed.
Thank you!
Best regards,
Alexander
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2023-03-09 09:10:58 | BUG #17826: An assert failed in /src/backend/optimizer/util/var.c |
Previous Message | Thomas Munro | 2023-03-09 04:39:24 | Re: BUG #17368: Assert failed in GetSafeSnapshot() for SERIALIZABLE READ ONLY DEFERRABLE transaction |