pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: PostgreSQL Developers <pgsql-hackers@postgresql.org>
Subject: Re: PATCH: pgbench - merging transaction logs
Date: Sat, 2 May 2015 16:30:08 -0400 (AST)
Message-ID: <alpine.DEB.2.10.1505021604170.31061@sto> (raw)
In-Reply-To: <5544F8EC.6030908@2ndquadrant.com>
References: <54FCB11B.5050907@2ndquadrant.com>
	<alpine.DEB.2.10.1503150945070.4015@sto>
	<5505CF30.7030308@2ndquadrant.com>
	<alpine.DEB.2.10.1503151935160.4015@sto>
	<CA+TgmoZAuB+ZfMhS-LSjqsyv=gA7kBjADWf_A34cUeVTrNUmVA@mail.gmail.com>
	<alpine.DEB.2.10.1503171614580.31431@sto>
	<CA+TgmoZ8eFnFeg14bhWYstRdODLHa+f+zDtPjAweOgmPkLcUww@mail.gmail.com>
	<alpine.DEB.2.10.1503201327170.12124@sto>
	<550CCBE5.8060009@2ndquadrant.com>
	<alpine.DEB.2.10.1503281016080.17117@sto>
	<551730E9.108@2ndquadrant.com>
	<alpine.DEB.2.10.1503291003160.17117@sto>
	<5519F65F.7040005@2ndquadrant.com>
	<alpine.DEB.2.10.1505020916130.8161@sto>
	<5544F8EC.6030908@2ndquadrant.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>


> It might be done in the other direction, though - the "writer" thread 
> might collect current results at the end of the interval.

Yep, you can indeed accumulate per thread and sum on the end of the 
interval, but a lock is still needed if you want exact figures.

ISTM that it is what is done for --progress, without even bothering to 
lock anything (even if transactions are fast and some inconsistency arise, 
this is just for showing how things are faring on stderr, so no big deal).

>> "fprintf" does a lot of processing, so it is the main issue.
>
> The question is whether the processing happens while holding the lock, 
> though. I don't think that's the case.

Alas I'm pretty nearly sure it is necessarily the case, there is no 
intermediate buffer in fprintf, the buffering is done trough the file 
handler so a lock must be acquire throughout format processing.

https://www.gnu.org/software/libc/manual/html_node/Streams-and-Threads.html#Streams-and-Threads

"The POSIX standard requires that by default the stream operations are 
atomic.  I.e., issuing two stream operations for the same stream in two 
threads at the same time will cause the operations to be executed as if 
they were issued sequentially. The buffer operations performed while 
reading or writing are protected from other uses of the same stream. To do 
this each stream has an internal lock object which has to be (implicitly) 
acquired before any work can be done. "

-- 
Fabien.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



view thread (31+ messages)

Message-ID: <alpine.DEB.2.10.1505021604170.31061@sto>
Permalink:  ../alpine.DEB.2.10.1505021604170.31061@sto/
Also on:    postgresql.org/message-id/alpine.DEB.2.10.1505021604170.31061@sto

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: coelho@cri.ensmp.fr, tomas.vondra@2ndquadrant.com
  Subject: Re: PATCH: pgbench - merging transaction logs
  In-Reply-To: <alpine.DEB.2.10.1505021604170.31061@sto>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox