On Fri, Aug 6, 2021 at 2:00 PM Masahiko Sawada wrote:
>
> On Wed, Aug 4, 2021 at 12:08 AM vignesh C wrote:
> >
> > On Tue, Aug 3, 2021 at 12:00 PM tanghy.f...@fujitsu.com
> > wrote:
> > >
> > > On Monday, August 2, 2021 11:40 PM vignesh C wrote:
> > > >
> > > > Thanks for the comments, attached
On Mon, 9 Aug 2021 at 11:07, Mahendra Singh Thalor
wrote:
>
> Hi,
> I am able to hit "ERROR: cache lookup failed for function %d" while I am
dropping function from another session.
>
> Reproducible steps are as(I tried on current head d8a75b1308b133502ae3):
>
> Step 1) Fire below query from sessi
On Sat, Aug 7, 2021 at 11:40 AM Andres Freund wrote:
> Hi,
>
> On 2021-07-12 17:28:15 +0530, Ashutosh Bapat wrote:
> > On Mon, Jul 12, 2021 at 8:39 AM Amit Kapila
> wrote:
> >
> > > On Mon, Jul 5, 2021 at 12:54 PM Masahiko Sawada >
> > > Today, again looking at this patch, I don't think doing e
Hi,
I am able to hit "ERROR: cache lookup failed for function %d" while I am
dropping function from another session.
*Reproducible steps are as(I tried on current head d8a75b1308b133502ae3):*
*Step 1) Fire below query from session-1 to create a function:*
create function fun1(int) returns record
On Mon, 9 Aug 2021 at 17:14, A Z wrote:
>
> 1) Are there free scripts for CREATE TYPE (native type), more advanced,
> or sorts of types out there, online, free for commercial
> use? With function support, too? Can someone reply with a link or a
> suggestion?
>
> 2) How may I get PostgreSQL to
1) Are there free scripts for CREATE TYPE (native type), more advanced,
or sorts of types out there, online, free for commercial use? With
function support, too? Can someone reply with a link or a suggestion?
2) How may I get PostgreSQL to output the create table statement(s) for one or
more
On Mon, 9 Aug 2021 at 14:44, David Rowley wrote:
> I plan to push this and backpatch to 9.6 shortly unless there are any
> better ideas.
I pushed this patch. I've now marked the entry in the commitfest app
as committed too.
David
On Sun, Aug 8, 2021 at 2:52 PM vignesh C wrote:
>
> On Fri, Aug 6, 2021 at 4:39 PM Amit Kapila wrote:
> >
> > On Fri, Aug 6, 2021 at 2:02 PM vignesh C wrote:
> > >
> > > On Wed, Aug 4, 2021 at 4:10 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Tue, Aug 3, 2021 at 8:38 PM vignesh C wrote:
> >
On Thu, Aug 5, 2021 at 12:03 PM Greg Nancarrow wrote:
>
As the current v7 patch doesn't fix the coredump issue and also the
cfbot is now failing (as one of the regression tests fails) I'm
reinstating my v2/v5 patch (as v8) as the current best solution to
this issue.
So far I haven't found a test
On Mon, Aug 9, 2021 at 12:46 PM Amit Kapila wrote:
>
> On Sun, Aug 8, 2021 at 10:21 AM Peter Smith wrote:
> >
> > On Sat, Aug 7, 2021 at 4:33 PM Amit Kapila wrote:
> > >
> > > On Thu, Jul 8, 2021 at 6:31 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > Hi all,
> > > >
> > > > When reading the d
On Mon, 9 Aug 2021 at 02:06, Julien Rouhaud wrote:
> > Any objection to applying the attached to pg14 and master?
>
> No objection.
Thanks for looking. I've now pushed this to master and pg14.
David
On Mon, Aug 9, 2021 at 3:06 AM Andres Freund wrote:
>
> Hi,
>
> On 2021-08-08 11:53:39 -0700, Andres Freund wrote:
> > On 2021-08-08 13:46:39 +0800, Julien Rouhaud wrote:
> > > > I suspect that to make the elog.c usage safe, we'll have to clear
> > > > MyBEEntry in
> > > > pgstat_beshutdown_hook(
On Mon, 9 Aug 2021 at 12:58, John Naylor wrote:
>
> On Sun, Aug 8, 2021 at 8:31 PM David Rowley wrote:
> >
> > I've attached a v2 patch which I think is more along the lines of what
> > you had in mind.
>
> LGTM
Thanks for the review.
Pushed.
David
On Sun, Aug 8, 2021 at 11:44 AM Peter Smith wrote:
>
> PSA a patch to fix trivial comment typo in newly committed TAP test.
>
> "amd" -> "and"
>
I'll push this in some time.
--
With Regards,
Amit Kapila.
On Sat, Aug 7, 2021 at 6:53 PM houzj.f...@fujitsu.com
wrote:
>
> On Sat, Aug 7, 2021 1:36 PM Amit Kapila wrote:
> > On Fri, Aug 6, 2021 at 9:57 PM Japin Li wrote:
> >
> > Do you mean to say that do it for both Add and Drop or just for Drop?
> > Actually, doing it both will make the behavior cons
On Wed, Aug 4, 2021 at 4:14 PM Amit Kapila wrote:
>
> I have pushed this last patch in the series.
>
I have closed this CF entry. Thanks to everyone involved in this work!
--
With Regards,
Amit Kapila.
On Sun, Aug 8, 2021 at 10:21 AM Peter Smith wrote:
>
> On Sat, Aug 7, 2021 at 4:33 PM Amit Kapila wrote:
> >
> > On Thu, Jul 8, 2021 at 6:31 PM Masahiko Sawada
> > wrote:
> > >
> > > Hi all,
> > >
> > > When reading the doc of ALTER SUBSCRIPTION I realized that 'refresh
> > > options' in the fo
On Wed, 7 Jul 2021 at 23:44, David Rowley wrote:
>
> On Sun, 4 Jul 2021 at 22:38, David Rowley wrote:
> > I could do with a 2nd opinion about if we should just adjust the
> > maximum value for the autovacuum_work_mem GUC to 1GB in master.
> >
> > I'm also not sure if since we'd not backpatch the
v1 -> v2
Rebased.
--
Kind Regards,
Peter Smith.
Fujitsu Australia
v2-0001-create-subscription-options-list-order.patch
Description: Binary data
On Mon, 9 Aug 2021 at 06:56, Sadhuprasad Patro wrote:
>
> Hi,
>
> > > 3)
> > > pgstat_recv_resetsinglecounter(PgStat_MsgResetsinglecounter *msg, int
> > > len)
> > > {
> > > PgStat_StatDBEntry *dbentry;
> > > +boolfound;
> > >
> > > dbentry = pgstat_get_db_entry(msg->m_dat
Hi,
> > 3)
> > pgstat_recv_resetsinglecounter(PgStat_MsgResetsinglecounter *msg, int len)
> > {
> > PgStat_StatDBEntry *dbentry;
> > +boolfound;
> >
> > dbentry = pgstat_get_db_entry(msg->m_databaseid, false);
> >
> > @@ -5168,13 +5192,41 @@
> > pgstat_recv_resetsinglecount
On Sun, Aug 8, 2021 at 8:31 PM David Rowley wrote:
>
> I've attached a v2 patch which I think is more along the lines of what
> you had in mind.
LGTM
--
John Naylor
EDB: http://www.enterprisedb.com
On Thu, 5 Aug 2021 at 07:02, John Naylor wrote:
> > #if defined(_MSC_VER) && defined(_WIN64)
> > #define HAVE_X86_64_POPCNTQ
> > #endif
>
> That seems fine. I don't know PG can build with Arm on Windows, but for the
> cpuid to work, it seems safer to also check for __x86_64?
That's a good point.
> On Aug 8, 2021, at 3:28 PM, Tom Lane wrote:
>
> Cool, thanks. I also tried your millions-of-random-regexps script
> and didn't find any difference between the results from HEAD and
> those from the v3 patch.
The patch looks ready to commit. I don't expect to test it any further unless
yo
Mark Dilger writes:
> I have applied your latest patch and do not see any problems with it. All my
> tests pass with no asserts and with no differences in results vs. master.
> This is a test suite of nearly 1.5 million separate regular expressions.
Cool, thanks. I also tried your millions-o
> On Aug 8, 2021, at 1:25 PM, Tom Lane wrote:
>
> Ugh. The regex engine is finding the match correctly, but it's failing to
> tell the caller where it is :-(. I was a little too cute in optimizing
> the regmatch_t result-vector copying in pg_regexec, and forgot to ensure
> that the overall m
Mark Dilger writes:
> Hmm. This changes the behavior when applied against master
> (c1132aae336c41cf9d316222e525d8d593c2b5d2):
> select regexp_split_to_array('uuuzkodphfbfbfb', '((.))(\1\2)', 'ntw');
> regexp_split_to_array
> ---
> - {"",zkodphfbfbfb}
> + {uuuzkodphfbfbf
Hi,
> >
>> > Currently, this capability is not included in the patch. If the table on
>> > the subscriber
>> > server has lesser attributes than that on the publisher server, it
>> > throws an error at the
>> > time of CREATE SUBSCRIPTION.
>> >
>>
>> That's a bit surprising, to be honest. I do u
On Sun, Aug 8, 2021 at 11:34 AM Michael Meskes wrote:
> > https://postgr.es/m/CAH2-Wzk=qxtsp0h5ekv92eh0u22hvmqlhgwyp4_fa3ytiei...@mail.gmail.com
>
> This email said nothing about sending a status update or a deadline or
> any question at all, only that you'd revert the patch if I was unable
> to r
Hi,
On 2021-08-08 11:53:39 -0700, Andres Freund wrote:
> On 2021-08-08 13:46:39 +0800, Julien Rouhaud wrote:
> > > I suspect that to make the elog.c usage safe, we'll have to clear
> > > MyBEEntry in
> > > pgstat_beshutdown_hook().
> >
> > I agree, and a quick test indeed fix your scenario. It
Hi,
On 2021-08-08 13:46:39 +0800, Julien Rouhaud wrote:
> On Sat, Aug 07, 2021 at 04:44:07PM -0700, Andres Freund wrote:
> >
> > As currently implemented those pgstat_get_my_query_id() calls are not
> > safe. It's fine during backend startup because MyBEEntry is not set, but
> > during shutdown t
On Sat, 2021-08-07 at 15:31 -0700, Peter Geoghegan wrote:
> On Sat, Aug 7, 2021 at 12:43 PM Michael Meskes
> wrote:
> > Again, I didn't know the RMT was expecting anything from me. Yes, I
> > knew I needed to spend some time on a technical issues, but that's
> > exactly the information I had at th
"tanghy.f...@fujitsu.com" writes:
> On Sunday, August 8, 2021 8:13 AM, Dagfinn Ilmari Mannsåker
> wrote:
>>> + "\\r", "\\rset",
>>
>>There's a typo here, that should be "\\reset". Also, I noticed that for
>>\connect, the situation is the opposite: it has the full form but not
>>the s
> On Aug 8, 2021, at 10:04 AM, Tom Lane wrote:
>
> I've also rebased over the bug fixes from the other thread,
> and added a couple more test cases.
>
> regards, tom lane
Hmm. This changes the behavior when applied against master
(c1132aae336c41cf9d316222e525d8d593c2b
> On Aug 8, 2021, at 10:34 AM, Mark Dilger wrote:
>
> I'll rerun my tests with the new master. I was still using the code that I
> pulled yesterday.
I am now testing REL_13_STABLE (ba9f665a4413f855bbf4b544481db326f7b9bd73) vs
master (c1132aae336c41cf9d316222e525d8d593c2b5d2). The regular
> On Aug 8, 2021, at 10:32 AM, Mark Dilger wrote:
>
> I'm not sure what you mean by "as-committed". Did you commit one of these
> recently?
Nevermind, I see the commit now.
I'll rerun my tests with the new master. I was still using the code that I
pulled yesterday.
—
Mark Dilger
Enterpr
> On Aug 8, 2021, at 10:29 AM, Tom Lane wrote:
>
> Mark Dilger writes:
>> Applying your to master changes
>> the outcome of some regular expression queries, but I *think* it changes
>> them for the better.
>
> [ squint... ] You sure you applied the patch properly? All these examples
> gi
Mark Dilger writes:
> Applying your to master changes
> the outcome of some regular expression queries, but I *think* it changes them
> for the better.
[ squint... ] You sure you applied the patch properly? All these examples
give me the same results in HEAD (with said patches as-committed) a
> On Aug 8, 2021, at 10:15 AM, Mark Dilger wrote:
>
> But these next two look to me correct before the patch and wrong after:
>
> select regexp_matches('ircecpbgyiggvtruqgxzigxzigxzisdbkuhbkuhrvl',
> '(((.)))(?:(\3))[^\f]');
> regexp_matches
>
> -(0 rows)
> + {g,g,g,g}
> +(
> On Aug 7, 2021, at 6:03 PM, Tom Lane wrote:
>
> That requires tweaking the API of parseqatom,
> which why I'd not done it like that to begin with --- but that's not
> a hard or complicated change, just a mite tedious.
>
> Hence, the attached patch.
Applying your to master changes the
out
Mark Dilger writes:
> The patch triggers an assertion that master does not:
> +select 'azrlfkjbjgidgryryiglcabkgqluflu' !~ '(.(.)((.)))((?:(\3)))';
On looking into this, it's pretty simple: regexec.c has an assertion
that a pure-capture subre node ought to be doing some capturing.
case
> On Aug 8, 2021, at 9:31 AM, Tom Lane wrote:
>
> I realized that the earlier patch is actually a bad idea
Applying only your to master, the following
which did not crash begins to crash:
select regexp_split_to_array('rjgy', '(?:(.))((\1\1.))');
It also changes the results for anothe
I wrote:
> While this is sufficient to make the problem go away, I'm
> inclined to apply both changesets. Even if it accidentally
> works right now to have later backrefs consult the outer s/s2
> state pair rather than the original pair, that seems far too
> convoluted and bug-prone. The outer st
On Sun, Aug 08, 2021 at 11:56:41PM +1200, David Rowley wrote:
>
> On looking a little closer I also saw that plannedstmt->queryId is a
> uint64. I guess that we're showing this as an int64 so that it
> matches the queryid column in the pg_stat_statements view?
The only reason we display it as an
čt 5. 8. 2021 v 17:13 odesílatel Pavel Stehule
napsal:
>
>
> čt 5. 8. 2021 v 16:50 odesílatel Platon Pronko
> napsal:
>
>> Hi!
>>
>> > pspg supports copy cell to clipboard - you can copy complete cell
>> >
>> > but I am not sure if it is working well in extended mode. This mode is
>> not
>> > ex
On Mon, 9 Aug 2021 at 00:38, Tomas Vondra wrote:
> I'm not sure quadrupling the size is a good idea, though, because it
> increases the amount of memory we might be wasting. With the doubling,
> the amount of wasted /unused memory is limited to ~50%, because the next
> block is (roughly) equal to
On Wed, 4 Aug 2021 at 02:10, Tomas Vondra wrote:
> I did run the same set of benchmarks as for Slab, measuring some usual
> allocation patterns. The results for i5-2500k machine are attached (for
> the xeon it's almost exactly the same behavior). While running those
> tests I realized the last pat
On 8/8/21 12:11 PM, David Rowley wrote:
On Sat, 7 Aug 2021 at 12:10, Tomas Vondra wrote:
All of the tests show that the patches to improve the allocation
efficiency of generation.c don't help to improve the results of the
test cases. I wondered if it's maybe worth trying to see what happens
if
On 8/8/21 9:02 AM, David Rowley wrote:
On Sat, 7 Aug 2021 at 12:10, Tomas Vondra wrote:
On 8/6/21 3:07 PM, David Rowley wrote:
All of the tests show that the patches to improve the allocation
efficiency of generation.c don't help to improve the results of the
test cases. I wondered if it's
I was wondering about the following code in explain.c
char buf[MAXINT8LEN + 1];
pg_lltoa(plannedstmt->queryId, buf);
ExplainPropertyText("Query Identifier", buf, es);
I thought it was a bit strange that we don't just use
ExplainPropertyInteger() instead of going to the trouble of building
the st
On Wed, 4 Aug 2021 at 00:02, David Rowley wrote:
> Yeah, I think it can be safely removed. I can do so unless someone
> thinks otherwise.
Pushed.
David
On Sunday, August 8, 2021 6:34 PM, vignesh C wrote
>Thanks for the updated patch, your changes look good to me. You might
>want to include the commit message in the patch, that will be useful.
Thanks for your kindly suggestion.
Updated patch attached. Added the patch commit message with no new fi
On Sunday, August 8, 2021 8:13 AM, Dagfinn Ilmari Mannsåker
wrote:
>> +"\\r", "\\rset",
>
>There's a typo here, that should be "\\reset". Also, I noticed that for
>\connect, the situation is the opposite: it has the full form but not
>the short form (\c).
>
>I've addressed both in th
On Sat, 7 Aug 2021 at 12:10, Tomas Vondra wrote:
> > All of the tests show that the patches to improve the allocation
> > efficiency of generation.c don't help to improve the results of the
> > test cases. I wondered if it's maybe worth trying to see what happens
> > if instead of doubling the all
On Fri, Aug 6, 2021 at 3:33 PM tanghy.f...@fujitsu.com
wrote:
>
> Hi
>
> I saw some inaccurate comments for AlterPublicationStmt structure when
> reviewing patches related to publication[1].
>
> The variable tables are used for 'ALTER PUBLICATION ... ADD/DROP/SET TABLE',
> but the comments only sa
On Fri, Aug 6, 2021 at 4:39 PM Amit Kapila wrote:
>
> On Fri, Aug 6, 2021 at 2:02 PM vignesh C wrote:
> >
> > On Wed, Aug 4, 2021 at 4:10 PM Amit Kapila wrote:
> > >
> > > On Tue, Aug 3, 2021 at 8:38 PM vignesh C wrote:
> >
> > > 6.
> > > + {PublicationSchemaRelationId, /* PUBLICATIONSCHEMAMAP
On Sat, 7 Aug 2021 at 12:10, Tomas Vondra wrote:
>
> On 8/6/21 3:07 PM, David Rowley wrote:
> > All of the tests show that the patches to improve the allocation
> > efficiency of generation.c don't help to improve the results of the
> > test cases. I wondered if it's maybe worth trying to see what
57 matches
Mail list logo
