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 1rHjpG-0040di-Sl for pgsql-bugs@arkaria.postgresql.org; Mon, 25 Dec 2023 12:12:55 +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 1rHjpF-002Hxh-Iv for pgsql-bugs@arkaria.postgresql.org; Mon, 25 Dec 2023 12:12:53 +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 1rHjpE-002HxT-EM for pgsql-bugs@lists.postgresql.org; Mon, 25 Dec 2023 12:12:53 +0000 Received: from sonic302-48.consmr.mail.ne1.yahoo.com ([66.163.186.174]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rHjpB-00C7bR-A6 for pgsql-bugs@lists.postgresql.org; Mon, 25 Dec 2023 12:12:51 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703506367; bh=oJQD5q+g+kX6Hyj0c8F4UPt54JLgLXWi1QBkGE8TPRQ=; h=Date:From:To:Subject:References:From:Subject:Reply-To; b=Rphi91MuTIJzIMm2gVn7hLSaLsT0H4lD1axHYuUuKV4GQ6uIOzuBpMe3Zq3j7mn8w5irP7yezARQu1EFMgyCHXvKJTttIfsc+8PLzYijCzVZEhKE2yiFGfmnKMv4KhcRE9KTjWgUGM4tyvAhlbqwVd0lW507dVB5RkcKXJ1wEqoNDYEpTZ4TDKQWja/BuU1RoD3/zhakKXJSXlqc/SLg3qAGX6qrMACD8ox5EFN0OGGf9YRmFHg3NJbDHEgYii7eq3JSVmxxh6FPoRF5IUeiLKPPD3asSd2dBvIaJPyJoFzNs48zRNBHOczM+9ytqLXweuQeV068kH5HYP8G13WC3g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703506367; bh=bSx/jfMW9wwVJGbiLac/JkDo/cRP3Ym7MekZzplkDtv=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=NeK/WhfXDujgzDF/8BqWBbfjuW/EYvleXFxU9kr8nj/WmXW4ps2/Q/MlMDF0K39KmPklJHlxEQ3tSSMzWkuci2Pj4YaAdOLKc5M9Y6lXG1SdppxwpNl4GNUW9lMHV/akEHci6ucjRRRUIxDv2d+FUbDVaAiY2F2/5zJiZKy+dbR6XbL/DuisXwnNrALMIZ8l1sDlqJK+5GC7p6owfONDa2XozEsWx9oWolog4cXPiRvtGFYvHZcOyPqrjgNWFD1bRNmNOTOh3IsT0qzs9OUnWnv6ouKZSCbJaCzWHzTgd6L8xFFRnetxt4rkz5LTRDkPDk23jun9p6vISvCtKYwBKw== X-YMail-OSG: l_LLbBEVM1mw5GBCSF0VWb6_ZSuIX9K2NtLpzEMG7wou6MAl1vbip2ZGJYekSgb sHbut7bQRHvyU2_HBg6lDu7c2Sb64KYbEnEQZVROmTWf7fw9SgOWd6nkFcUdKQe7GFvuG4dBrGx1 2dp_GIEXPe0sMdIt49dt5RdPjxPtxkE7qT_ELP2Of4yJ9YKPeg841cyA8OeCWfL8Zd76LDeE54HE FljjRS5Uae_KvrZ9JxKXJsRVvjkBIhvRojN3Eg36nzoQWWDxHeeBBiE8jXERtLNuNMAgu.h_LSiS 3AA1WM4XJmpqoImnNpbI.MBMYd4iMBRcDijSDu8hcf65gZc.1fYiTlzEq235Apv_W9RdJxTaDQVi A3O.sKmJrlB7jU2Dkml8ssNsx79kQrJQeYyNpo02KS93cyoIJ6HtFrYhfRpEuo0tP5bMeL_U6Cm6 Jj5Ml75LnwyLYraTdzcc0.zD8Bm0dcDQe9jiS6oggSdMARPGrnMpzpuABwFzF_ofScseVUmdIMLG aunpM8YltYCMo7tBgdDYfFGjQ26XrxtCIRXpSJzvkPmozAbFX9bYGF8pPh4d1asznQeNWsacr3OA UF7hNhimnMyDfFfLV0P.Gz0pnas1M_QokZm6eJ9XgudYt83_agXG3rFCT0C224kK7BHH2NaHIkXw QPLtWxc7yknApUXzsGS_Md4MLqJqpIM2ZQBDdsujuHMgY_wcoioogrJ8CUd.uqrx434flNfmmDr0 qPATvSmbz19QLoz4hcRjr4X2zerIvkF.f52CzpfSJWnl8yhIzFtbQjFppJSgMEirtDZ0EGITjU2A GvKgSYNVDIEjBjVlrqxb7rzxQ45MkiGQHolPRszjLNN96KJA4Lfx1vJ2tulixuvuxOyLCZhwX2a7 _DIXfmSR_EBh1hYSmptBG9vUM9vN3VPvohXXuQKmBBzbZh3SykMuuEB0FrTy6AWmpIt4O0S08sRQ bAE8d_UlIp8jTxY_WuIMax0dz2ohNUgRhrrjC5O5WATESm_Q56j7RPjXWDywECgor7jL5Wf1YqZc YbLJnWO4e4825yjxcneroIoHGL0dQFEToM2fZ3hWIyml9WCQuMaGFv__.ZeGwBvdxv5GU_f6yReL mvtV2aT9jrBmcBWAinUgvnkpg7C4PnZgFpk1Zlr_INIro1AGLnGr8xxBO7XRv1i.tI1_gRAhyj1X mFX9IM6GThlVdKeG3Y3W8W8td04qlZ0KukmMfXPCOlqL9uHl64SHn8CO_Yry5Kwc_819AN6o71fn ZTSmjKewaCmVi3HrBvSNci5URby2b0JmO7Wthypj8_QSxKopUSN79JIHyTPpiSRMjy9x6Gvetfju l.PLoEH6TxPuXwk4eINkwWxVYEvqdQa217JWZrqLJXPdki0x2wHsI0sIMQyqe_cX_fGRuN9goT4G 1iJXKRR.3rnwJcfMOvbZnPPllbvNfEO7aUFzGySuNH5XQ38N1BV.lGX9.fP0l67J9Vn69hf8BLZa eo9239YFw3xY.izUuOfS8pl8ORtKECtWWh4XZn07dR8DdMEOero9ggwdSutfshRIv8aKN4d6oIhC 7gizG8ued6PYKH86f.jcMvrvkDzWq8kdgcQFIE86htYMq7ZqZCAE4JWHkOD1Ad32qF5QMmp4mbTu MEY9nnmFp.h0INgocswB3C5JNYposbT26F8yddeh3SfMD9pdZUPHsyaW5OLy.G8_5qWTtBgeban5 7w2_KXFAP0.GWdr5AQLhaG6UX6hJlwFcuWowWA7zNu4J4sJprY0UahSq97hBEtJlxaqFcGwinF2V QH9Nlucq0MFsoyZryZJyYwqlh.0TX12phnzEOMDvb0JRDF4pivEsh8Og6s7aw_mRrWcbPMdDxXFi ttyT7ZqDnnJZWV_n8W92vD1Zs9UQ3BWU68VFG_HgBl9YBf3iOgZVglpIZ0G5Hg2gEDV1E4NdczID B.l6cxmXzbjZ5FG1xZIuz.44gfMz24x3qFXU8vkBIGhehrLWj8wglPnAUqepI8hvRxSVJFkIAohV HcAMjOl6yHo4y7FoADlTy8vFe93wfXG8_VHycQZ4WhPIyKOEObvdJ1uCb.43Bzbv5GSDhWTvFd9y 4ktC6mUVXVykg142kh6usGguB8Sjc6yaxJy.7QoTd2n63QZvy58X5QDNcbwzM2n5psLmRFfIG_Iu ST10dhdSRCd9OTS6Ts9vpIW.rDqVqUBDsboj9EeiREPu1G65bV65xWNFUSzZo_O0WnxWv5axVl8D I.KM_Zw_0Y9_5bG5wBF2evYi95qfYTA5MZFTd77R.sx34.DCz.g9GsnvmLHqPTw-- X-Sonic-MF: X-Sonic-ID: 4998f569-8609-4549-91e5-d0a1b92d0a5f Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Mon, 25 Dec 2023 12:12:47 +0000 Date: Mon, 25 Dec 2023 12:10:40 +0000 (UTC) From: Nagaraj Raj To: Message-ID: <1237927313.5086260.1703506240368@mail.yahoo.com> Subject: Issue with Running VACUUM on Database with Large Tables MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5086259_921768658.1703506240367" References: <1237927313.5086260.1703506240368.ref@mail.yahoo.com> X-Mailer: WebService/1.1.21952 YahooMailIosMobile Content-Length: 6622 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------=_Part_5086259_921768658.1703506240367 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello, While executing a vacuum analyze on our database containing large tables (approximately 200k), I encountered an issue. If a table gets dropped during the vacuum process, the vacuum job fails at that point with an error message stating "OID relation is not found" and exits. This behavior seems to interrupt the entire process without providing a warning or handling the error gracefully. Considering the possibility of dynamic objects within our database design, this abrupt termination makes it challenging to complete the vacuum process successfully. This issue has persisted across multiple versions, including the current version we're using (14.8). Is this behavior expected or could it possibly be a bug? It would be beneficial to have a mechanism in place to handle such instances, perhaps by providing a notice or warning when encountering dropped tables, allowing the process to skip those tables and continue with the rest of the vacuum analyze. Your support in resolving this matter is greatly appreciated. Thanks, Rj ------=_Part_5086259_921768658.1703506240367 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello,

While executing a vacuu= m analyze on our database containing large tables (approximately 200k), I e= ncountered an issue. If a table gets dropped during the vacuum process, the= vacuum job fails at that point with an error message stating "OID relation= is not found" and exits. This behavior seems to interrupt the entire proce= ss without providing a warning or handling the error gracefully.

Considering the possibility of dynamic objects within our data= base design, this abrupt termination makes it challenging to complete the v= acuum process successfully. This issue has persisted across multiple versio= ns, including the current version we're using (14.8).

Your support in resolving this matter is greatly= appreciated.


Thanks,

Rj

------=_Part_5086259_921768658.1703506240367--