| From: | Noah Misch <noah(at)leadboat(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: valgrind versus pg_atomic_init() |
| Date: | 2020-06-17 04:01:21 |
| Message-ID: | 20200617040121.GA2917395@rfd.leadboat.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jun 16, 2020 at 08:35:58PM -0700, Andres Freund wrote:
> On June 16, 2020 8:24:29 PM PDT, Noah Misch <noah(at)leadboat(dot)com> wrote:
> >Suppose the initializing process does:
> >
> > pg_atomic_init_u64(&somestruct->atomic, 123);
> > somestruct->atomic_ready = true;
> >
> >In released versions, any process observing atomic_ready==true will
> >observe
> >the results of the pg_atomic_init_u64(). After the commit from this
> >thread,
> >that's no longer assured.
>
> Why did that hold true before? There wasn't a barrier in platforms already (wherever we know what 64 bit reads/writes have single copy atomicity).
You are right. It didn't hold before.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2020-06-17 04:02:49 | Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions |
| Previous Message | Tom Lane | 2020-06-17 03:47:58 | Re: valgrind versus pg_atomic_init() |