On Sat, Jul 24, 2021 at 07:41:12PM +0900, Michael Paquier wrote:
> I have looked at that over the last couple of days, and applied it
> after some small fixes, including an indentation.
One thing that we forgot here is the handling of trailing
whitespaces. Attached is small patch to adjust that,
On Monday, July 26, 2021 1:04 PM, Michael Paquier wrote:
>> -make check PGOPTIONS="-c log_checkpoints=on -c work_mem=50MB"
>> +make check PGOPTIONS="-c geqo=off -c work_mem=50MB"
>>
>> log_checkpoints couldn't be set in PGOPTIONS.
>>
>> Replace log_checkpoints with geqo in the example code
>>
>R
On Mon, Jul 26, 2021 at 7:41 AM tanghy.f...@fujitsu.com <
tanghy.f...@fujitsu.com> wrote:
>
> On Friday, July 23, 2021 8:18 PM vignesh C wrote:
> >
> > I have changed it to not report any error, this issue is fixed in the
> > v14 patch attached at [1].
> > [1] - https://www.postgresql.org/message-
On Fri, Jul 23, 2021 at 8:58 AM Amit Kapila wrote:
>
> Okay, thanks. I think one point we need to consider here is that on
> the subscriber side, we use dirtysnapshot to search the key, so we
> need to ensure that we don't fetch the wrong data. I am not sure what
> will happen when by the time we
On Thu, Jul 15, 2021 at 7:54 PM Bharath Rupireddy
wrote:
>
> On Mon, Jul 12, 2021 at 10:11 PM Bharath Rupireddy
> wrote:
> >
> > On Mon, Jul 12, 2021 at 9:20 PM Fujii Masao
> > wrote:
> > > +
> > > + Avoid Using non-negative Word in Error
> > > Messages
> > > +
> > > +
> > > +Do not
On Friday, July 23, 2021 7:10 PM Ajin Cherian wrote:
> On Fri, Jul 23, 2021 at 7:38 PM Peter Smith wrote:
> >
> > I have reviewed the v10 patch.
The patch v11 looks good to me as well.
Thanks for addressing my past comments.
Best Regards,
Takamichi Osumi
On Fri, Jul 23, 2021 at 06:12:02AM +, tanghy.f...@fujitsu.com wrote:
> Here's a tiny fix in regress.sgml.
>
> -make check PGOPTIONS="-c log_checkpoints=on -c work_mem=50MB"
> +make check PGOPTIONS="-c geqo=off -c work_mem=50MB"
>
> log_checkpoints couldn't be set in PGOPTIONS.
>
> Replace lo
On 2021/07/26 12:32, Julien Rouhaud wrote:
On Sun, Jul 25, 2021 at 11:26:02PM -0400, Tom Lane wrote:
Julien Rouhaud writes:
I attach a patch that splits the test and add a comment explaining the
boundaries for the new query.
Checked with and without forced invalidations.
Pushed with a lit
On Sun, Jul 25, 2021 at 11:26:02PM -0400, Tom Lane wrote:
> Julien Rouhaud writes:
> > I attach a patch that splits the test and add a comment explaining the
> > boundaries for the new query.
> > Checked with and without forced invalidations.
>
> Pushed with a little cosmetic fooling-about.
Than
Julien Rouhaud writes:
> I attach a patch that splits the test and add a comment explaining the
> boundaries for the new query.
> Checked with and without forced invalidations.
Pushed with a little cosmetic fooling-about.
regards, tom lane
On Fri, 23 Jul 2021 at 02:29, David Rowley wrote:
> I've attached a patch that adjusts the comment so it's more aligned to
> what it now does.
This was a bit more outdated than I first thought. I also removed the
mention of the function setting the aggtranstype and what it mentions
about also ga
On Fri, Jul 23, 2021 at 10:16 PM vignesh C wrote:
>
> I have changed it to pg_pubication_schema as earlier as both you and Houzj
> San felt pg_publication_schema was better. This is fixed in the v14 patch
> attached at [1].
> [1] -
> https://www.postgresql.org/message-id/CALDaNm3DTj535ezfmm8QHL
On Sun, Jul 25, 2021 at 12:28:04PM -0400, Tom Lane wrote:
> Andres Freund writes:
>> We really ought to just remove every single use of long.
>
> I have no objection to that as a long-term goal. But I'm not volunteering
> to do all the work, and in any case it wouldn't be a back-patchable fix.
>
On Fri, Jul 23, 2021 at 04:20:37PM -0300, Ranier Vilela wrote:
> Maybe not yet. Valgrind may also don't understand yet.
I think that you should do things the opposite way. In short, instead
of attempting to understand first Valgrind or Coverity and then
Postgres, try to understand the internals o
On Friday, July 23, 2021 8:18 PM vignesh C wrote:
>
> I have changed it to not report any error, this issue is fixed in the
> v14 patch attached at [1].
> [1] - https://www.postgresql.org/message-
> id/CALDaNm3DTj535ezfmm8QHLOtOkcHF2ZcCfSjfR%3DVbTbLZXFRsA%40mail.g
> mail.com
>
Thanks for your n
On Fri, Jul 23, 2021 at 8:09 PM Ajin Cherian wrote:
>
> fixed.
The v11 patch LGTM.
Regards,
Greg Nancarrow
Fujitsu Australia
On Mon, Jul 26, 2021 at 01:08:08AM +0800, Julien Rouhaud wrote:
> Le lun. 26 juil. 2021 à 00:59, Tom Lane a écrit :
>
> > Julien Rouhaud writes:
> > > On Sun, Jul 25, 2021 at 12:03:25PM -0400, Tom Lane wrote:
> >
>
> > > Would it be worth to split the query for the prepared statement row vs
> >
FYI - I have checked the v11 patch. Everything applies, builds, and
tests OK for me, and I have no more review comments. So v11 LGTM.
--
Kind Regards,
Peter Smith.
Fujitsu Australia
Andrew Dunstan writes:
> On 7/25/21 12:03 PM, Tom Lane wrote:
>> So AFAICS this test is inherently unstable and there is no code bug
>> to be fixed. We could drop the "plans" column from this query, or
>> print something approximate like "plans > 0 AND plans <= calls".
>> Thoughts?
> Is that lik
On 7/25/21 12:03 PM, Tom Lane wrote:
>
> So AFAICS this test is inherently unstable and there is no code bug
> to be fixed. We could drop the "plans" column from this query, or
> print something approximate like "plans > 0 AND plans <= calls".
> Thoughts?
>
Is that likely to tell us anything ve
Em dom., 25 de jul. de 2021 às 15:53, Tom Lane escreveu:
> Ranier Vilela writes:
> > I think int64 is in most cases the counterpart of *long* on Windows.
>
> I'm not particularly on board with s/long/int64/g as a universal
> solution.
Sure, not a universal solution, I mean a start point.
When I
> On 23-Jul-2021, br...@momjian.us wrote:
>
> On Fri, Jul 23, 2021 at 10:55:11AM -0700, Bryn Llewellyn wrote:
>> SELECT
>> '1.2345 months 1.2345 days 1.2345 seconds'::interval =
>> '1 month 1 day 1 second'::interval*1.2345;
>>
>> In 13.3, the result is TRUE. (I know that this doesn’t guarantee
Ranier Vilela writes:
> I think int64 is in most cases the counterpart of *long* on Windows.
I'm not particularly on board with s/long/int64/g as a universal
solution. I think that most of these usages are concerned with
memory sizes and would be better off as "size_t". We might need
int64 in p
On Fri, Jul 23, 2021 at 04:09:47PM +0530, Nitin Jadhav wrote:
> > I think walkdir() should only call LogStartupProgress(FSYNC_IN_PROGRESS,
> > path);
> > when action == datadir_fsync_fname.
>
> I agree and fixed it.
I saw that you fixed it by calling InitStartupProgress() after the walkdir()
cal
Em dom., 25 de jul. de 2021 às 13:28, Tom Lane escreveu:
> Andres Freund writes:
> > On 2021-07-23 17:15:24 -0400, Tom Lane wrote:
> >> That's because they spill to disk where they did not before. The easy
> >> answer of "raise hash_mem_multiplier" doesn't help, because on Windows
> >> the prod
Le lun. 26 juil. 2021 à 00:59, Tom Lane a écrit :
> Julien Rouhaud writes:
> > On Sun, Jul 25, 2021 at 12:03:25PM -0400, Tom Lane wrote:
>
> > Would it be worth to split the query for the prepared statement row vs
> the rest
> > to keep the full "plans" coverage when possible?
>
> +1, the same
Julien Rouhaud writes:
> On Sun, Jul 25, 2021 at 12:03:25PM -0400, Tom Lane wrote:
>> So AFAICS this test is inherently unstable and there is no code bug
>> to be fixed. We could drop the "plans" column from this query, or
>> print something approximate like "plans > 0 AND plans <= calls".
>> Tho
On Sun, Jul 25, 2021 at 12:03:25PM -0400, Tom Lane wrote:
> The cause of the failure of course is that cache clobbering includes
> plan cache clobbering, so that the prepared statement's plan is
> remade each time it's used, not only twice as the test expects.
> However, remembering that cache flu
Andres Freund writes:
> On 2021-07-23 17:15:24 -0400, Tom Lane wrote:
>> That's because they spill to disk where they did not before. The easy
>> answer of "raise hash_mem_multiplier" doesn't help, because on Windows
>> the product of work_mem and hash_mem_multiplier is clamped to 2GB,
>> thanks
Hi,
I've dreamed to write more compact structure for vacuum for three
years, but life didn't give me a time to.
Let me join to friendly competition.
I've bet on HATM approach: popcount-ing bitmaps for non-empty elements.
Novelties:
- 32 consecutive pages are stored together in a single sparse
[ blast from the past department ]
Fujii Masao writes:
> Finally I pushed the patch!
> Many thanks for all involved in this patch!
It turns out that the regression test outputs from this patch are
unstable under debug_discard_caches (nee CLOBBER_CACHE_ALWAYS).
You can easily check this in HEAD o
Hi, Alvaro and all,
> this patch hasn't been posted by the author so let's assume
> they're not authorizing them to use it.
Not sure what you mean. I am the author and I authorize anyone to do
whatever they want with it.
> Otherwise, why wouldn't they just post it here instead of doing the
absur
Alvaro Herrera writes:
> I pushed this patch with some minor corrections (mostly improved the
> message wording.)
Coverity does not like this bit, and I fully agree:
/srv/coverity/git/pgsql-git/postgresql/src/backend/commands/trigger.c: 1639 in
renametrig_partition()
>>> CID 1489387: Incor
Hi
>
> some like:
>
> //* plpgsql_check: OFF *//
> RAISE NOTICE '%', r.x
>
> or second design
>
> b) can we introduce some flag for plpgsql_parser, that allows storing
> comments in AST (it will not be default).
>
> so "-- plpgsql_check: OFF " will work for my purpose, and I don't need
> any spe
ne 25. 7. 2021 v 12:52 odesílatel Dinesh Chemuduru
napsal:
> On Sat, 17 Jul 2021 at 01:29, Pavel Stehule
> wrote:
>
>> Hi
>>
>> pá 16. 7. 2021 v 21:47 odesílatel Dinesh Chemuduru <
>> dinesh.ku...@migops.com> napsal:
>>
>>> Hi Everyone,
>>>
>>> We would like to propose the below 2 new plpgsql di
On Sat, 17 Jul 2021 at 01:29, Pavel Stehule wrote:
> Hi
>
> pá 16. 7. 2021 v 21:47 odesílatel Dinesh Chemuduru <
> dinesh.ku...@migops.com> napsal:
>
>> Hi Everyone,
>>
>> We would like to propose the below 2 new plpgsql diagnostic items,
>> related to parsing. Because, the current diag items are
> 25 июля 2021 г., в 05:29, Andres Freund написал(а):
>
> Hi,
>
> On 2021-07-24 15:53:15 +0500, Andrey Borodin wrote:
>> Are there any other problems with blocking cancels?
>
> Unless you have commandline access to the server, it's not hard to get
> into a situation where you can't change the
> I think that in cases where there's not a semantic hazard involved,
> we'd usually have pulled up the subquery so that this is all moot
> anyway.
>
I get your point with this statement. Things driven by this idea look
practical and lucky. But for the UniqueKey stuff, we are not
that lucky.
SEL
38 matches
Mail list logo
