On Fri, 27 Mar 2020 at 10:32, Fujii Masao wrote:
>
>
>
> On 2020/03/26 14:33, Masahiko Sawada wrote:
> > On Tue, 24 Mar 2020 at 17:04, Fujii Masao
> > wrote:
> >>
> >>
> >>
> >> On 2020/03/05 20:16, Fujii Masao wrote:
> >>>
> >>>
> >>> On 2020/03/05 16:58, Masahiko Sawada wrote:
> On Wed, 4
Hi,
On 2020-03-23 12:15:54 -0400, Robert Haas wrote:
> +
> +MANIFEST
> +
> +
> + When this option is specified with a value of
> ye'
s/ye'/yes/
> + or force-escape, a backup manifest is created
> + and sent along with the backup. The la
On Fri, Mar 27, 2020 at 11:46 AM Justin Pryzby wrote:
>
> On Thu, Mar 26, 2020 at 11:44:24PM -0500, Justin Pryzby wrote:
> > On Fri, Mar 27, 2020 at 09:49:29AM +0530, Amit Kapila wrote:
> > > On Fri, Mar 27, 2020 at 3:47 AM Justin Pryzby
> > > wrote:
> > > >
> > > > > Hm, I was just wondering wh
On Thu, Mar 26, 2020 at 11:44:24PM -0500, Justin Pryzby wrote:
> On Fri, Mar 27, 2020 at 09:49:29AM +0530, Amit Kapila wrote:
> > On Fri, Mar 27, 2020 at 3:47 AM Justin Pryzby wrote:
> > >
> > > > Hm, I was just wondering what happens if an error happens *during*
> > > > update_vacuum_error_cbarg(
On Thu, Mar 26, 2020 at 09:39:17PM -0300, Alvaro Herrera wrote:
> Now, would anyone be too upset if I push these in this other order? I
> realized that the reason the tests broke after Sergei's patch is that
> recovery/t/001_stream_rep.pl's get_slot_xmins() is broken for temp
> walreceiver slots,
Hi,
On 2020-03-26 15:37:11 -0400, Stephen Frost wrote:
> The argument is that adding checksums takes more time. I can understand
> that argument, though I don't really agree with it. Certainly a few
> percent really shouldn't be that big of an issue, and in many cases even
> a sha256 hash isn't
Hi,
On 2020-03-26 14:02:29 -0400, Robert Haas wrote:
> On Thu, Mar 26, 2020 at 12:34 PM Stephen Frost wrote:
> > Why was crc32c
> > picked for that purpose?
>
> Because it was discovered that 64-bit CRC was too slow, per commit
> 21fda22ec46deb7734f793ef4d7fa6c226b4c78e.
Well, a 32bit crc, not
On 2020/03/27 10:26, Tom Lane wrote:
Twice in the past month [1][2], buildfarm member hoverfly has managed
to reach the "unreachable" Assert(false) at the end of
SyncRepGetSyncStandbysPriority.
When I search the past discussions, I found that Noah Misch reported
the same issue.
https://www.p
On Fri, Mar 27, 2020 at 09:49:29AM +0530, Amit Kapila wrote:
> On Fri, Mar 27, 2020 at 3:47 AM Justin Pryzby wrote:
> >
> > > Hm, I was just wondering what happens if an error happens *during*
> > > update_vacuum_error_cbarg(). It seems like if we set
> > > errcbarg->phase=VACUUM_INDEX before set
Hi,
On 2020-03-26 11:37:48 -0400, Robert Haas wrote:
> I mean, you're just repeating the same argument here, and it's just
> not valid. Regardless of the file size, the chances of a false
> checksum match are literally less than one in a billion. There is
> every reason to believe that users will
On Fri, Mar 27, 2020 at 3:47 AM Justin Pryzby wrote:
>
>
> > Hm, I was just wondering what happens if an error happens *during*
> > update_vacuum_error_cbarg(). It seems like if we set
> > errcbarg->phase=VACUUM_INDEX before setting errcbarg->indname=indname, then
> > an
> > error would cause a
> Another issue is this:
> > +VACUUM ( FULL [, ...] ) [ TABLESPACE > class="parameter">new_tablespace ] [ > class="parameter">table_and_columns [, ...] ]
> As you mentioned in your v1 patch, in the other cases, "tablespace
> [tablespace]" is added at the end of the command rather than in the midd
On 2020/03/26 14:33, Masahiko Sawada wrote:
On Tue, 24 Mar 2020 at 17:04, Fujii Masao wrote:
On 2020/03/05 20:16, Fujii Masao wrote:
On 2020/03/05 16:58, Masahiko Sawada wrote:
On Wed, 4 Mar 2020 at 15:21, Fujii Masao wrote:
On 2020/03/04 14:31, Masahiko Sawada wrote:
On Wed, 4 M
On Thu, Mar 26, 2020 at 05:56:56PM +0800, Richard Guo wrote:
Hello,
When calculating the disk costs of hash aggregation that spills to disk,
there is something wrong with how we determine depth:
depth = ceil( log(nbatches - 1) / log(num_partitions) );
If nbatches is some number be
Twice in the past month [1][2], buildfarm member hoverfly has managed
to reach the "unreachable" Assert(false) at the end of
SyncRepGetSyncStandbysPriority.
What seems likely to me, after quickly eyeballing the code, is that
hoverfly is hitting the blatantly-obvious race condition in that function
Anna, thank you for your review.
On 2020-03-25 21:10, Anna Akenteva wrote:
On 2020-03-21 14:16, Kartyshov Ivan wrote:
and event is:
LSN value [options]
TIMESTAMP value
I would maybe remove WAIT FOR TIMESTAMP. As Robert Haas has pointed
out, it seems a lot like pg_slee
Hi,
Attached is v3 of the patch with one big change and various small ones.
The main change is that it gets rid of the SlruType enum and the new
field in SlruCtlData. Instead, the patch now uses the name passed to
SimpleLruInit (which is then stored as LWLock tranche name).
The counters are sti
On 2020-Mar-26, Justin Pryzby wrote:
> On Thu, Mar 26, 2020 at 07:49:51PM -0300, Alvaro Herrera wrote:
> > BTW I'm pretty sure this "revert back" phrasing is not good English --
> > you should just use "revert". Maybe get some native speaker's opinion
> > on it.
>
> I'm a native speaker; "rever
Now, would anyone be too upset if I push these in this other order? I
realized that the reason the tests broke after Sergei's patch is that
recovery/t/001_stream_rep.pl's get_slot_xmins() is broken for temp
walreceiver slots, since it's using the non-temp name it tries to give
to the slot, rather
Hello Surafel,
From: Surafel Temesgen
>An error that can be surly handled without transaction rollback can
>be included in error handling but i will like to proceed without binary file
>errors handling for the time being
Thank you.
Also it seems that you apply Alexey's comment.
So I'll mark thi
On Thu, Mar 26, 2020 at 07:49:51PM -0300, Alvaro Herrera wrote:
> > > ... So once we've "reverted back", 1) the pointer is null; and, 2)
> > > the callback function doesn't access it for the previous/reverted
> > > phase anyway.
>
> BTW I'm pretty sure this "revert back" phrasing is not good Engli
On 2020-Mar-26, Justin Pryzby wrote:
> On Thu, Mar 26, 2020 at 10:04:57AM -0500, Justin Pryzby wrote:
> > And I think you're right: we only save state when the calling function has a
> > indname=NULL, so we never "put back" a non-NULL indname. We go from having
> > a
> > indname=NULL at lazy_sc
On Thu, Mar 26, 2020 at 06:56:36PM -0300, Alvaro Herrera wrote:
> Uh, is XLOGDIR the only reason to include xlog_internal.h? Maybe it
> would be easier to have a routine in xlog.c that returns the path?
> There's a few functions in xlog.c that could use it, as well.
Yep, that's all. We could als
Hi Andres
thanks for your reply and your patch review. Please see my comments below
>On 2020-03-24 16:19:21 -0700, Cary Huang wrote:
>> I have shared a patch that allows sequence relation to be supported in
>> logical replication via the decoding plugin ( test_decoding for
>> example );
On Thu, Mar 26, 2020 at 10:04:57AM -0500, Justin Pryzby wrote:
> Does that address your comment ?
I hope so.
> > I'm not sure why "free_oldindname" is necessary. Since we initialize
> > vacrelstats->indname with NULL and revert the callback arguments at
> > the end of functions that needs update
On 2020-Mar-26, Michael Paquier wrote:
> I was looking at this patch again today and I am rather fine with the
> existing semantics. Still I don't like much to name the frontend-side
> routine FrontendRestoreArchivedFile() and use a different name than
> the backend counterpart because we have to
Bonjour Michaël,
[...] Still sounds strange to me to invent a new variable to this
structure if it is possible to track the exact same thing with an
existing part of a Command, or it would make sense to split Command into
two different structures with an extra structure used after the parsing
On 2020-03-26 10:34, Michael Paquier wrote:
On Tue, Mar 24, 2020 at 12:22:16PM +0900, Michael Paquier wrote:
Thanks Alvaro and Alexander. 0001 has been applied as of e09ad07.
Now for 0002, let's see about it later. Attached is a rebased
version, with no actual changes.
I was looking at this
On Fri, 27 Mar 2020 at 07:51, Andres Freund wrote:
>
> Hi,
>
> On 2020-03-26 10:12:39 +0100, Laurenz Albe wrote:
> > On Wed, 2020-03-25 at 23:19 +0300, Alexander Korotkov wrote:
> > I am reluctant to introduce new semantics like a reloption value of -2
> > to disable a feature in this patch right
On 25.03.2020 2:08, Tom Lane wrote:
Nikita Glukhov writes:
Attached new version of the patch.
I spent a little bit of time looking through this, and have a few
comments:
* You have a lot of places where tests for particular ASCII characters
are done like this:
if ((charlen == 1) &&
Andres Freund writes:
> On 2020-03-26 14:37:59 -0400, Tom Lane wrote:
>> Testing that reminded me of the other regression test failure I'd seen
>> when I first tried to do it: select_parallel.sql shows a WARNING about
>> a plancache leak in a parallel worker process. When I looked into the
>> rea
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Mar 26, 2020, at 12:37 PM, Stephen Frost wrote:
> > * Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> >>> On Mar 26, 2020, at 9:34 AM, Stephen Frost wrote:
> >>> I'm not actually argueing about which hash functions we shou
>BTW, so far as I can see, the only reason you're bothering with the whole
thing is to compare the size of the subquery output with work_mem, because
that's all that subplan_is_hashable does. I wonder whether that
consideration is even still necessary in the wake of 1f39bce02. If
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Mar 26, 2020 at 12:34 PM Stephen Frost wrote:
> > I do agree with excluding things like md5 and others that aren't good
> > options. I wasn't saying we should necessarily exclude crc32c either..
> > but rather saying that it shoul
> On Mar 26, 2020, at 12:37 PM, Stephen Frost wrote:
>
> Greetings,
>
> * Mark Dilger (mark.dil...@enterprisedb.com) wrote:
>>> On Mar 26, 2020, at 9:34 AM, Stephen Frost wrote:
>>> I'm not actually argueing about which hash functions we should support,
>>> but rather what the default is and
On 3/26/20 11:37 AM, Robert Haas wrote:
On Wed, Mar 25, 2020 at 4:54 PM Stephen Frost wrot >
This is where I feel like I'm trying to make decisions in a vacuum. If
we had a few more people weighing in on the thread on this point, I'd
be happy to go with whatever the consensus was. If most peopl
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Mar 26, 2020, at 9:34 AM, Stephen Frost wrote:
> > I'm not actually argueing about which hash functions we should support,
> > but rather what the default is and if crc32c, specifically, is actually
> > a reasonable choice. Ju
On 2020-03-26 21:01, Justin Pryzby wrote:
@@ -262,7 +280,7 @@ cluster(ClusterStmt *stmt, bool isTopLevel)
* and error messages should refer to the operation as VACUUM not
CLUSTER.
*/
void
-cluster_rel(Oid tableOid, Oid indexOid, int options)
+cluster_rel(Oid tableOid, Oid indexOid, Oid t
Andres Freund writes:
> On 2020-03-26 14:37:59 -0400, Tom Lane wrote:
>> + * This function, together with CachedPlanIsSimplyValid, provides a fast
>> path
>> + * for revalidating "simple" generic plans. The core requirement to be
>> simple
>> + * is that the plan must not require taking any loc
Hi,
On 2020-03-26 10:12:39 +0100, Laurenz Albe wrote:
> On Wed, 2020-03-25 at 23:19 +0300, Alexander Korotkov wrote:
> I am reluctant to introduce new semantics like a reloption value of -2
> to disable a feature in this patch right before feature freeze.
>
> I believe there are enough options to
Hi,
On 2020-03-26 14:37:59 -0400, Tom Lane wrote:
> I wrote:
> > I had a thought about a possibly-cleaner way to do this. We could invent
> > a resowner function, say ResourceOwnerReleaseAllPlanCacheRefs, that
> > explicitly releases all plancache pins it knows about. So plpgsql
> > would not ca
On 2020-03-26 18:49, Pavel Stehule wrote:
Hi
[psql-gfmt.patch]
This seems useful and works well; I haven't found any errors. Well done.
However, I have a suggestion that is perhaps slightly outside of this
patch but functionally so close that maybe we can discuss it here.
When you try to g
I wrote:
> I had a thought about a possibly-cleaner way to do this. We could invent
> a resowner function, say ResourceOwnerReleaseAllPlanCacheRefs, that
> explicitly releases all plancache pins it knows about. So plpgsql
> would not call the regular ResourceOwnerRelease entry point at all,
> but
On Thu, Mar 26, 2020 at 12:34 PM Stephen Frost wrote:
> I do agree with excluding things like md5 and others that aren't good
> options. I wasn't saying we should necessarily exclude crc32c either..
> but rather saying that it shouldn't be the default.
>
> Here's another way to look at it- where
> I included your new solution regarding this part from 0004 into 0001. It
> seems that at least a tip of the problem was in that we tried to change
> tablespace to pg_default being already there.
Right, causing it to try to drop that filenode twice.
> +++ b/doc/src/sgml/ref/cluster.sgml
> +
čt 26. 3. 2020 v 18:55 odesílatel Vik Fearing
napsal:
> On 3/26/20 10:49 AM, Pavel Stehule wrote:
> > Hi
> >
> > čt 26. 3. 2020 v 17:45 odesílatel Vik Fearing
> > napsal:
> >
> >> After some opinions on the first issue and fixing the second, I think
> >> this is good to be committed.
> >>
> >
>
On 3/26/20 10:49 AM, Pavel Stehule wrote:
> Hi
>
> čt 26. 3. 2020 v 17:45 odesílatel Vik Fearing
> napsal:
>
>> After some opinions on the first issue and fixing the second, I think
>> this is good to be committed.
>>
>
> Thank you for review
This patch now looks good to me. Marking as Ready
Hi
čt 26. 3. 2020 v 17:45 odesílatel Vik Fearing
napsal:
> On 3/24/20 3:02 AM, Pavel Stehule wrote:
> > Hi
> >
> > rebase
>
> Thank you, Pavel.
>
> I have now had time to review it, and it looks good to me except for two
> issues.
>
> The first is, even though I suggested gf, I think it should a
> On Mar 26, 2020, at 9:34 AM, Stephen Frost wrote:
>
> I'm not actually argueing about which hash functions we should support,
> but rather what the default is and if crc32c, specifically, is actually
> a reasonable choice. Just because it's fast and we already had an
> implementation of it
Amit Langote writes:
> One thing -- I don't get the division between
> CachedPlanAllowsSimpleValidityCheck() and CachedPlanIsSimplyValid().
> Maybe I am missing something, but could there not be just one
> function, possibly using whether expr_simple_expr is set or not to
> skip or do, resp., the
On Thu, 26 Mar 2020 at 19:39, Tom Lane wrote:
> Ashutosh Bapat writes:
> > On Wed, 18 Mar 2020 at 08:18, movead...@highgo.ca
> > wrote:
> >> if we change return type of all those functions to int64, we won't need
> >> this cast.
> >> I change the 'encode' function, it needs an int64 return type
On 2020-03-26 02:40, Justin Pryzby wrote:
On Thu, Mar 12, 2020 at 08:08:46PM +0300, Alexey Kondratov wrote:
On 09.03.2020 23:04, Justin Pryzby wrote:
On Sat, Feb 29, 2020 at 08:53:04AM -0600, Justin Pryzby wrote:
On Sat, Feb 29, 2020 at 03:35:27PM +0300, Alexey Kondratov wrote:
tests for that.
While reviewing the patch for \gf, I noticed that \gx does not have tab
completion for its optional filename. Trivial patch attached. I would
also suggest this be backpatched.
--
Vik Fearing
diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
index ae35fa4aa9..7252b6c4e6 10064
On 3/24/20 3:02 AM, Pavel Stehule wrote:
> Hi
>
> rebase
Thank you, Pavel.
I have now had time to review it, and it looks good to me except for two
issues.
The first is, even though I suggested gf, I think it should actually be
gfmt. There may be something else in the future that starts with f
On Thu, Mar 26, 2020 at 11:44:44AM -0400, Tom Lane wrote:
> Fujii Masao writes:
> > Does anyone object to this patch? I'm thinking to commit it separetely
> > at first before committing the planning_counter_in_pg_stat_statements
> > patch.
>
> I took a quick look through v9-0001-Pass-query-string
On Wed, Mar 25, 2020 at 8:53 AM Peter Eisentraut
wrote:
> HINT: This is to be expected if this is the end of the WAL. Otherwise,
> it could indicate corruption.
First, I agree that this general issue is a problem, because it's come
up for me in quite a number of customer situations. Either peop
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Mar 25, 2020 at 4:54 PM Stephen Frost wrote:
> > > That's a fair argument, but I think the other relevant principle is
> > > that we try to give people useful defaults for things. I think that
> > > checksums are a sufficiently use
Le 25/03/2020 à 03:49, Dave Sharpe a écrit :
>
> Hi pghackers,
>
> This is my first time posting here ... Gilles Darold and I are
> developing a new FDW which is based on the contrib/postgres_fdw. The
> postgres_fdw logic uses a RegisterXactCallback function to send local
> transactions remote. Bu
On 25.03.2020 20:04, Rafia Sabih wrote:
Also, there is no description about any of the functions here,
wouldn’t hurt having some more comments there.
Attached please find new version of the patch with more comments and
descriptions added.
--
Konstantin Knizhnik
Postgres Professional: htt
Fujii Masao writes:
> Does anyone object to this patch? I'm thinking to commit it separetely
> at first before committing the planning_counter_in_pg_stat_statements
> patch.
I took a quick look through v9-0001-Pass-query-string-to-the-planner.patch
and it's fine by me. It also matches up with so
On Wed, Mar 25, 2020 at 4:54 PM Stephen Frost wrote:
> > That's a fair argument, but I think the other relevant principle is
> > that we try to give people useful defaults for things. I think that
> > checksums are a sufficiently useful thing that having the default be
> > not to do it doesn't mak
On Thu, Mar 26, 2020 at 08:56:54PM +0900, Masahiko Sawada wrote:
> 1.
> @@ -1844,9 +1914,15 @@ lazy_vacuum_page(Relation onerel, BlockNumber
> blkno, Buffer buffer,
> int uncnt = 0;
> TransactionId visibility_cutoff_xid;
> boolall_frozen;
> + LVRelStats olderrcbarg;
>
Thank you very much for review.
On 25.03.2020 20:04, Rafia Sabih wrote:
+static void
+AddMultiColumnStatisticsForNode(PlanState *planstate, ExplainState *es);
+
This doesn't look like the right place for it, you might want to
declare it with other functions in the starting of the file.
Also,
On Thu, Mar 26, 2020 at 10:54:35PM +0900, Fujii Masao wrote:
>
> On 2020/03/10 6:31, legrand legrand wrote:
> > Hello,
> >
> > This is a call for committers, reviewers and users,
> > regarding "planning counters in pg_stat_statements"
> > patch [1] but not only.
>
> Does anyone object to this pa
Hello
> If we don't ignore walreceiver and does try to connect to the master,
> a promotion and recovery cannot end forever since new WAL data can
> be streamed. You think this behavior is more consistent?
We have no simple point to stop replay.
Well, except for "immediately" - just one easy stop
Marco Atzeri writes:
> Am 17.02.2020 um 17:49 schrieb Tom Lane:
>> 1. On platforms where Python 2.x is still supported, recommend that
>> packagers continue to build both plpython2 and plpython3, same as now.
> there is some documentation on how to build both ?
> The INSTALL gives no hint.
It's
On Wed, Mar 25, 2020 at 9:29 PM Peter Eisentraut
wrote:
> On 2020-03-23 06:02, Amit Langote wrote:
> > Okay, added some tests.
> >
> > Attached updated patches.
>
> I have committed the worker.c refactoring patch.
>
> "Add subscription support to replicate into partitioned tables" still
> has lack
On Thu, Mar 26, 2020 at 03:02:42PM +0100, Daniel Gustafsson wrote:
> I noticed in passing that backend/storage/page/README hadn't gotten the memo
> about pg_checksums. The attached tiny diff adds a small mention of it.
Good catch! LGTM
Ashutosh Bapat writes:
> On Wed, 18 Mar 2020 at 08:18, movead...@highgo.ca
> wrote:
>> if we change return type of all those functions to int64, we won't need
>> this cast.
>> I change the 'encode' function, it needs an int64 return type, but keep
>> other
>> functions in 'pg_encoding', because I
On Thu, Mar 26, 2020 at 3:02 PM Daniel Gustafsson wrote:
>
> I noticed in passing that backend/storage/page/README hadn't gotten the memo
> about pg_checksums. The attached tiny diff adds a small mention of it.
That seems obvious enough. Pushed, thanks!
--
Magnus Hagander
Me: https://www.hag
Andres Freund writes:
> On 2020-03-25 17:51:50 -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> Hm, any chance that the multiple resowner calls here could show up in a
>>> profile? Probably not?
>> Doubt it. On the other hand, as the code stands it's certain that the
>> resowner contains not
I noticed in passing that backend/storage/page/README hadn't gotten the memo
about pg_checksums. The attached tiny diff adds a small mention of it.
cheers ./daniel
cksum_page_readme.diff
Description: Binary data
On 2020/03/10 6:31, legrand legrand wrote:
Hello,
This is a call for committers, reviewers and users,
regarding "planning counters in pg_stat_statements"
patch [1] but not only.
Does anyone object to this patch? I'm thinking to commit it separetely
at first before committing the planning_co
On Wed, 18 Mar 2020 at 08:18, movead...@highgo.ca
wrote:
>
> Hello thanks for the detailed review,
>
> >I think the second argument indicates the bit position, which would be
> max bytea length * 8. If max bytea length covers whole int32, the second
> argument >needs to be wider i.e. int64.
> Yes
On Thu, Mar 26, 2020 at 08:08:35PM +0900, Fujii Masao wrote:
>
> On 2020/03/25 22:45, Julien Rouhaud wrote:
> > On Wed, Mar 25, 2020 at 10:09:37PM +0900, Fujii Masao wrote:
> > > + /*
> > > + * We can't process the query if no query_text is provided, as
> > > pgss_store
> > > + * needs it. We
On 2020/03/25 19:42, Sergei Kornilov wrote:
Hi
Could we add a few words in func.sgml to clarify the behavior? Especially for
users from my example above. Something like:
If a promotion is triggered while recovery is paused, the paused state ends,
replay of any WAL immediately availab
On 2020-03-25 17:56, Robert Haas wrote:
On Wed, Mar 25, 2020 at 6:13 AM Peter Eisentraut
wrote:
Any concerns about applying and backpatching the patch I posted?
Not from me.
The talk about reorganizing this code doesn't seem very concrete at the
moment and would probably not be backpatch ma
On Thu, 26 Mar 2020 at 15:34, Amit Kapila wrote:
>
> On Thu, Mar 26, 2020 at 12:03 PM Amit Kapila wrote:
> >
> > On Thu, Mar 26, 2020 at 10:11 AM Justin Pryzby wrote:
> > >
> > > Seems fine. Rather than saying "different phases" I, would say:
> > > "The index vacuum and heap vacuum phases may b
On 2020/03/25 22:45, Julien Rouhaud wrote:
On Wed, Mar 25, 2020 at 10:09:37PM +0900, Fujii Masao wrote:
On 2020/03/21 4:30, Julien Rouhaud wrote:
On Fri, Mar 20, 2020 at 05:09:05PM +0300, Sergei Kornilov wrote:
Hello
Yet another is missed in docs: total_time
Oh good catch! I rechecked
On Thu, Mar 26, 2020 at 4:44 AM Tom Lane wrote:
>
> Pavel Stehule writes:
> > I'll mark this patch as ready for commiters.
>
> Thanks for reviewing! Amit, do you have any thoughts on this?
Thanks for picking this up. Test cases added by your patch really
shows why the plancache and the planner
On Tue, Mar 24, 2020 at 12:01 PM Kyotaro Horiguchi
wrote:
> At Mon, 23 Mar 2020 21:13:48 +0800, Richard Guo
> wrote in
> > Hi all,
> >
> > With the following statements on latest master (c81bd3b9), I find
> > negative cost for plan nodes.
> >
> > create table a (i int, j int);
> > insert into a
Hello,
When calculating the disk costs of hash aggregation that spills to disk,
there is something wrong with how we determine depth:
>depth = ceil( log(nbatches - 1) / log(num_partitions) );
If nbatches is some number between 1.0 and 2.0, we would have a negative
depth. As a result,
Hello
Thank you! You were ahead of me. I wanted to double-check my changes this
morning before posting.
> Sergei included LOG messages to indicate which setting has been changed.
> I put these in "#if 0" for now, but I'm thinking to remove these
> altogether;
No objections.
> Not sure if we ca
On 2020-03-26 06:46, Marco Atzeri wrote:
Am 17.02.2020 um 17:49 schrieb Tom Lane:
We've had multiple previous discussions of $SUBJECT (eg [1][2]),
without any resolution of what to do exactly. Thinking about this
some more, I had an idea that I don't think has been discussed.
To wit:
1. On pla
On Wed, 2020-03-25 at 23:19 +0300, Alexander Korotkov wrote:
> On Wed, Mar 25, 2020 at 10:26 PM Andres Freund wrote:
> > On 2020-03-25 11:05:21 -0500, Justin Pryzby wrote:
> > > Since we talked about how scale_factor can be used to effectively disable
> > > this
> > > new feature, I thought that
On Wed, Mar 25, 2020 at 4:18 AM Thomas Munro wrote:
>
> Thanks! Pushed.
>
Great!
> From the things we learned in this thread, I think there is an open
> item for someone to write a patch to call EnumSystemLocalesEx() and
> populate the initial set of collations, where we use "locale -a" on
>
On Thu, 12 Mar 2020 at 04:34, Peter Eisentraut
wrote:
>
> Here is an updated patch that incorporates some of the suggestions. In
> particular, some of the warning messages have been rephrased to more
> accurate (but also less specific), the warning message at recovery pause
> repeats every 1 minu
Hi Takanori Asaba,
>
>
> Although it is a small point, it may be better like this:
> +70005 27 36 46 56 -> 70005 27 37 47 57
>
>
done
> I want to discuss about copy from binary file.
> It seems that this patch tries to avoid the error that number of field is
> di
On Tue, Mar 24, 2020 at 12:22:16PM +0900, Michael Paquier wrote:
> Thanks Alvaro and Alexander. 0001 has been applied as of e09ad07.
> Now for 0002, let's see about it later. Attached is a rebased
> version, with no actual changes.
I was looking at this patch again today and I am rather fine wit
On Wed, Jan 22, 2020 at 3:35 PM Andrew Gierth
wrote:
> > "Alvaro" == Alvaro Herrera writes:
>
>
> I was largely holding off on doing further work hoping for some
> discussion of which way we should go. If you think my approach is worth
> pursuing (I haven't seriously tested the performance,
90 matches
Mail list logo
