On Fri, Sep 18, 2020 at 11:31:26AM +0500, Andrey M. Borodin wrote:
> This is whole point of having prefetch. restore_command just links
> file from the same partition.
If this stuff is willing to do so, you may have your reasons, but even
if you wish to locate both pg_wal/ and the prefetch path in
Hi,
On Fri, 18 Sep 2020 at 08:59, Michael Paquier wrote:
> If this stuff is willing to do so, you may have your reasons, but even
> if you wish to locate both pg_wal/ and the prefetch path in the same
> partition, I don't get why it is necessary to have the prefetch path
> included directly in p
Hello.
It needed rebasing. (Attached)
At Tue, 25 Aug 2020 16:32:02 +0300, Heikki Linnakangas wrote
in
> On 20/08/2020 11:32, Kyotaro Horiguchi wrote:
> > 0002: Rewording that old->target and new->source makes the meaning far
>
> Good idea! I changed the patch that way.
Looks Good.
> > 0003:
Hello,
Sorry, I sent a wrong version of the patch, contains some spelling
errors. This is the right one.
Sigh.. I fixed some more wordings.
I have submitted a patch which reworks how things are computed so that
performance figures make some/more sense, among other things.
Maybe you coul
On Thu, 17 Sep 2020 at 14:25, Michael Paquier wrote:
>
> On Fri, Aug 21, 2020 at 03:25:29PM +0900, Masahiko Sawada wrote:
> > Thank you for letting me know. I've attached the latest version patch set.
>
> A rebase is needed again as the CF bot is complaining.
Thank you for letting me know. I'm up
On Tue, Sep 15, 2020 at 02:39:08PM +0200, Peter Eisentraut wrote:
> I didn't mean use strtol() to be able to process larger values, but for the
> error checking. atoi() cannot detect any errors other than ERANGE. So if
> you are spending effort on making the option value parsing more robust,
> rel
At Thu, 17 Sep 2020 17:59:45 +0900 (JST), Kyotaro Horiguchi
wrote in
> Sigh.. I fixed some more wordings.
The condition "all clients took the same time to establish a
connection" is not needed for the transformation, and an intermediate
expression was wrong. Fixed them.
regards.
--
Kyotaro H
At Fri, 18 Sep 2020 09:55:30 +0200 (CEST), Fabien COELHO
wrote in
>
> Hello,
>
> >> Sorry, I sent a wrong version of the patch, contains some spelling
> >> errors. This is the right one.
> >
> > Sigh.. I fixed some more wordings.
>
> I have submitted a patch which reworks how things are compu
On Fri, Sep 18, 2020 at 8:10 AM Michael Paquier wrote:
> On Thu, Sep 17, 2020 at 10:20:16AM +0200, Oleksandr Shulgin wrote:
> > Ouch. I think pg_rewind shouldn't try to remove any random files in
> pg_wal
> > that it doesn't know about.
> > What if the administrator made a backup of some WAL seg
This is a proposal to add some features to pg_stat_statements.
Attached is the patch of this.
pg_stat_statements uses a hash table to hold statistics,
and the maximum number of its entries can be configured through
pg_stat_statements.max.
When the number of entries exceeds the pg_stat_statement
Hello.
I’d like to improve pg_stat_statements so that it can report the
timestamp when the stats are reset. Currently it’s difficult to check
that reset timestamp. But this information is useful, for example, when
calculating the SQL executions per second by SELECT calls / (now() -
reset_time
At Fri, 18 Sep 2020 17:28:22 +0900 (JST), Kyotaro Horiguchi
wrote in
> > I have submitted a patch which reworks how things are computed so that
> > performance figures make some/more sense, among other things.
> >
> > Maybe you could have a look at it and tell whether it is an
> > improvement w
Hi,
On Fri, Sep 18, 2020 at 10:54 AM Katsuragi Yuta
wrote:
>
> This is a proposal to add some features to pg_stat_statements.
> Attached is the patch of this.
>
> pg_stat_statements uses a hash table to hold statistics,
> and the maximum number of its entries can be configured through
> pg_stat_s
Hi,
While hacking my way around a different patch (better option handling
for pg_test_fsync), I got surprised by the fact that if we run the TAP
tests, logging initialization could return with errno set to ENOTTY
because we call isatty() to check for output coloring. I found that
this can be poss
On Thu, 17 Sep 2020 at 13:06, Amit Langote wrote:
> Hi Ashutosh,
>
> I had forgotten about this thread, but Michael's ping email brought it
> to my attention.
>
> Thanks Amit for addressing comments.
@@ -4256,5 +4256,8 @@ transformPartitionBoundValue(ParseState *pstate, Node
*val,
if (!IsA(val
On Thu, 17 Sep 2020 at 08:55, Andres Freund wrote:
>
> Hi,
>
> On 2020-09-17 14:20:50 +1200, Thomas Munro wrote:
> > I wonder if there is a way we could make "Minimal Tuples but with the
> > length travelling separately (and perhaps chopped off?)" into a
> > first-class concept... It's also a sha
On Thu, Sep 17, 2020 at 8:47 PM Juan José Santamaría Flecha <
juanjo.santama...@gmail.com> wrote:
> On Thu, Sep 17, 2020 at 6:04 PM Tom Lane wrote:
>
>>
>> One thing I noticed, which is a pre-existing problem but maybe now
>> is a good time to consider it, is that we're mapping lstat() to be
>> e
> On Thu, Sep 17, 2020 at 05:19:19PM +0200, Pavel Stehule wrote:
>
> ok, then I think we can design some workable behaviour
>
> My first rule - there should not be any implicit action that shifts
> positions in the array. It can be explicit, but not implicit. It is true
> for positive indexes, and
On Thu, Sep 17, 2020 at 05:42:59PM -0400, John Naylor wrote:
On Thu, Sep 17, 2020 at 12:34 PM Tomas Vondra
wrote:
On Thu, Sep 17, 2020 at 10:33:06AM -0400, John Naylor wrote:
>On Sun, Sep 13, 2020 at 12:40 PM Tomas Vondra
> wrote:
>> <20200913 patch set>
But those are opclass parameters, so th
On Thu, Sep 17, 2020 at 06:48:11PM -0400, John Naylor wrote:
I wrote:
Hmm, I came across that paper while doing background reading. Okay,
now I get that "% (filter->nbits - 1)" is the second hash function in
that scheme. But now I wonder if that second function should actually
act on the passed
On Tue, Sep 15, 2020 at 10:43 PM Amit Kapila wrote:
> I don't think it is complete yet.
> *
> * This error can only occur when we are sending the data in
> * streaming mode and the streaming is not finished yet.
> */
> - Assert(streaming);
> - Assert(stream_started);
> + Assert(streaming || r
> 18 сент. 2020 г., в 11:59, Michael Paquier написал(а):
>
> On Fri, Sep 18, 2020 at 11:31:26AM +0500, Andrey M. Borodin wrote:
>> This is whole point of having prefetch. restore_command just links
>> file from the same partition.
>
> If this stuff is willing to do so, you may have your reaso
On Thu, Sep 17, 2020 at 10:35 PM Amit Kapila wrote:
> Yeah, I think that would be better. How about if name the new variable
> as cleanup_prepared?
I haven't added a new flag to indicate that the prepare was cleaned
up, as that wasn' really necessary. Instead I used a new function to
do partial
On Thu, Sep 17, 2020 at 06:31:12PM -0300, Ranier Vilela wrote:
Em qui., 17 de set. de 2020 às 17:09, Tomas Vondra <
tomas.von...@2ndquadrant.com> escreveu:
On Thu, Sep 17, 2020 at 02:12:12PM -0300, Ranier Vilela wrote:
>Hi,
>
>In case gd->any_hashable is FALSE, grouping_is_hashable is never cal
On Fri, Sep 18, 2020 at 09:28:10PM +0800, Andy Fan wrote:
On Thu, Nov 28, 2019 at 12:48 AM Tomas Vondra
wrote:
On Tue, Nov 26, 2019 at 08:59:22AM +0800, Andy Fan wrote:
>The optimizer cost model usually needs 2 inputs, one is used to represent
>data distribution and the other one is used to r
Michael Paquier writes:
> Some system calls may not set errno even if they succeed, like
> strtol() on Linux for example, so in this case it can cause option
> handling to fail because of the error set by logging initialization.
> Shouldn't we reset errno to 0 once logging initialization is done?
On Wed, 16 Sep 2020 at 13:20, tsunakawa.ta...@fujitsu.com
wrote:
>
> From: Masahiko Sawada
> > > If so, can't we stipulate that the FDW implementor should ensure that the
> > commit function always returns control to the caller?
> >
> > How can the FDW implementor ensure that? Since even palloc c
> On 17 Aug 2020, at 06:12, Michael Paquier wrote:
> Leaving the problems with pgcrypto aside for now
Returning to this subject, I decided to take a stab at fixing pgcrypto since it
wasn't working.
Since we support ciphers that are now deprecated, we have no other choice than
to load the legacy
Unsurprisingly, commit 1ed6b8956 has led to the buildfarm's
cross-version upgrade tests no longer working, eg
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=tadarida&dt=2020-09-18%2013%3A06%3A52
Checking for reg* data types in user tables ok
Checking for contrib/isn with
That'd be useful in my book. My scripts just have a hard coded timestamp I
replace when I call reset so those calculations work, but it would be much
preferred to have that data available by a built in function.
-Adam
So I've finished up applying 0001 and started to look at 0002
... and I find the terminology you've chosen to be just really
opaque and confusing. "aliastype" being "implicit" or "explicit"
is not going to make any sense to anyone until they read the
manual, and it probably still won't make sense
Hi!
There's a thread about GiST build [0]. And we've found out there that logging
newly created index with batches of 32 pages is slightly faster. Heikki
implemented new logging routine log_newpages() for GiST build and it makes code
for this batching nice and clean.
Here is PoC with porting th
> On Sep 18, 2020, at 8:29 AM, Tom Lane wrote:
>
> So I've finished up applying 0001 and started to look at 0002
> ... and I find the terminology you've chosen to be just really
> opaque and confusing. "aliastype" being "implicit" or "explicit"
> is not going to make any sense to anyone until
pá 18. 9. 2020 v 13:01 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Thu, Sep 17, 2020 at 05:19:19PM +0200, Pavel Stehule wrote:
> >
> > ok, then I think we can design some workable behaviour
> >
> > My first rule - there should not be any implicit action that shifts
> > position
On Wed, Sep 16, 2020 at 10:27 PM Ashutosh Sharma wrote:
> > This is OK by me.
>
> Looks good to me too.
Cool, thanks to both of you for looking. Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Fri, Sep 18, 2020 at 11:29 AM Tom Lane wrote:
> I confess to not having paid very close attention to this thread
> lately, but the last I'd noticed the terminology proposed for
> internal use was "bare column label", which I think is much better.
I agree.
> As for what to expose in pg_get_key
On 2020/09/18 9:30, Thomas Munro wrote:
On Thu, Sep 17, 2020 at 10:47 PM Heikki Linnakangas wrote:
Hmm, so for speedy response to postmaster death, you're relying on the
loops to have other postmaster-death checks besides
HandleStartupProcInterrupts(), in the form of WL_EXIT_ON_PM_DEATH. Tha
Robert Haas writes:
> On Fri, Sep 18, 2020 at 11:29 AM Tom Lane wrote:
>> As for what to expose in pg_get_keywords, I think something like
>> "label_requires_as bool" would be immediately understandable.
>> If you really want it to be an enum sort of thing, maybe the output
>> column title could
On Fri, Sep 18, 2020 at 2:11 PM Tom Lane wrote:
> After re-reading the description of pg_get_keywords, I was reminded that
> what it outputs now is intended to provide both a machine-friendly
> description of the keyword category ("catcode") and a human-friendly
> description ("catdesc"). So we r
Robert Haas writes:
> On Fri, Sep 18, 2020 at 2:11 PM Tom Lane wrote:
>> What I now propose is to add two output columns:
>>
>> barelabel bool (t or f, obviously)
>> baredesc text ("can be bare label" or "requires AS", possibly localized)
> That might be over-engineered in a vacuum, but it s
pgcrypto has an abstraction for palloc/pfree via PX_OWN_ALLOC with the
intention to make it easy to swap out for another allocator. There are however
a number of palloc calls that have snuck in over the years, so the abstraction
is leaking a fair bit making it less useful. Since there have been n
On 9/18/20 10:39 AM, Tom Lane wrote:
> Unsurprisingly, commit 1ed6b8956 has led to the buildfarm's
> cross-version upgrade tests no longer working, eg
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=tadarida&dt=2020-09-18%2013%3A06%3A52
>
> Checking for reg* data types in user tables
Andrew Dunstan writes:
> On 9/18/20 10:39 AM, Tom Lane wrote:
>> I intentionally let that happen, figuring that it'd be good to get some
>> buildfarm cycles on the new code in pg_upgrade that does this check.
>> But now we have to think about updating the test. I think the best
>> bet is just to
On 9/18/20 4:25 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 9/18/20 10:39 AM, Tom Lane wrote:
>>> I intentionally let that happen, figuring that it'd be good to get some
>>> buildfarm cycles on the new code in pg_upgrade that does this check.
>>> But now we have to think about updating th
Andrew Dunstan writes:
> On 9/18/20 4:25 PM, Tom Lane wrote:
>> Hmm, that's not a postfix operator ... oh, it's because it depends on the
>> numeric_fac function alias which we also removed. We could eliminate
>> the need to drop it if we changed the definition to use "factorial"
>> instead of "n
Pushed with the discussed terminological changes and some other
fooling about, including fixing the documentation.
regards, tom lane
On Fri, Sep 18, 2020 at 7:40 AM Tomas Vondra
wrote:
>
> On Thu, Sep 17, 2020 at 06:48:11PM -0400, John Naylor wrote:
> >I wrote:
> >
> >> Hmm, I came across that paper while doing background reading. Okay,
> >> now I get that "% (filter->nbits - 1)" is the second hash function in
> >> that scheme.
I wrote:
> Andrew Dunstan writes:
>> Yeah, probably worth doing. It's a small enough change and it's only in
>> the test suite.
> OK, I'll go take care of that in a bit.
Done, you should be able to remove @#@ (NONE, bigint) from the
kill list.
regards, tom lane
On Wed, Sep 9, 2020 at 03:27:42PM -0300, Alvaro Herrera wrote:
> On 2020-Sep-09, Fujii Masao wrote:
>
> > On 2020/09/09 14:15, Etsuro Fujita wrote:
> > > Hi,
> > >
> > > Attached is a patch to standardize Japanese names as given-name-first
> > > in the v13 contributors list as before.
> >
> > U
On Fri, Sep 18, 2020 at 05:06:49PM -0400, John Naylor wrote:
On Fri, Sep 18, 2020 at 7:40 AM Tomas Vondra
wrote:
On Thu, Sep 17, 2020 at 06:48:11PM -0400, John Naylor wrote:
>I wrote:
>
>> Hmm, I came across that paper while doing background reading. Okay,
>> now I get that "% (filter->nbits -
Robert Haas writes:
> Cool, thanks to both of you for looking. Committed.
Hmph, according to whelk this is worse not better:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=whelk&dt=2020-09-18%2017%3A42%3A11
I'm at a loss to understand what's going on there.
reg
On Thu, Sep 10, 2020 at 11:02:07AM +0800, Craig Ringer wrote:
> Hi all
>
> As I've gained experience working on background workers, it's become
> increasingly clear that they're a bit too different to normal backends for
> many
> nontrivial uses.
>
> I thought I'd take a moment to note some of i
On Wed, Sep 16, 2020 at 05:40:30PM +0200, Pavel Stehule wrote:
> May be I am wrong, but it seems to me that not so much people know about
> pgxn.org
> Before writing this mail I have tried to locate such resource in Google
> and
> didn't succeed.
>
> yes, It is not strongly joined
On Fri, Sep 11, 2020 at 02:39:51PM +0200, Magnus Hagander wrote:
> Right now, pg_service.conf returns "syntax error" if it encounters a parameter
> it doesn't know about.
>
> This seems user-unfriendly, both in the error message (because it really isn't
> a syntax error) and in the behaviour itsel
On Tue, Sep 15, 2020 at 9:56 AM Thomas Munro wrote:
> > I looked over the patch and the only thing I saw was that we might
> > also want to remove the following line:
> >
> > #define DEF_FFACTOR1 /* default fill factor */
>
> Right, thanks. Fixed in the attached.
Pushed. Thanks Jakub, every
On Fri, Sep 18, 2020 at 4:48 PM Tom Lane wrote:
> Pushed with the discussed terminological changes and some other
> fooling about, including fixing the documentation.
Awesome. Thanks!
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Thu, Sep 17, 2020 at 10:40 AM Robert Haas wrote:
> Yeah, I plan to push forward with 0001 through 0003 soon, but 0001
> needs to be revised with a PGDLLIMPORT marking, I think, and 0002
> needs documentation.
So here's an updated version of those three, with proposed commit
messages, a PGDLLIM
Thomas Munro writes:
> Pushed. Thanks Jakub, everyone.
BTW, looking over this patch, I wonder about
/*
* Can't split if running in partitioned mode, nor if frozen, nor if
* table is the subject of any active hash_seq_search scans. Strange
* order of these tes
I wrote:
> ISTM that getting rid of the division obviates the concern that the
> nentries condition is too expensive,
Also, we could make it slightly cheaper yet, by changing the condition
to
hctl->freeList[0].nentries > (long) (hctl->max_bucket)
ie drop the +1. I'd argue that this
On Fri, Sep 18, 2020 at 09:56:14AM -0400, Tom Lane wrote:
> No, this is a bad idea. The right place to fix this is whatever code
> segment is relying on errno to be initially zero; that is NEVER a sane
> assumption. That is, a valid coding pattern is something like
It seems to me that it could b
Michael Paquier writes:
> On Fri, Sep 18, 2020 at 09:56:14AM -0400, Tom Lane wrote:
>> No, this is a bad idea. The right place to fix this is whatever code
>> segment is relying on errno to be initially zero; that is NEVER a sane
>> assumption. That is, a valid coding pattern is something like
On Fri, Sep 18, 2020 at 04:11:13PM +0200, Daniel Gustafsson wrote:
> Since we support ciphers that are now deprecated, we have no other choice than
> to load the legacy provider.
Ah, thanks. I actually tried something similar to that when I had my
mind on it by loading the legacy providers, but m
+ * changed to "inprogress-off", the barrier for mvoving to "off" can be
moving
+ * When disabling checksums, data_checksums will be set of "inprogress-off"
set *to*
+ get_namespace_name(RelationGetNamespace(reln)),
RelationGetRelationName(reln),
I think this palloc()s a new copy of the n
On Fri, Sep 18, 2020 at 09:54:42PM -0400, Tom Lane wrote:
> No, absolutely not. That way leads to madness, because you will be trying
> to enforce a system-wide property for the benefit of a few places. There
> is *no code anywhere* that promises to leave errno zero, but what you are
> suggesting
On Sat, Sep 19, 2020 at 1:30 PM Tom Lane wrote:
> I wrote:
> > ISTM that getting rid of the division obviates the concern that the
> > nentries condition is too expensive,
True, that comment needed to go.
> Also, we could make it slightly cheaper yet, by changing the condition
> to
>
>
so 19. 9. 2020 v 0:42 odesílatel Bruce Momjian napsal:
> On Wed, Sep 16, 2020 at 05:40:30PM +0200, Pavel Stehule wrote:
> > May be I am wrong, but it seems to me that not so much people know
> about
> > pgxn.org
> > Before writing this mail I have tried to locate such resource in
> Go
On Mon, Aug 31, 2020 at 8:50 PM Jakub Wartak wrote:
> - IO_URING - gives a lot of promise here I think, is it even planned to be
> shown for PgSQL14 cycle ? Or it's more like PgSQL15?
I can't answer that, but I've played around with the prototype quite a
bit, and thought quite a lot about how to
67 matches
Mail list logo
