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 1iXawC-00018G-H6 for pgsql-hackers@arkaria.postgresql.org; Thu, 21 Nov 2019 01:07:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iXawB-0005o1-92 for pgsql-hackers@arkaria.postgresql.org; Thu, 21 Nov 2019 01:07:11 +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 1iXawA-0005nu-S8 for pgsql-hackers@lists.postgresql.org; Thu, 21 Nov 2019 01:07:11 +0000 Received: from mail-io1-xd44.google.com ([2607:f8b0:4864:20::d44]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iXaw7-0001J4-Ql for pgsql-hackers@postgresql.org; Thu, 21 Nov 2019 01:07:10 +0000 Received: by mail-io1-xd44.google.com with SMTP id j13so1498451ioe.0 for ; Wed, 20 Nov 2019 17:07:07 -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=PxfZDFGRhuxmJdFJ1F+AnOdpiaVl8D9FCaE81YW3EjM=; b=SDvy/9N22pP3gty5lxYObk9CIzJfIsMr81Zuf+NFVLXbL1aolVUvw5i43tnXiSEr/H 8I8sEEWBWzYmRmG/R3we1emBMPXzvyVKoI+wbp2j3SOL8ww9Cit2Jr+8vHxvviGSkb4t RV4l1BQRvJi87MyLj4uS29xBbCpPUUCfEzG5ZqGdNHsT1UKi17QAheD961zTwqjdgITR t1zhOyoLnbU7y17IyscvOn56kf3iS0Jct2Y1/S0CYMQvmZ773x+ikwLW0hx+6gubrPDV h4sbA1Mb5Yx6KbVqkVh1MuW/m2Ndy5+XGrDMOIvox877vCMJrzrUGjAZLQbHdLk77j0E 2nDA== 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=PxfZDFGRhuxmJdFJ1F+AnOdpiaVl8D9FCaE81YW3EjM=; b=tLnMGkdHC2K01r7kBAYjciw7P+oE1WrPLvKyVLKKL6LUgeioIwDP4VQZBK/JqlZBwa MaQpyOQ7hGrKOK13DQIYzi4+8LImRm7WdeaWQF/a7sbI6LoT98jTSALw3DC3/n0pCbIa VXfKP8EK2Z0Lgt5CA+FG5Iwrhc61ZDqqmY/0El3tmqXppFY4bd9ks3PYKwWVRqvzRgJY f283pBieD2Jyg3K1CgiWo2BugpKQLw62UvtdiZREGOkDdTTu/pmTOL244sIfMPh7TNT3 36KEeWrIiE9JNC61NGbre/dp5dCAkYRQ7nGnCtBSMuEJEZ5gmXafD6J6XKZ43rYH0oX0 E1qg== X-Gm-Message-State: APjAAAXGlVZa26nAvoYRVTu76+CXM42w+g40Py5IYEaOi/Z1cwKcC2vM I2/z20V21ktIrCR+R8hSDyk31A== X-Google-Smtp-Source: APXvYqwDZ9qcjAY2JRVQauMQdgRH20UoK8AMFdkbc49K4t1lcY43R80a+iRoTYfM/FX7aZs7Kv2yKA== X-Received: by 2002:a6b:b58b:: with SMTP id e133mr4954429iof.86.1574298425709; Wed, 20 Nov 2019 17:07:05 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id q69sm357931ilb.4.2019.11.20.17.07.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Nov 2019 17:07:04 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id D9197800AE5; Wed, 20 Nov 2019 19:07:03 -0600 (CST) Date: Wed, 20 Nov 2019 19:07:03 -0600 From: Justin Pryzby To: Thomas Munro Cc: pgsql-hackers@postgresql.org Subject: Re: checkpointer: PANIC: could not fsync file: No such file or directory Message-ID: <20191121010703.GF30362@telsasoft.com> References: <20191119115759.GI30362@telsasoft.com> <20191119224910.GU30362@telsasoft.com> <20191120012226.GW30362@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191120012226.GW30362@telsasoft.com> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Tue, Nov 19, 2019 at 07:22:26PM -0600, Justin Pryzby wrote: > I was trying to reproduce what was happening: > set -x; psql postgres -txc "DROP TABLE IF EXISTS t" -c "CREATE TABLE t(i int unique); INSERT INTO t SELECT generate_series(1,999999)"; echo "begin;SELECT pg_export_snapshot(); SELECT pg_sleep(9)" |psql postgres -At >/tmp/snapshot& sleep 3; snap=`sed "1{/BEGIN/d}; q" /tmp/snapshot`; PGOPTIONS='-cclient_min_messages=debug' psql postgres -txc "ALTER TABLE t ALTER i TYPE bigint" -c CHECKPOINT; pg_dump -d postgres -t t --snap="$snap" |head -44; > > Under v12, with or without the CHECKPOINT command, it fails: > |pg_dump: error: query failed: ERROR: cache lookup failed for index 0 > But under v9.5.2 (which I found quickly), without CHECKPOINT, it instead fails like: > |pg_dump: [archiver (db)] query failed: ERROR: cache lookup failed for index 16391 > With the CHECKPOINT command, 9.5.2 works, but I don't see why it should be > needed, or why it would behave differently (or if it's related to this crash). Actually, I think that's at least related to documented behavior: https://www.postgresql.org/docs/12/mvcc-caveats.html |Some DDL commands, currently only TRUNCATE and the table-rewriting forms of ALTER TABLE, are not MVCC-safe. This means that after the truncation or rewrite commits, the table will appear empty to concurrent transactions, if they are using a snapshot taken before the DDL command committed. I don't know why CHECKPOINT allows it to work under 9.5, or if it's even related to the PANIC .. Justin