| From: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
|---|---|
| To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
| Cc: | Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Reducing the log spam |
| Date: | 2024-05-02 11:08:30 |
| Message-ID: | CAGECzQQWxim24gO1kmZbRrXGT0xqjFn7qbwHkm-48CA4k_Tu8Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 2 May 2024 at 12:47, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> 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 using SQL would be
much better. But having no way at all (by default) to find the cause
of the failure is clearly much worse.
> The feature will become much less useful if unique voilations keep getting logged.
Agreed. How about changing the patch so that the GUC is not applied to
logical replication apply workers (and document that accordingly). I
can think of two ways of achieving that (but there might be
other/better ones):
1. Set the GUC to empty string when an apply worker is started.
2. Change the newly added check in errcode() to only set
output_to_server to false when IsLogicalWorker() returns false.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jelte Fennema-Nio | 2024-05-02 11:11:44 | Re: Reducing the log spam |
| Previous Message | Laurenz Albe | 2024-05-02 10:47:45 | Re: Reducing the log spam |