From: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> |
---|---|
To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Cc: | michael(at)paquier(dot)xyz, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Session WAL activity |
Date: | 2019-12-11 09:37:57 |
Message-ID: | 3c569427-e9ad-6b63-d5df-d625a71fc8a1@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11.12.2019 7:26, Kyotaro Horiguchi wrote:
>
> Still I'm not sure non-atomic write is acceptable, but I agree on the
> necessity of updating it during a transaction. Couldn't we update
> shared stats every n bytes (XLOG_BLCKSZ or such) or every command end?
>
> I think we should refrain from inserting an instruction within the
> WALInsertLock section, but I'm not sure which is better between "var
> += var" within the section and "if (inserted) var += var;" outside. If
> we can ignore the possitbility of the case where xlogswitch is
> omitted, the "if (inserted)" is not needed.
I think that 32-bit Postgres installations are really exotic, but I
agree that showing incorrect result (even with very small probability)
is not acceptable behavior in this case. I attached new versoin of the
patch with use pg_atomic_write_u64 for updating walWritten field.
As far as at 64-bit systems, pg_atomic_write_u64and pg_atomic_read_u64
are translated to ordinary memory access, them should not have some
negative
impact on performance.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Attachment | Content-Type | Size |
---|---|---|
wal_activity-2.patch | text/x-patch | 4.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Khandekar | 2019-12-11 10:46:43 | Re: logical decoding : exceeded maxAllocatedDescs for .spill files |
Previous Message | ROS Didier | 2019-12-11 08:54:45 | RE: get_database_name() from background worker |