From: 鈴木 幸市 <ko...@in...> - 2013-08-02 01:35:15
|
Thank you Michael for the input. DEBUG2 message level will get some more information on execution of barrier. You may have enormous amount of other messages in the log too though. Regards; --- Koichi Suzuki On 2013/08/02, at 9:02, Michael Paquier <mic...@gm...> wrote: > > > > On Thu, Aug 1, 2013 at 5:20 PM, 上泉 英二 <uwa...@as...> wrote: > Coordinator1 outputs a log of BARRIER. > ------------------------------------------ > 2013-08-01 14:31:58 JST [local] postgres postgres 100116 41DEBUG: 00000: CREATE BARRIER request received > ... > omission > ... > 2013-08-01 14:31:58 JST [local] postgres postgres 100116 63DEBUG: 00000: Successfully completed CREATE BARRIER <barrier01> END command on all nodes > ------------------------------------------ > > Coordinator2 and Datanode1,2 doesn't outputs a log of BARRIER. > Those messages inform you that the BARRIER has been correctly created on *all* the nodes, and not on each node individually. So having this message only on the Coordinator from which the sql has been launched is perfectly fine. CREATE BARRIER just adds an xlog record to mark the barrier consistently on the remote nodes, and Postgres does not log any messages when adding an XLOG record each time even for other things like checkpoints. IMO, in this feature it would not make much sense to add a log message that a local barrier has been created on remote nodes except for debugging, the essential point being that you are sure that barrier has been created on *all* the nodes. Even if the coordinator you used for hte barrier creation goes down, I highly doubt that a user would be crazy enough to take the time to look at the logs of all the Datanodes to see if a given barrier record has been created correctly everywhere. You would simply re-run the command until it succeeds. > > Thoughts about the addition of a debug message? > -- > Michael > ------------------------------------------------------------------------------ > Get your SQL database under version control now! > Version control is standard for application code, but databases havent > caught up. So what steps can you take to put your SQL databases under > version control? Why should you start doing it? Read more to find out. > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk_______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers |