On Thu, 25 Jul 2024 at 18:03, Laurenz Albe wrote:
> Thanks for the review!
>
> On Wed, 2024-07-24 at 15:27 +0200, Rafia Sabih wrote:
> > I liked the idea for this patch. I will also go for the default being
> > an empty string.
> > I went through this patch and have some comments on the code,
> >
Thanks for the review!
On Wed, 2024-07-24 at 15:27 +0200, Rafia Sabih wrote:
> I liked the idea for this patch. I will also go for the default being
> an empty string.
> I went through this patch and have some comments on the code,
>
> 1. In general, I don't like the idea of goto, maybe we can ha
Hello Laurenz,
I liked the idea for this patch. I will also go for the default being
an empty string.
I went through this patch and have some comments on the code,
1. In general, I don't like the idea of goto, maybe we can have a
free_something function to call here.
2.
if (!SplitIdentifierStrin
On Mon, 2024-06-17 at 16:40 -0500, Justin Pryzby wrote:
> > The feature will become much less useful if unique voilations keep getting
> > logged.
>
> Uh, to be clear, your patch is changing the *defaults*, which I found
> surprising, even after reaading the thread. Evidently, the current
> beha
On Thu, May 02, 2024 at 12:47:45PM +0200, Laurenz Albe wrote:
> On Mon, 2024-03-11 at 09:33 +0100, Jelte Fennema-Nio wrote:
> > - the subscriber's server log.
> > + the subscriber's server log if you remove 23505 from
> > + .
> >
> > This seems like a pretty big regression. Being able to kno
On Thu, 2024-05-02 at 13:11 +0200, Jelte Fennema-Nio wrote:
> On Thu, 2 May 2024 at 13:08, Jelte Fennema-Nio wrote:
> > 2. Change the newly added check in errcode() to only set
> > output_to_server to false when IsLogicalWorker() returns false.
>
> Actually a third, and probably even better solut
On Thu, 2 May 2024 at 13:08, Jelte Fennema-Nio wrote:
> 2. Change the newly added check in errcode() to only set
> output_to_server to false when IsLogicalWorker() returns false.
Actually a third, and probably even better solution would be to only
apply this new GUC to non-backgroundworker proces
On Thu, 2 May 2024 at 12:47, Laurenz Albe wrote:
> Yes. But I'd argue that that is a shortcoming of logical replication:
> there should be a ways to get this information via SQL. Having to look into
> the log file is not a very useful option.
Definitely agreed that accessing the error details u
On Mon, 2024-03-11 at 09:33 +0100, Jelte Fennema-Nio wrote:
> - the subscriber's server log.
> + the subscriber's server log if you remove 23505 from
> + .
>
> This seems like a pretty big regression. Being able to know why your
> replication got closed seems pretty critical.
Yes. But I'd
On Mon, 2024-03-11 at 09:33 +0100, Jelte Fennema-Nio wrote:
> - the subscriber's server log.
> + the subscriber's server log if you remove 23505 from
> + .
>
> This seems like a pretty big regression. Being able to know why your
> replication got closed seems pretty critical.
The actual SQL
- the subscriber's server log.
+ the subscriber's server log if you remove 23505 from
+ .
This seems like a pretty big regression. Being able to know why your
replication got closed seems pretty critical.
On Mon, 11 Mar 2024 at 03:44, Laurenz Albe wrote:
>
> On Sat, 2024-03-09 at 14:03 +01
On Sat, 2024-03-09 at 14:03 +0100, Laurenz Albe wrote:
> Here is a patch that implements this.
And here is patch v2 that fixes a bug and passes the regression tests.
Yours,
Laurenz Albe
From 6c72ea7d0aa1df569a4e53f54fcb1a11542ac0ef Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Mon, 11 Mar 20
On Thu, 2024-03-07 at 08:30 +0100, Laurenz Albe wrote:
> On Wed, 2024-03-06 at 17:33 -0500, Isaac Morland wrote:
> > I have two questions about this:
> >
> > First, can it be done per role? If I have a particular application which is
> > constantly throwing some particular error, I might want to s
On Wed, 2024-03-06 at 17:33 -0500, Isaac Morland wrote:
> I have two questions about this:
>
> First, can it be done per role? If I have a particular application which is
> constantly throwing some particular error, I might want to suppress it, but
> not suppress the same error occasionally coming
On Tue, 5 Mar 2024 at 07:55, Laurenz Albe wrote:
> Inspired by feedback to [1], I thought about how to reduce log spam.
>
> My experience from the field is that a lot of log spam looks like
>
> database/table/... "xy" does not exist
> duplicate key value violates unique constraint "xy"
>
> So
On Wed, 2024-03-06 at 10:50 -0500, Greg Sabino Mullane wrote:
> On Tue, Mar 5, 2024 at 7:55 AM Laurenz Albe wrote:
> > My experience from the field is that a lot of log spam looks like
> >
> > database/table/... "xy" does not exist
> > duplicate key value violates unique constraint "xy"
>
>
On Wed, 2024-03-06 at 17:09 +0300, Aleksander Alekseev wrote:
> I like the idea of suppressing certain log messages in general, but
> the particular user interface doesn't strike me as an especially
> convenient one.
>
> Firstly I don't think many people remember sqlstates and what 3F000
> stands
On Tue, Mar 5, 2024 at 7:55 AM Laurenz Albe
wrote:
> My experience from the field is that a lot of log spam looks like
>
> database/table/... "xy" does not exist
> duplicate key value violates unique constraint "xy"
Forcibly hiding those at the Postgres level seems a heavy hammer for what
i
Hi,
> So what about a parameter "log_suppress_sqlstates" that suppresses
> logging ERROR and FATAL messages with the enumerated SQL states?
>
> My idea for a default setting would be something like
>
> log_suppress_sqlstates = '23505,3D000,3F000,42601,42704,42883,42P01'
>
> but that's of course
On Tue, 5 Mar 2024 at 14:55, Jim Jones wrote:
> > So what about a parameter "log_suppress_sqlstates" that suppresses
> > logging ERROR and FATAL messages with the enumerated SQL states?
Big +1 from me for this idea.
Hi
út 5. 3. 2024 v 14:55 odesílatel Jim Jones
napsal:
> Hi Laurenz
>
> On 05.03.24 13:55, Laurenz Albe wrote:
> > Inspired by feedback to [1], I thought about how to reduce log spam.
> >
> > My experience from the field is that a lot of log spam looks like
> >
> >database/table/... "xy" does
Hi Laurenz
On 05.03.24 13:55, Laurenz Albe wrote:
Inspired by feedback to [1], I thought about how to reduce log spam.
My experience from the field is that a lot of log spam looks like
database/table/... "xy" does not exist
duplicate key value violates unique constraint "xy"
So what abo
Hi
út 5. 3. 2024 v 13:55 odesílatel Laurenz Albe
napsal:
> Inspired by feedback to [1], I thought about how to reduce log spam.
>
> My experience from the field is that a lot of log spam looks like
>
> database/table/... "xy" does not exist
> duplicate key value violates unique constraint "x
Inspired by feedback to [1], I thought about how to reduce log spam.
My experience from the field is that a lot of log spam looks like
database/table/... "xy" does not exist
duplicate key value violates unique constraint "xy"
So what about a parameter "log_suppress_sqlstates" that suppresses
24 matches
Mail list logo