Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gqmND-0004zR-8l for pgsql-general@arkaria.postgresql.org; Mon, 04 Feb 2019 22:05:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gqmNC-000587-0J for pgsql-general@arkaria.postgresql.org; Mon, 04 Feb 2019 22:05:50 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gqmNB-000558-L2 for pgsql-general@lists.postgresql.org; Mon, 04 Feb 2019 22:05:49 +0000 Received: from mail-pf1-x42b.google.com ([2607:f8b0:4864:20::42b]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gqmN9-0001VZ-8H for pgsql-general@postgresql.org; Mon, 04 Feb 2019 22:05:48 +0000 Received: by mail-pf1-x42b.google.com with SMTP id q1so566391pfi.5 for ; Mon, 04 Feb 2019 14:05:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=GF55R7Gi+gJ4j3rdM2WnvjlSqGHhAstOcM9KBkUkOvk=; b=HMPEun04r8uAjD6FViQWmWk8kEjDn/Vok7cfA1XZQViv4F+3WPAiSx02WVgdZjpte+ Zu2S7Uy7vnK0ujzbluIT9U4KowbTWJmM3HJY4kajQXyYXowKZHOaRYKSlbVdQ7HxsZ9l EEjtEiqUooHsZvTQw1EPo6KCt6CgH1oy1fRpdQTyXNffKaYOEozUlqBtcRVBHvf4Ygbx BQyuoHLoRIEiaxaevVgeodVMXR3tn504DL79ed4F9IBtFKi5+A0XcC/X1iJhZPVWzKpd zdSmNn1305AWpIfcKQjPyoSEYKJqWmWshxQO0TXIhKlVkofSh5oQc8fk84cdrF3m8nFr KqRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=GF55R7Gi+gJ4j3rdM2WnvjlSqGHhAstOcM9KBkUkOvk=; b=pBc6du2K10de5tJOCNrSzYduoCtwFCcdfwjEU8msV6zJqGD8uvF+HSdfPrFwbxbKll mlYU+G7kdKBUzh7HvhiIRc0t0+ldDlDGZW/t/k8SSLOzwlznPeWAWuDZsbRquFkrxZIW 1GnZaLKpSgx/d4nP12rUsZNR99+aGQMCkLYeqqsQ/NSZgtJ4HNMJTRuZHF5M0dRCF3ul 8FkyclhamsFqDJhv7nsy+eiq3d/KqOgBtWH4j4C7qxW8JvXhCQtvGTnBtKZKyxyrMtvP a6RYVuXElp8w8R6Pgxr8SV5ZvCm5gq61bbAyVkslpNPnMNta43NScJ6Qd+ZZZmBu20ff MwsA== X-Gm-Message-State: AHQUAuaeSiq4iuXmv07+JlGf+YGMQHGNAUvTJ842KS1pE+2RsLJB0Rhl Xmv3mXPlPcdac9lyng2xCsu3oSMg X-Google-Smtp-Source: AHgI3IYMhkhr6u3fnuDA2IdpYSHhNFXBB4Au/kc7iHbBJxGYgNksAqGJpyeVSacyCPnzjyL7NBXioQ== X-Received: by 2002:a63:ee4c:: with SMTP id n12mr1406191pgk.21.1549317945972; Mon, 04 Feb 2019 14:05:45 -0800 (PST) Received: from 192-168-1-102.tpgi.com.au ([61.69.131.212]) by smtp.gmail.com with ESMTPSA id h64sm1460273pfc.142.2019.02.04.14.05.44 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 04 Feb 2019 14:05:45 -0800 (PST) Message-ID: <3062c3953f78637800eec4339bf4f4eff877f32b.camel@gmail.com> Subject: Re: Server goes to Recovery Mode when run a SQL From: rob stone To: PegoraroF10 , pgsql-general@postgresql.org Date: Tue, 05 Feb 2019 09:05:41 +1100 In-Reply-To: <1549294429092-0.post@n3.nabble.com> References: <1549209182255-0.post@n3.nabble.com> <37bc715f-12e2-84ac-6492-88d7b6306777@aklaver.com> <1549211574297-0.post@n3.nabble.com> <0689b9bcac79f7f5e76ed69dd4baea012d6a3d33.camel@gmail.com> <1549278827534-0.post@n3.nabble.com> <7719c8bd-2e98-8a67-d01d-3b111e8d669c@aklaver.com> <1549294429092-0.post@n3.nabble.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.4-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Olá Marcos, On Mon, 2019-02-04 at 08:33 -0700, PegoraroF10 wrote: > About replication ... Logical Replication with CREATE > PUBLICATION/SUBSCRIPTION. > > Yes, some DDL commands were ran on that server but none of them were > related > with that select. > Let me explain better. We have a single server with a single database > on it. > Each customer has its own schema and connects to it to work > exclusively on > that schema. So, sometimes we add some customer or change something > on an > old one. But this DDL change we could ran is not related with that > schema we > are talking. Schemas can have different structures but that schema > which > puts my server on recovery mode was not changed. > > Maybe something related happened some days ago. When we start a new > customer > we add a schema, put all their tables on it and it´s ok. Our server > has > today 90 schemas and each schema has 100 tables, resulting in 9000 > tables. > Some days ago we added 5 new customers on same day, so we added 500 > tables. > Then, when we did that some selects on system tables were very very > slow and > that was only solved when we did a REINDEX DATABASE. Even REINDEX > SYSTEM did > not solve. Is this problem related with recovery mode of my server ? > > I trust that you saved the output from your "create" scripts. I would find those five log files and see if any errors occurred. Also, you would have to run them on the "subscriber" server first. So, if you "diff'd" the log files for "escola-53" (or whatever) from the publication and the subscriber servers, they should be similar in all respects? I don't know the answer to that question. Chapter 31.4 in the doco is interesting reading. Cheers, Robert