Hi all,
While reading the code of pg_log_backend_memory_contexts(), I have
been surprised to see that the code would attempt to look at a PROC
entry based on the given input PID *before* checking if the function
has been called by a superuser. This does not strike me as a good
idea as this allows
On Sat, May 01, 2021 at 03:24:58PM +0800, Julien Rouhaud wrote:
>
> I'm attaching some POC patches that implement this approach to start a
> discussion.
I just noticed that the cfbot fails with the v1 patch. Attached v2 that should
fix that.
>From db68ec4dd0f0590db2275f0ca99ec24948983462 Mon Sep
On Tue, Nov 03, 2020 at 07:22:14PM -0500, Tom Lane wrote:
> I feel like this is committable at this point --- any objections?
(This became commit 40c24bf, "Improve our ability to regurgitate SQL-syntax
function calls.")
> --- a/src/backend/nodes/equalfuncs.c
> +++ b/src/backend/nodes/equalfuncs.c
On Fri, May 7, 2021 at 6:44 PM vignesh C wrote:
>
> On Fri, May 7, 2021 at 5:44 PM Dilip Kumar wrote:
> >
> > On Fri, May 7, 2021 at 5:38 PM Bharath Rupireddy
> > wrote:
> > >
> > > On Fri, May 7, 2021 at 11:50 AM Dilip Kumar wrote:
> > > >
> > > > On Thu, May 6, 2021 at 7:22 PM vignesh C wrot
On Sat, Mar 27, 2021 at 01:17:14AM +0100, Tomas Vondra wrote:
> OK, pushed after a bit more polishing and testing.
This added a "transformed" field to CreateStatsStmt, but it didn't mention
that field in src/backend/nodes. Should those functions handle the field?
On Wed, Apr 07, 2021 at 09:55:40PM +0200, Peter Eisentraut wrote:
> Committed. Thanks!
I get a NULL pointer dereference if the function body has a doubled semicolon:
create function f() returns int language sql begin atomic select 1;; end;
Program received signal SIGSEGV, Segmentation fault.
On Fri, Jun 04, 2021 at 07:21:11PM -0400, Alvaro Herrera wrote:
> On 2021-Jun-04, Tom Lane wrote:
>
> > Alvaro Herrera writes:
>
> > > Now, while this patch does seem to work correctly, it raises a number of
> > > weird cpluspluscheck warnings, which I think are attributable to the
> > > new mac
On Sat, Jun 05, 2021 at 12:06:46PM +0530, Bharath Rupireddy wrote:
> On Sat, Jun 5, 2021 at 7:02 AM Noah Misch wrote:
> > On Tue, Jun 01, 2021 at 01:25:24PM +0530, Bharath Rupireddy wrote:
> > > On Tue, Jun 1, 2021 at 9:19 AM Noah Misch wrote:
> > > > Given that limitation, is pg_wait_for_backend
On Fri, Jun 4, 2021 at 4:14 PM Jacob Champion wrote:
> On Tue, 2021-06-01 at 15:38 +0300, Aleksander Alekseev wrote:
> > I came across this patch and noticed that it rotted a little,
> > especially after removing inheritance_planner() in 86dc9005. I
> > managed to resolve the conflicts on current
On 2021-Jun-04, Noah Misch wrote:
> On Fri, Apr 09, 2021 at 05:16:11PM -0400, Alvaro Herrera wrote:
> > Pushed now.
>
> This added a PQtraceSetFlags() function. We have a dozen PQset*() functions,
> but this and PQresultSetInstanceData() are the only PQSomethingSet()
> functions. Is it okay if
serinus has been complaining about the new gcd functions in 13~:
moonjelly, which also runs a bleeding-edge gcc, started to fail the same
way at about the same time. Given that none of our code in that area
has changed, it's hard to think it's anything but a broken compiler.
Maybe somebod
> Alvaro Herrera writes:
> > Now, while this patch does seem to work correctly, it raises a number of
> > weird cpluspluscheck warnings, which I think are attributable to the
> > new macro definitions. I didn't look into it closely, but I suppose it
> > should be fixable given sufficient effort:
> On Jun 5, 2021, at 2:29 AM, Peter Eisentraut
> wrote:
>
> On 04.06.21 22:24, David Christensen wrote:
>> So what are the necessary and sufficient conditions to check at this point?
>> The constraint already exists, so what permissions would we need to check
>> against which table(s) in o
On Sat, 5 Jun 2021 at 03:30, Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 03.06.21 22:49, David Christensen wrote:
> > Presented for discussion is a POC for a DELETE CASCADE functionality,
> > which will allow you one-shot usage of treating existing NO ACTION and
> > RESTRICT
> On Jun 5, 2021, at 2:30 AM, Peter Eisentraut
> wrote:
>
> On 03.06.21 22:49, David Christensen wrote:
>> Presented for discussion is a POC for a DELETE CASCADE functionality, which
>> will allow you one-shot usage of treating existing NO ACTION and RESTRICT FK
>> constraints as if they we
Hi,
I have observed the following behavior with PostgreSQL 13.3.
The WAL sender process sends approximately 500 keepalive messages per
second to pg_recvlogical.
These keepalive messages are totally un-necessary.
Keepalives should be sent only if there is no network traffic and a certain
time (half
On Sat, Jun 5, 2021 at 4:08 AM Peter Eisentraut
wrote:
>
> On 04.06.21 06:28, Julien Rouhaud wrote:
> > Yes, but we have a lot a examples of functions without pg_nodiscard and
> > callers
> > still explicitly ignoring the results, like fsm_vacuum_page() in the same
> > file.
> > It would be more
On 03.06.21 22:49, David Christensen wrote:
Presented for discussion is a POC for a DELETE CASCADE functionality,
which will allow you one-shot usage of treating existing NO ACTION and
RESTRICT FK constraints as if they were originally defined as CASCADE
constraints. I can't tell you how many
On 04.06.21 22:24, David Christensen wrote:
So what are the necessary and sufficient conditions to check at this
point? The constraint already exists, so what permissions would we need
to check against which table(s) in order to grant this action?
I think you would need DELETE privilege on al
19 matches
Mail list logo
