On Mon, Feb 26, 2024 at 04:05:05PM +0100, Christoph Berg wrote:
> I tried that now. Mind that I'm not a benchmarking expert, and there's
> been quite some jitter in the results, but I think there's a clear
> trend.
>
> Even if we regard the 1873 as an outlier, I've seen many vanilla runs
> with
Re: Michael Paquier
> Something like this can be measured with a bunch of concurrent
> connections attempting connections and a very high rate, like pgbench
> with an empty script and -C, for local connections.
I tried that now. Mind that I'm not a benchmarking expert, and there's
been quite some
On Fri, Feb 23, 2024 at 04:39:47PM +0100, Christoph Berg wrote:
> I'd be concerned about the cost of doing that as part of the startup
> of every single backend process. Shouldn't this rather be done within
> the postmaster so it's automatically inherited by forked backends?
> (EXEC_BACKEND
Re: Michael Paquier
> >>• backtrace() and backtrace_symbols_fd() don't call malloc()
> >> explic‐
> >> itly, but they are part of libgcc, which gets loaded
> >> dynamically
> >> when first used. Dynamic loading usually triggers a call to
> >> mal‐
> >>
On Mon, Feb 12, 2024 at 6:52 AM Ashutosh Bapat
wrote:
>
> >
> > > We defer actual action triggered by a signal till CHECK_FOR_INTERRUPTS
> > > is called. I understand that we can't do that here since we want to
> > > capture the backtrace at that moment and can't wait till next CFI. But
> > >
On Sat, Feb 10, 2024 at 5:36 AM Michael Paquier wrote:
>
> On Fri, Feb 09, 2024 at 02:27:26PM +0530, Ashutosh Bapat wrote:
> > On Fri, Feb 9, 2024 at 2:18 PM Alvaro Herrera
> > wrote:
> >> Hmm, but the backtrace() manpage says
> >>
> >>• backtrace() and backtrace_symbols_fd() don't
On Fri, Feb 09, 2024 at 02:27:26PM +0530, Ashutosh Bapat wrote:
> On Fri, Feb 9, 2024 at 2:18 PM Alvaro Herrera wrote:
>> Hmm, but the backtrace() manpage says
>>
>>• backtrace() and backtrace_symbols_fd() don't call malloc() explic‐
>> itly, but they are part of libgcc,
On Fri, Feb 9, 2024 at 2:18 PM Alvaro Herrera wrote:
>
> On 2024-Feb-09, Michael Paquier wrote:
>
> > Anyway, I've been digging around the signal-safety of backtrace(3)
> > (even looking a bit at some GCC code, brrr), and I am under the
> > impression that backtrace() is just by nature not safe
On 2024-Feb-09, Michael Paquier wrote:
> Anyway, I've been digging around the signal-safety of backtrace(3)
> (even looking a bit at some GCC code, brrr), and I am under the
> impression that backtrace() is just by nature not safe and also
> dangerous in signal handlers. One example of issue
On Thu, Feb 08, 2024 at 12:25:18PM +0900, Michael Paquier wrote:
> In HandleLogBacktraceInterrupt(), we don't use backtrace_symbols() and
> rely on backtrace_symbols_fd() to avoid doing malloc() in the signal
> handler as mentioned in [1] back in 2022. Perhaps the part about the
> fact that we
On Thu, Feb 08, 2024 at 12:30:00AM +0530, Bharath Rupireddy wrote:
> I've missed adding LoadBacktraceFunctions() in InitAuxiliaryProcess
> for 0002 patch. Please find the attached v29 patch set. Sorry for the
> noise.
I've been torturing the patch with \watch and loops calling the
function while
On Wed, Feb 7, 2024 at 9:00 PM Bharath Rupireddy
wrote:
>
> On Wed, Feb 7, 2024 at 2:57 PM Michael Paquier wrote:
> >
> > On Wed, Feb 07, 2024 at 02:04:39PM +0530, Bharath Rupireddy wrote:
> > > Well, that 'ubuntu' is the default username there, I've changed it now
> > > and kept the output
On Wed, Feb 7, 2024 at 2:57 PM Michael Paquier wrote:
>
> On Wed, Feb 07, 2024 at 02:04:39PM +0530, Bharath Rupireddy wrote:
> > Well, that 'ubuntu' is the default username there, I've changed it now
> > and kept the output short.
>
> I would keep it just at two or three lines, with a "For
On Wed, Feb 07, 2024 at 02:04:39PM +0530, Bharath Rupireddy wrote:
> Well, that 'ubuntu' is the default username there, I've changed it now
> and kept the output short.
I would keep it just at two or three lines, with a "For example, with
lines like":
> I've simplified the tests, now we don't
On Tue, Feb 6, 2024 at 4:21 PM Michael Paquier wrote:
>
> --- a/src/backend/storage/ipc/procarray.c
> +++ b/src/backend/storage/ipc/procarray.c
> +bool
> +SendProcSignalBackendOrAuxproc(int pid, ProcSignalReason reason)
> +{
>
> Looking at 0001. This API is a thin wrapper of SendProcSignal(),
On Fri, Jan 26, 2024 at 11:58:00PM +0530, Bharath Rupireddy wrote:
> You probably were looking at v21, the above change isn't there in
> versions after that. Can you please review the latest version v26
> attached here?
>
> We might want this patch extended to the newly added walsummarizer
>
On Fri, Jan 26, 2024 at 4:11 PM Alvaro Herrera wrote:
>
Thanks for reviewing.
> > +You can get the file name and line number from the logged details by
> > using
> > +gdb/addr2line in linux platforms (users must ensure gdb/addr2line is
> > +already installed).
>
> This doesn't read
On 2022-Jan-27, vignesh C wrote:
> diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
> index 0ee6974f1c..855ccc8902 100644
> --- a/doc/src/sgml/func.sgml
> +++ b/doc/src/sgml/func.sgml
> +You can get the file name and line number from the logged details by
> using
> +
On Sun, 5 Nov 2023 at 01:49, Bharath Rupireddy
wrote:
>
> On Thu, Jul 20, 2023 at 8:22 PM Daniel Gustafsson wrote:
> >
> > > On 11 Jan 2023, at 15:44, Bharath Rupireddy
> > > wrote:
> > >
> > > On Wed, Nov 30, 2022 at 11:43 AM Bharath Rupireddy
> > > wrote:
> > >>
> > >> I'm attaching the v22
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, passed
I'm not sure if this actually still needs review, but it's
On Thu, Jul 20, 2023 at 8:22 PM Daniel Gustafsson wrote:
>
> > On 11 Jan 2023, at 15:44, Bharath Rupireddy
> > wrote:
> >
> > On Wed, Nov 30, 2022 at 11:43 AM Bharath Rupireddy
> > wrote:
> >>
> >> I'm attaching the v22 patch set for further review.
> >
> > Needed a rebase due to
> On 11 Jan 2023, at 15:44, Bharath Rupireddy
> wrote:
>
> On Wed, Nov 30, 2022 at 11:43 AM Bharath Rupireddy
> wrote:
>>
>> I'm attaching the v22 patch set for further review.
>
> Needed a rebase due to 216a784829c2c5f03ab0c43e009126cbb819e9b2.
> Attaching v23 patch set for further review.
On Wed, Nov 30, 2022 at 11:43 AM Bharath Rupireddy
wrote:
>
> I'm attaching the v22 patch set for further review.
Needed a rebase due to 216a784829c2c5f03ab0c43e009126cbb819e9b2.
Attaching v23 patch set for further review.
--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source
On Fri, Nov 11, 2022 at 6:04 PM Bharath Rupireddy
wrote:
>
> On Fri, Nov 11, 2022 at 7:59 AM Kyotaro Horiguchi
> wrote:
> >
> > At Thu, 10 Nov 2022 15:56:35 +0530, Bharath Rupireddy
> > wrote in
> > > On Mon, Apr 18, 2022 at 9:10 AM vignesh C wrote:
> > > >
> > > > The attached v21 patch has
On Fri, Nov 11, 2022 at 7:59 AM Kyotaro Horiguchi
wrote:
>
> At Thu, 10 Nov 2022 15:56:35 +0530, Bharath Rupireddy
> wrote in
> > On Mon, Apr 18, 2022 at 9:10 AM vignesh C wrote:
> > >
> > > The attached v21 patch has the changes for the same.
> >
> > Thanks for the patch. Here are some
At Thu, 10 Nov 2022 15:56:35 +0530, Bharath Rupireddy
wrote in
> On Mon, Apr 18, 2022 at 9:10 AM vignesh C wrote:
> >
> > The attached v21 patch has the changes for the same.
>
> Thanks for the patch. Here are some comments:
>
> 1. I think there's a fundamental problem with this patch, that
On Mon, Apr 18, 2022 at 9:10 AM vignesh C wrote:
>
> The attached v21 patch has the changes for the same.
Thanks for the patch. Here are some comments:
1. I think there's a fundamental problem with this patch, that is, it
prints the backtrace when the interrupt is processed but not when
On Fri, Apr 15, 2022 at 11:49 AM Kyotaro Horiguchi
wrote:
>
> At Thu, 14 Apr 2022 10:33:50 +0530, vignesh C wrote in
> > On Wed, Apr 6, 2022 at 12:29 PM vignesh C wrote:
> > >
> > > On Tue, Apr 5, 2022 at 9:18 PM Robert Haas wrote:
> > > > This looks like a grotty hack.
> > >
> > > I have
At Thu, 14 Apr 2022 10:33:50 +0530, vignesh C wrote in
> On Wed, Apr 6, 2022 at 12:29 PM vignesh C wrote:
> >
> > On Tue, Apr 5, 2022 at 9:18 PM Robert Haas wrote:
> > > This looks like a grotty hack.
> >
> > I have changed it so that the backtrace is set and returned to the
> > caller. The
On Wed, Apr 6, 2022 at 12:29 PM vignesh C wrote:
>
> On Tue, Apr 5, 2022 at 9:18 PM Robert Haas wrote:
> >
> > On Wed, Mar 30, 2022 at 12:03 PM Justin Pryzby wrote:
> > > On Wed, Mar 30, 2022 at 11:53:52AM -0400, Greg Stark wrote:
> > > > Sadly the cfbot is showing a patch conflict again. It's
On Tue, Apr 5, 2022 at 9:18 PM Robert Haas wrote:
>
> On Wed, Mar 30, 2022 at 12:03 PM Justin Pryzby wrote:
> > On Wed, Mar 30, 2022 at 11:53:52AM -0400, Greg Stark wrote:
> > > Sadly the cfbot is showing a patch conflict again. It's just a trivial
> > > conflict in the regression test schedule
On Wed, Mar 30, 2022 at 12:03 PM Justin Pryzby wrote:
> On Wed, Mar 30, 2022 at 11:53:52AM -0400, Greg Stark wrote:
> > Sadly the cfbot is showing a patch conflict again. It's just a trivial
> > conflict in the regression test schedule so I'm not going to update
> > the status but it would be
On Wed, Mar 30, 2022 at 11:53:52AM -0400, Greg Stark wrote:
> Sadly the cfbot is showing a patch conflict again. It's just a trivial
> conflict in the regression test schedule so I'm not going to update
> the status but it would be good to rebase it so we continue to get
> cfbot testing.
Done.
Sadly the cfbot is showing a patch conflict again. It's just a trivial
conflict in the regression test schedule so I'm not going to update
the status but it would be good to rebase it so we continue to get
cfbot testing.
On Wed, Mar 9, 2022 at 9:26 PM Justin Pryzby wrote:
>
> rebased to appease cfbot.
>
> + couple of little fixes as 0002.
Thanks for rebasing and fixing a few issues. I have taken all your
changes except for mcxtfuncs changes as those changes were not done as
part of this patch. Attached v19 patch
rebased to appease cfbot.
+ couple of little fixes as 0002.
--
Justin
>From 4be93f2bab460682a0f5af9e1e3f4970709b3517 Mon Sep 17 00:00:00 2001
From: Vigneshwaran C
Date: Tue, 25 Jan 2022 08:21:22 +0530
Subject: [PATCH 1/2] Add function to log the backtrace of the specified
postgres process.
On Sat, Jan 29, 2022 at 8:06 AM vignesh C wrote:
>
> On Fri, Jan 28, 2022 at 1:54 PM Bharath Rupireddy
> wrote:
> >
> > On Thu, Jan 27, 2022 at 10:45 AM vignesh C wrote:
> > >
> > > On Wed, Jan 26, 2022 at 11:07 AM Bharath Rupireddy
> > > wrote:
> > > >
> > > > On Tue, Jan 25, 2022 at 12:00 PM
On Fri, Jan 28, 2022 at 1:54 PM Bharath Rupireddy
wrote:
>
> On Thu, Jan 27, 2022 at 10:45 AM vignesh C wrote:
> >
> > On Wed, Jan 26, 2022 at 11:07 AM Bharath Rupireddy
> > wrote:
> > >
> > > On Tue, Jan 25, 2022 at 12:00 PM vignesh C wrote:
> > > > Thanks for the comments, attached v17 patch
On Thu, Jan 27, 2022 at 10:45 AM vignesh C wrote:
>
> On Wed, Jan 26, 2022 at 11:07 AM Bharath Rupireddy
> wrote:
> >
> > On Tue, Jan 25, 2022 at 12:00 PM vignesh C wrote:
> > > Thanks for the comments, attached v17 patch has the fix for the same.
> >
> > Have a minor comment on v17:
> >
> >
On Wed, Jan 26, 2022 at 11:07 AM Bharath Rupireddy
wrote:
>
> On Tue, Jan 25, 2022 at 12:00 PM vignesh C wrote:
> > Thanks for the comments, attached v17 patch has the fix for the same.
>
> Have a minor comment on v17:
>
> can we modify the elog(LOG, to new style ereport(LOG, ?
> +
On Tue, Jan 25, 2022 at 12:00 PM vignesh C wrote:
> Thanks for the comments, attached v17 patch has the fix for the same.
Have a minor comment on v17:
can we modify the elog(LOG, to new style ereport(LOG, ?
+ elog(LOG_SERVER_ONLY, "current backtrace:%s", errtrace.data);
/*--
*
On Mon, Jan 24, 2022 at 1:05 PM torikoshia wrote:
>
> On 2022-01-14 19:48, Bharath Rupireddy wrote:
> > On Sat, Nov 20, 2021 at 11:50 AM Bharath Rupireddy
> > wrote:
> >>
> >> On Fri, Nov 19, 2021 at 4:07 PM vignesh C wrote:
> >> > The Attached v15 patch has the fixes for the same.
> >>
> >>
On Mon, Jan 24, 2022 at 10:06 PM Fujii Masao
wrote:
>
>
>
> On 2022/01/24 16:35, torikoshia wrote:
> > On 2022-01-14 19:48, Bharath Rupireddy wrote:
> >> On Sat, Nov 20, 2021 at 11:50 AM Bharath Rupireddy
> >> wrote:
> >>>
> >>> On Fri, Nov 19, 2021 at 4:07 PM vignesh C wrote:
> >>> > The
On 2022/01/24 16:35, torikoshia wrote:
On 2022-01-14 19:48, Bharath Rupireddy wrote:
On Sat, Nov 20, 2021 at 11:50 AM Bharath Rupireddy
wrote:
On Fri, Nov 19, 2021 at 4:07 PM vignesh C wrote:
> The Attached v15 patch has the fixes for the same.
Thanks. The v15 patch LGTM and the cf bot
On 2022-01-14 19:48, Bharath Rupireddy wrote:
On Sat, Nov 20, 2021 at 11:50 AM Bharath Rupireddy
wrote:
On Fri, Nov 19, 2021 at 4:07 PM vignesh C wrote:
> The Attached v15 patch has the fixes for the same.
Thanks. The v15 patch LGTM and the cf bot is happy hence marking it as
RfC.
The
On Sat, Nov 20, 2021 at 11:50 AM Bharath Rupireddy
wrote:
>
> On Fri, Nov 19, 2021 at 4:07 PM vignesh C wrote:
> > The Attached v15 patch has the fixes for the same.
>
> Thanks. The v15 patch LGTM and the cf bot is happy hence marking it as RfC.
The patch was not applying because of the recent
On Fri, Nov 19, 2021 at 4:07 PM vignesh C wrote:
> The Attached v15 patch has the fixes for the same.
Thanks. The v15 patch LGTM and the cf bot is happy hence marking it as RfC.
Regards,
Bharath Rupireddy.
On Thu, Nov 18, 2021 at 9:52 PM Justin Pryzby wrote:
>
> On Wed, Nov 17, 2021 at 08:12:44PM +0530, vignesh C wrote:
> > Attached v14 patch has the fixes for the same.
>
> Thanks for updating the patch.
>
> I cleaned up the docs and comments. I think this could be nearly "Ready".
>
> If you like
On Wed, Nov 17, 2021 at 08:12:44PM +0530, vignesh C wrote:
> Attached v14 patch has the fixes for the same.
Thanks for updating the patch.
I cleaned up the docs and comments. I think this could be nearly "Ready".
If you like the changes in my "fixup" patch (0002 and 0004), you should be able
On Tue, Nov 16, 2021 at 1:12 AM Justin Pryzby wrote:
>
> On Mon, Nov 15, 2021 at 09:12:49PM +0530, vignesh C wrote:
> > The idea here is to implement & expose pg_print_backtrace function,
> > internally
>
> This patch is closely related to this one
> https://commitfest.postgresql.org/35/3142/
>
On Tue, Nov 16, 2021 at 1:12 AM Justin Pryzby wrote:
>
> On Mon, Nov 15, 2021 at 09:12:49PM +0530, vignesh C wrote:
> > The idea here is to implement & expose pg_print_backtrace function,
> > internally
>
> This patch is closely related to this one
> https://commitfest.postgresql.org/35/3142/
>
On Mon, Nov 15, 2021 at 09:12:49PM +0530, vignesh C wrote:
> The idea here is to implement & expose pg_print_backtrace function, internally
This patch is closely related to this one
https://commitfest.postgresql.org/35/3142/
| Logging plan of the currently running query
I suggest to review that
On Mon, Nov 15, 2021 at 11:37 AM Dilip Kumar wrote:
>
> On Mon, Nov 15, 2021 at 10:34 AM vignesh C wrote:
>
> >
> > Thanks for the comments, the attached v12 patch has the changes for the
> > same.
>
> I have reviewed this patch and have some comments on v12-0001,
>
> 1.
> +This feature
On Mon, Nov 15, 2021 at 12:08 PM Dilip Kumar wrote:
> > > 2.
> > > postgres[64154]=# select pg_print_backtrace(64136);
> > > WARNING: 01000: PID 64136 is not a PostgreSQL server process
> > > LOCATION: pg_print_backtrace, signalfuncs.c:335
> > > pg_print_backtrace
> > >
>
On Mon, Nov 15, 2021 at 12:13 PM vignesh C wrote:
>
> On Mon, Nov 15, 2021 at 11:00 AM Bharath Rupireddy
> wrote:
> >
> > On Mon, Nov 15, 2021 at 10:34 AM vignesh C wrote:
> > > > 2) I think "which is enough because the target process for logging of
> > > > backtrace is a backend" isn't valid
On Mon, Nov 15, 2021 at 11:00 AM Bharath Rupireddy
wrote:
>
> On Mon, Nov 15, 2021 at 10:34 AM vignesh C wrote:
> > > 2) I think "which is enough because the target process for logging of
> > > backtrace is a backend" isn't valid anymore with 0002, righit? Please
> > > remove it.
> > > + * to
On Mon, Nov 15, 2021 at 11:53 AM Bharath Rupireddy
wrote:
>
> On Mon, Nov 15, 2021 at 11:37 AM Dilip Kumar wrote:
> >
> > On Mon, Nov 15, 2021 at 10:34 AM vignesh C wrote:
> >
> > >
> > > Thanks for the comments, the attached v12 patch has the changes for the
> > > same.
> >
> > I have
On Mon, Nov 15, 2021 at 11:37 AM Dilip Kumar wrote:
>
> On Mon, Nov 15, 2021 at 10:34 AM vignesh C wrote:
>
> >
> > Thanks for the comments, the attached v12 patch has the changes for the
> > same.
>
> I have reviewed this patch and have some comments on v12-0001,
>
> 1.
> +This feature
On Mon, Nov 15, 2021 at 10:34 AM vignesh C wrote:
>
> Thanks for the comments, the attached v12 patch has the changes for the same.
I have reviewed this patch and have some comments on v12-0001,
1.
+This feature is not supported for the postmaster, logger, checkpointer,
+
On Mon, Nov 15, 2021 at 10:34 AM vignesh C wrote:
> > 2) I think "which is enough because the target process for logging of
> > backtrace is a backend" isn't valid anymore with 0002, righit? Please
> > remove it.
> > + * to call this function if we see PrintBacktracePending set. It is called
> >
On Mon, Nov 15, 2021 at 7:37 AM Bharath Rupireddy
wrote:
>
> On Sun, Nov 14, 2021 at 8:49 PM vignesh C wrote:
> > > 7) Do we need TAP tests for this function? I think it is sufficient to
> > > test the function in misc_functions.sql, please remove
> > > 002_print_backtrace_validation.pl. Note
On Sun, Nov 14, 2021 at 8:49 PM vignesh C wrote:
> > 7) Do we need TAP tests for this function? I think it is sufficient to
> > test the function in misc_functions.sql, please remove
> > 002_print_backtrace_validation.pl. Note that we don't do similar TAP
> > testing for
On Fri, Nov 12, 2021 at 6:11 PM Bharath Rupireddy
wrote:
>
> On Fri, Nov 12, 2021 at 5:15 PM Bharath Rupireddy
> wrote:
> >
> > On Thu, Nov 11, 2021 at 12:14 PM vignesh C wrote:
> > > Thanks for the comments, the attached v10 patch has the fixes for the
> > > same.
> >
> > Thanks for the
On Fri, Nov 12, 2021 at 5:15 PM Bharath Rupireddy
wrote:
>
> On Thu, Nov 11, 2021 at 12:14 PM vignesh C wrote:
> > Thanks for the comments, the attached v10 patch has the fixes for the same.
>
> Thanks for the patches. Here are some comments:
>
> 1) In the docs, let's have the similar
On Fri, Nov 12, 2021 at 5:15 PM Bharath Rupireddy
wrote:
>
> On Thu, Nov 11, 2021 at 12:14 PM vignesh C wrote:
> > Thanks for the comments, the attached v10 patch has the fixes for the same.
>
> Thanks for the patches. Here are some comments:
>
> 1) In the docs, let's have the similar
On Thu, Nov 11, 2021 at 12:14 PM vignesh C wrote:
> Thanks for the comments, the attached v10 patch has the fixes for the same.
Thanks for the patches. Here are some comments:
1) In the docs, let's have the similar description of
pg_log_backend_memory_contexts for pg_print_backtrace, just for
On Wed, Nov 10, 2021 at 12:17 PM Bharath Rupireddy
wrote:
>
> On Tue, Nov 9, 2021 at 4:45 PM vignesh C wrote:
> > Thanks for reporting this, the attached v9 patch has the changes for the
> > same.
>
> Thanks for the v9 patch. I have some comments:
>
> 1) I think we are moving away from if
On Tue, Nov 9, 2021 at 4:45 PM vignesh C wrote:
> Thanks for reporting this, the attached v9 patch has the changes for the same.
Thanks for the v9 patch. I have some comments:
1) I think we are moving away from if (!superuser()) checks, see the
commit [1]. The goal is to let the GRANT-REVOKE
On Tue, Oct 12, 2021 at 10:47 AM bt21tanigaway
wrote:
>
> Hi,
>
> > The previous patch was failing because of the recent test changes made
> > by commit 201a76183e2 which unified new and get_new_node, attached
> > patch has the changes to handle the changes accordingly.
> > Thanks for your
On Thu, Nov 4, 2021 at 4:06 PM Daniel Gustafsson wrote:
>
> > On 26 Aug 2021, at 16:56, vignesh C wrote:
>
> > The previous patch was failing because of the recent test changes made
> > by commit 201a76183e2 which unified new and get_new_node, attached
> > patch has the changes to handle the
> On 26 Aug 2021, at 16:56, vignesh C wrote:
> The previous patch was failing because of the recent test changes made
> by commit 201a76183e2 which unified new and get_new_node, attached
> patch has the changes to handle the changes accordingly.
This patch now fails because of the test changes
Hi,
The previous patch was failing because of the recent test changes made
by commit 201a76183e2 which unified new and get_new_node, attached
patch has the changes to handle the changes accordingly.
Thanks for your update!
I have two comments.
1.Do we need “set_backtrace(NULL, 0);” on
On Wed, Jul 21, 2021 at 10:56 PM vignesh C wrote:
>
> On Wed, Jul 21, 2021 at 3:52 PM Bharath Rupireddy
> wrote:
> >
> > On Tue, Jul 13, 2021 at 9:03 PM vignesh C wrote:
> > >
> > > On Wed, May 12, 2021 at 2:27 AM Robert Haas wrote:
> > > >
> > > > Maybe we should have a role that is
On Wed, Jul 21, 2021 at 3:52 PM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
>
> On Tue, Jul 13, 2021 at 9:03 PM vignesh C wrote:
> >
> > On Wed, May 12, 2021 at 2:27 AM Robert Haas
wrote:
> > >
> > > Maybe we should have a role that is specifically for server debugging
> >
On Tue, Jul 13, 2021 at 9:03 PM vignesh C wrote:
>
> On Wed, May 12, 2021 at 2:27 AM Robert Haas wrote:
> >
> > Maybe we should have a role that is specifically for server debugging
> > type things. This kind of overlaps with Mark Dilger's proposal to try
> > to allow SET for security-sensitive
On Wed, May 12, 2021 at 2:27 AM Robert Haas wrote:
>
> On Thu, May 6, 2021 at 3:31 PM Tom Lane wrote:
> > Andres Freund writes:
> > > On 2021-05-06 14:56:09 -0400, Tom Lane wrote:
> > >> If we think it's worth having a predefined role for, OK. However,
> > >> I don't like the future I see us
On Thu, May 6, 2021 at 3:31 PM Tom Lane wrote:
> Andres Freund writes:
> > On 2021-05-06 14:56:09 -0400, Tom Lane wrote:
> >> If we think it's worth having a predefined role for, OK. However,
> >> I don't like the future I see us heading towards where there are
> >> hundreds of random
Hi,
On 2021-05-06 15:22:02 -0400, Tom Lane wrote:
> Andres Freund writes:
> > we allow generating backtraces in all kind of places, including
> > e.g. some inside critical sections via backtrace_functions.
>
> If there's an elog call inside a critical section, that seems
> like a problem
Hi,
On 2021-05-06 15:31:02 -0400, Tom Lane wrote:
> I'd probably vote for pg_read_all_data, considering that much of
> the concern about this has to do with the possibility of exposure
> of sensitive data. I'm not quite sure what the security expectations
> are for pg_monitor.
I was wondering
Andres Freund writes:
> On 2021-05-06 14:56:09 -0400, Tom Lane wrote:
>> If we think it's worth having a predefined role for, OK. However,
>> I don't like the future I see us heading towards where there are
>> hundreds of random predefined roles. Is there an existing role
>> that it'd be
Andres Freund writes:
> On 2021-05-06 14:38:51 -0400, Robert Haas wrote:
>> On Wed, Feb 3, 2021 at 2:30 AM Tom Lane wrote:
>>> This point is entirely separate from the question of whether
>>> triggering stack traces at inopportune moments could cause system
>>> malfunctions, but that question is
Hi,
On 2021-05-06 14:56:09 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Feb 3, 2021 at 2:30 AM Tom Lane wrote:
> >> TBH, I'm leaning to the position that this should be superuser
> >> only.
>
> > I agree that ordinary users shouldn't be able to trigger it, but I
> > think it should
Hi,
On 2021-05-06 14:38:51 -0400, Robert Haas wrote:
> On Wed, Feb 3, 2021 at 2:30 AM Tom Lane wrote:
> > This point is entirely separate from the question of whether
> > triggering stack traces at inopportune moments could cause system
> > malfunctions, but that question is also not to be
Robert Haas writes:
> On Wed, Feb 3, 2021 at 2:30 AM Tom Lane wrote:
>> TBH, I'm leaning to the position that this should be superuser
>> only.
> I agree that ordinary users shouldn't be able to trigger it, but I
> think it should be restricted to some predefined role, new or
> existing, rather
On Wed, Feb 3, 2021 at 2:30 AM Tom Lane wrote:
> A backtrace normally exposes the text of the current query, for
> instance, which could contain very sensitive data (passwords in ALTER
> USER, customer credit card numbers in ordinary data, etc etc). We
> don't allow the postmaster log to be seen
On Thu, May 6, 2021 at 7:43 AM Justin Pryzby wrote:
>
> Here's a cleaned-up copy of the doc text.
>
> Send a request to the backend with the specified process ID to log its
> backtrace.
> The backtrace will be logged at message level LOG.
> It will appear in the server log based on the log
Here's a cleaned-up copy of the doc text.
Send a request to the backend with the specified process ID to log its
backtrace.
The backtrace will be logged at message level LOG.
It will appear in the server log based on the log configuration set
(See for more information),
but will not be sent to
On Wed, Feb 3, 2021 at 3:24 PM Bharath Rupireddy
wrote:
>
> On Wed, Feb 3, 2021 at 1:49 PM vignesh C wrote:
> >
> > On Wed, Feb 3, 2021 at 1:00 PM Tom Lane wrote:
> > >
> > > vignesh C writes:
> > > > On Mon, Feb 1, 2021 at 11:04 AM Bharath Rupireddy
> > > > wrote:
> > > >> Are these
On 2021-03-04 21:55, Bharath Rupireddy wrote:
On Mon, Mar 1, 2021 at 10:43 AM torikoshia
wrote:
Since the current patch use BackendPidGetProc(), it does not
support this feature not only postmaster, logging, and
statistics but also checkpointer, background writer, and
walwriter.
And when I
On Mon, Mar 1, 2021 at 10:43 AM torikoshia wrote:
> Since the current patch use BackendPidGetProc(), it does not
> support this feature not only postmaster, logging, and
> statistics but also checkpointer, background writer, and
> walwriter.
>
> And when I specify pid of these PostgreSQL
Hi,
I also think this feature would be useful when supporting
environments that lack debugger or debug symbols.
I think such environments are not rare.
+ for more information.
This
+will help in identifying where exactly the backend process is
currently
+executing.
On Wed, Feb 3, 2021 at 1:49 PM vignesh C wrote:
>
> On Wed, Feb 3, 2021 at 1:00 PM Tom Lane wrote:
> >
> > vignesh C writes:
> > > On Mon, Feb 1, 2021 at 11:04 AM Bharath Rupireddy
> > > wrote:
> > >> Are these superuser and permission checks enough from a security
> > >> standpoint that we
On Wed, Feb 3, 2021 at 1:00 PM Tom Lane wrote:
>
> vignesh C writes:
> > On Mon, Feb 1, 2021 at 11:04 AM Bharath Rupireddy
> > wrote:
> >> Are these superuser and permission checks enough from a security
> >> standpoint that we don't expose some sensitive information to the
> >> user?
>
> >
vignesh C writes:
> On Mon, Feb 1, 2021 at 11:04 AM Bharath Rupireddy
> wrote:
>> Are these superuser and permission checks enough from a security
>> standpoint that we don't expose some sensitive information to the
>> user?
> This will just print the backtrace of the current backend. Users
>
On Mon, Feb 1, 2021 at 11:04 AM Bharath Rupireddy
wrote:
>
> On Mon, Feb 1, 2021 at 6:14 AM Bharath Rupireddy
> wrote:
> > On Fri, Jan 29, 2021 at 7:10 PM vignesh C wrote:
> > > > 4) How about following
> > > > + errmsg("must be a superuser to print backtrace
> > > > of
Thanks Bharath for your comments.
On Mon, Feb 1, 2021 at 6:14 AM Bharath Rupireddy
wrote:
>
> On Fri, Jan 29, 2021 at 7:10 PM vignesh C wrote:
> > > 4) How about following
> > > + errmsg("must be a superuser to print backtrace
> > > of backend process")));
> > > instead of
>
On Fri, Jan 29, 2021 at 7:10 PM vignesh C wrote:
>
> Thanks Bharath for your review comments. Please find my comments inline below.
>
> On Thu, Jan 28, 2021 at 7:40 PM Bharath Rupireddy
> wrote:
> >
> > On Thu, Jan 28, 2021 at 5:22 PM vignesh C wrote:
> > > Thanks for the comments, I have fixed
At Fri, 29 Jan 2021 19:10:24 +0530, vignesh C wrote in
> Attached v5 patch has the fixes for the same.
PMSIGNAL_BACKTRACE_EMIT is not used anywhere?
(the commit message seems stale.)
+++ b/src/bin/pg_ctl/t/005_backtrace.pl
pg_ctl doesn't (or no longer?) seem relevant to this patch.
+
On Mon, Feb 1, 2021 at 6:14 AM Bharath Rupireddy
wrote:
> On Fri, Jan 29, 2021 at 7:10 PM vignesh C wrote:
> > > 4) How about following
> > > + errmsg("must be a superuser to print backtrace
> > > of backend process")));
> > > instead of
> > > +
On Fri, Jan 29, 2021 at 7:10 PM vignesh C wrote:
> > 4) How about following
> > + errmsg("must be a superuser to print backtrace
> > of backend process")));
> > instead of
> > + errmsg("must be a superuser to print backtrace
> > of superuser query
1 - 100 of 135 matches
Mail list logo
