On Wed, Jan 10, 2018 at 11:49:47PM +0100, Daniel Gustafsson wrote:
>> On 08 Jan 2018, at 17:27, Robert Haas wrote:
>> nor has anyone taken the trouble to list with precision all of the
>> places where the behavior will change. I think the latter is
>> absolutely indispensable,
>
> I had a look a
Hello,
At Thu, 4 Jan 2018 23:10:40 -0500, Stephen Frost wrote in
<20180105041040.gi2...@tamriel.snowman.net>
> > The attached patch applies on the current HEAD and passes all
> > recovery tests.
>
> This is currently marked as 'waiting on author' in the CF app, but it
> sounds like it should be
At Mon, 11 Dec 2017 20:07:53 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20171211.200753.191768178.horiguchi.kyot...@lab.ntt.co.jp>
> > The attached PoC patch theoretically has no impact on the normal
> > code paths and just brings gain in async cases.
>
> The parallel append just
Konstantin Knizhnik wrote:
> On 09.01.2018 19:48, Antonin Houska wrote:
>
>> Have you considered using the range types (internally in
>> operator_predicate_proof()) instead of hard-coding operator OIDs? The range
>> types do have the knowledge that k < 20001 and k <= 2 are equivalent for
>>
Hello
>> patch -p1 gives some "Stripping trailing CRs from patch"
>> messages for me, but applied to current HEAD and builds. After
>
> Hmm. I wonder why I get that complaint so often. (It's rather
> common? or caused by the MIME format of my mail?) I'd say with
> confidence that it is because y
On 2018/01/04 23:29, Ashutosh Bapat wrote:
> On Fri, Dec 29, 2017 at 6:32 PM, Alvaro Herrera
> wrote:
>> I happened to notice that Ashutosh's patch series at
>> https://www.postgresql.org/message-id/CAFjFpReJhFSoy6DqH0ipFSHd=sLNEkSzAtz4VWCaS-w2jZL=u...@mail.gmail.com
>> has a 0001 patch that modi
On Sun, Jan 7, 2018 at 1:35 AM, David Steele wrote:
> On 1/6/18 3:48 AM, Michael Paquier wrote:
>>
>> On Fri, Jan 5, 2018 at 11:27 PM, Simon Riggs
>> wrote:
>>
>>> Which also makes it a smaller and clearer patch
>>
>>
>> Yes, this generates less diffs, reducing the likelihood of bugs. What
>> do
Hello!
I like heapam verification functionality and use it right now. So, I'm planning
to provide review for this patch, probably, this week.
From my current use I have some thoughts on interface. Here's what I get.
# select bt_index_check('messagefiltervalue_group_id_59490523e6ee451f',true);
Hi,
The declaration of estimate_path_cost_size uses baserel, but
the actual definition uses foreignrel. It would be better to sync.
Please find attached a patch.
Tatsuro Yamada
NTT Open Source Software Center
diff --git a/contrib/postgres_fdw/postgres_fdw.c b/contrib/postgres_fdw/postgres_fdw.c
Thanks for addressing that list.
Just one thing to reply on before I look at the updated version:
On 11 January 2018 at 22:52, Amit Langote wrote:
> On 2018/01/10 10:55, David Rowley wrote:
>> One more thing I discovered while troubleshooting a bug Beena reported
>> in the run-time partition pru
> On 11 January 2018 at 22:52, Amit Langote
> wrote:
>> Can you point me to the email where Beena reported the problem in question?
>
> https://www.postgresql.org/message-id/CAOG9ApERiop7P=grkqqka82aubkjxn3qvixie3wk4wqqpej...@mail.gmail.com
To save you from having to look at the run-time prune p
On Thu, Jan 11, 2018 at 7:36 PM, Haribabu Kommi
wrote:
> -DATA = pg_stat_statements--1.4.sql pg_stat_statements--1.4--1.5.sql \
> +DATA = pg_stat_statements--1.5.sql pg_stat_statements--1.4--1.5.sql \
>
> The current version of the pg_stat_statements is already 1.5, this patch
> should increase it
> On Thu, Dec 14, 2017 at 4:01 PM, Ashutosh Bapat <
> ashutosh.ba...@enterprisedb.com> wrote:
>
>>
>> +
>> +-- Partial aggregation as GROUP BY clause does not match with PARTITION
>> KEY
>> +EXPLAIN (COSTS OFF)
>> +SELECT b, sum(a), count(*) FROM pagg_tab GROUP BY b ORDER BY 1, 2, 3;
>> +
On Wed, Jan 10, 2018 at 8:02 PM, Alvaro Herrera
wrote:
> Teodor Sigaev wrote:
>
> > SQL-query seems too huge for release notes and isn't looking for
> > materialized view (fixable) and functional indexes with function which
> > contains this operator somewhere inside (not fixable by this query).
On 9 January 2018 at 23:07, Robert Haas wrote:
> On Thu, Jan 4, 2018 at 1:18 AM, Amit Khandekar wrote:
>> --
>> 1. ExecUpdate() needs to revert back tcs_map value changed by ExecInsert()
>> --
>>
It seems like the ON CONFLICT stuff handled that by adding a
>>>
Hi,
I found a variable (queryEnv) which should be added in
ExplainOneQuery_hook because if it is missing, hook function
can't call ExplainOnePlan.
Sorry if this wasn't correct.
Please find attached a patch.
Tatsuro Yamada
NTT Open Source Software Center
diff --git a/src/backend/commands/explain
On Fri, Jan 12, 2018 at 12:16 AM, Tatsuro Yamada
wrote:
> I found a variable (queryEnv) which should be added in
> ExplainOneQuery_hook because if it is missing, hook function
> can't call ExplainOnePlan.
> Sorry if this wasn't correct.
>
> Please find attached a patch.
Yeah, I think you're right
Thanks to all, pushed
I think this is useful enough. The fact remains that we can't check
very well for functions; maybe suggest a LIKE clause to look for ~>
anywhere in function source code?Seems, it's overengineering. It could give a false positive results and doesn't
cover all c
On 11.01.2018 12:34, Antonin Houska wrote:
Konstantin Knizhnik wrote:
On 09.01.2018 19:48, Antonin Houska wrote:
Have you considered using the range types (internally in
operator_predicate_proof()) instead of hard-coding operator OIDs? The range
types do have the knowledge that k < 20001 a
On 01/11/18 02:07, Tom Lane wrote:
> Hm, it won't help your sanity to know that those cases pass fine
> for me, interactively, on a couple of different machines:
> ...
> You sure you're using a stock build of Postgres? No handmade
> versions of operator ^ lying around?
Interesting thought
A
Teodor Sigaev wrote:
>
> > I think this is useful enough. The fact remains that we can't check
> > very well for functions; maybe suggest a LIKE clause to look for ~>
> > anywhere in function source code?
> Seems, it's overengineering. It could give a false positive results
> and doe
Tom Lane writes:
> Chapman Flack writes:
>> I see there are some tests in src/test/regress:
>> [ that don't work for me ]
>> Is there some special GUC setting in effect during the make check
>> that would be different in my ordinary session? What else could
>> be different? This is making me que
On 03-01-2018 19:28, Fabien COELHO wrote:
Hello Marina,
Hello!
Some comment about WIP pgbench error handling v4.
Many thanks!
Patch applies, compiles, global & local "make check" are ok. doc
compiles.
I'm generally okay with having such a feature, but I'd like it to be
*MUCH* simpler, o
Hello
I am surprised, but i can confirm error on versions prior 9.6: on 9.5, 9.4, 9.3
same error. On 9.6 and 10 query works correctly
All checked postgresql are x86_64 from postgresql debian repository:
http://apt.postgresql.org/pub/repos/apt/ jessie-pgdg main
postgres=# select 0.5678::numeric o
On Fri, Jan 12, 2018 at 12:43:22AM +1300, Thomas Munro wrote:
> Yeah, I think you're right. That's an oversight in 18ce3a4a.
+1.
> I'm surprised we haven't heard any complaints sooner if there are
> advisors using that hook[1] and expecting to be able to forward to
> ExplainOnePlan(), but I supp
On Thu, Jan 11, 2018 at 07:10:50PM +0900, Masahiko Sawada wrote:
> On Sun, Jan 7, 2018 at 1:35 AM, David Steele wrote:
>> On 1/6/18 3:48 AM, Michael Paquier wrote:
>>> On Fri, Jan 5, 2018 at 11:27 PM, Simon Riggs
>>> wrote:
>>>
Which also makes it a smaller and clearer patch
>>>
>>> Yes, thi
ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
> The behaviour seems to have changed in 9.6:
Indeed, https://www.postgresql.org/docs/current/static/release-9-6.html
has the following entry:
* Improve the accuracy of the ln(), log(), exp(), and pow() functions
for type numeric (Dean Ras
On 11 January 2018 at 09:55, Sergei Kornilov wrote:
> if (active_pid != 0)
> status = "streaming";
> else
> status = "keeping";
Perhaps "idle" by analogy to a pg_stat_activity entry for a backend
that's connected but not doing anything.
> s
Lucas, Robert, all,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Nov 6, 2017 at 4:43 AM, Tom Lane wrote:
> > I wonder if we couldn't somehow repurpose the work that was done for
> > parallel workers' locks. Lots of security-type issues to be handled
> > if we're to open that up to clie
Amul,
* amul sul (sula...@gmail.com) wrote:
> Agree, updated in the attached patch. Patch 0001 also includes your
> previous review comment[1] and typo correction suggested by Alvaro[2].
Looks like this needs to be rebased (though the failures aren't too bad,
from what I'm seeing), so going to m
On Wed, Jan 10, 2018 at 03:05:39PM +0100, Julian Markwort wrote:
> Hello hackers,
>
> I'd like to follow up to my previous proposition of tracking (some) best and
> worst plans for different queries in the pg_stat_statements extension.
>
> Based on the comments and suggestions made towards my las
On 01/11/2018 12:08 AM, Noah Misch wrote:
> On Sun, Dec 10, 2017 at 11:46:08AM -0800, Noah Misch wrote:
>> On Sun, Dec 10, 2017 at 12:36:13PM +, Christian Ullrich wrote:
>>> * Noah Misch wrote:
On Wed, Nov 29, 2017 at 11:45:35PM -0500, Tom Lane wrote:
> Oh, OK. In that case, we need
Alvaro Herrera writes:
> That's true, and I agree we don't necessarily have to find everything.
> I still think we should print the pg_depend query in the relnotes,
> because those would be the most common cases of objects that need to be
> rebuilt.
Wait. A. Minute. This patch seems totally unac
Due to circumstances beyond my control, I've had to shut down the ageing
Windows buildfarm animals in $SUBJECT.
I hope to restart them at some point, but it might be some time.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Ente
Tom Lane wrote:
> >> Since behavior of ~> (cube, int) operator is changed, depending entities
> >> must be refreshed after upgrade. Such as, expression indexes using this
> >> operator must be reindexed, materialized views must be rebuilt, stored
> >> procedures and client code must be revised to
Michael Paquier writes:
> While reviewing another patch related to the use of pg_strcasecmp in the
> backend, I have noticed this bit in ruleutils.c:
> /*
> * Some GUC variable names are 'LIST' type and hence must not
> * be quoted.
> */
> if (pg_strcasecmp(configitem, "Dat
Hello,
The first function call is 10 times slower than the other calls in the same
session. Is it possible to shorten this long time on the first call?
For example. Call my function for once, this call returns at 70ms on the
next call, the return is at 7ms.
thanks.
Hello,
On Fri, Dec 22, 2017 at 03:05:25PM +0300, Maksim Milyutin wrote:
> Hi, hackers!
>
>
> I want to propose the patch that allows to define custom signals and their
> handlers on extension side.
>
I've looked a little bit on the patch. The patch applyes and regression tests
pass.
I have a
Hello Fabien,
10/01/2018 21:42, Fabien COELHO пишет:
Should we probably add some infrastructure for optional arguments?
>>>
>>> You can look at the handling of "CASE" which may or may not have an
>>> "ELSE" clause.
>>>
>>> I'd suggest you use a new negative argument with the special meaning
Alvaro Herrera writes:
> Tom Lane wrote:
>> Was there any real discussion of whether we could get away with that
>> in the back branches? My opinion is no. It's not even clear to me
>> that this is acceptable in HEAD --- isn't it going to create huge
>> problems for pg_upgrade?
> This was discu
Hello -
I have found that in leveraging the parser code to decode DDL SQL, it is
very easy to get which type of general command is being issued with
CreateCommandTag(parsetree). However, is there a way (or a starting point)
to identify the sub-command as well i.e. ENABLE TRIGGER, ADD FOREIGN KEY,
Diego Silva e Silva writes:
> The first function call is 10 times slower than the other calls in the same
> session. Is it possible to shorten this long time on the first call?
> For example. Call my function for once, this call returns at 70ms on the
> next call, the return is at 7ms.
The first
On Thu, Jan 11, 2018 at 8:52 AM, Diego Silva e Silva
wrote:
> Hello,
>
> The first function call is 10 times slower than the other calls in the
> same session. Is it possible to shorten this long time on the first call?
> For example. Call my function for once, this call returns at 70ms on the
>
On 01/11/2018 07:44 AM, Sergei Kornilov wrote:
> Hello
> I am surprised, but i can confirm error on versions prior 9.6: on 9.5, 9.4,
> 9.3 same error. On 9.6 and 10 query works correctly
One of my tests (in fact, the one where I first noticed) was a build
from git a couple days ago at e35dba475a4
HelloYou can start with functions ATPrepCmd and ATExecCmd in src/backend/commands/tablecmds.cAlso note, one alter table statement can have multiple different actions. Regards, Sergei11.01.2018, 18:56, "Jeremy Finzel" :Hello -I have found that in leveraging the parser code to decode DDL SQL, it is v
10/01/2018 21:42, Fabien COELHO пишет:
>
> Hmm. I do not think that we should want a shared seed value. The seed
> should be different for each call so as to avoid undesired
> correlations. If wanted, correlation could be obtained by using an
> explicit identical seed.
>
> ISTM that the best way
Dagfinn Ilmari Mannsåker wrote:
> ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
>
> > The behaviour seems to have changed in 9.6:
>
> Indeed, https://www.postgresql.org/docs/current/static/release-9-6.html
> has the following entry:
>
> * Improve the accuracy of the ln(), log(), exp(), a
Jeremy Finzel wrote:
> Hello -
>
> I have found that in leveraging the parser code to decode DDL SQL, it is
> very easy to get which type of general command is being issued with
> CreateCommandTag(parsetree). However, is there a way (or a starting point)
> to identify the sub-command as well i.e.
On 01/11/2018 11:23 AM, Alvaro Herrera wrote:
> Dagfinn Ilmari Mannsåker wrote:
>> ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
>>
>>> The behaviour seems to have changed in 9.6:
>>
>> Indeed, https://www.postgresql.org/docs/current/static/release-9-6.html
>> has the following entry:
>>
>>
Hello -
Attached is a proposed patch to fix a bug in the ECPG preprocessor that
generates application code that core dumps at run-time. When the input pgc
code uses a record struct for returning query results and uses an indicator
struct that has fewer fields than the record struct, the generated
Tatsuro Yamada writes:
> The declaration of estimate_path_cost_size uses baserel, but
> the actual definition uses foreignrel. It would be better to sync.
Yeah, the join_conds parameter's been renamed at some point too :-(
Fixed.
regards, tom lane
Thomas Munro writes:
> On Fri, Jan 12, 2018 at 12:16 AM, Tatsuro Yamada
> wrote:
>> I found a variable (queryEnv) which should be added in
>> ExplainOneQuery_hook because if it is missing, hook function
>> can't call ExplainOnePlan.
> Yeah, I think you're right. That's an oversight in 18ce3a4a.
Hello, hackers! I got a permanent failure of master (commit
ca454b9bd34c75995eda4d07c9858f7c22890c2b) make check on Solaris 10.
Regression output and diffs are attached.
I used the following commands:
./configure CC="ccache gcc" CFLAGS="-m64 -I/opt/csw/include"
LDFLAGS="-L/opt/csw/lib/sparcv9
Robert, all,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Nov 21, 2017 at 9:26 AM, Amit Kapila wrote:
> > +1. I was also once confused with these macros. I think this is a
> > good cleanup. On a quick look, I don't see any problem with your
> > changes.
>
> One difference between th
On Wed, Jan 10, 2018 at 7:09 PM, Tom Lane wrote:
> * The complaint I had about the "container" terminology isn't just
> terminology. Rather, there is a bunch of knowledge in the system that
> some data types can be found embedded in other types; for one example,
> see find_composite_type_dependen
Marina Polyakova writes:
> Hello, hackers! I got a permanent failure of master (commit
> ca454b9bd34c75995eda4d07c9858f7c22890c2b) make check on Solaris 10.
> Regression output and diffs are attached.
Hm, buildfarm member protosciurus is running a similar configuration
without problems. Lookin
Hi,
On 2018-01-11 20:21:11 +0300, Marina Polyakova wrote:
> Hello, hackers! I got a permanent failure of master (commit
> ca454b9bd34c75995eda4d07c9858f7c22890c2b) make check on Solaris 10.
Did this use to work? If so, could you check whether it worked before
69c3936a1499b772a749ae629fc59b2d72722
Stephen Frost writes:
> I'll leave the patch status in 'Needs review' since there's more
> changes, but hopefully someone can take a look and we can move this
> along, seems like a pretty small and reasonable improvement.
I'm on board with Stephen's changes, except in _bt_restore_page.
The issue
Robert Haas writes:
> On Wed, Jan 10, 2018 at 7:09 PM, Tom Lane wrote:
>> * The complaint I had about the "container" terminology isn't just
>> terminology. Rather, there is a bunch of knowledge in the system that
>> some data types can be found embedded in other types; for one example,
>> see f
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I'll leave the patch status in 'Needs review' since there's more
> > changes, but hopefully someone can take a look and we can move this
> > along, seems like a pretty small and reasonable improvement.
>
> I'm on board with
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I'm on board with Stephen's changes, except in _bt_restore_page.
>> The issue there is that the "from" pointer isn't necessarily adequately
>> aligned to be considered an IndexTuple pointer; that's why we're doing
>> the memcpy danc
On Thu, Jan 11, 2018 at 1:15 PM, Tom Lane wrote:
> I think you missed the point. The question is whether the existence of a
> subscripting function means that we need to treat the subscriptable type
> as physically containing the subscript result type. For example, if the
> subscript result type
On 2018-01-11 13:26:27 -0500, Tom Lane wrote:
> I wonder whether there is a way to get alignment traps on Intel-type
> hardware. It's getting less and less likely that most hackers are
> developing on anything else, so that we don't see gotchas of this
> type until code hits the buildfarm (and eve
Robert Haas writes:
> On Thu, Jan 11, 2018 at 1:15 PM, Tom Lane wrote:
>> I think you missed the point. The question is whether the existence of a
>> subscripting function means that we need to treat the subscriptable type
>> as physically containing the subscript result type.
> I don't think I
On 1/10/18 22:24, Michael Paquier wrote:
> On Wed, Jan 10, 2018 at 09:45:56PM -0500, Peter Eisentraut wrote:
>> On 1/8/18 23:47, Michael Paquier wrote:
>> Should we just remove it? Apparently, it was never functional to begin
>> with. Otherwise, we'd have to write a second query to return the val
On Thu, Jan 11, 2018 at 1:26 PM, Tom Lane wrote:
>> I certainly hadn't been thinking about that. I didn't see any
>> issues in my testing (where I created a table with a btree index and
>> insert'd a bunch of records into and then killed the server, forcing WAL
>> replay and then checked that the
Hackers,
Currently, `bytea` does not have any bitwise logical operations yet.
This issue came up in an old thread from 2006 [1], but nobody seemed to
have picked this issue so far.
Being in the need for this myself, I copied the bit vector's bitwise
logical operations and converted them to bytea.
On Thu, Jan 11, 2018 at 1:37 PM, Tom Lane wrote:
>> I don't think I missed the point at all -- this is the exact same set
>> of issues that arise with respect to functions. Indeed, I gave an
>> example of a function that needs to be updated if a column of the
>> input type is altered. In the cas
Robert Haas writes:
> On Thu, Jan 11, 2018 at 1:37 PM, Tom Lane wrote:
>> Right, but in the case of stored arrays, we've decided that it *is*
>> our problem (as indeed it must be, because the user has no tools with
>> which they could fix a representation change for stored data). The
>> question
Tom Lane wrote:
> Alvaro Herrera writes:
> > This was discussed upthread and the solution found was "objects need to
> > be rebuilt, indexes need to be reindexed". The point of Alexander's
> > query was to find affected objects that need such treatment. Teodor
> > explicitly disregarded any cha
On 12/22/17 23:57, Tomas Vondra wrote:
> PART 1: adding logical_work_mem memory limit (0001)
> ---
>
> Currently, limiting the amount of memory consumed by logical decoding is
> tricky (or you might say impossible) for several reasons:
I would like
On Thu, Jan 11, 2018 at 6:07 AM, Amit Khandekar wrote:
> In the first paragraph of my explanation, I was explaining why two
> Transition capture states does not look like a good idea to me :
Oh, sorry. I didn't read what you wrote carefully enough, I guess.
I see your points. I think that ther
On Thu, Jan 11, 2018 at 2:20 PM, Tom Lane wrote:
> But I think we've probably beaten this topic to death ...
Yep.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Wed, Jan 10, 2018 at 5:42 PM, Peter Geoghegan wrote:
> On Wed, Jan 10, 2018 at 2:21 PM, Robert Haas wrote:
>>> I share your general feelings on all of this, but I really don't know
>>> what to do about it. Which of these alternatives is the least worst,
>>> all things considered?
>>
>> Let's g
On Thu, Jan 11, 2018 at 10:29 PM, Alvaro Herrera
wrote:
> Tom Lane wrote:
> > What we've done in the past for comparable situations is to make the
> > change in a new major version and teach pg_upgrade to detect and report
> > the need for changes --- in this case, it might do something like crea
I am creating a user-defined aggregate function that needs an additional
parameter. More precisely it is a cumulative (aka window) minimum that
takes as second parameter a time interval defining the window. Since the
aggregate function operates on my user-defined data types I have conveyed a
dummy
This was discussed upthread and the solution found was "objects need to
be rebuilt, indexes need to be reindexed". The point of Alexander's
query was to find affected objects that need such treatment. Teodor
explicitly disregarded any change in pg_upgrade because the database
you're upgrading *f
On Thu, Jan 11, 2018 at 11:51 AM, Robert Haas wrote:
> I think the force_parallel_mode thing is too ugly to live. I'm not
> sure that forcing low memory in workers is a thing we need to have,
> but if we do, then we'll have to invent some other way to have it.
It might make sense to have the "mi
On Thu, Jan 11, 2018 at 12:06 PM, Peter Geoghegan wrote:
> It might make sense to have the "minimum memory per participant" value
> come from a GUC, rather than be hard coded (it's currently hard-coded
> to 32MB).
> What do you think of that idea?
A third option here is to specifically recognize
Greetings Tom, Robert, Ildar, all,
* Stephen Frost (sfr...@snowman.net) wrote:
> That said, since it's not aligned, regardless of the what craziness the
> compiler might try to pull, we probably shouldn't go casting it
> to something that later hackers might think will be aligned, but we
> should
On Thu, Jan 11, 2018 at 3:25 PM, Peter Geoghegan wrote:
> On Thu, Jan 11, 2018 at 12:06 PM, Peter Geoghegan wrote:
>> It might make sense to have the "minimum memory per participant" value
>> come from a GUC, rather than be hard coded (it's currently hard-coded
>> to 32MB).
>
>> What do you think
On 1/9/18 00:17, Michael Paquier wrote:
>> * When a type narrower than Datum is stored in a Datum, we place it in the
>> * low-order bits and are careful that the DatumGetXXX macro for it discards
>> * the unused high-order bits (as opposed to, say, assuming they are zero).
>> * This is needed
On Thu, Jan 11, 2018 at 1:44 PM, Robert Haas wrote:
>> A third option here is to specifically recognize that
>> compute_parallel_worker() returned a value based on the table storage
>> param max_workers, and for that reason alone no "insufficient memory
>> per participant" decrementing/vetoing sho
On Wed, Jan 10, 2018 at 1:45 PM, Robert Haas wrote:
> There's a lot here I haven't grokked yet, but I'm running out of
> mental energy so I think I'll send this for now and work on this some
> more when time permits, hopefully tomorrow.
Looking at the logtape changes:
While the patch contains, a
On Thu, Jan 11, 2018 at 08:51:27PM +0100, Esteban Zimanyi wrote:
> I am creating a user-defined aggregate function that needs an additional
> parameter. More precisely it is a cumulative (aka window) minimum that
> takes as second parameter a time interval defining the window. Since the
> aggregate
On Fri, Oct 6, 2017 at 2:45 AM, Robert Haas wrote:
> On Tue, Oct 3, 2017 at 9:38 PM, Andres Freund wrote:
>>> Do you have any suggestion as to how we should transmit the blacklist to
>>> parallel workers?
>>
>> How about storing them in the a dshash table instead of dynahash?
>> Similar to how we
Esteban Zimanyi writes:
> How to tell PostgreSQL that my final function also needs a parameter? I am
> working on PostgreSQL 10.1. I know that according to the documentation
> direct parameters are only allowed for ordered-set aggregates, but I would
> also need a direct parameter for "normal" agg
On Fri, Jan 5, 2018 at 4:55 PM, Vaishnavi Prabakaran <
vaishnaviprabaka...@gmail.com> wrote:
>
>
> On Tue, Nov 28, 2017 at 12:57 PM, Michael Paquier <
> michael.paqu...@gmail.com> wrote:
>
>> On Thu, Oct 5, 2017 at 9:58 AM, Vaishnavi Prabakaran
>> wrote:
>> > Thanks for the suggestion and, OK I w
On Thu, Jan 11, 2018 at 10:00 PM, Thomas Munro <
thomas.mu...@enterprisedb.com> wrote:
> On Thu, Jan 11, 2018 at 7:36 PM, Haribabu Kommi
> wrote:
>
> > +OUT plans int8,
> >
> > Addition of this column is good to find out how many time the plan is
> > generated
> > for the same query. But I am
Stephen Frost writes:
> Updated (combined) patch attached for review. I went through and looked
> again to make sure there weren't any cases of making an unaligned
> pointer to a struct and didn't see any, and I added some comments to
> _bt_restore_page().
Looks OK from here.
On 11 January 2018 at 19:41, Peter Eisentraut
wrote:
> Two, what to do when the memory limit is reached. With the old
> accounting, this was easy, because we'd decide for each subtransaction
> independently whether to spill it to disk, when it has reached its 4096
> limit. Now, we are looking a
Peter Eisentraut writes:
> That leaves the uses in rowtypes.c. Those were introduced as a
> portability fix by commit 4cbb646334b. I'm curious why these are
> necessary. The Datums they operate come from heap_deform_tuple(), which
> gets them from fetchatt(), which does run all pass-by-value va
On Tue, Jan 9, 2018 at 6:24 AM, Catalin Iacob wrote:
> On Fri, Dec 1, 2017 at 10:09 PM, Thomas Munro
> wrote:
>>> On 11/30/17 23:35, Thomas Munro wrote:
Hmm. Yeah, it does, but apparently it's not so transparent. So if we
mention that we'd better indicate in the same paragraph that yo
On Thu, Dec 7, 2017 at 12:40 AM, Anthony Bykov wrote:
> Hello,
> fixed the issues:
> 1. Rising errors when invalid object being transformed.
> 2. We don't rise the exception when transforming range(3) only in
> python 2. In third one it is an error.
>
> Please, find the 4-th version of the patch i
On Sun, Jan 7, 2018 at 11:51 AM, Stephen Frost wrote:
> * Konstantin Knizhnik (k.knizh...@postgrespro.ru) wrote:
>> Updated version of the patch is attached.
>
> This patch appears to apply with just a bit of fuzz and make check
> passes, so I'm not sure why this is currently marked as 'Waiting fo
On 2018/01/12 1:54, Tom Lane wrote:
Tatsuro Yamada writes:
The declaration of estimate_path_cost_size uses baserel, but
the actual definition uses foreignrel. It would be better to sync.
Yeah, the join_conds parameter's been renamed at some point too :-(
Fixed.
regard
On Mon, Nov 27, 2017 at 1:01 AM, Michael Paquier
wrote:
> On Fri, Nov 24, 2017 at 9:13 PM, Michael Paquier
> wrote:
>> Attached is a rebased patch set. Álvaro, as you have introduced most
>> of the problems with 4464303 & friends dated of 2015 when you
>> introduced get_object_address(), could yo
On Thu, Jan 4, 2018 at 1:12 PM, Tomas Vondra
wrote:
> Attached is an updated patch series, where the first patch fixes this by
> removing the reset of estimatedclauses (and tweaking the comment).
Hi Tomas,
FYI, from the annoying robot department:
ref/create_statistics.sgml:170: parser error : O
On Mon, Dec 4, 2017 at 1:34 PM, Jing Wang wrote:
> I have rebased the patch on the latest version.
Hi Jing,
According to my testing robot this fails make check-world (or
presumably cd src/bin/pg_dump ; make check), here:
t/001_basic.pl . ok
# Failed test 'binary_upgrade: dumps COMMENT
On Thu, Jan 11, 2018 at 10:42:38AM -0500, Tom Lane wrote:
> Michael Paquier writes:
>> guc.c already holds a find_option()
>> which can be used to retrieve the flags of a parameter. What about using
>> that and filtering by GUC_LIST_INPUT? This requires exposing the
>> function, and I am not sure
1 - 100 of 136 matches
Mail list logo
