From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Robins Tharakan <tharakan(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, "Tharakan, Robins" <tharar(at)amazon(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Why is parula failing? |
Date: | 2024-04-17 01:34:48 |
Message-ID: | CAApHDvpV_6SVv+EbuZexmx=8ZiXqPJkC1V3z+OCUQAKXgtPSWA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 16 Apr 2024 at 18:58, Robins Tharakan <tharakan(at)gmail(dot)com> wrote:
> The last 25 consecutive runs have passed [1] after switching
> REL_12_STABLE to -O0 ! So I am wondering whether that confirms that
> the compiler version is to blame, and while we're still here,
> is there anything else I could try?
I don't think it's conclusive proof that it's a compiler bug. -O0
could equally just have changed the timing sufficiently to not trigger
the issue.
It might be a long shot, but I wonder if it might be worth running a
workload such as:
psql -c "create table a (a int primary key, b text not null, c int not
null); insert into a values(1,'',0);" postgres
echo "update a set b = repeat('a', random(1,10)), c=c+1 where a = 1;"
> bench.sql
pgbench -n -t 12500 -c 8 -j 8 -f bench.sql postgres
psql -c "table a;" postgres
On a build with the original CFLAGS. I expect the value of "c" to be
100k after running that. If it's not then something bad has happened.
That would exercise the locking code heavily and would show us if any
updates were missed due to locks not being correctly respected or seen
by other backends.
David
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2024-04-17 02:36:09 | Re: An improved README experience for PostgreSQL |
Previous Message | John Naylor | 2024-04-17 00:21:58 | Re: cpluspluscheck/headerscheck require build in REL_16_STABLE |