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 1u3qO3-003rPl-Fr for pgsql-hackers@arkaria.postgresql.org; Sun, 13 Apr 2025 06:00:11 +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 1u3qO0-0046Mk-8g for pgsql-hackers@arkaria.postgresql.org; Sun, 13 Apr 2025 06:00:09 +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 1u3qNz-0046MT-RF for pgsql-hackers@lists.postgresql.org; Sun, 13 Apr 2025 06:00:08 +0000 Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1u3qNy-0004Uh-0L for pgsql-hackers@postgresql.org; Sun, 13 Apr 2025 06:00:08 +0000 Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-43cfba466b2so33411745e9.3 for ; Sat, 12 Apr 2025 23:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744524004; x=1745128804; darn=postgresql.org; h=in-reply-to:content-language:references:cc:to:from:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=DAotfJ+vcOpnMAy6jEN5pHQwBLOkI7podYbFKSCIKHo=; b=f37XhePYkdlyPJdr1x9Ox3rFNYNRb5vXyhTaIhYBw3AF+2S3jaAL7j0YydujS2+4pj 1dddOt6VxDphKMrQEY4HugqYaggn1MBFulDwbHZ9rw4VMjSgtNVZ2/D4XYNsc1o9SqrT MJKYKaHLlQnOthffwt6dMdkxOPb+qWrlLT5RuoTleP5xlHtQCABViJ2YPYHoqpUxeojG zK7hF9qnibDCQ0omjSsQnTMHC7vt31DTPtVUBHrmLhlAaO7/pQEYcFTAWcRUdplg3wov yR0gMq2eDPS6aH2bwQm2YG3IZ/sbpyH7/2okXTMVVqPpSwhrcfmAVEKzx6gszWEnUypB cQDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744524004; x=1745128804; h=in-reply-to:content-language:references:cc:to:from:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=DAotfJ+vcOpnMAy6jEN5pHQwBLOkI7podYbFKSCIKHo=; b=mJnGGLAavg5kvPEbtZgrynk1r1/GP499+Vduo+++PbzRqAM+jaUF9d8ophErir23kF yvMEI53lqEfa79UnDkww54XmqgDHHh9fiPC4GaRRzaEuAFBh2ISf4yKAY7nTeXEFUPXn xoIvnrjPSyIzjU5R9RYyw4Yk/g+G51y88BPfFgEh/WqoMJdmnKOyPZXjFeXIRl3HLVLK qdIZCrys+pLKNU9weWEB7NKk2Ij7+K8J/rVaZzntbNSfQ6H4Gg88u5pAzdh9yCUNC/R1 ShDxylDV5zf3PvgLcOq8tN2CTMb+Q8AFFzfGl4RDsqhY9TsoAGj937mxqCwZ79uKyYyA L4Hg== X-Forwarded-Encrypted: i=1; AJvYcCXSZlbiNPgmuiC/zQg+cm1VKBls2fL792Xs6v2xjgnXRFLFV922Qkk5J9h0UXApXIn9nfHTDUcxg64600SP@postgresql.org X-Gm-Message-State: AOJu0YxDTKb4sbGOB3sfl3Na1oUpVwUv4vAY4muBNDDjwtcbydHL1dX0 7HESlESYtRSek4LyB3mv7IzD3gQoH/xFuHKL6xOAOopgpq9NVL7H X-Gm-Gg: ASbGncu4t82A5aS3S2May1iGsbbD6axjr/Rzr20ZSHDB9KIwDxRVf8HOEf6N6eXsqIY DZkksecZ3BMOj/547h14wU4zuKeUsCqWnj4LdwA7qkAike203gWjTjKJvM2vXXe4LMI6ifrQd8I qrQSR/jtrFNuEQJSbBwV/VGIZmrOTbwi6WokN4XoJZ/XONZoQwoLwFGBiDW0UCdntoC5Y2mKuFq E2zT0iOR9tMP10rL2uTVTjVoosshHCTdfO4C9b7BBYaVbG8rQy+UOO+ypb75/lRbiPCj26TWj/S 20iPfojLoCQr/5HJ2Yp+RcF3KxT+h7yT3Xb069EJ47Q= X-Google-Smtp-Source: AGHT+IGvON/3KyNm1qYGFembdAX20D/S20feNRvnh07qIOa5E3AtOFlGEHXx0NFyMjFOaJfpkTuRSg== X-Received: by 2002:a05:600c:1e8f:b0:43d:683:8cb2 with SMTP id 5b1f17b1804b1-43f3a93f78amr72058365e9.14.1744524003486; Sat, 12 Apr 2025 23:00:03 -0700 (PDT) Received: from [192.168.0.50] ([89.149.68.176]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43f23158849sm138700795e9.0.2025.04.12.23.00.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 12 Apr 2025 23:00:02 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------zjzYceLsLcfRhAEFsgTJRPVb" Message-ID: <96abefe8-fa72-41f5-8840-0517125c24e3@gmail.com> Date: Sun, 13 Apr 2025 09:00:01 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: AIO v2.5 From: Alexander Lakhin To: Andres Freund Cc: Noah Misch , pgsql-hackers@postgresql.org, Thomas Munro , Heikki Linnakangas , Robert Haas , Jakub Wartak , Jelte Fennema-Nio , Antonin Houska References: <20250329212929.a6.nmisch@google.com> <7s6fclfekpcxoaaorwrq67v4vmgixf2dcjcgznuj7vxs3ie3wq@okqbi5vabqbx> <20250401151159.51.nmisch@google.com> <20250402001324.e4.nmisch@google.com> <3fhulsvzks4khqahl6tngcnuda7pyrrl7223tmjh2x2spralm3@iisldh6pcowy> <8160688e-db8e-4d7d-a7e7-ff366adf9717@gmail.com> <4nervqmqplfr23jrjvkp5tsumi6qgouhgjqlubf7ujrudw2epb@6mszddainl4u> <6a6756a0-bad5-4ee5-a591-c763af289940@gmail.com> Content-Language: en-US In-Reply-To: <6a6756a0-bad5-4ee5-a591-c763af289940@gmail.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------zjzYceLsLcfRhAEFsgTJRPVb Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hello Andres, 07.04.2025 22:10, Alexander Lakhin wrote: >> I ran it for a while in a VM, it hasn't triggered yet. Neither on xfs nor on >> tmpfs. > > Before sharing the script I tested it on two my machines, but I had > anticipated that the error can be hard to reproduce. Will try to reduce > the reproducer... I've managed to reduce it to the following: ulimit -n 4096 echo " fsync = off autovacuum = off checkpoint_timeout = 30s io_max_concurrency = 10 io_method = io_uring " >> $PGDATA/postgresql.conf pg_ctl -l server.log start for i in `seq 1000`; do   numjobs=$((20 + $RANDOM % 60))   echo "iteration $i (jobs: $numjobs)"   date   for ((j=1;j<=numjobs;j++)); do     (       createdb db$j;       for ((n=1;n<=50;n++)); do         cat << EOF | psql -d db$j -a >>/dev/null 2>&1 DROP TABLE IF EXISTS tenk1; CREATE TABLE tenk1 (     unique1     int4,     unique2     int4,     two         int4,     four        int4,     ten         int4,     twenty      int4,     hundred     int4,     thousand    int4,     twothousand int4,     fivethous   int4,     tenthous    int4,     odd         int4,     even        int4,     stringu1    name,     stringu2    name,     string4     name ); COPY tenk1 FROM '.../src/test/regress/data/tenk.data'; EOF       done;     ) &   done   wait   for ((j=1;j<=numjobs;j++)); do dropdb db$j & done   wait   grep -A3 -E '(ERROR|could not read blocks )' server.log && break; done pg_ctl stop It fails for me as below: iteration 13 (jobs: 25) Sun Apr 13 05:31:47 AM UTC 2025 iteration 14 (jobs: 67) Sun Apr 13 05:31:50 AM UTC 2025 dropdb: error: database removal failed: ERROR:  could not read blocks 0..0 in file "global/1213": Operation canceled 2025-04-13 05:31:58.930 UTC [1153451] LOG:  could not read blocks 0..0 in file "global/1213": Operation canceled 2025-04-13 05:31:58.930 UTC [1153451] CONTEXT:  completing I/O on behalf of process 1153456 2025-04-13 05:31:58.930 UTC [1153451] STATEMENT:  DROP DATABASE db5; 2025-04-13 05:31:58.930 UTC [1153456] ERROR:  could not read blocks 0..0 in file "global/1213": Operation canceled 2025-04-13 05:31:58.930 UTC [1153456] STATEMENT:  DROP DATABASE db6; 2025-04-13 05:31:58.931 UTC [1034758] LOG:  checkpoint complete: wrote 3 buffers (0.0%), wrote 0 SLRU buffers; 0 WAL file(s) added, 0 removed, 0 recycled; write=0.002 s, sync=0.001 s, total=0.002 s; sync files=0, longest=0.000 s, average=0.000 s; distance=18 kB, estimate=458931 kB; lsn=16/54589E08, redo lsn=16/54586F88 2025-04-13 05:31:58.931 UTC [1034758] LOG:  checkpoint starting: immediate force wait I reproduced this error on three different machines (all are running Ubuntu 24.04, two with kernel version 6.8, one with 6.11), with PGDATA located on tmpfs. Best regards, Alexander Lakhin Neon (https://neon.tech) --------------zjzYceLsLcfRhAEFsgTJRPVb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hello Andres,

07.04.2025 22:10, Alexander Lakhin wrote:
I ran it for a while in a VM, it hasn't triggered yet. Neither on xfs nor on
tmpfs.

Before sharing the script I tested it on two my machines, but I had
anticipated that the error can be hard to reproduce. Will try to reduce
the reproducer...

I've managed to reduce it to the following:
ulimit -n 4096

echo "
fsync = off
autovacuum = off

checkpoint_timeout = 30s

io_max_concurrency = 10
io_method = io_uring
" >> $PGDATA/postgresql.conf

pg_ctl -l server.log start

for i in `seq 1000`; do
  numjobs=$((20 + $RANDOM % 60))
  echo "iteration $i (jobs: $numjobs)"
  date
  for ((j=1;j<=numjobs;j++)); do
    (
      createdb db$j;
      for ((n=1;n<=50;n++)); do
        cat << EOF | psql -d db$j -a >>/dev/null 2>&1
DROP TABLE IF EXISTS tenk1;
CREATE TABLE tenk1 (
    unique1     int4,
    unique2     int4,
    two         int4,
    four        int4,
    ten         int4,
    twenty      int4,
    hundred     int4,
    thousand    int4,
    twothousand int4,
    fivethous   int4,
    tenthous    int4,
    odd         int4,
    even        int4,
    stringu1    name,
    stringu2    name,
    string4     name
);
COPY tenk1 FROM '.../src/test/regress/data/tenk.data';
EOF
      done;
    ) &
  done
  wait
 
  for ((j=1;j<=numjobs;j++)); do dropdb db$j & done
  wait
  grep -A3 -E '(ERROR|could not read blocks )' server.log && break;
done

pg_ctl stop

It fails for me as below:
iteration 13 (jobs: 25)
Sun Apr 13 05:31:47 AM UTC 2025
iteration 14 (jobs: 67)
Sun Apr 13 05:31:50 AM UTC 2025
dropdb: error: database removal failed: ERROR:  could not read blocks 0..0 in file "global/1213": Operation canceled
2025-04-13 05:31:58.930 UTC [1153451] LOG:  could not read blocks 0..0 in file "global/1213": Operation canceled
2025-04-13 05:31:58.930 UTC [1153451] CONTEXT:  completing I/O on behalf of process 1153456
2025-04-13 05:31:58.930 UTC [1153451] STATEMENT:  DROP DATABASE db5;
2025-04-13 05:31:58.930 UTC [1153456] ERROR:  could not read blocks 0..0 in file "global/1213": Operation canceled
2025-04-13 05:31:58.930 UTC [1153456] STATEMENT:  DROP DATABASE db6;
2025-04-13 05:31:58.931 UTC [1034758] LOG:  checkpoint complete: wrote 3 buffers (0.0%), wrote 0 SLRU buffers; 0 WAL file(s) added, 0 removed, 0 recycled; write=0.002 s, sync=0.001 s, total=0.002 s; sync files=0, longest=0.000 s, average=0.000 s; distance=18 kB, estimate=458931 kB; lsn=16/54589E08, redo lsn=16/54586F88
2025-04-13 05:31:58.931 UTC [1034758] LOG:  checkpoint starting: immediate force wait


I reproduced this error on three different machines (all are running
Ubuntu 24.04, two with kernel version 6.8, one with 6.11), with PGDATA
located on tmpfs.

Best regards,
Alexander Lakhin
Neon (https://neon.tech) --------------zjzYceLsLcfRhAEFsgTJRPVb--