Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n7BwG-00006n-0o for pgsql-hackers@arkaria.postgresql.org; Tue, 11 Jan 2022 07:51:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1n7BwE-0003QP-TO for pgsql-hackers@arkaria.postgresql.org; Tue, 11 Jan 2022 07:51:26 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n7BwD-0003Mp-Ot for pgsql-hackers@lists.postgresql.org; Tue, 11 Jan 2022 07:51:26 +0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n7BwA-0004ka-Rt for pgsql-hackers@postgresql.org; Tue, 11 Jan 2022 07:51:24 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id B317E5C00C6; Tue, 11 Jan 2022 02:51:20 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 11 Jan 2022 02:51:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=22KYwFjbPlE1lrnUsMAMSUupyig J1mmNaM4wxMb8W6Y=; b=aopi1WQcfwGohrMpAZ2pfBaIM0tBVYQFdP00FrJKNPw IEPDLvuyNMFmCDPEECTfuGlMivMCbz3AtJutBMnzFiIhmwpRbP/C70ZlaD+qL6kj J37nk8IkfX0WRIdMJWqm7b8ps7VkeBy1K7EfzFdyZDcr9Xt6uJ8Y4EQ2/aJxchU7 Ke+htZdfdDaLx7Z46jRaaE0bOScf4IhDyHI1UO74/S+7KMeZDrh0d47M9UGbkRg6 jpaQ9lRsM8tjKwCyI4RYpFs47Wu5rcXZzeAb8lw+7uxiZo2p51XPPdSwRdvS/GfG uHtawTMH3EZG2GHeuaePfM8ZP7KLkNsAR+8IeuT80SQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=22KYwF jbPlE1lrnUsMAMSUupyigJ1mmNaM4wxMb8W6Y=; b=UaJBNJDJIYNgt97mQo8d6U b/rpkotoJPB3dtPllU1CXxQBLQpDgPgW+SfKxj7Aw3HKS7rTTX8YMNPTG31dYP3L +nbv6arlyNOBbs2v2+e5edWHVgzP+mkvjZrepziSJgdpqqMiann7UKfyiOXsvx2M GpRjIPmq6c1q/PBSrHDprBYT14D6f0mwNfoPqHcQQuf5OIKzld5u2CHC5iw0gcTk /AWn78G5KsH1Kt81ZdtK2eRqsNHNHTI/bIAPMPU10nPR6ytCYKl4rJSzD/A7awza wVZe/Sx+z/WfyTGJ16eT6XEaO7bttfWOyNkzMzWQfN/2xT+G7mgMWWGdRpyK41kw == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudehvddguddufecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkfhggtggujgesthdtredttddtvdenucfhrhhomheptehnughr vghsucfhrhgvuhhnugcuoegrnhgurhgvshesrghnrghrrgiivghlrdguvgeqnecuggftrf grthhtvghrnhepvdfhgfekjedugfejtdeviefgheeuueelhedugfffvddvhfevudefudej ffekteeunecuffhomhgrihhnpehmihgtrhhoshhofhhtrdgtohhmnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghnughrvghssegrnhgrrhgr iigvlhdruggv X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 11 Jan 2022 02:51:20 -0500 (EST) Date: Mon, 10 Jan 2022 23:51:19 -0800 From: Andres Freund To: Andrew Dunstan Cc: pgsql-hackers@postgresql.org, Tom Lane , Craig Ringer Subject: Re: Windows crash / abort handling Message-ID: <20220111075119.6ri6msoxv4z7fu73@alap3.anarazel.de> References: <20211005193033.tg4pqswgvu3hcolm@alap3.anarazel.de> <56014fa7-be7f-86f4-9f25-e8341342d5f5@dunslane.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56014fa7-be7f-86f4-9f25-e8341342d5f5@dunslane.net> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On 2022-01-10 10:57:00 -0500, Andrew Dunstan wrote: > On 10/5/21 15:30, Andres Freund wrote > > The above ends up dumping all crashes into a single file, but that can > > probably be improved. But cdb is so gnarly that I wanted to stop looking once > > I got this far... FWIW, I figured out how to put the dumps into separate files by now... > > Andrew, I wonder if something like this could make sense for windows BF animals? > Very possibly. I wonder how well it will work on machines where I have > more than one animal .e.g. lorikeet (cygwin) jacana (msys) and bowerbird > (MSVC) are all on the same machine. Likewise drongo (MSVC) and fairywren > (msys2). Hm. I can see a few ways to deal with it. Are they running concurrently? If not then it's easy enough to deal with. It'd be a bit of a fight with cdb's awfully documented and quirky scripting [1], but the best solution would probably be to just use an environment variable from the target process to determine the dump location. Then each buildfarm config could set a BF_BACKTRACE_LOCATION variable or such... [1] So there's !envvar. But that yields a string like BF_BACKTRACE_LOCATION = value of environment variable when set to an alias. And I haven't found an easy way to get rid of the "variablename = ". There is .foreach /pS [2] which could be used to skip over the varname =, but that then splits on all whitespaces. Gah. [2] https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/-foreach Greetings, Andres Freund