On Tue, 2 Jul 2019 at 11:27, Tom Lane wrote:
> My previous patch would have had you replace this with a loop using
> an integer list-position index. You can still do that if you like,
> but it's less change to convert the loop to a foreach(), drop the
> prev/next variables, and replace the list_d
On Tue, Jul 2, 2019 at 1:47 PM amul sul wrote:
> Attached version is rebase atop of the latest master head(c74d49d41c), thanks.
Thanks! Will review.
Best regards,
Etsuro Fujita
On Fri, Mar 1, 2019 at 12:01 AM Antonin Houska wrote:
> Tom Lane wrote:
>
> > Antonin Houska writes:
> > > Michael Paquier wrote:
> > >> Latest patch set fails to apply, so moved to next CF, waiting on
> > >> author.
> >
> > > Rebased.
> >
> > This is in need of rebasing again :-(. I went ahe
On Sun, Jun 30, 2019 at 12:09:18PM -0400, Tom Lane wrote:
> We could apply the same hack on the source node, but I wonder if it
> wouldn't be better to make this less of a kluge. I'm tempted to
> propose that "pg_regress --config-auth --user XXX" should understand
> XXX as the bootstrap superuser
Hi Tom,
On Wed, Feb 20, 2019 at 6:49 AM Tom Lane wrote:
> Obviously this'd be a major rewrite with no chance of making it into v12,
> but it doesn't sound too big to get done during v13.
Are you planning to work on this?
Thanks,
Amit
Hi David,
On Thu, Jun 27, 2019 at 2:28 PM David Rowley
wrote:
> Deja vu from this time last year when despite everyone's best efforts
> (mostly Alvaro) we missed getting run-time pruning in for MergeAppend
> into the PG11 release. This year it was ModifyTable, which is now
> possible thanks to
Hi Alvaro!
On 2019/06/22 3:52, Alvaro Herrera wrote:
Hello
Here's a patch that implements progress reporting for ANALYZE.
Sorry for the late reply.
My email address was changed to tatsuro.yamada...@nttcom.co.jp.
I have a question about your patch.
My ex-colleague Vinayak created same patch i
Could the attached patch fix this issue? Or does any one else plan to fix
it?
If people are busy and have not time, I can go ahead to fix it. To fix
this issue, do we need a patch for each official branch?
Regards,
Ruihai
On Tue, Jul 2, 2019 at 11:23 PM Tom Lane wrote:
> Rui Hai Jiang writ
Hi Prabhat,
On Tue, Jul 2, 2019 at 5:12 PM Prabhat Sahu
wrote:
>
> Hi,
>
> In below testcase when I changed the staorage option for root partition,
> newly attached partition not including the changed staorage option.
> Is this an expected behavior?
Thanks for the report. This seems like a bug
Hi,
> Memory leaks occur when the ecpg_update_declare_statement() is called
> the second time.
> ...
I'm going to commit this patch HEAD, this way we can see if it works as
advertised. It does not hurt if it gets removed by a rewrite.
Thanks for finding the issue,
Michael
--
Michael Meskes
Mic
Matsumura-san,
> I noticed that CREATE AS EXECUTE with using clause needs a new
> implementation that all parameters in using clause must be embedded
> into
> expr-list of EXECUTE in text-format as the following because there is
> no interface of protocol for our purpose.
> It spends more time fo
Hi,
because there's destination data
src/makefiles/pgxs.mk line
ln -s $< $@
fails and make clean doesn't remove these links.
ln -sf
is an option but it's not tested in configure
or rm -f
Regards
Didier
Hi Jeff,
On Mon, Jul 01, 2019 at 12:13:53PM -0700, Jeff Davis wrote:
This is for design review. I have a patch (WIP) for Approach 1, and if
this discussion starts to converge on that approach I will polish and
post it.
Thanks for working on this.
Let's start at the beginning: why do we have
On Tue, Jul 02, 2019 at 02:10:11PM +0900, Michael Paquier wrote:
> OK, committed to HEAD for now after perltidy'ing the patch. Let's see
> what the buildfarm has to say about it first. Once we are sure that
> the thing is stable, I'll try to backpatch it. This works on my own
> dev machines with
The single largest benefit of the v12 nbtree enhancement was its
adaptability with indexes where a portion of the key space contains
many duplicates. Successive page splits choose split points in a way
that leaves duplicates together on their own page, and eventually pack
pages full of duplicates.
On 2019-07-01 16:18, Alexey Kondratov wrote:
> I have found two minor issues with unified logging system for
> command-line programs (commited by Peter cc8d415117), while was rebasing
> my pg_rewind patch:
Fixed, thanks.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL D
John Naylor writes:
> 0001 is a small patch to remove some unneeded generality from the
> current rules. This lowers the number of elements in the yy_transition
> array from 37045 to 36201.
I don't particularly like 0001. The two bits like this
-whitespace ({space}+|{comment})
+whit
Peter Eisentraut writes:
> Attached is a patch to implement this in a handful of cases that are
> particularly verbose right now. I think those are easy wins.
> (Also a second patch that makes use of %zu for size_t where this was not
> yet done.)
I took a look through these and see nothing objec
> On 2 Jul 2019, at 22:35, Alvaro Herrera wrote:
> Anyway I'm not objecting to the patch -- I agree that we're already not
> testing translatability and that this patch shouldn't be forced to start
> doing it.
I forgot to add that to my previous email, the patch as it stands in v8 looks
good to
On 2019-Jul-02, Daniel Gustafsson wrote:
> > On 2 Jul 2019, at 22:16, Tom Lane wrote:
>
> > even if we made a test case that presumed
> > --enable-nls and tried to exercise this, the lack of translations
> > for the new words would get in the way for a long while.
>
> For testing though, couldn
> On 2 Jul 2019, at 22:16, Tom Lane wrote:
> even if we made a test case that presumed
> --enable-nls and tried to exercise this, the lack of translations
> for the new words would get in the way for a long while.
For testing though, couldn’t we have an autogenerated .po which has a unique
and p
Alvaro Herrera writes:
> On 2019-Jul-02, Tom Lane wrote:
>> * The persistence description values ought to be translatable, as
>> is the usual practice in describe.c. This is slightly painful
>> because it requires tweaking the translate_columns[] values in a
>> non-constant way, but it's not that
David Fetter writes:
> [ v7-0001-Add-warn-to-psql.patch ]
I took a look at this. I have no quibble with the proposed feature,
and the implementation is certainly simple enough. But I'm unconvinced
about the proposed test scaffolding. Spinning up a new PG instance is a
*hell* of a lot of overhe
On 2019-Jul-02, Tom Lane wrote:
> * The persistence description values ought to be translatable, as
> is the usual practice in describe.c. This is slightly painful
> because it requires tweaking the translate_columns[] values in a
> non-constant way, but it's not that bad.
LGTM. I only fear tha
Alexander Korotkov writes:
> On Tue, Jul 2, 2019 at 9:19 PM Nikita Glukhov wrote:
>> We could use commuted "const <-> var" operators for kNN searches, but the
>> current implementation requires the existence of "var <-> const" operators,
>> and
>> order-by-op clauses are rebuilt using them (see
David Fetter writes:
> [ v7-0001-Show-detailed-relation-persistence-in-dt.patch ]
I looked this over and had a few suggestions, as per attached v8:
* The persistence description values ought to be translatable, as
is the usual practice in describe.c. This is slightly painful
because it requires
On Tue, Jul 2, 2019 at 9:19 PM Nikita Glukhov wrote:
> We could use commuted "const <-> var" operators for kNN searches, but the
> current implementation requires the existence of "var <-> const" operators,
> and
> order-by-op clauses are rebuilt using them (see match_clause_to_ordering_op()
> at
Attached 2nd version of the patches.
On 20.04.2019 16:41, Fabien COELHO wrote:
About the test, I'd suggest to name the result columns, eg "pt to box
dist" and "box to pt dist", otherwise why all is repeated is unclear.
Fixed.
On 02.07.2019 7:01, Tom Lane wrote:
[ warning, drive-by comment
On Tue, Jul 02, 2019 at 03:06:52PM +0100, Peter Eisentraut wrote:
> On 2019-05-18 19:39, David Fetter wrote:
> > On Wed, May 15, 2019 at 09:32:31AM -0400, Tom Lane wrote:
> >> David Fetter writes:
> >>> I hope the patch is a little easier to digest as now attached.
> >>
> >> To be blunt, I find 50
On 28.06.2019 16:12, Alvaro Herrera wrote:
On Wed, Feb 20, 2019 at 7:04 PM Andres Freund wrote:
Or even just return it as a row. CopyBoth is relatively widely supported
these days.
i think generating warning about it also sufficiently meet its propose of
notifying user about skipped record wit
Robert Haas writes:
> Long story short, I agree with you that most people probably don't
> care about this very much, but I also agree with Andrew that some of
> the current choices we're making are pretty strange, and I'm not
> convinced as you are that it's impossible to make a principled choice
Rui Hai Jiang writes:
> I think I found an issue in the TopoSort() function.
This indeed seems like a live bug introduced by a1c1af2a.
Robert?
regards, tom lane
Oleksandr Shulgin writes:
> Not related to the diff v6..v7, but shouldn't we throw additionally a
> memset() with '\0' before calling pfree():
I don't see the point of that. In debug builds CLOBBER_FREED_MEMORY will
take care of it, and in non-debug builds I don't see why we'd expend
the cycles.
Peter Eisentraut writes:
> On 2019-06-30 14:50, Fabien COELHO wrote:
>> I'm wondering whether pg_random_uuid() should be taken out of pgcrypto if
>> it is available in core?
> That would probably require an extension version update dance in
> pgcrypto. I'm not sure if it's worth that. Thoughts
I wrote:
> Andres Freund writes:
>> Tom, any comments? Otherwise I'll go ahead, and commit after a round or
>> two of polishing.
> Sorry for not getting to this sooner --- I'll try to look tomorrow.
I took a look, and I think this is going in the right direction.
We definitely need a test case c
Hi,
In monitoring.sgml, "a" is missing in "row for ech backend that is
currently running that command[...]".
Anthony
On Tuesday, July 2, 2019, Julien Rouhaud wrote:
> On Fri, Jun 21, 2019 at 8:52 PM Alvaro Herrera
wrote:
>>
>> Here's a patch that implements progress reporting for ANALYZE.
>
> P
On Mon, Jul 1, 2019 at 6:46 AM Binguo Bao wrote:
> > Andrey Borodin 于2019年6月29日周六 下午9:48写道：
>> I've took a look into the code.
>> I think we should extract function for computation of max_compressed_size
>> and put it somewhere along with pglz code. Just in case something will
>> change somethi
Hi Hackers,
I think I found an issue in the TopoSort() function.
As the comments say,
/* .
* .. If there are any other processes
* in the same lock group on the queue, set their number of
* beforeConstraints to -1 to indi
On Tue, Jul 2, 2019 at 7:22 AM Surafel Temesgen
wrote:
>
> Hi,
> Here are same review comment
Thanks for your review.
> - any numeric, string, date/time, network, or enum type,
> + any numeric, string, date/time, network, lsn, or enum type,
> or arrays of these types
>
> Just to clarify what Adam is proposing in this thread is *not* a fault
> injection framework.
>
Yes, thanks for clarifying Ashwin.
Sorry Michael, this testing framework is more like these other frameworks:
Java with Junit + Hamcrest: http://hamcrest.org/JavaHamcrest/tutorial
Ruby with Rspec:
h
On 2019-05-18 19:39, David Fetter wrote:
> On Wed, May 15, 2019 at 09:32:31AM -0400, Tom Lane wrote:
>> David Fetter writes:
>>> I hope the patch is a little easier to digest as now attached.
>>
>> To be blunt, I find 500K worth of changes in the regression test
>> outputs to be absolutely unaccep
On Fri, Jun 21, 2019 at 8:52 PM Alvaro Herrera wrote:
>
> Here's a patch that implements progress reporting for ANALYZE.
Patch applies, code and doc and compiles cleanly. I have few comments:
@@ -512,7 +529,18 @@ do_analyze_rel(Relation onerel, VacuumParams *params,
if (numrows > 0)
{
On Mon, 1 Jul 2019 at 17:28, Alexander Korotkov
wrote:
> On Mon, Jul 1, 2019 at 5:51 PM Alvaro Herrera
> wrote:
> > On 2019-Jul-01, Alexander Korotkov wrote:
> >
> > > As I get we're currently need to make high-level decision of whether
> > > we need this [1]. I was going to bring this topic up
On Tue, 2 Jul 2019 at 21:00, Thomas Munro wrote:
> I took this for a quick spin today. The DISTINCT ON support is nice
> and I think it will be very useful. I've signed up to review it and
> will have more to say later. But today I had a couple of thoughts
> after looking into how src/backend/o
On Mon, Jul 01, 2019 at 12:02:28PM +0100, Dean Rasheed wrote:
On Sat, 29 Jun 2019 at 14:01, Tomas Vondra wrote:
>However, it looks like the problem is with mcv_list_items()'s use
>of %f to convert to text, which is pretty ugly.
>>>There's one issue with the signature, though - cur
Hi,
Here are same review comment
- any numeric, string, date/time, network, or enum type,
+ any numeric, string, date/time, network, lsn, or enum type,
or arrays of these types
same as argument type
In the documentation it refereed as pg_lsn type rather than lsn alone
On Fri, Apr 26, 2019 at 5:38 AM Michael Paquier wrote:
>
> On Thu, Apr 25, 2019 at 03:08:36PM -0400, Alvaro Herrera wrote:
> > On 2019-Apr-26, Fujii Masao wrote:
> >> I did that arrangement because the format of PREPARE TRANSACTION record,
> >> i.e., that struct, also needs to be accessed in backe
On Tue, Jul 02, 2019 at 10:45:44AM +0200, Julien Rouhaud wrote:
On Tue, Jul 2, 2019 at 10:28 AM Tomas Vondra
wrote:
I wonder why this is necessary:
pg_log_error("cannot reindex glibc dependent objects and a subset of objects");
What's the reasoning behind that? It seems like a valid use case
Hi Tom,
I think an assumption of d25ea01275 breaks partitionwise join. Sorry
it took me a while to report it.
In https://postgr.es/m/8168.1560446...@sss.pgh.pa.us, Tom wrote:
> I poked into this and found the cause. For the sample query, we have
> an EquivalenceClass containing the expression
>
On Fri, Jun 21, 2019 at 1:20 AM Jesper Pedersen
wrote:
> Attached is v20, since the last patch should have been v19.
I took this for a quick spin today. The DISTINCT ON support is nice
and I think it will be very useful. I've signed up to review it and
will have more to say later. But today I
On Tue, Jul 2, 2019 at 10:28 AM Tomas Vondra
wrote:
>
> I wonder why this is necessary:
>
> pg_log_error("cannot reindex glibc dependent objects and a subset of
> objects");
>
> What's the reasoning behind that? It seems like a valid use case to me -
> imagine you have a bug database, but only a
On Sun, Jun 30, 2019 at 08:30:33PM -0400, Tom Lane wrote:
Tomas Vondra writes:
Attached is a slightly improved version of the serialization patch.
I reviewed this patch, and tested it on hppa and ppc. I found one
serious bug: in the deserialization varlena case, you need
-
On 2/7/19 9:26, Peter Eisentraut wrote:
On 2019-06-30 14:50, Fabien COELHO wrote:
I'm wondering whether pg_random_uuid() should be taken out of pgcrypto if
it is available in core?
That would probably require an extension version update dance in
pgcrypto. I'm not sure if it's worth that. Thou
On Tue, Jul 2, 2019 at 9:19 AM Peter Eisentraut
wrote:
>
> On 2019-07-01 22:46, Alvaro Herrera wrote:
> > On 2019-Jul-02, Thomas Munro wrote:
> >> On Tue, Jul 2, 2019 at 8:34 AM Julien Rouhaud wrote:
> >>> Even if that's just me being delusional, I'd still prefer Alvaro's
> >>> approach to have d
On Sun, Jun 30, 2019 at 11:45:47AM +0200, Julien Rouhaud wrote:
Hi,
With the glibc 2.28 coming, all users will have to reindex almost
every indexes after a glibc upgrade to guarantee the lack of
corruption. Unfortunately, reindexdb is not ideal for that as it's
processing everything using a sin
On Tue, Jul 02, 2019 at 09:56:03AM +0200, Daniel Gustafsson wrote:
> I’m not sure we need to go to that length, but I don’t have overly strong
> opinions. I think of this more like a case of “we’ve changed the API with new
> errorcases that we didn’t handle before, so we’re being a little defensiv
On Mon, Jul 1, 2019 at 11:21 PM Peter Geoghegan wrote:
>
> On Mon, Jul 1, 2019 at 1:34 PM Julien Rouhaud wrote:
> > I have a vague recollection that ICU was providing some backward
> > compatibility so that even if you upgrade your lib you can still get
> > the sort order that was active when you
Hi,
In below testcase when I changed the staorage option for root partition,
newly attached partition not including the changed staorage option.
Is this an expected behavior?
postgres=# CREATE TABLE tab1 (c1 INT, c2 text) PARTITION BY RANGE(c1);
CREATE TABLE
postgres=# create table tt_p1 as selec
On Mon, Jul 01, 2019 at 04:32:15PM -0700, Andres Freund wrote:
Hi,
On 2019-06-29 22:15:19 +0200, Tomas Vondra wrote:
I think we should consider changing the effective_io_concurrency default
value, i.e. the guc that determines how many pages we try to prefetch in
a couple of places (the most imp
On Mon, Jun 17, 2019 at 5:01 PM Jamison, Kirk wrote:
>
> Hi all,
>
> Attached is the v2 of the patch. I added the optimization that Sawada-san
> suggested for DropRelFileNodeBuffers, although I did not acquire the lock
> when comparing the minBlock and target block.
>
> There's actually a comment
> On 2 Jul 2019, at 07:41, Michael Paquier wrote:
>> In the below passage, we leave the input buffer with a non-complete
>> encoded string. Should we memset the buffer to zero to avoid the
>> risk that code which fails to check the return value believes it has
>> an encoded string?
>
> Hmm. Go
On Tue, Jul 02, 2019 at 08:14:25AM +0100, Peter Eisentraut wrote:
> It appears that we have consensus to go ahead with this.
Yeah, I was planning to look at that one next. Or perhaps you would
like to take care of it, Peter?
>
> I was wondering whether the provided binary blob contained any che
On Tue, Jul 2, 2019 at 1:27 AM Tom Lane wrote:
>
> So I think this is a win, and attached is v7.
>
Not related to the diff v6..v7, but shouldn't we throw additionally a
memset() with '\0' before calling pfree():
+ListCell *newelements;
+
+newelements = (ListCell *)
+
On Thu, Feb 21, 2019 at 04:40:13PM +0900, Michael Paquier wrote:
> Rebased version fixing some conflicts with HEAD.
And rebased version for this stuff on HEAD (66c5bd3), giving visibly
v16.
--
Michael
From 76ef961e02e0276af5516bdce6e0e543526db5b2 Mon Sep 17 00:00:00 2001
From: Michael Paquier
Dat
On 2019-06-30 14:50, Fabien COELHO wrote:
> I'm wondering whether pg_random_uuid() should be taken out of pgcrypto if
> it is available in core?
That would probably require an extension version update dance in
pgcrypto. I'm not sure if it's worth that. Thoughts?
--
Peter Eisentraut
On 2019-07-01 22:46, Alvaro Herrera wrote:
> On 2019-Jul-02, Thomas Munro wrote:
>> On Tue, Jul 2, 2019 at 8:34 AM Julien Rouhaud wrote:
>>> Even if that's just me being delusional, I'd still prefer Alvaro's
>>> approach to have distinct switches for each collation system.
>>
>> Makes sense. But
On 2019-06-18 13:05, Daniel Gustafsson wrote:
> This was touched upon, but never really discussed AFAICT, back when then EDH
> parameters were reworked a few years ago. Instead of replacing with custom
> ones, as suggested in [1] it we might as well replace with standardized ones
> as
> this is a
On Mon, Jul 1, 2019 at 11:26 PM Michael Paquier wrote:
> On Fri, Jun 28, 2019 at 09:42:54AM -0400, Adam Berlin wrote:
> > If we were to use this tool, would the community want to vendor the
> > framework in the Postgres repository, or keep it in a separate repository
> > that produces a versioned
68 matches
Mail list logo
