st 30. 11. 2022 v 5:28 odesílatel Pavel Stehule
napsal:
>
>
> st 30. 11. 2022 v 1:38 odesílatel shashidhar Reddy <
> shashidharreddy...@gmail.com> napsal:
>
>> I have tried updating after upgrade but that wasn't working, so I have
>> dropped and recreated the extension.
>> Now it is crashing
st 30. 11. 2022 v 1:38 odesílatel shashidhar Reddy <
shashidharreddy...@gmail.com> napsal:
> I have tried updating after upgrade but that wasn't working, so I have
> dropped and recreated the extension.
> Now it is crashing every time when we call the function.
>
what is version od
I have tried updating after upgrade but that wasn't working, so I have
dropped and recreated the extension.
Now it is crashing every time when we call the function.
On Tue, 29 Nov, 2022, 9:58 pm Pavel Stehule,
wrote:
>
>
> út 29. 11. 2022 v 16:37 odesílatel shashidhar Reddy <
>
On Mon, Nov 28, 2022 at 9:18 AM Ron wrote:
> On 11/28/22 07:29, Arlo Louis O'Keeffe wrote:
> > Hello everyone,
> >
> > I am seeing weird behaviour of a delete statement that is returning more
> results than I am expecting.
> >
> > This is the query:
> >
> > DELETE FROM queue
> > WHERE
> >
Hello PostgreSQL users,
https://github.com/apache/age
Apache AGE is an Apache 2-licensed open source PostgreSQL extension for
storing Graph data.
The current version of Apache AGE is to enable PostgreSQL users to use
Neo4j's openCypher-based graph queries in unison with existing relational
Hello PostgreSQL users,
https://github.com/apache/age
Apache AGE is an Apache 2-licensed open source PostgreSQL extension for
storing Graph data.
The current version of Apache AGE is to enable PostgreSQL users to use
Neo4j's openCypher-based graph queries in unison with existing relational
Harmen writes:
> On Mon, Nov 28, 2022 at 12:11:53PM -0500, Tom Lane wrote:
>> So basically it's unsafe to run the sub-select more than once,
>> but the query as written leaves it up to the planner whether
>> to do that. I'd suggest rephrasing as [...]
> I'm not the original poster, but I do use
On Tue, Nov 29, 2022 at 12:01:01PM -0500, Tom Lane wrote:
> Yeah, I don't see that "cluster" adds anything. It's sometimes worth
> saying "database superuser" to ensure that you don't confuse people
> who might think of some external-to-Postgres meaning of "superuser",
> but otherwise plain
"David G. Johnston" writes:
> On Tue, Nov 29, 2022 at 9:31 AM Bruce Momjian wrote:
>> I know I am replying late here, but isn't it the database _cluster_
>> superuser?
> The "cluster" being implied doesn't seem like a big deal. The shorter term
> is nice. It doesn't seem worth changing all
On Tue, Nov 29, 2022 at 9:31 AM Bruce Momjian wrote:
>
> I know I am replying late here, but isn't it the database _cluster_
> superuser?
>
>
The "cluster" being implied doesn't seem like a big deal. The shorter term
is nice. It doesn't seem worth changing all the many, many, places in the
On Wed, Oct 26, 2022 at 09:57:50PM -0700, Adrian Klaver wrote:
> On 10/26/22 18:33, Bryn Llewellyn wrote:
> > The descriptive designation "the role that owns the SQL part of the
> > implementation of PostgreSQL" is too much of a mouthful for daily use.
> > And anyway, this notion captures only
út 29. 11. 2022 v 16:37 odesílatel shashidhar Reddy <
shashidharreddy...@gmail.com> napsal:
> Plogsql check version is 2.2 and one more finding is before calling the
> function if we drop and recreate the plpgsql_check extension there is no
> issue, but each time we can't drop and create.
>
On Mon, Nov 28, 2022 at 12:11:53PM -0500, Tom Lane wrote:
> So basically it's unsafe to run the sub-select more than once,
> but the query as written leaves it up to the planner whether
> to do that. I'd suggest rephrasing as
>
> WITH target_rows AS MATERIALIZED (
> SELECT id
> FROM
Plogsql check version is 2.2 and one more finding is before calling the
function if we drop and recreate the plpgsql_check extension there is no
issue, but each time we can't drop and create.
On Tue, 29 Nov, 2022, 7:19 pm shashidhar Reddy, <
shashidharreddy...@gmail.com> wrote:
> Hello Pavel,
>
Hello everyone!
I am hosting this month's #PGSQL Phriday. This monthly event inspires the
community to write about a specific topic.
I have chosen the topic "What is the PostgreSQL Community to you?"
You can find all the rules and details in the blog post below. I hope you
will consider
Hello Pavel,
This is the function causing the issue on all servers, and also i noticed
when I use *plpgsql_check_function *in any function I am facing the same
issue.
On Tue, Nov 29, 2022 at 6:43 PM Pavel Stehule
wrote:
> Hi
>
>
> út 29. 11. 2022 v 13:49 odesílatel shashidhar Reddy <
>
Hi
út 29. 11. 2022 v 13:49 odesílatel shashidhar Reddy <
shashidharreddy...@gmail.com> napsal:
> Hello,
>
> Recently we have upgraded postgres from version 12 to 13 and upgraded
> plpgsql_check
> to the latest version but after upgrade when calling the below function
> causing postgres
Hello,
Recently we have upgraded postgres from version 12 to 13 and upgraded
plpgsql_check
to the latest version but after upgrade when calling the below function
causing postgres restart .
CREATE OR REPLACE FUNCTION pro.po_check(
)
RETURNS void
LANGUAGE 'plpgsql'
COST 100
Hello all!
Thanks for the many hints to look for. We did some tuning and further
debugging and here are the outcomes, answering all questions in a single
email.
In the meantime, you could experiment with setting
checkpoint_flush_after to 0
We did this:
# SHOW checkpoint_flush_after;
19 matches
Mail list logo
