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 1hTNeK-0006f2-Pi for pgsql-hackers@arkaria.postgresql.org; Wed, 22 May 2019 09:35:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hTNeJ-0005GZ-LA for pgsql-hackers@arkaria.postgresql.org; Wed, 22 May 2019 09:35:03 +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 1hTNeJ-0005GR-8x for pgsql-hackers@lists.postgresql.org; Wed, 22 May 2019 09:35:03 +0000 Received: from mail-lf1-x144.google.com ([2a00:1450:4864:20::144]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hTNeG-00014P-PJ for pgsql-hackers@postgresql.org; Wed, 22 May 2019 09:35:02 +0000 Received: by mail-lf1-x144.google.com with SMTP id u27so1151734lfg.10 for ; Wed, 22 May 2019 02:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1lEi8Sa4ghYb/RFwpg7fkzfKwT0elycVBDVCHu88R6Q=; b=H20vkZOds/uyNBCXV2JfzTzgfr4BS1lCxRAag3jzzvEC0FLOhF4s3w6GwMGRvRaqj4 TaWiOXfXEUXBybPjmBotn/z0xkaPIveYRhjrUIsbcK2v0HDzgAVnqKVT69yE6uv0C1IU OiJlon51uhbZV88uf5/6tFdiLbXeiASVHCm0fEfqjMdtxMydVcgpklw0Udmk622f1dnC EoqY5GQ0MwLa/87W4fNy8EguNRbP8Ai3poO1f308tKs3dFZxyNADKiSqJcunYrijDVtg kcr4MUn9O+IvDFl3BNpbyb14tV5nn38WBccOYheWup5xZz5T6EjPT1EVBeqn6A7xOqOJ uirg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1lEi8Sa4ghYb/RFwpg7fkzfKwT0elycVBDVCHu88R6Q=; b=NbxcnVwyuMdzz/rh82r0L430THORgSBWoLSmaCuHWS3JAQsK/VTtCKwqIFSWgEF31N QpUXqp0XpgVpYGgyiVEH+ovjCjrR2i26Q3wuH3bsYnVyomfMK5Jm+vUw42sCcyTieTUZ NskpQomgVlPLnxd06QGAcENd1ijmwr2G7tGunxJYWuiJYzLskgF66w2hVyCs6QYUjaqU I1C1NTVhdGuSoE5785tQcK/WP/OJa3O4m9k1wvEeCHEf7rby4GZCFYAIvBf52p1uIQ+f n7YvfXHZ11RewqQK5ZzNxq9or5kZDmR2kfQxAB3Z4PTGT3/4UmVcCwzUe+NQH8IiBPLT P76Q== X-Gm-Message-State: APjAAAXm3ajtJski+5XX+7qALP08lVGB3LZgxGJUW1/srnWKf13fhFUd UlQCy0YPZ3gL6JO+k+HUgqlF2KVOyZAEYEiHjGo= X-Google-Smtp-Source: APXvYqws4kWBNd1vMMxHx3/9WKufiQxJYSY+SCEFtDrYaZ7f/skzw2jjOkiG4iiC4y2frJCCxk3KtNWGQazvcYtxE/A= X-Received: by 2002:ac2:4111:: with SMTP id b17mr774067lfi.31.1558517698571; Wed, 22 May 2019 02:34:58 -0700 (PDT) MIME-Version: 1.0 References: <20181212204154.nsxf3gzqv3gesl32@alap3.anarazel.de> <20181214005521.jaty2d24lz4nroil@alap3.anarazel.de> <20190402160414.h4wwhetcpggmy3tv@alap3.anarazel.de> <20190405231553.njjcu7igoyuk2hx5@alap3.anarazel.de> In-Reply-To: From: Amit Khandekar Date: Wed, 22 May 2019 15:05:29 +0530 Message-ID: Subject: Re: Minimal logical decoding on standbys To: Andres Freund Cc: Robert Haas , Craig Ringer , Petr Jelinek , "pgsql-hackers@postgresql.org" Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Tue, 9 Apr 2019 at 22:23, Amit Khandekar wrote: > > On Sat, 6 Apr 2019 at 04:45, Andres Freund wrote: > > > diff --git a/src/backend/replication/slot.c b/src/backend/replication/slot.c > > > index 006446b..5785d2f 100644 > > > --- a/src/backend/replication/slot.c > > > +++ b/src/backend/replication/slot.c > > > @@ -1064,6 +1064,85 @@ ReplicationSlotReserveWal(void) > > > } > > > } > > > > > > +void > > > +ResolveRecoveryConflictWithSlots(Oid dboid, TransactionId xid) > > > +{ > > > + int i; > > > + bool found_conflict = false; > > > + > > > + if (max_replication_slots <= 0) > > > + return; > > > + > > > +restart: > > > + if (found_conflict) > > > + { > > > + CHECK_FOR_INTERRUPTS(); > > > + /* > > > + * Wait awhile for them to die so that we avoid flooding an > > > + * unresponsive backend when system is heavily loaded. > > > + */ > > > + pg_usleep(100000); > > > + found_conflict = false; > > > + } > > > + > > > + LWLockAcquire(ReplicationSlotControlLock, LW_SHARED); > > > + for (i = 0; i < max_replication_slots; i++) > > > + { > > > + ReplicationSlot *s; > > > + NameData slotname; > > > + TransactionId slot_xmin; > > > + TransactionId slot_catalog_xmin; > > > + > > > + s = &ReplicationSlotCtl->replication_slots[i]; > > > + > > > + /* cannot change while ReplicationSlotCtlLock is held */ > > > + if (!s->in_use) > > > + continue; > > > + > > > + /* not our database, skip */ > > > + if (s->data.database != InvalidOid && s->data.database != dboid) > > > + continue; > > > + > > > + SpinLockAcquire(&s->mutex); > > > + slotname = s->data.name; > > > + slot_xmin = s->data.xmin; > > > + slot_catalog_xmin = s->data.catalog_xmin; > > > + SpinLockRelease(&s->mutex); > > > + > > > + if (TransactionIdIsValid(slot_xmin) && TransactionIdPrecedesOrEquals(slot_xmin, xid)) > > > + { > > > + found_conflict = true; > > > + > > > + ereport(WARNING, > > > + (errmsg("slot %s w/ xmin %u conflicts with removed xid %u", > > > + NameStr(slotname), slot_xmin, xid))); > > > + } > > > + > > > + if (TransactionIdIsValid(slot_catalog_xmin) && TransactionIdPrecedesOrEquals(slot_catalog_xmin, xid)) > > > + { > > > + found_conflict = true; > > > + > > > + ereport(WARNING, > > > + (errmsg("slot %s w/ catalog xmin %u conflicts with removed xid %u", > > > + NameStr(slotname), slot_catalog_xmin, xid))); > > > + } > > > + > > > + > > > + if (found_conflict) > > > + { > > > + elog(WARNING, "Dropping conflicting slot %s", s->data.name.data); > > > + LWLockRelease(ReplicationSlotControlLock); /* avoid deadlock */ > > > + ReplicationSlotDropPtr(s); > > > + > > > + /* We released the lock above; so re-scan the slots. */ > > > + goto restart; > > > + } > > > + } > > > > > I think this should be refactored so that the two found_conflict cases > > set a 'reason' variable (perhaps an enum?) to the particular reason, and > > then only one warning should be emitted. I also think that LOG might be > > more appropriate than WARNING - as confusing as that is, LOG is more > > severe than WARNING (see docs about log_min_messages). > > What I have in mind is : > > ereport(LOG, > (errcode(ERRCODE_INTERNAL_ERROR), > errmsg("Dropping conflicting slot %s", s->data.name.data), > errdetail("%s, removed xid %d.", conflict_str, xid))); > where conflict_str is a dynamically generated string containing > something like : "slot xmin : 1234, slot catalog_xmin: 5678" > So for the user, the errdetail will look like : > "slot xmin: 1234, catalog_xmin: 5678, removed xid : 9012" > I think the user can figure out whether it was xmin or catalog_xmin or > both that conflicted with removed xid. > If we don't do this way, we may not be able to show in a single > message if both xmin and catalog_xmin are conflicting at the same > time. > > Does this message look good to you, or you had in mind something quite > different ? The above one is yet another point that needs to be concluded on. Till then I will use the above way to display the error message in the upcoming patch version. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company