Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1grWVN-0001st-EB for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Feb 2019 23:21:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1grWVM-0004Vm-74 for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Feb 2019 23:21:20 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1grWVL-0004Tk-Qt for pgsql-hackers@lists.postgresql.org; Wed, 06 Feb 2019 23:21:19 +0000 Received: from mail-it1-x143.google.com ([2607:f8b0:4864:20::143]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1grWVJ-0005DC-45 for pgsql-hackers@lists.postgresql.org; Wed, 06 Feb 2019 23:21:19 +0000 Received: by mail-it1-x143.google.com with SMTP id z7so10350801iti.0 for ; Wed, 06 Feb 2019 15:21:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=mf+huOO1CxAsuTFNnivtqBV6WWjI9qONUYpME34GZes=; b=W7AK56IT36SnnoXo0HFw3gRs14v6gUIqveT3ZTPmzHwwjPsroRfX5RAu4TBA9HKOzA WV0/FKOtBIpd7IqkJbabSG2U+RIHbyeLNfJsC/9Rzi6dER2jvXg0n5BN6wsEYPwlC0wZ bYFvjV2C52H8ChP3BmaesDYtHWeLE4l6wRWHy4VXnu4DQNQ4IqSQAPdwM1DBLZ8bdpj/ Fro/UkaJAySKXauqrbsc7UOwMfgsPoV9OcgsI2H6Qt+U0BPHEXPArr9sZ4PYTR0rmeng DxwBVGI9x/3AoJipZDP2eIM314Y6qnbjrdKoJfrqnxbBsu3E88HxYGkpVoBToCepSOJS +l/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=mf+huOO1CxAsuTFNnivtqBV6WWjI9qONUYpME34GZes=; b=eSGsbrBF0SKmLvZ52hYhnQFrYuHlhZIX3c26/Gs7K2IyH+0eWTBcCD+01VAMqJAG2c irhX9PT1ClKJTHjj55Lo6spdOqOIa0DaOdoYZar+E7NS24G+p8bzIm8yVq2c2lEjs5VS /IXKQd8QLwXPqncTHQi8A2d869nQ3Y56pyYt2LQ5qb9nAiYFG65e1y83NSC5dMgACY/O oABlTgUujtmUkmnS0wYLkmHvlDKP9KKhuEPRJI2XuBvhhKazdQCLb5i3QL8YzG6bbTTv iIBb49cPjspyv72i2mJO5rp8pYqcmH4eie1fKSxuPSpYWc7Vn/Xqj4w1nWDFRoBqEacU ApyA== X-Gm-Message-State: AHQUAuZhi3AkT0zRqCITbsE8Dzo9GFEohPshpsV9LtqxABMabVa7iZL4 lsI56rXH54PsHWE1iG1zKzqjOQ== X-Google-Smtp-Source: AHgI3IYYz8FfuULiTLxXTxhM8LXzCCId8vXedbhkFtMoaRuTjqwn7H2xBDKwYZyTv2CZkDoHZPzQbA== X-Received: by 2002:a05:660c:4c5:: with SMTP id v5mr3702111itk.104.1549495275345; Wed, 06 Feb 2019 15:21:15 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id l186sm4387958itl.22.2019.02.06.15.21.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Feb 2019 15:21:14 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id 2D80A800BD7; Wed, 6 Feb 2019 17:21:11 -0600 (CST) Date: Wed, 6 Feb 2019 17:21:11 -0600 From: Justin Pryzby To: Jakub Glapa Cc: Thomas Munro , Fabio Isabettini , Arne Roland , Sand Stone , Rick Otten , pgsql-hackers@lists.postgresql.org Subject: Re: dsa_allocate() faliure Message-ID: <20190206232110.GH29720@telsasoft.com> References: <6f3fe9fa5a984dc19e40e79fbef45edc@index.de> <6c2e8a16999f4e17b975d7369f6605b4@index.de> <45C7466A-7D67-4BB4-829C-F66CBB2961DB@voipfuture.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Moving to -hackers, hopefully it doesn't confuse the list scripts too much. On Mon, Feb 04, 2019 at 08:52:17AM +0100, Jakub Glapa wrote: > I see the error showing up every night on 2 different servers. But it's a > bit of a heisenbug because If I go there now it won't be reproducible. Do you have query logging enabled ? If not, could you consider it on at least one of those servers ? I'm interested to know what ELSE is running at the time that query failed. Perhaps you could enable query logging JUST for the interval of time that the server usually errors ? The CSV logs can be imported to postgres for analysis. You might do something like SELECT left(message,99),COUNT(1),max(session_id) FROM postgres_log WHERE log_time BETWEEN .. AND .. GROUP BY 1 ORDER BY 2; And just maybe there'd be a query there that only runs once per day which would allow reproducing the error at will. Or utility command like vacuum.. I think ideally you'd set: log_statement = all log_min_messages = info log_destination = 'stderr,csvlog' # stderr isn't important for this purpose, but I keep it set to capture crash messages, too You should set these to something that works well at your site: log_rotation_age = '2min' log_rotation_size = '32MB' I would normally set these, and I don't see any reason why you wouldn't set them too: log_checkpoints = on log_lock_waits = on log_temp_files = on log_min_error_statement = notice log_temp_files = 0 log_min_duration_statement = '9sec' log_autovacuum_min_duration = '999sec' And I would set these too but maybe you'd prefer to do something else: log_directory = /var/log/postgresql log_file_mode = 0640 log_filename = postgresql-%Y-%m-%d_%H%M%S.log Justin