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 1twtuJ-000pCm-P9 for pgsql-hackers@arkaria.postgresql.org; Tue, 25 Mar 2025 02:20:47 +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 1twtuI-00DXU3-BZ for pgsql-hackers@arkaria.postgresql.org; Tue, 25 Mar 2025 02:20:46 +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 1twtuI-00DXTr-1Y for pgsql-hackers@lists.postgresql.org; Tue, 25 Mar 2025 02:20:46 +0000 Received: from mail-pl1-x62f.google.com ([2607:f8b0:4864:20::62f]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1twtuF-000zJs-1A for pgsql-hackers@postgresql.org; Tue, 25 Mar 2025 02:20:45 +0000 Received: by mail-pl1-x62f.google.com with SMTP id d9443c01a7336-224100e9a5cso97292215ad.2 for ; Mon, 24 Mar 2025 19:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; t=1742869241; x=1743474041; darn=postgresql.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=m4Jrc2iQJmAuE+XwVHQUWKMCJMsfDYySXwQ7bwtCsys=; b=Y7D7suawYMQ0B9vQ6eylYurqOi9lU/w1H2PVKaQtZxpA1JmvwtfdCXSIbZzuY99Qp1 O/75Spmj+UQG5KQoN7bdGRe4bAkbSQbvEF9O9u1nP4FebaEjv9kgyaGswZc6iZAZzI77 xA1A1shR3F7IUhJD8IvxyFXUnTHj5lvoxuUPg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742869241; x=1743474041; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=m4Jrc2iQJmAuE+XwVHQUWKMCJMsfDYySXwQ7bwtCsys=; b=De3zBxQecKrYJLMbnILJMJVCr6w5rLzewrBJvMp2QeHohyoxdLxc9UszmSvlf8WMW4 /njbZM4r5xn0nQh8G1cX3yTJO3GtwMSBqW+BcDxMjSe8cl5jHf5JToA3iaCZwms6OO7k qFA+OpAV+I+BNRxY1alwreBoBFnxMe4jk8J53yw2YjNrvM/Z6G+jmjwe3udQ0T2ckpnX rCfmM3JQ8nUG0C9TZgKV7GlhtTR693kJZMldBLHo6jLDztb/52Uo3tSEPasgLbrHZ/jF PcItt6yDS/lGrEkVWiDKBK0QpvQWgSnvXJbe7jXmybNsA9DCer4NYv3eUtZdmFgO0ObO mgIg== X-Forwarded-Encrypted: i=1; AJvYcCVt2/bXy3Pb+VhQdZFLcupm2aRzubLgLj1KHrhsJfxi63p22zDvjNf71PvLVM4YoeYSECyvQk620WpgOPjD@postgresql.org X-Gm-Message-State: AOJu0YwnmnCkAYQ5TF4Ub3PcXrPQwiGF1Dc73h8gwK+2uD48Tgl6rxXk mFnX/cE25wjdz9DZ/CSEC4vIubnDnqhNB/RDrD0fclsFNPH7nCA7UYrnGp9fLA== X-Gm-Gg: ASbGncv4B3OUlbcGClj0iQi4hdYUYqDf3tb56B6y3WNxnmPZbQwb+IquL3It/rJONsP I9Fb42V2Ol65D/jCnD/QMg+MWpPDRiCZIYC0LIXd96tzRDbmBHz8CxoLLnSMU4llpLR3XEYlbXi 3ViVf8I5otB6rw4sV+ArhbZeQwp7trsvlXlYqlKSbMeKf4pgoeQLcE4OUZCm457s5bWTApzyr4y WmbBvS4EZ+vcNfUzABoWj3HGOD/PtT51bGc0Vtr6eMZWegd6zwPrCo7j/cKFBTU5GsOLuTSfPiJ Du5/F6DH9TJ/WyEixSTI9plMul1DFNB+DNYlozTIMg== X-Google-Smtp-Source: AGHT+IGs3ET7ZMJDeSmvVEqemYSivAoFTJXGuYkclSDjsFmI86wSyC+TQ0Q/lzLZ9mLHyW46uk75kA== X-Received: by 2002:a05:6a00:194a:b0:736:2a73:675b with SMTP id d2e1a72fcca58-73905a3b2acmr22889937b3a.19.1742869240719; Mon, 24 Mar 2025 19:20:40 -0700 (PDT) Received: from google.com ([2601:647:5600:80d0::31cd]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-af8a2a479c1sm7932987a12.70.2025.03.24.19.20.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Mar 2025 19:20:40 -0700 (PDT) Date: Mon, 24 Mar 2025 19:20:37 -0700 From: Noah Misch To: Andres Freund Cc: Antonin Houska , pgsql-hackers@postgresql.org, Thomas Munro , Heikki Linnakangas , Robert Haas , Jakub Wartak , Jelte Fennema-Nio Subject: Re: AIO v2.5 Message-ID: <20250325022037.91.nmisch@google.com> References: <20250311194108.c5.nmisch@google.com> <5dzyoduxlvfg55oqtjyjehez5uoq6hnwgzor4kkybkfdgkj7ag@rbi4gsmzaczk> <20250312035743.f5.nmisch@google.com> <4b3f32ug3cayekysqlgspz2qjmeb7lca3gvazayglxr2m3d4dv@il33accgsji7> <17906.1741863183@localhost> <3yxd5r23zly5bytvgyktbxtxq2r3gbpi7xd4dugevh3h4w4q6c@lu6oatjjpltz> <6ak556uyqiptdwjaci4kbi5eykwkmzqgkbtkyaosjnopjhncrc@2v4ac2jwyz22> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6ak556uyqiptdwjaci4kbi5eykwkmzqgkbtkyaosjnopjhncrc@2v4ac2jwyz22> User-Agent: Mutt/2.2.12 (2023-09-09) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, Mar 20, 2025 at 09:58:37PM -0400, Andres Freund wrote: > Subject: [PATCH v2.11 09/27] bufmgr: Implement AIO read support [I checked that v2.12 doesn't invalidate these review comments, but I didn't technically rebase the review onto v2.12's line numbers.] > static void > TerminateBufferIO(BufferDesc *buf, bool clear_dirty, uint32 set_flag_bits, > - bool forget_owner) > + bool forget_owner, bool syncio) > { > uint32 buf_state; > > @@ -5586,6 +5636,14 @@ TerminateBufferIO(BufferDesc *buf, bool clear_dirty, uint32 set_flag_bits, > if (clear_dirty && !(buf_state & BM_JUST_DIRTIED)) > buf_state &= ~(BM_DIRTY | BM_CHECKPOINT_NEEDED); > > + if (!syncio) > + { > + /* release ownership by the AIO subsystem */ > + Assert(BUF_STATE_GET_REFCOUNT(buf_state) > 0); > + buf_state -= BUF_REFCOUNT_ONE; > + pgaio_wref_clear(&buf->io_wref); > + } Looking at the callers: ZeroAndLockBuffer[1083] TerminateBufferIO(bufHdr, false, BM_VALID, true, true); ExtendBufferedRelShared[2869] TerminateBufferIO(buf_hdr, false, BM_VALID, true, true); FlushBuffer[4827] TerminateBufferIO(buf, true, 0, true, true); AbortBufferIO[6637] TerminateBufferIO(buf_hdr, false, BM_IO_ERROR, false, true); buffer_readv_complete_one[7279] TerminateBufferIO(buf_hdr, false, set_flag_bits, false, false); buffer_writev_complete_one[7427] TerminateBufferIO(buf_hdr, clear_dirty, set_flag_bits, false, false); I think we can improve on the "syncio" arg name. The first two aren't doing IO, and AbortBufferIO() may be cleaning up what would have been an AIO if it hadn't failed early. Perhaps name the arg "release_aio" and pass release_aio=true instead of syncio=false (release_aio = !syncio). > + * about which buffers are target by IO can be hard to debug, making s/target/targeted/ > +static pg_attribute_always_inline PgAioResult > +buffer_readv_complete_one(uint8 buf_off, Buffer buffer, uint8 flags, > + bool failed, bool is_temp) > +{ ... > + if ((flags & READ_BUFFERS_ZERO_ON_ERROR) || zero_damaged_pages) > + { > + ereport(WARNING, > + (errcode(ERRCODE_DATA_CORRUPTED), > + errmsg("invalid page in block %u of relation %s; zeroing out page", My earlier review requested s/LOG/WARNING/, but I wasn't thinking about this in full depth. In the !is_temp case, this runs in a complete_shared callback. A process unrelated to the original IO may run this callback. That's unfortunate in two ways. First, that other process's client gets an unexpected WARNING. The process getting the WARNING may not even have zero_damaged_pages enabled. Second, the client of the process that staged the IO gets no message. AIO ERROR-level messages handle this optimally. We emit a LOG-level message in the process that runs the complete_shared callback, and we arrange for the ERROR-level message in the stager. That would be ideal here: LOG in the complete_shared runner, WARNING in the stager. One could simplify things by forcing io_method=sync under ZERO_ON_ERROR || zero_damaged_pages, perhaps as a short-term approach. Thoughts?