On Mon, Oct 19, 2020 at 08:15:56AM +0200, Peter Eisentraut wrote:
> On 2020-10-12 13:36, Michael Paquier wrote:
> > On Mon, Oct 12, 2020 at 03:39:51PM +0900, Masahiko Sawada wrote:
> > > Yes, this patch resolves the problem.
> >
> > Okay, applied then.
>
> Could you adjust the generation script s
Hi
I found some code like the following:
> StringInfoData s;
> ...
> values[6] = CStringGetTextDatum(s.data);
The length of string can be found in ' StringInfoData.len',
but the macro CStringGetTextDatum will use strlen to count the length again.
I think we can use PointerGetDatum(cstring_to_te
On 2020-10-12 13:36, Michael Paquier wrote:
On Mon, Oct 12, 2020 at 03:39:51PM +0900, Masahiko Sawada wrote:
Yes, this patch resolves the problem.
Okay, applied then.
Could you adjust the generation script so that the resulting header file
passes the git whitespace check? Check the output
From: Masahiko Sawada
> > Unfortunately, I'm afraid we can do nothing about it. If the DBMS's client
> library doesn't support cancellation (e.g. doesn't respond to Ctrl+C or
> provide a
> function that cancel processing in pgorogss), then the Postgres user just
> finds
> that he can't cancel q
On Thu, Oct 15, 2020 at 9:02 AM Amit Kapila wrote:
>
> On Mon, Oct 5, 2020 at 8:11 AM Amit Kapila wrote:
> >
> > On Sat, Oct 3, 2020 at 6:55 PM Masahiko Sawada
> > wrote:
> > >
> > > To make the behavior of parallel vacuum more consistent with other
> > > parallel maintenance commands (i.g., onl
On Mon, Oct 19, 2020 at 9:04 AM Masahiko Sawada
wrote:
>
> On Thu, 15 Oct 2020 at 17:51, Amit Kapila wrote:
> >
> >
> > AFAICS, we use name data-type in many other similar stats views like
> > pg_stat_subscription, pg_statio_all_sequences, pg_stat_user_functions,
> > pg_stat_all_tables. So, shoul
On Mon, 12 Oct 2020 at 17:19, tsunakawa.ta...@fujitsu.com
wrote:
>
> From: Masahiko Sawada
> > I was thinking to have a GUC timeout parameter like statement_timeout.
> > The backend waits for the setting value when resolving foreign
> > transactions.
>
> Me too.
>
>
> > But this idea seems differ
On Sun, Oct 18, 2020 at 12:54 AM Alvaro Herrera wrote:
> On 2020-Oct-17, Amit Langote wrote:
> > Hmm, I don't see ri_PartitionCheckExpr as being a piece of routing
> > information, because it's primarily meant to be used when inserting
> > *directly* into a partition, although it's true we do init
On Mon, Oct 19, 2020 at 12:18 PM Ian Lawrence Barwick wrote:
>
> Hi
>
> The errdetail emitted when creating/modifying an ENUM value is misleading:
>
> postgres=# CREATE TYPE enum_valtest AS ENUM (
> 'foo',
> 'ああ'
>);
> ERR
Hi
The errdetail emitted when creating/modifying an ENUM value is misleading:
postgres=# CREATE TYPE enum_valtest AS ENUM (
'foo',
'ああ'
);
ERROR: invalid enum label "ああ"
DETAIL: Labels must be 63
Hello Andrey-san,
Thank you for challenging an interesting feature. Below are my review comments.
(1)
- /* for use by copy.c when performing multi-inserts */
+ /*
+* The following fields are currently only relevant to copy.c.
+*
+* True if okay to use multi-
Hi
Found one more place needed to be changed(long -> int64).
Also changed the output for int64 data(Debug mode on & define EXEC_SORTDEBUG )
And, maybe there's a typo in " src\backend\executor\nodeIncrementalSort.c" as
below.
Obviously, the ">=" is meaningless, right?
- SO1_printf
On Thu, 15 Oct 2020 at 17:51, Amit Kapila wrote:
>
> On Tue, Oct 13, 2020 at 5:41 AM Masahiko Sawada
> wrote:
> >
> > On Mon, 12 Oct 2020 at 23:45, Shinoda, Noriyoshi (PN Japan A&PS
> > Delivery) wrote:
> > >
> > >
> > > > As it may have been discussed, I think the 'name' column in
> > > > pg_s
> * Aggregate support
>
> The current patch supports several built-in aggregates, that is, count, sum,
> avg, min, and max. Other built-in aggregates or user-defined aggregates are
> not supported.
>
> Aggregates in a materialized view definition is checked if this is supported
> using OIDs of a
On Mon, Oct 19, 2020 at 10:39 AM Michael Paquier wrote:
>
> On Fri, Oct 16, 2020 at 09:22:02AM +0800, Julien Rouhaud wrote:
> > And Michael just told me that I also missed adding one of the C files
> > while splitting the patch into two.
>
> + if (PageIsNew(page))
> + {
> + /*
> +
On Sat, 17 Oct 2020 at 05:24, Bruce Momjian wrote:
>
> On Fri, Jul 31, 2020 at 04:06:38PM +0900, Masahiko Sawada wrote:
> > > Given that the purpose of the key manager is to help TDE, discussing
> > > the SQL interface part (i.g., the second patch) deviates from the
> > > original purpose. I think
On Fri, Oct 16, 2020 at 09:22:02AM +0800, Julien Rouhaud wrote:
> And Michael just told me that I also missed adding one of the C files
> while splitting the patch into two.
+ if (PageIsNew(page))
+ {
+ /*
+* Check if the page is really new or if there's corruption that
+
On Thu, Oct 15, 2020 at 04:22:12PM +0900, Michael Paquier wrote:
> That's a bit annoying, because this memory is allocated directly by
> OpenSSL, and Postgres does not know how to free it until it gets
> registered in the list of open_digests that would be used by the
> cleanup callback, so I think
Amit-san, Sawada-san,
Thank you for your comment.
> AFAICS, we use name data-type in many other similar stats views like
> pg_stat_subscription, pg_statio_all_sequences, pg_stat_user_functions,
> pg_stat_all_tables. So, shouldn't we consistent with those views?
I checked the data type used for
On Mon, 19 Oct 2020 at 13:06, Tom Lane wrote:
> (BTW, am I wrong to suppose that the same case fails the same
> way in our older branches? Certainly that Assert has been there
> a long time.)
I only tested as back as far as 9.5, but it does fail there.
David
David Rowley writes:
> It would be good to hear Onder's case to see if he has a good argument
> for having a vested interest in pg13 not failing this way with assets
> enabled.
Yeah, some context for this report would be a good thing.
(BTW, am I wrong to suppose that the same case fails the same
On Mon, 19 Oct 2020 at 12:25, Tom Lane wrote:
>
> David Rowley writes:
> > On Mon, 19 Oct 2020 at 12:10, Tom Lane wrote:
> >> TBH, I see no need to do anything in the back branches. This is not
> >> an issue for production usage.
>
> > I understand the Assert failure is pretty harmless, so non-
David Rowley writes:
> On Mon, 19 Oct 2020 at 12:10, Tom Lane wrote:
>> TBH, I see no need to do anything in the back branches. This is not
>> an issue for production usage.
> I understand the Assert failure is pretty harmless, so non-assert
> builds shouldn't suffer too greatly. I just assume
On Mon, 19 Oct 2020 at 12:10, Tom Lane wrote:
>
> David Rowley writes:
> > For the backbranches, I think I go with something more minimal in the
> > form of adding:
>
> TBH, I see no need to do anything in the back branches. This is not
> an issue for production usage.
I understand the Assert f
David Rowley writes:
> On Sat, 17 Oct 2020 at 06:00, Tom Lane wrote:
>> I'm good with the v2 patch.
> Thanks a lot for having a look. I'll proceed in getting the v2 which I
> sent earlier into master.
> For the backbranches, I think I go with something more minimal in the
> form of adding:
TBH
On Sun, 18 Oct 2020 at 08:21, Justin Pryzby wrote:
> /* don't print information if no JITing happened */
> - if (!ji || ji->created_functions == 0)
> + if (!ji || (ji->created_functions == 0 &&
> + es->format == EXPLAIN_FORMAT_TEXT))
> retu
On Sat, 17 Oct 2020 at 06:00, Tom Lane wrote:
> I'm confused now, because the v2 patch does remove those isnan calls?
I think that was a case of a last-minute change of mind and forgetting
to attach the updated patch.
> I rechecked the archives, and I agree that there's no data about
> exactly h
Alexander Lakhin writes:
> I just wanted to inform that the ECPG-test failures can still persist in
> the buildfarm, unfortunately.
Right, but at least now we can see that there are other issues to
investigate. Personally I stopped paying any attention to buildfarm
ECPG failures on Windows some
Alexander Lakhin writes:
> I've made a simple cmd script to reproduce problems seen on dory:
> ...
> Without the fix I've got errors on iterations 43, 46, 128, 47, 14, 4,
> 27, which approximately corresponds to the ECPG-Check failure frequency
> on dory (for HEAD).
> With the fix all the 200 iter
18.10.2020 21:04, Tom Lane wrote:
> Alexander Lakhin writes:
>> @@ -0,0 +1 @@
>> +SQL error: descriptor "mydesc" not found on line 31
> does not look like the same kind of failure as what we've been dealing
> with up to now. So maybe what we've got is that we fixed the stdio
> loss problem, and n
I wrote:
>> diff -w -U3
>> .../src/interfaces/ecpg/test/expected/thread-descriptor.stderr
>> .../src/interfaces/ecpg/test/results/thread-descriptor.stderr
>> --- .../src/interfaces/ecpg/test/expected/thread-descriptor.stderr
>> 2019-12-04 16:05:46 +0300
>> +++ .../src/interfaces/ecpg/test/result
Alexander Lakhin writes:
> With the fix all the 200 iterations passed as expected.
> Then I ran the loop again just to be sure and got:
> test thread/descriptor ... stderr FAILED 81 ms
> iteration 124 failed.
Sigh ... still, this:
> diff -w -U3
> .../src/interfaces/ecpg/test/exp
17.10.2020 21:44, Tom Lane wrote:
> I propose the attached patch. If this doesn't cause buildfarm problems,
> perhaps we should back-patch it.
Thank you!
I've made a simple cmd script to reproduce problems seen on dory:
https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=dory&br=HEAD
FOR /
If you go into src/test/thread/ and type "make", you get
a bunch of "undefined reference to `pg_fprintf'" failures.
That's because thread_test.c #include's postgres.h but
the Makefile doesn't bother to link it with libpgport,
arguing (falsely) that that might not exist yet.
Presumably, this has be
I wrote:
> Isn't the real problem that lo_write returns int, not size_t?
After looking at it some more, I decided that we'd just been lazy
to begin with: we should be handling this as a regular SQL error
condition. Pushed at 929c69aa19.
regards, tom lane
On Wed, Aug 05, 2020 at 10:00:02PM -0700, Noah Misch wrote:
> On Mon, Aug 03, 2020 at 09:46:23AM -0400, Robert Haas wrote:
> > On Mon, Aug 3, 2020 at 2:30 AM Noah Misch wrote:
> > > Between (b)(2)(X) and (b)(3)(X), what are folks' preferences? Does anyone
> > > strongly favor some other option (i
On Sat, Oct 17, 2020 at 6:11 AM Anastasia Lubennikova
wrote:
>
> On 16.10.2020 12:07, Julien Rouhaud wrote:
>
> Le ven. 16 oct. 2020 à 16:12, Pavel Stehule a écrit
> :
>>
>>
>>
>> pá 16. 10. 2020 v 9:43 odesílatel napsal:
>>>
>>> Hi, hackers.
>>> For some distributions of data in tables, differ
On Sun, Oct 18, 2020 at 12:20 PM Tom Lane wrote:
>
> Alvaro Herrera writes:
> > Wait ... what? I've been thinking that this GUC is just to enable or
> > disable the computation of query ID, not to change the algorithm to do
> > so. Do we really need to allow different algorithms in different
>
38 matches
Mail list logo
