On Thu, Mar 21, 2019 at 07:45:59PM -0300, Lucas Viecelli wrote:
> Hi everyone,
>
> A very common question among new users is how wal_level works and it
> levels. I heard about some situations like that, a user create a new
> publication in its master database and he/she simply does not change
> wa
David Fetter writes:
> On Thu, Mar 21, 2019 at 07:45:59PM -0300, Lucas Viecelli wrote:
>> I am sending a patch that when an PUBLICATION is created and the
>> wal_level is different from logical prints a WARNING in console/log:
> Is a WARNING sufficient? Maybe I'm misunderstanding something
> imp
>
> > Is a WARNING sufficient? Maybe I'm misunderstanding something
>
> important, but I think the attempt should fail with a HINT to set the
> > wal_level ahead of time.
>
I thought about this possibility, but I was afraid to change the current
behavior a lot, but it's worth discussing.
>
>
I
On Sun, Mar 24, 2019 at 02:06:59PM -0400, Tom Lane wrote:
> David Fetter writes:
> > On Thu, Mar 21, 2019 at 07:45:59PM -0300, Lucas Viecelli wrote:
> >> I am sending a patch that when an PUBLICATION is created and the
> >> wal_level is different from logical prints a WARNING in console/log:
>
>
On Mon, Mar 25, 2019 at 10:15 AM David Fetter wrote:
> > I do not believe this is practical either. GUC manipulation cannot
> > look at the catalogs.
>
> In this case, it really has to do something. Is setting GUCs a path so
> critical it can't take one branch?
No, but that has about zero to do
Robert Haas writes:
> On Mon, Mar 25, 2019 at 10:15 AM David Fetter wrote:
>>> I do not believe this is practical either. GUC manipulation cannot
>>> look at the catalogs.
>> In this case, it really has to do something. Is setting GUCs a path so
>> critical it can't take one branch?
> No, but
Hi,
On 2019-03-25 13:53:32 -0400, Tom Lane wrote:
> One idea that might be useful is to have walsenders refuse to transmit
> any logical-replication data if they see wal_level is too low. That
> would get users' attention pretty quickly.
They do:
/*
* Load previously initiated logical slot an
Andres Freund writes:
> On 2019-03-25 13:53:32 -0400, Tom Lane wrote:
>> One idea that might be useful is to have walsenders refuse to transmit
>> any logical-replication data if they see wal_level is too low. That
>> would get users' attention pretty quickly.
> They do:
Oh, OK, then this seems
>> One idea that might be useful is to have walsenders refuse to transmit
> >> any logical-replication data if they see wal_level is too low. That
> >> would get users' attention pretty quickly.
>
> > They do:
>
I checked this before creating the patch
>
> Oh, OK, then this seems like it's basi
On Wed, Mar 27, 2019 at 1:36 AM Lucas Viecelli wrote:
>> Oh, OK, then this seems like it's basically covered already. I think
>> the original suggestion to add a WARNING during CREATE PUBLICATION
>> isn't unreasonable. But we don't need to do more than that (and it
>> shouldn't be higher than WA
Hi Thomas.
Attached is the rebased
> The July Commitfest has started. This patch is in "Needs review"
> status, but it doesn't apply. If I read the above discussion
> correctly, it seems there is agreement that a warning here is a good
> idea to commit this patch. Could you please post a reba
Follow the correct file, I added the wrong patch in the previous email
> Attached is the rebased
>
thanks a lot
*Lucas Viecelli*
diff --git a/src/backend/commands/publicationcmds.c b/src/backend/commands/publicationcmds.c
index 1ac1a71bd9..902180cedc 100644
--- a/src/backend/commands/publicati
On Tue, Jul 9, 2019 at 5:40 PM Lucas Viecelli wrote:
> Follow the correct file, I added the wrong patch in the previous email
New status: Ready for Committer. If nobody wants to bikeshed the
wording or other details, I will commit this tomorrow.
--
Thomas Munro
https://enterprisedb.com
Thomas Munro writes:
> New status: Ready for Committer. If nobody wants to bikeshed the
> wording or other details, I will commit this tomorrow.
Hm, so:
1.
+ errmsg("insufficient wal_level to publish logical
changes"),
Might read better as "wal_level is insufficient to
On Wed, Jul 10, 2019 at 12:47 PM Tom Lane wrote:
> 1.
>
> + errmsg("insufficient wal_level to publish logical
> changes"),
>
> Might read better as "wal_level is insufficient to publish logical changes"?
>
> 2.
>
> + errhint("Set wal_level to logical be
> Agreed, fixed. Also run through pgindent
>
Thank you for the adjustments.
> I agree that it's not really worth having tests for this, and I take
> your point about the dependency on wal_level that we don't currently
> have. The problem is that the core tests include publications
> already, a
Thomas Munro writes:
> On Wed, Jul 10, 2019 at 12:47 PM Tom Lane wrote:
>> 3. AFAICS, the proposed test case changes will cause the core regression
>> tests to fail if wal_level is not replica. This is not true today ---
>> they pass regardless of wal_level --- and I object in the strongest term
On Sat, Jul 13, 2019 at 3:21 AM Lucas Viecelli wrote:
>> Agreed, fixed. Also run through pgindent
>
> Thank you for the adjustments.
> All right, for me. If wal_level can not interfere with the testes result, it
> seems to a better approach
Pushed. Thanks for the patch!
--
Thomas Munro
http
On Thu, Mar 21, 2019 at 07:45:59PM -0300, Lucas Viecelli wrote:
> Hi everyone,
>
> A very common question among new users is how wal_level works and it
> levels. I heard about some situations like that, a user create a new
> publication in its master database and he/she simply does not change
> wa
David Fetter writes:
> On Thu, Mar 21, 2019 at 07:45:59PM -0300, Lucas Viecelli wrote:
>> I am sending a patch that when an PUBLICATION is created and the
>> wal_level is different from logical prints a WARNING in console/log:
> Is a WARNING sufficient? Maybe I'm misunderstanding something
> imp
>
> > Is a WARNING sufficient? Maybe I'm misunderstanding something
>
> important, but I think the attempt should fail with a HINT to set the
> > wal_level ahead of time.
>
I thought about this possibility, but I was afraid to change the current
behavior a lot, but it's worth discussing.
>
>
I
On Sun, Mar 24, 2019 at 02:06:59PM -0400, Tom Lane wrote:
> David Fetter writes:
> > On Thu, Mar 21, 2019 at 07:45:59PM -0300, Lucas Viecelli wrote:
> >> I am sending a patch that when an PUBLICATION is created and the
> >> wal_level is different from logical prints a WARNING in console/log:
>
>
On Mon, Mar 25, 2019 at 10:15 AM David Fetter wrote:
> > I do not believe this is practical either. GUC manipulation cannot
> > look at the catalogs.
>
> In this case, it really has to do something. Is setting GUCs a path so
> critical it can't take one branch?
No, but that has about zero to do
Robert Haas writes:
> On Mon, Mar 25, 2019 at 10:15 AM David Fetter wrote:
>>> I do not believe this is practical either. GUC manipulation cannot
>>> look at the catalogs.
>> In this case, it really has to do something. Is setting GUCs a path so
>> critical it can't take one branch?
> No, but
Hi,
On 2019-03-25 13:53:32 -0400, Tom Lane wrote:
> One idea that might be useful is to have walsenders refuse to transmit
> any logical-replication data if they see wal_level is too low. That
> would get users' attention pretty quickly.
They do:
/*
* Load previously initiated logical slot an
Andres Freund writes:
> On 2019-03-25 13:53:32 -0400, Tom Lane wrote:
>> One idea that might be useful is to have walsenders refuse to transmit
>> any logical-replication data if they see wal_level is too low. That
>> would get users' attention pretty quickly.
> They do:
Oh, OK, then this seems
>> One idea that might be useful is to have walsenders refuse to transmit
> >> any logical-replication data if they see wal_level is too low. That
> >> would get users' attention pretty quickly.
>
> > They do:
>
I checked this before creating the patch
>
> Oh, OK, then this seems like it's basi
On Wed, Mar 27, 2019 at 1:36 AM Lucas Viecelli wrote:
>> Oh, OK, then this seems like it's basically covered already. I think
>> the original suggestion to add a WARNING during CREATE PUBLICATION
>> isn't unreasonable. But we don't need to do more than that (and it
>> shouldn't be higher than WA
Hi Thomas.
Attached is the rebased
> The July Commitfest has started. This patch is in "Needs review"
> status, but it doesn't apply. If I read the above discussion
> correctly, it seems there is agreement that a warning here is a good
> idea to commit this patch. Could you please post a reba
Follow the correct file, I added the wrong patch in the previous email
> Attached is the rebased
>
thanks a lot
*Lucas Viecelli*
diff --git a/src/backend/commands/publicationcmds.c b/src/backend/commands/publicationcmds.c
index 1ac1a71bd9..902180cedc 100644
--- a/src/backend/commands/publicati
On Tue, Jul 9, 2019 at 5:40 PM Lucas Viecelli wrote:
> Follow the correct file, I added the wrong patch in the previous email
New status: Ready for Committer. If nobody wants to bikeshed the
wording or other details, I will commit this tomorrow.
--
Thomas Munro
https://enterprisedb.com
Thomas Munro writes:
> New status: Ready for Committer. If nobody wants to bikeshed the
> wording or other details, I will commit this tomorrow.
Hm, so:
1.
+ errmsg("insufficient wal_level to publish logical
changes"),
Might read better as "wal_level is insufficient to
On Wed, Jul 10, 2019 at 12:47 PM Tom Lane wrote:
> 1.
>
> + errmsg("insufficient wal_level to publish logical
> changes"),
>
> Might read better as "wal_level is insufficient to publish logical changes"?
>
> 2.
>
> + errhint("Set wal_level to logical be
> Agreed, fixed. Also run through pgindent
>
Thank you for the adjustments.
> I agree that it's not really worth having tests for this, and I take
> your point about the dependency on wal_level that we don't currently
> have. The problem is that the core tests include publications
> already, a
Thomas Munro writes:
> On Wed, Jul 10, 2019 at 12:47 PM Tom Lane wrote:
>> 3. AFAICS, the proposed test case changes will cause the core regression
>> tests to fail if wal_level is not replica. This is not true today ---
>> they pass regardless of wal_level --- and I object in the strongest term
On Sat, Jul 13, 2019 at 3:21 AM Lucas Viecelli wrote:
>> Agreed, fixed. Also run through pgindent
>
> Thank you for the adjustments.
> All right, for me. If wal_level can not interfere with the testes result, it
> seems to a better approach
Pushed. Thanks for the patch!
--
Thomas Munro
http
36 matches
Mail list logo
