On Mon, Oct 2, 2023 at 1:24 PM Amit Langote wrote:
> Pushed this 30 min ago (no email on -committers yet!) and am looking
> at the following llvm crash reported by buildfarm animal pogona [1]:
>
> #4 0x7f5bceb673d5 in __assert_fail_base (fmt=0x7f5bcecdbdc8
> "%s%s%s:%u: %s%sAssertion `%s'
On Fri, Sep 29, 2023 at 1:57 PM Amit Langote wrote:
> On Thu, Sep 28, 2023 at 8:04 PM Alvaro Herrera
> wrote:
> > On 2023-Sep-27, Amit Langote wrote:
> > > Maybe the following is better:
> > >
> > > + /*
> > > +* For expression nodes that support soft errors. Should be set to
> > > NULL
On Sun, 2023-10-01 at 10:55 -0400, Andrew Dunstan wrote:
> Thanks, pushed.
Thanks for taking care of that.
Yours,
Laurenz Albe
On Tue, Sep 26, 2023 at 4:02 PM Bruce Momjian wrote:
>
> Patch applied back to PG 11.
+Peter E. since I received the following automated note:
> Closed in commitfest 2023-09 with status: Moved to next CF (petere)
Just a note that this patch has been committed (3fea854691), so I have
marked the
On Fri, 2023-09-29 at 22:34 -0400, Bruce Momjian wrote:
> Very good point! Updated patch attached.
Thanks! Some small corrections:
> diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
> index 9cf9d030a8..be1c522575 100644
> --- a/doc/src/sgml/maintenance.sgml
> +++
On Mon, Oct 02, 2023 at 09:24:33AM +0900, Michael Paquier wrote:
> On Sun, Oct 01, 2023 at 04:20:42PM -0700, Peter Geoghegan wrote:
> > On Sun, Oct 1, 2023 at 2:00 PM Noah Misch wrote:
> >> [brin_desummarize_range brin_summarize_new_values brin_summarize_range
> >> gin_clean_pending_list]
On Sun, Oct 1, 2023 at 5:24 PM Michael Paquier wrote:
> > FWIW, amcheck's handling of unlogged relations when in hot standby
> > mode is based on the following theory: if recovery were to end, the
> > index would become an empty index, so just treat it as if it was
> > already empty during
On Sun, Oct 01, 2023 at 04:20:42PM -0700, Peter Geoghegan wrote:
> On Sun, Oct 1, 2023 at 2:00 PM Noah Misch wrote:
> > Okay. If no other preferences appear, I'll do pgstatindex that way.
>
> Sounds reasonable.
>
>> [pgstatginindex pgstathashindex pgstattuple] currently succeed. Like
>>
Erwin Brandstetter writes:
> On Mon, 2 Oct 2023 at 00:33, Dean Rasheed wrote:
>> The only place that exposes the eref's made-up relation name is the
>> existing query deparsing code in ruleutils.c, which uniquifies it and
>> generates SQL spec-compliant output. For example:
> I ran into one
On Sun, Oct 1, 2023 at 11:46 AM Peter Eisentraut wrote:
> What is the status of this patch discussion now? It had been set as
> Ready for Committer for some months. Do these recent discussions
> invalidate that? Does it need more discussion?
I don't think that recent discussion invalidated
On Sun, Oct 1, 2023 at 2:00 PM Noah Misch wrote:
> Okay. If no other preferences appear, I'll do pgstatindex that way.
Sounds reasonable.
> [pgstatginindex pgstathashindex pgstattuple] currently succeed. Like
> pgstatindex, they should ERROR, including in the back branches.
Makes sense.
>
Version 5, this time with attachments.
Changed word order in a sentence:
v5-0012-Explain-role-management.patch
Added a hyperlink:
v5-0013-Hyperlink-from-CREATE-FUNCTION-reference-page-to-.patch
Added 3 index entries:
v5-0014-Add-index-entries-for-parallel-safety.patch
> On Mon, 25 Sep 2023
Version 5
Changed word order in a sentence:
v5-0012-Explain-role-management.patch
Added a hyperlink:
v5-0013-Hyperlink-from-CREATE-FUNCTION-reference-page-to-.patch
Added 3 index entries:
v5-0014-Add-index-entries-for-parallel-safety.patch
> On Mon, 25 Sep 2023 23:37:44 -0500
> "Karl O. Pinc"
On Mon, 2 Oct 2023 at 00:33, Dean Rasheed wrote:
> The only place that exposes the eref's made-up relation name is the
> existing query deparsing code in ruleutils.c, which uniquifies it and
> generates SQL spec-compliant output. For example:
>
I ran into one other place: error messages.
On Sun, Oct 01, 2023 at 04:37:25PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > Running pgstatindex on some !indisready indexes fails with "ERROR: XX001:
> > could not read block 0 in file". This reproduces it:
> > ...
> > Since XX001 = ERRCODE_DATA_CORRUPTED appears in the "can't-happen"
Noah Misch writes:
> Running pgstatindex on some !indisready indexes fails with "ERROR: XX001:
> could not read block 0 in file". This reproduces it:
> ...
> Since XX001 = ERRCODE_DATA_CORRUPTED appears in the "can't-happen" class, it's
> not a good fit for this scenario. I propose to have
Running pgstatindex on some !indisready indexes fails with "ERROR: XX001:
could not read block 0 in file". This reproduces it:
begin;
drop table if exists not_indisready_t;
create table not_indisready_t (c int);
insert into not_indisready_t values (1),(1);
commit;
create unique index
Peter Eisentraut writes:
> Is this patch still being worked on?
I thought Andres simply hadn't gotten back to it yet.
It still seems like a worthwhile improvement.
regards, tom lane
On 22.04.23 01:07, Nathan Bossart wrote:
On Wed, Mar 01, 2023 at 03:13:04PM -0800, Andres Freund wrote:
On 2023-03-01 14:47:51 -0800, Nathan Bossart wrote:
Here is an attempt at adding a signal safe function for writing to STDERR.
Cool.
I'm gently bumping this thread to see if anyone had
On 20.09.23 05:41, Peter Geoghegan wrote:
On Sun, May 14, 2023 at 6:06 PM Peter Geoghegan wrote:
BTW, Google cloud already just instruct their users to ignore the
xidStopLimit HINT about single user mode:
https://cloud.google.com/sql/docs/postgres/txid-wraparound
I read this just today, and
On 30/09/2023 02:16, Imseih (AWS), Sami wrote:
The initial idea was to advance the latest_page_number
during SerialSetActiveSerXmin, but the initial approach is
obviously wrong.
That approach at high level could work, a
When SerialSetActiveSerXmin is called for a new active
serializable
Is this patch still being worked on?
On 07.03.23 01:51, Tom Lane wrote:
Andres Freund writes:
On 2023-03-03 15:09:18 -0500, Tom Lane wrote:
It'd be good to have a header comment for ExecInitExprRec documenting
the arguments, particularly that resv/resnull are where to put the
subplan's
=?koi8-r?B?5dLPyMnOIOTFzsnTIPfMwcTJzcnSz9fJ3g==?= writes:
> There is a problem on receiving large tsvector from binary format with
> getting error "invalid tsvector: maximum total lexeme length exceeded".
Good catch! Even without an actual failure, we'd be wasting space
on-disk anytime we
On Sun, Oct 1, 2023 at 8:57 AM Zhang Mingli wrote:
> And if it’s true, shall we skip the order by clause for Materialized
> View when executing create/refresh statement?
>
We tend to do precisely what the user writes into their query. If they
don't want an order by they can remove it. I
HI,
> On Oct 1, 2023, at 22:54, Tom Lane wrote:
>
> For one example,
> you can't just remove the sort clause if the query uses DISTINCT ON
Hi, Tom, got it, thanks,
Zhang Mingli
HashData https://www.hashdata.xyz
On 2023-09-26 Tu 04:11, Laurenz Albe wrote:
Here is an improved version of the patch with regression tests.
Thanks, pushed.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Zhang Mingli writes:
> When create or refresh a Materialized View, if the view’s query has order
> by, we may sort and insert the sorted data into view.
Indeed.
> And if it’s true, shall we skip the order by clause for Materialized View
> when executing create/refresh statement?
No. The
Hi, all
When create or refresh a Materialized View, if the view’s query has order by,
we may sort and insert the sorted data into view.
Create Materialized View mv1 as select c1, c2 from t1 order by c2;
Refresh Materialized View mv1;
And it appears that we could get ordered
Hi David,
But overall, I'm more inclined to just go with the more simple "add a
> cheap unordered startup append path if considering cheap startup
> plans" version. I see your latest patch does both. So, I'd suggest two
> patches as I do see the merit in keeping this simple and cheap. If we
>
New version of the patch. Fixed minor inconsistencies and rebased onto
current master.
--
regards,
Andrey Lepikhov
Postgres Professional
From 2f5a42c8a53286f830e3376ff4d3f8b7d4215b4b Mon Sep 17 00:00:00 2001
From: "Andrey V. Lepikhov"
Date: Wed, 13 Sep 2023 11:20:03 +0700
Subject: [PATCH]
30 matches
Mail list logo
