Michael Paquier wrote: > Thanks Álvaro for pushing the patch. I had a second look and the > result looks good to me. > > - SpinLockAcquire(&walsnd->mutex); > + } > + pid = walsnd->pid; > The WAL receiver code used a cast to (int) in > pg_stat_get_wal_receiver(). I don't recall adding it.
I added it because it made me a bit nervous to pass a pid_t to DatumGetInt32. This one is assigning to a variable of type pid_t, so it doesn't need a cast. I'm not too clear on using pid_t variables as int32 Datum-packed variables. We don't do it a lot in the backend code (I found some occurrences in contrib, but these don't inspire me a lot of confidence.) > Why not being consistent for both by removing the one of the WAL > receiver code? I can't think of any reason to remove that cast. It serves as documentation if nothing else -- it alerts the reader that something is going on. > > In passing, clean up some leftover braces which were used to create > > unconditional blocks. Once upon a time these were used for > > volatile-izing accesses to those shmem structs, which is no longer > > required. Many other occurrences of this pattern remain. > > Here are the places where a cleanup can happen: > - WalSndSetState > - ProcessStandbyReplyMessage > - XLogRead, 2 places > - XLogSendLogical > - WalRcvWaitForStartPosition > - WalRcvDie > - XLogWalRcvFlush > - ProcessWalSndrMessage > In most of the places of the WAL sender, braces could be removed to > improve the style. For the WAL receiver, declarations are not > necessary. As a matter of style, why not cleaning up just the WAL > sender stuff? Changing the WAL receiver code just to remove some > declarations would not improve readability, and would make back-patch > more difficult. I think we should clean this up whenever we're modifying the surrounding code, but otherwise we can leave well enough alone. It's not a high priority item at any rate. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
