Re: Failures in constraints regression test, "read only 0 of 8192 bytes"
От | Tomas Vondra |
---|---|
Тема | Re: Failures in constraints regression test, "read only 0 of 8192 bytes" |
Дата | |
Msg-id | 05fd672f-2eac-4758-91e9-fa7afafa147e@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Failures in constraints regression test, "read only 0 of 8192 bytes" (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: Failures in constraints regression test, "read only 0 of 8192 bytes"
|
Список | pgsql-hackers |
On 3/8/24 21:29, Thomas Munro wrote: > On Sat, Mar 9, 2024 at 2:36 AM Tomas Vondra > <tomas.vondra@enterprisedb.com> wrote: >> On 3/8/24 13:21, Tomas Vondra wrote: >>> My guess would be 8af25652489, as it's the only storage-related commit. >>> >>> I'm currently running tests to verify this. >>> >> >> Yup, the breakage starts with this commit. I haven't looked into the >> root cause, or whether the commit maybe just made some pre-existing >> issue easier to hit. Also, I haven't followed the discussion on the >> pgsql-bugs thread [1], maybe there are some interesting findings. > > Adding Heikki. I spent a bit of time investigating this today, but haven't made much progress due to (a) my unfamiliarity with the smgr code in general and the patch in particular, and (b) CLOBBER_CACHE_ALWAYS making it quite time consuming to iterate and experiment. However, the smallest schedule that still reproduces the issue is: ------------------- test: test_setup test: create_aggregate create_function_sql create_cast constraints triggers select inherit typed_table vacuum drop_if_exists updatable_views roleattributes create_am hash_func errors infinite_recurse ------------------- I tried to reduce the second step to just "constraints", but that does not fail. Clearly there's some concurrency at play, and having just a single backend makes that go away. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: