Re: Session WAL activity - Mailing list pgsql-hackers

From Konstantin Knizhnik
Subject Re: Session WAL activity
Date
Msg-id 3c569427-e9ad-6b63-d5df-d625a71fc8a1@postgrespro.ru
Whole thread Raw
In response to Re: Session WAL activity  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List 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

pgsql-hackers by date:

Previous
From: ROS Didier
Date:
Subject: RE: get_database_name() from background worker
Next
From: Amit Khandekar
Date:
Subject: Re: logical decoding : exceeded maxAllocatedDescs for .spill files