From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [RFC] Removing "magic" oids |
Date: | 2019-07-07 17:00:35 |
Message-ID: | 20190707170035.GA1485546@rfd.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Nov 20, 2018 at 01:20:04AM -0800, Andres Freund wrote:
> On 2018-11-14 21:02:41 -0800, Andres Freund wrote:
> > On 2018-11-15 04:57:28 +0000, Noah Misch wrote:
> > > On Wed, Nov 14, 2018 at 12:01:52AM -0800, Andres Freund wrote:
> > > > - one pgbench test tested concurrent insertions into a table with
> > > > oids, as some sort of stress test for lwlocks and spinlocks. I *think*
> > > > this doesn't really have to be a system oid column, and this was just
> > > > because that's how we triggered a bug on some machine. Noah, do I get
> > > > this right?
> > >
> > > The point of the test is to exercise OidGenLock by issuing many parallel
> > > GetNewOidWithIndex() and verifying absence of duplicates. There's nothing
> > > special about OidGenLock, but it is important to use an operation that takes a
> > > particular LWLock many times, quickly. If the test query spends too much time
> > > on things other than taking locks, it will catch locking races too rarely.
> >
> > Sequences ought to do that, too. And if it's borked, we'd hopefully see
> > unique violations. But it's definitely not a 1:1 replacement.
> I've tested this on ppc. Neither the old version nor the new version
> stress test spinlocks sufficiently to error out with weakened spinlocks
> (not that surprising, there are no spinlocks in any hot path of either
> workload). Both versions very reliably trigger on weakened lwlocks. So I
> think we're comparatively good on that front.
I tested this on xlc, the compiler that motivated the OID test, and the v12+
version of the test didn't catch the bug[1] with xlc 13.1.3. CREATE TYPE
... AS ENUM generates an OID for each label, so the attached patch makes the
v12+ test have locking behavior similar to its v11 ancestor.
[1] https://postgr.es/m/flat/a72cfcb0-37d0-de2f-b3ec-f38ad8d6a8cc(at)postgrespro(dot)ru
Attachment | Content-Type | Size |
---|---|---|
lwlock-test-v1.patch | text/plain | 1.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2019-07-07 19:05:26 | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS) |
Previous Message | Tom Lane | 2019-07-07 15:26:04 | Re: Switching PL/Python to Python 3 by default in PostgreSQL 12 |