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 1tZUmc-00AEdw-CV for pgsql-general@arkaria.postgresql.org; Sun, 19 Jan 2025 12:52:08 +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 1tZUmZ-0078kA-Nu for pgsql-general@arkaria.postgresql.org; Sun, 19 Jan 2025 12:52:04 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tZUmY-0078k2-P0 for pgsql-general@lists.postgresql.org; Sun, 19 Jan 2025 12:52:03 +0000 Received: from sonic305-20.consmr.mail.ir2.yahoo.com ([77.238.177.82]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tZUmV-000Nrt-2D for pgsql-general@lists.postgresql.org; Sun, 19 Jan 2025 12:52:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s2048; t=1737291117; bh=ViYHRX/Mhy1NoNUYySI5+93ZfT9okPPF+S7TNnXV0jo=; h=From:To:Cc:References:In-Reply-To:Subject:Date:From:Subject:Reply-To; b=XDwVshm+bR2HeZJ/8+2ybCxZCOAIUqs7WtmduXKzdKCF0snhxUytPX3XkNTdFEDo/jkZC56s2EI/1A7hHWIQKLKR8F3CktpxmaSGzGdpq8lB0SER50FfgkmBLzJikV8B32jWiRJQDTRFFwYqo+s2e9yi06A1wFAjh1Wl8ngwVhPr/9dj0tZOE5cPzOc7UbugA9YlS1rh6T18zWuPsCsnC7WzZYRzbmJOoHOpkZPzBCTFj385h7c0BxpSubMd6hD/1JNfOkn9a56rN1H+DqaTDlGgJIxnvhKmAuAeCFCebrIn/dEIcKNsPHKWKdp+IsuMJsDVGGwuCel5LyMQDuPKdg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1737291117; bh=D2Gzh0dI3eKgn5vBrjTzgFsTD3wUcSsJUo0EfsnChN3=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=ctRIZI0cF9mDcxUqF6jiZPhOn29GHZQMdWpwH2ZCGNzS2lj+ECUNPz0kq8F6Z5+kqH/SRvpmXeZmGAexJ0B9NomTDaRVSt89dGqC1ZyKgxgdcYVe0QGQZ8bgNSuXPypIu6+Umx6p4cJL+dCIHPvSUxWADzZUezIS5vF8R0JNamWdpT8JLLVuSM3eUTCliPZM84Po9k33ofCMIl4JOEhC9SxLt6G7FXjmbUzsuEVxdDTfbuuLJACdaLIPzTXh4yYvxXJQ5N5+IpKUhAh/xdshyCJ7tbVH/sbysMMI1YO9RjiAKjupzqUvvbWMwGYXUvHMLC4t3DVEjRBSBlmv2ox0QA== X-YMail-OSG: Em.MKkEVM1lH4HzCHBYqC3cx8PucNaxL_buxiPuCMjfkoZaQkoyhhkx9aXORe9q Yass_ssGcpENSvLwZ2iluK7jGz.E5xcV0QRwxYordNePeDVsRECZlXjAD6P6MyipQ7Z7nDgedyvc .3ryCZ2RLW6_CtxJY6hOk3T4w2ayt53ZFZ__6PZ3LT4hZ9N_l6rq.StMzZRXVNxrtNMhAQZiGni_ 4uU_HnYtVDbw88FuEqCG7a5FL3pgkuGPVTYBILAPLHPIXuZqpdzWJK2qWX24_BV.o8k75A74czM5 Pf4.xw0S3NluukVfKOVLKzXahZsTLN23VOtQMzhcboInIuNmh68vtorJuGsicLqnSA5zLnhnICI3 cSrrLVRmnozFMu2sPNgeP5X4VOhnvoaZ.wp2yGCY9HgTXe4GBGXLKmNuZg_v.eRIfuKMpUAD3JTa kp0dGnFEL1fKKynnrjDuU2OwkV2cw_LX5WTslwdmxRgwFsQ4koMlZUhKIDrnIZWrZ.q4h2ys70x. t8wvQ.7fL1H7eU0XLtnr5YltiYMTNMH9nJ78lsxzCWw5mCDzNEl3p4n4fKNsePEUxNNdkFyHzMp. Md5sSALTfAaI_QFRFRm_CWcrZtHWIkQmUHgyoWco21ccczTU6dUukykOxdd2zJRuZgoAQC2.egZF 3DUFu55kaAOcSGxWBVxXCFvZ25PgJ4jeh5E.bPusbbX8fALtS5Sz3KetcaF3rNwA9lBanZQPlLU0 6.wvP4tmRTtavvgt5nb2JwCqyDG40LYwvKlHoYc629UCsx4PT6oPmYFuLwJU_z.uhg.0pY0sTHB5 dGWWZC_7r7pWrS3Ni9zrvkuB2gDI_hJDjBpKSMwq9XTOjHka6iYJ7pOIJNI69f6P6W2TMoazWt5R DdWOeQalJWWvBwXM1w8ddtN1jWQvy4tblLNK_FNhy15nDcOa1qK4Bwa924t6KZhAAuV73Sq07w.4 raVgoJaroSntT0Hn3eZsG3LnnUwE6AHOXmxTEiWITdtFLM0QVgDpwfrJQNi1gYyGIXFi841ZP96u 0u6tcP.OzvByax_nafPDJwnup42xB_jR9J15e2tufIKUqKNwsgZxSV81XloU.oTFQip7Yj3dqERA hH6KojdS6pnWOQZoBDSBeAUdlIzwoWLTIBQ12BNdvKIrDgJ5A2Y8unnd7uZdcfff52kB.VioHGYb 14q6B_NnI6cIxfpnvvVufn3XH0rG95qPBKEA16VFPJvTenZJNkg60UBiZdbqgGlwrmpG8zIAnSmH UrMQL0QZIq.tLSlxWq_MCOo87vmJYPcnViwqPZtB954cXteigj7mAFDsC_tfmbMvFcXcNdIAwuhF ay2_M3eVd7gJXatLaEdYgAlJqRwkH5MuO4vqP5lO9FOLLzNl40SxwQBb7v3TBfjsBE76hfnIgqDq xzygGtD800KAfhxXU3MHR.63Nwz4pVS0vRXTRxip12OBHRbBltN2WXUtVkAwaOK91WUkcZK4RyNI WT00KdSL4.Sa6dMiyuBhkbkwF3TqcWWfFSLhgsMhYhA6PEwmujBn8Mv4dLQ.Yjlc7nzk4HsO0H1u iGCbKHS340lwblFQeQ5QKk2l00T4uo7gFESDGi.4n5O8pQz4_R_gsk6WhYhP3X44fWQBOUFYN0uI RV_1DOcQaYUs3DgqH7SWs9PfI4NpmQl60W9pdnJsI4D8jfyGiwTUPrzpir082I1kBGIyroYi9drP .ijm_5TcDplq2ZvXT93142b4syW4syBBBaWBGzoCR2xst2o88IZS0XsTQ1TqnYadgX5_vyyVuzKm JjnBWG67fsb_L673nPGeIaXuvKNtRPVqCSRzL7tp7QGEYGPjr1mYmZpOtQI92fZg7el0HQDfhZsH yzq8MCbfGpX8EReZUza.Luud4t9fTIidPHC5kiX1Lgs2EX7MgLk6Kol364pfQwT12VlpM9MLa9E. sY4BdaiToqNMwXjziTi0WsLSV2yuOC7En9lIfU.TSHeYJLBOXGD3OArsq2uOm2wBLvgAGQo8f8M4 27Lk19z3WfLeKlWPOu_hLv8p5LGDCHUcwjHd9LbmjTWMG7oXBwmhPU1cvNGh7R5rgMAkDPsszvFy sRUxuQQpj69LTWVSLdXIR1wtHcdqcqmUjBgU4reGDT4YEQvvuW0HhORR9Y3as5OH0mXW8sj19D8Q bdM3G1_sHigvkneqq_YMO5KjurLNCy2rNXvH6MZ3Gzs9ve_f.hLmI6hLptsyoTI.przqY8QMn.BF voaI30SYMnPox_cgaOnVl891b199a7ZNQ X-Sonic-MF: X-Sonic-ID: 416e140d-1181-4e46-b95a-390de5ee30a0 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ir2.yahoo.com with HTTP; Sun, 19 Jan 2025 12:51:57 +0000 Received: by hermes--production-bf1-66bb576cbb-sv4hw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 77f9ceafaca9ef4be8be7f6b97c5364f; Sun, 19 Jan 2025 12:51:56 +0000 (UTC) From: To: Cc: References: <1726378815.4209727.1736772006968.ref@mail.yahoo.com> <1726378815.4209727.1736772006968@mail.yahoo.com> In-Reply-To: Subject: RE: pg_repack and locks Date: Sun, 19 Jan 2025 13:51:53 +0100 Message-ID: <000001db6a70$ebb65c80$c3231580$@yahoo.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQMGQEVA7dVrgCJU6kC+ijeZrizzlAFwY4sSAYy4xmGwsHdysA== Content-Language: fr Content-Length: 1543 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi Thanks for the help but this will not help, killing other process is not = safe The good way will be that pg_repack tools include a timeout so, that = after expiration delay, he will stop waiting and discard the repack = action But thanks again for your proposition. Regards, Nicolas -----Message d'origine----- De : depesz@depesz.com =20 Envoy=C3=A9 : lundi 13 janvier 2025 16:42 =C3=80 : nicolas Cc : pgsql-general@lists.postgresql.org Objet : Re: pg_repack and locks On Mon, Jan 13, 2025 at 12:40:06PM +0000, nicolas wrote: > Hello everyone, >=20 > We are using postgresql v12 and added the pg_repack package >=20 > Since I cannot stop other process, I use the = =E2=80=9C--no-kill-backend=E2=80=9D and=20 > Pg_repack will wait indefinitly until pg_repack get the lock >=20 > I get sometimes a problem of lock: >=20 > sometimes, I get indefinitly this message : =E2=80=9CNOTICE: Waiting = for 1 transactions to finish. First PID: xxxx=E2=80=9D >=20 > this is a real problem because the database is usd all the time. > If I kill the process, a trigger on source table will still exist and = temporary tables and type still exists in the repack schema. The tables = are not empty if data has been modified in the source table during the = repack. >=20 > If I drop table repack tables, I will loose all data modifications=20 > done on source table how can I properly cleanup the database ? Allow it to kill offending backends after some time? For example -T = 7200? Best regards, depesz