On Wed, Dec 26, 2018 at 1:21 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > One thing we'd have to think about if we want to take this seriously > is whether a process-wide PRNG state is really adequate; if you're > trying to make a particular call site be deterministic, you'd likely > wish it weren't interfered with by other call sites. On the flip > side, having more call sites probably makes things more random and > thus better for normal usage. Not sure how to resolve that tension > (but I don't want to build a whole lot of new infrastructure here).
I don't think that you need to resolve the tension -- I'd be fine with continuing to have a process-wide PRNG that was cordoned-off for internal use. I care about making behavior deterministic when running an SQL script within a single backend. This can only be expected to work when all inputs (non-random and random alike) are carefully accounted for, including even the mutation of a seed value as the test case runs. I also found myself disabling synchronized sequential scanning within the same test case I mentioned, because they caused false positive failures very occasionally. I can imagining a similar test case where the tester has to worry about autovacuum running ANALYZE, too (as it happens, these were all INSERT ... SELECT statements, where that didn't seem to be an issue). Trying to reason about the behavior of a call site in isolation seems way too complicated to be practical. In general, there will never be a standard way to think about this kind of debugging, and it would be unreasonable to insist on providing any kind of standard framework. It's a low-level tool, useful only to backend hackers. -- Peter Geoghegan
