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 1m1TDb-0006zB-N4 for pgsql-performance@arkaria.postgresql.org; Thu, 08 Jul 2021 12:33:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m1TDa-0001m1-M3 for pgsql-performance@arkaria.postgresql.org; Thu, 08 Jul 2021 12:33: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 1m1TDa-0001ix-Av for pgsql-performance@lists.postgresql.org; Thu, 08 Jul 2021 12:33:26 +0000 Received: from mail-io1-xd29.google.com ([2607:f8b0:4864:20::d29]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1m1TDX-0005Tr-Mw for pgsql-performance@lists.postgresql.org; Thu, 08 Jul 2021 12:33:25 +0000 Received: by mail-io1-xd29.google.com with SMTP id l18so2988913iow.4 for ; Thu, 08 Jul 2021 05:33:23 -0700 (PDT) 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:content-transfer-encoding:in-reply-to :user-agent; bh=ABYjV0yXwH7aY08LdtbX2dpQlhe1KH8Ph/7AJMyg0u8=; b=nCBKKmo+xxQfkR1miU/1rSXzQ0gZ3m6d6o1tIXVCbsJtV1SX9f0gAuixAijrh8oZFj EsugrfSUZH+fDFEb5iAq4XoZ6Y35BdJP/+sGXJRODcefsNgru31Jn9cBzG39+Md1A+Hk wxjzImpeZ4b1yr5A8qSg4SF7oUnpcCr79JFDtZqGCsU7SHH/DM18sgEv0te0xMCidMXi GRhJkBmmdXSQj0MxT0eqoCzgFQxVcX4lUfqFUCzdUBZ496mKoOWLJYC6TkVIjIGXPG2Q d0CbgU5jIJg45djrObfy1tRVof/iERwHxcKBiAV4Uc+fVn6U7iec/B9Y/rrl/Eo3cUGZ k9Zg== 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:content-transfer-encoding :in-reply-to:user-agent; bh=ABYjV0yXwH7aY08LdtbX2dpQlhe1KH8Ph/7AJMyg0u8=; b=c7cfgFBXHwCNaspQRpd0RZAkJsB/fo5ZWG6wk5GQbJVbdX7A9s/B919g9AAGi1wAXW iB0OyZUZxKWOnV/9bxthPcA+dbgBWKXzSdHt5GUhyPjm+5DqzLs/cvfIc1RGa2m/r3FD 8qjJkC/hFf0N/kM1bAEl1bIqFV1efbwxVSvkHd2nHESNUAmQCl26XNcR+OELNT0x7480 kEZvqXXvl9qpgPOOWguA0ZK2KYSAV8PPzJs/eKXt9p0RCgwaDw4ddHNd4orVnhRZqJiW dtpOoyAJC5NSs3/kw8VtrLm1zRuKeuw79alrX4exF41mEqp12EX0yc+2kTC7FcX5MEwE OajA== X-Gm-Message-State: AOAM530BZ5gm6Om0YVb8cohCHyk9Pbdq8ZxfX9l/ojrCVB6JEbGZD4oD UsIe9QUu6tt8RWTio+05UNbSKQ== X-Google-Smtp-Source: ABdhPJxSzeh1q4UdVjUNXkTIuPSTRgG/eR6P64c6mg/Cl6Ay8fTGeLtmwShTH2CGC8hrCCTtHWarDg== X-Received: by 2002:a5e:dd42:: with SMTP id u2mr13135949iop.135.1625747602754; Thu, 08 Jul 2021 05:33:22 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id o12sm1128641ilg.10.2021.07.08.05.33.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Jul 2021 05:33:22 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id D4CF6800AEA; Thu, 8 Jul 2021 07:33:20 -0500 (CDT) Date: Thu, 8 Jul 2021 07:33:20 -0500 From: Justin Pryzby To: Allan Barrielle Cc: pgsql-performance@lists.postgresql.org, Pierrick Martin Subject: Re: ETL - sql orchestrator is stuck when there is not sleep() between queries Message-ID: <20210708123320.GB22043@telsasoft.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, Jul 08, 2021 at 01:00:28AM +0200, Allan Barrielle wrote: > All is fine, and can work great. > But sometimes, some queries that used to take about 20 secs to complete can > suddenly end in 5mins. > Important all queries have the same shape -> CREATE TABLE SELECT AS *(a bit > of transform) FROM TABLE). No update, nothing, it’s dead simple. > > Nothing works, it’s very random, some query won’t simply work ( even after > hours ). When it doesn't work, you could check SELECT * FROM pg_stat_activity, and SELECT pg_blocking_pids(pid), * FROM pg_locks, to see what's going on. > Important all queries have the same shape -> CREATE TABLE SELECT AS *(a bit > of transform) FROM TABLE). No update, nothing, it’s dead simple. > We are just trying to copy a table from schema1, to schema2, to schema3 and > finally schema3. That’s it. Is it true that the SELECTs have no joins in them ? Did this ever work better or differently under different versions of postgres ? > Why does the query never end even after hours ? Why there is no log about > where the query is stuck. Please send your nondefault config. https://wiki.postgresql.org/wiki/Server_Configuration Also enable logging (I just added this to the wiki). https://wiki.postgresql.org/wiki/Slow_Query_Questions#Enable_Logging It'd be very useful to get "explain analyze" for a working query and for a stuck query. It sound like the stuck query never finishes, so maybe the second part is impossible (?) But it'd be good to get at least "explain" output. You'd have to edit your sql script to run an "explain" before each query, and run it, logging the ouput, until you capture the plan for a stuck query. Save the output and send here, along with the query plan for a working query. -- Justin