On 2018-Jun-15, Alvaro Herrera wrote:
> By the way, why do we need to strlen() the target buffer when strlcpy
> already reports the length? (You could argue that there is a difference
> if the string is truncated ... but surely we don't care about that case)
> I propose the attached.
I decided n
Hi Alvaro,
>> There was a slight oversight in the twophase_gid length calculation in
>> the XactLogCommitRecord() code path in the cf5a1890592 commit. The
>> corresponding XactLogAbortRecord() code path was ok. PFA, a small
>> patch to fix the oversight.
>
> Forgot to add: maybe it would be usefu
By the way, why do we need to strlen() the target buffer when strlcpy
already reports the length? (You could argue that there is a difference
if the string is truncated ... but surely we don't care about that case)
I propose the attached.
--
Álvaro Herrerahttps://www.2ndQuadrant.
On 2018-Jun-14, Nikhil Sontakke wrote:
> There was a slight oversight in the twophase_gid length calculation in
> the XactLogCommitRecord() code path in the cf5a1890592 commit. The
> corresponding XactLogAbortRecord() code path was ok. PFA, a small
> patch to fix the oversight.
Forgot to add: may
On 2018-Jun-14, Nikhil Sontakke wrote:
> There was a slight oversight in the twophase_gid length calculation in
> the XactLogCommitRecord() code path in the cf5a1890592 commit. The
> corresponding XactLogAbortRecord() code path was ok. PFA, a small
> patch to fix the oversight.
Thanks, pushed.
-
Hi Heikki,
>
> Pushed, thanks for the review!
>
There was a slight oversight in the twophase_gid length calculation in
the XactLogCommitRecord() code path in the cf5a1890592 commit. The
corresponding XactLogAbortRecord() code path was ok. PFA, a small
patch to fix the oversight.
Regards,
Nikhil
On 10/04/18 03:24, Michael Paquier wrote:
+ /* twophase_gid follows if XINFO_HAS_GID. As a null-terminated string. */
+ /* xl_xact_origin follows if XINFO_HAS_ORIGIN, stored unaligned! */
Worth mentioning that the first one is also unaligned with your patch?
Hmm. 'twophase_gid' is actually
On Mon, Apr 09, 2018 at 03:30:39PM +0300, Heikki Linnakangas wrote:
> There seems to be some confusion on the padding here. Firstly, what's the
> point of zero-padding the GID length to the next MAXALIGN boundary, which
> would be 8 bytes on 64-bit systems, if the start is only guaranteed 4-byte
>
On 28/03/18 19:47, Simon Riggs wrote:
Store 2PC GID in commit/abort WAL recs for logical decoding
This forgot to update the comments in xl_xact_commit and xl_xact_abort,
for the new fields.
+
+ if (parsed->xinfo & XACT_XINFO_HAS_GID)
+ {
+ i
