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
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
>
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
>
>
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
>
+ * 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
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
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 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
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
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
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
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 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,
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
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
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
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=2020-09-18%2017%3A42%3A11
I'm at a loss to understand what's going on there.
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
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.
> >
> >
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 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
Pushed with the discussed terminological changes and some other
fooling about, including fixing the documentation.
regards, tom lane
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
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
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 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=2020-09-18%2013%3A06%3A52
>
> Checking for reg* data types in user tables
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
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
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
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 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.
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
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
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
> >
> 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
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
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
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
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=2020-09-18%2013%3A06%3A52
Checking for reg* data types in user tables ok
Checking for contrib/isn with
> 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
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
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 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
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
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
> 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
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 ||
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
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
> 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 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
>>
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
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
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
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
>
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
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() -
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
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
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
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
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,
>
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
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
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.
> >
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
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
> 18 сент. 2020 г., в 11:10, Michael Paquier написал(а):
>
> 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
On Wed, Sep 9, 2020 at 10:20 AM Amit Kapila wrote:
>
> On Thu, Jul 30, 2020 at 6:42 PM Amit Kapila wrote:
> >
> > On Thu, Jul 30, 2020 at 12:02 PM Amit Kapila
> > wrote:
> > >
> > > On Wed, Jul 29, 2020 at 7:18 PM Robert Haas wrote:
> > > >
> > > > I still don't agree with this as proposed.
>
On Fri, Sep 18, 2020 at 9:07 AM Amit Langote wrote:
>
> On Fri, Sep 18, 2020 at 12:30 PM Amit Kapila wrote:
> > I am not very excited to add information about structures used in the
> > file especially when we have explained 'LogicalRepPartMapEntry' a few
> > lines after. I think we can leave
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 segments there?
IMO, this would be a rather bad strategy anyway, so
71 matches
Mail list logo
