Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1riynl-002m5E-Nx for pgsql-hackers@arkaria.postgresql.org; Sat, 09 Mar 2024 15:39:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1riynk-0019lX-AD for pgsql-hackers@arkaria.postgresql.org; Sat, 09 Mar 2024 15:39:56 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1riynk-0019lP-10 for pgsql-hackers@lists.postgresql.org; Sat, 09 Mar 2024 15:39:56 +0000 Received: from mail-lj1-x230.google.com ([2a00:1450:4864:20::230]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1riynh-003dCm-VS for pgsql-hackers@postgresql.org; Sat, 09 Mar 2024 15:39:55 +0000 Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-2d2fad80eacso20627531fa.2 for ; Sat, 09 Mar 2024 07:39:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709998792; x=1710603592; darn=postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=8eAzQvZdgtUOfAwxOoLTENp0YvVdi6LuoBYwZ1t/3gA=; b=Sfy1hefxUUzAtXU75JUwHLxD+tkUwgXw3vd+mXyh4chBRGP8wuhN3Af4ZacJBv+tw5 aOCBb+QOMgrZVuwdVmjLo51ny4CNnqEPe93FsV9gov0FX2Gg2pVfMWxQ1A7V6wD8+97Q piAN8BfxFLt62vIWYmRzE96ytSV+aPmxwMchc/UOjhZXI//4UrvrT7zLDdqJebjyOWwr D7ucNESnlBzO9P6+g+tg8BOFw7BIVr9U86ySmEiCBp4qGEfY3gUaE9rSZf06lNiA42m8 NzqeAIRrLa+BQyxNC04C/8aX3in5M0R23kifp4YeRTle76yR7bkjDMKvYg73KD7i6sDn 4GgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709998792; x=1710603592; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=8eAzQvZdgtUOfAwxOoLTENp0YvVdi6LuoBYwZ1t/3gA=; b=jGZzmI8NXGXtxxOzBmqwev5obUqV5a8hkQoUut3piepNnuu504uerdBI4BVzLBn35V 3dl6Ktj9BnIg1/QxnzLhCC54mztbmtZSkgklrv9NgBOD5nyjGibgOADF0l4nQB2da2LG +KsQNlSy+JE8q2N7NsY5v9N4kWof9WUVDKqA1oD3rJE9sN7FcUCfW1y+owyiowsg4wbf cqDtO/KJaLts5xMfaTMtk3Ucm7sKrnt59J2PRfs5tSSFB1IhBxYuvKGL/lxZQY0YBs0g LknFqNNMoz7LOtphUYGw6ZPVvyXH8Viokw+F2wgCPMH4f8vvxy9fNG++84kQbNztnKXm /jsg== X-Gm-Message-State: AOJu0YxV1NSSACAjuMkMpJ7+bN60ad/TM/svKgaPoTzZVb6C0OUG+uih CxyjdkX6RRHtVK1DFOCwJCtR4pVbLW/YcH6hhC1cdm3SiSj6q7Ex+sztUivjUfAABP4F93zDFoV ttDqxgJmGkPW6sW+FSvDEbVUuSAkzzIWDuSQ= X-Google-Smtp-Source: AGHT+IG6ubiHRL3r6AEWC16qHuGU/nKsNCoETOsplcE6j2tIkt2dwbH0/rdSxZGOwnI8AYGdmC5v/j9JnlP1YdUmf8w= X-Received: by 2002:ac2:5bd1:0:b0:513:40e8:d4fc with SMTP id u17-20020ac25bd1000000b0051340e8d4fcmr1321155lfn.28.1709998791868; Sat, 09 Mar 2024 07:39:51 -0800 (PST) MIME-Version: 1.0 From: Kambam Vinay Date: Sat, 9 Mar 2024 21:09:39 +0530 Message-ID: Subject: Fix for timestamp lag issue from emit_log_hook when GUC log_line_prefix has '%m' To: pgsql-hackers@postgresql.org Content-Type: multipart/mixed; boundary="0000000000008e63ad06133c1e09" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000008e63ad06133c1e09 Content-Type: multipart/alternative; boundary="0000000000008e63ab06133c1e07" --0000000000008e63ab06133c1e07 Content-Type: text/plain; charset="UTF-8" Hi, We observed a slight lag in timestamp for a few logs from the emit_log_hook hook implementation when the log_line_prefix GUC has '%m'. Upon debugging, we found that the saved_timeval_set variable is set to 'true' in get_formatted_log_time() but is not reset to 'false' until the next call to send_message_to_server_log(). Due to this, saved_timeval_set will be true during the execution of hook emit_log_hook() which prefixes the saved timestamp 'saved_timeval' from the previous log line (our hook implementation calls log_line_prefix()). Attached patch sets the saved_timeval_set to false before executing the emit_log_hook() Thanks, Vinay --0000000000008e63ab06133c1e07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

We observed a slight la= g in timestamp for a few logs from the emit_log_hook hook implementation wh= en the log_line_prefix GUC has '%m'.

Upon debugging, we fou= nd that the saved_timeval_set variable is set to 'true' in get_form= atted_log_time() but is not reset to 'false' until the next call to= send_message_to_server_log(). Due to this, saved_timeval_set will be true = during the execution of hook emit_log_hook() which prefixes the saved times= tamp 'saved_timeval' from the previous log line (our hook implement= ation calls log_line_prefix()).

Attached patch sets the saved_timeva= l_set to false before executing the emit_log_hook()

= Thanks,
Vinay
--0000000000008e63ab06133c1e07-- --0000000000008e63ad06133c1e09 Content-Type: application/octet-stream; name="0001-set-saved_timeval_set-to-false-before-executing-emit.patch" Content-Disposition: attachment; filename="0001-set-saved_timeval_set-to-false-before-executing-emit.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_ltk9086p0 RnJvbSBjOGVjZWEyMzc1ZWUzZWM0NjExN2FjMDZiMzg0ZjM5ZGE1NjA2NzBlIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBWaW5heSBLYW1iYW0gPHZpbmF5a2FtYmFtQGdtYWlsLmNvbT4K RGF0ZTogU2F0LCA5IE1hciAyMDI0IDE5OjUyOjEwICswNTMwClN1YmplY3Q6IFtQQVRDSF0gc2V0 IHNhdmVkX3RpbWV2YWxfc2V0IHRvIGZhbHNlIGJlZm9yZSBleGVjdXRpbmcKIGVtaXRfbG9nX2hv b2soKQoKLS0tCiBzcmMvYmFja2VuZC91dGlscy9lcnJvci9lbG9nLmMgfCAxICsKIDEgZmlsZSBj aGFuZ2VkLCAxIGluc2VydGlvbigrKQoKZGlmZiAtLWdpdCBhL3NyYy9iYWNrZW5kL3V0aWxzL2Vy cm9yL2Vsb2cuYyBiL3NyYy9iYWNrZW5kL3V0aWxzL2Vycm9yL2Vsb2cuYwppbmRleCBlZDhhYTVj OWZhLi5lNzM1ZjUxMjA3IDEwMDY0NAotLS0gYS9zcmMvYmFja2VuZC91dGlscy9lcnJvci9lbG9n LmMKKysrIGIvc3JjL2JhY2tlbmQvdXRpbHMvZXJyb3IvZWxvZy5jCkBAIC0xNjk3LDYgKzE2OTcs NyBAQCBFbWl0RXJyb3JSZXBvcnQodm9pZCkKIAkgKiBtZXNzYWdlIGlkZW50aWZpZXIuIE5vdGUg dGhhdCB0aGUgb3JpZ2luYWwgdGV4dCBpcyBub3QgYXZhaWxhYmxlIGZvcgogCSAqIGRldGFpbCwg ZGV0YWlsX2xvZywgaGludCBhbmQgY29udGV4dCB0ZXh0IGVsZW1lbnRzLgogCSAqLworCXNhdmVk X3RpbWV2YWxfc2V0ID0gZmFsc2U7CiAJaWYgKGVkYXRhLT5vdXRwdXRfdG9fc2VydmVyICYmIGVt aXRfbG9nX2hvb2spCiAJCSgqZW1pdF9sb2dfaG9vaykgKGVkYXRhKTsKIAotLSAKMi4zNC4xCgo= --0000000000008e63ad06133c1e09--