On Sun, May 10, 2015 at 09:17:58PM -0400, Robert Haas wrote:
On Sun, May 10, 2015 at 1:40 PM, Noah Misch n...@leadboat.com wrote:
I don't know whether this deserves prompt remediation, but if it does, I
would
look no further than the hard-coded 25% figure. We permit users to operate
this a test case :
CREATE TABLE tab
(
_id bigserial NOT NULL,
_name text,
CONSTRAINT tab_pkey PRIMARY KEY (_id)
);
CREATE TABLE tab_s1
(
CONSTRAINT tab_s1_check CHECK (1 = 1)
)
INHERITS (tab);
CREATE OR REPLACE VIEW v_tab AS
SELECT tab._id,
tab._name
FROM tab;
CREATE OR REPLACE
Kohei KaiGai kai...@kaigai.gr.jp writes:
I briefly checked your updates.
Even though it is not described in the commit-log, I noticed a
problematic change.
This commit reverts create_plan_recurse() as static function.
Yes. I am not convinced that external callers should be calling that,
and
On 2015-05-10 22:51:33 -0400, Robert Haas wrote:
And there's definitely some things
around that pretty much only still exist because changing them would
break too much stuff.
Such as what?
Without even thinking about it:
* linitial vs lfirst vs lnext. That thing still induces an
On 2015-05-10 21:26:26 -0400, Robert Haas wrote:
On Sun, May 10, 2015 at 8:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This commit reverts create_plan_recurse() as static function.
Yes. I am not convinced that external callers should be calling that,
and would prefer not to enlarge
Tom,
I briefly checked your updates.
Even though it is not described in the commit-log, I noticed a
problematic change.
This commit reverts create_plan_recurse() as static function. It means extension
cannot have child node, even if it wants to add a custom-join logic.
Please assume a simple
Aliouii Ali aliouii@aol.fr writes:
this a test case :
This is not supposed to insert a default. Attach a default expression
to the view column, if you want inserts on the view to have defaults.
ALTER VIEW ... ALTER COLUMN ... SET DEFAULT is the way.
(Note that in recent versions of PG,
Andres Freund and...@anarazel.de writes:
I'm not sure what exactly to use as a performance benchmark
here. For now I chose
SELECT * FROM (SELECT ARRAY(SELECT generate_series(1, 1))) d,
generate_series(1, 1000) repeat(i);
that'll hit array_out, which uses iterators.
Hmm, probably those
On Sun, May 10, 2015 at 1:40 PM, Noah Misch n...@leadboat.com wrote:
I don't know whether this deserves prompt remediation, but if it does, I would
look no further than the hard-coded 25% figure. We permit users to operate
close to XID wraparound design limits. GUC maximums force an
On Sun, May 10, 2015 at 9:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Your unwillingness to make functions global or to stick PGDLLIMPORT
markings on variables that people want access to is hugely
handicapping extension authors. Many people have
Andres Freund just forwarded me a valgrind error report that Peter
Geoghegan noticed:
==29892== Unaddressable byte(s) found during client check request
==29892==at 0x7D1317: PageAddItem (bufpage.c:314)
==29892==by 0x468106: brin_doinsert (brin_pageops.c:315)
==29892==by 0x4671A5:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
[ EvalPlanQual-v6.patch ]
I've started to study this in a little more detail, and I'm not terribly
happy with some of the API decisions in it.
In particular, I find the addition of void *fdw_state to ExecRowMark
to be pretty questionable. That
On Sun, May 10, 2015 at 8:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Kohei KaiGai kai...@kaigai.gr.jp writes:
I briefly checked your updates.
Even though it is not described in the commit-log, I noticed a
problematic change.
This commit reverts create_plan_recurse() as static function.
Yes.
Hello.
I've gone ahead and marked this as Rejected. The concept of async
execution of postgres_fdw is certainly still open and a worthwhile goal,
but this implementation isn't the way to achieve that.
It sounds fair. I'm satisfied that we have agreed that the goal
is worthwhile. I'll show
On 2015-05-10 21:53:45 -0400, Robert Haas wrote:
Please name EVEN ONE instance in which core development has been
prevented for fear of changing a function API.
Even *moving* function declarations to a different file has been laudly
and repeatedly complained about... And there's definitely some
On Sun, May 10, 2015 at 10:37 PM, Andres Freund and...@anarazel.de wrote:
On 2015-05-10 21:53:45 -0400, Robert Haas wrote:
Please name EVEN ONE instance in which core development has been
prevented for fear of changing a function API.
Even *moving* function declarations to a different file
On Thu, May 7, 2015 at 3:23 AM, Amit Kapila amit.kapil...@gmail.com wrote:
I observed one issue while working on this review comment. When we
try to destroy the parallel setup via ExecEndNode (as due to Limit
Node, it could not destroy after consuming all tuples), it waits for
parallel
On 2015-05-10 12:09:41 -0400, Tom Lane wrote:
* I find the ARRAY_ITER_VARS/ARRAY_ITER_NEXT macros rather ugly. I don't
buy the argument that turning them into functions will be slower. I'd
bet the contrary on common platforms.
Perhaps; do you want to do some testing and see?
I've
On 2015-05-10 21:26:26 -0400, Robert Haas wrote:
On Sun, May 10, 2015 at 8:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This commit reverts create_plan_recurse() as static function.
Yes. I am not convinced that external callers should be calling that,
and would prefer not to enlarge
On 2015-05-01 18:37:23 +0200, Andres Freund wrote:
* Multivariate statistics
This is not intended to be committed this CF.
= I'd like to mark this as returned with (little) feedback.
* Avoiding plan disasters with LIMIT
I'm not enthused by the approach, it's disabled by default though.
On 2015-05-10 21:09:14 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
I'm not sure what exactly to use as a performance benchmark
here. For now I chose
SELECT * FROM (SELECT ARRAY(SELECT generate_series(1, 1))) d,
generate_series(1, 1000) repeat(i);
that'll hit
Robert Haas robertmh...@gmail.com writes:
Your unwillingness to make functions global or to stick PGDLLIMPORT
markings on variables that people want access to is hugely
handicapping extension authors. Many people have complained about
that on multiple occasions. Frankly, I find it
On 2015-05-10 12:09:41 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
Looking at this. First reading the patch to understand the details.
* The VARTAG_IS_EXPANDED(tag) trick in VARTAG_SIZE is unlikely to
beneficial, before the compiler could implement the whole thing as
On 5/8/15 1:15 PM, Robert Haas wrote:
I somehow did not realize until very recently that we
actually use two SLRUs to keep track of multixacts: one for the
multixacts themselves (pg_multixacts/offsets) and one for the members
(pg_multixacts/members). Confusingly, members are sometimes called
Kohei KaiGai kai...@kaigai.gr.jp writes:
I briefly checked your updates.
Even though it is not described in the commit-log, I noticed a
problematic change.
This commit reverts create_plan_recurse() as static function.
Yes. I am not convinced that external callers should be calling
On Fri, May 08, 2015 at 02:15:44PM -0400, Robert Haas wrote:
My colleague Thomas Munro and I have been working with Alvaro, and
also with Kevin and Amit, to fix bug #12990, a multixact-related data
corruption bug.
Thanks Alvaro, Amit, Kevin, Robert and Thomas for mobilizing to get this fixed.
On 05/10/2015 10:30 AM, Robert Haas wrote:
2. We have some logic that causes autovacuum to run in spite of
autovacuum=off when wraparound threatens. My commit
53bb309d2d5a9432d2602c93ed18e58bd2924e15 provided most of the
anti-wraparound protections for multixact members that exist for
On 05/08/2015 09:57 PM, Josh Berkus wrote:
[snip]
It's certainly possible to have workloads triggering that, but I think
it's relatively uncommon. I in most cases I've checked the multixact
consumption rate is much lower than the xid consumption. There are some
exceptions, but often that's
On Sat, May 9, 2015 at 1:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I originally wanted to go quite the other way with this and check for
join pushdown via handler X any time at least one of the two relations
involved used handler X, even if the other one used some other handler
or was a plain
On Fri, May 8, 2015 at 5:39 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
1. I believe that there is still a narrow race condition that cause
the multixact code to go crazy and delete all of its data when
operating very near the threshold for member space exhaustion. See
I pushed patches 04 and 07, as well as adopting some of the changes to
the regression test in 06. I'm afraid I caused a bit of merge pain for
you -- sorry about that.
No problem. I rebased the remaining ones.
brin-inclusion-v09-02-strategy-numbers.patch
Description: Binary data
Andres Freund and...@anarazel.de writes:
Looking at this. First reading the patch to understand the details.
* The VARTAG_IS_EXPANDED(tag) trick in VARTAG_SIZE is unlikely to
beneficial, before the compiler could implement the whole thing as a
computed goto or lookup table, afterwards
Robert Haas robertmh...@gmail.com writes:
On Sat, May 9, 2015 at 1:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
For these reasons, I think that if an FDW tried to be laxer than tables
must be on the same pg_foreign_server entry to be joined, the odds
approach unity that it would be broken, and
I've committed a cleanup patch along the lines discussed.
One thought is that we could test the nondefault-scan-tuple logic without
a lot of work by modifying the way postgres_fdw deals with columns it
decides don't need to be fetched. Right now it injects NULL columns so
that the remote query
postgres...@realityexists.net writes:
I have a deferred EXCLUDE constraint on a derived table. Inside a
transaction I insert a new row that conflicts with an existing one (so the
constraint would fail if it was immediate), delete the old row and run an
unrelated UPDATE on the new row, then try
35 matches
Mail list logo
