Re: Session WAL activity

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

In response to

Browse pgsql-hackers by date

  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