On Sun, May 10, 2015 at 6:01 AM, Andrew Dunstan wrote:
>
>
>
> This generally looks good, but I have a couple of questions before I
commit it.
>
> First, why is the new option for the BASE_BACKUP command of the
Streaming Replication protcol "TAR"? It seems rather misleading. Shouldn't
it be somet
On Sun, May 10, 2015 at 09:17:58PM -0400, Robert Haas wrote:
> On Sun, May 10, 2015 at 1:40 PM, Noah Misch 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
> On 2015-05-10 21:26:26 -0400, Robert Haas wrote:
> > On Sun, May 10, 2015 at 8:41 PM, Tom Lane 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 createpla
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 t
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 i
On Sun, May 10, 2015 at 10:37 PM, Andres Freund 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 has been laudl
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 som
On 2015-05-10 21:26:26 -0400, Robert Haas wrote:
> On Sun, May 10, 2015 at 8:41 PM, Tom Lane 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 createplan.c's API
On Sun, May 10, 2015 at 9:34 PM, Tom Lane wrote:
> Robert Haas 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 occ
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: form_
On 2015-05-10 21:09:14 -0400, Tom Lane wrote:
> Andres Freund 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,
Robert Haas 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 obstructionist and
> petty.
On Sun, May 10, 2015 at 8:41 PM, Tom Lane wrote:
> Kohei KaiGai 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
On Sun, May 10, 2015 at 1:40 PM, Noah Misch 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 anti-wraparound
> vacuum
Andres Freund 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 results are swa
> Kohei KaiGai 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,
> a
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'v
Kohei KaiGai 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 would prefer no
Etsuro Fujita 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 does not seem like a good
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
offs
On 2015-05-10 12:09:41 -0400, Tom Lane wrote:
> Andres Freund 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
> > co
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 case
Aliouii Ali 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, that view would be au
On Thu, May 7, 2015 at 3:23 AM, Amit Kapila 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
>> > workers t
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 FU
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
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 re
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
multixa
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/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 pret
Andres Freund 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 not.
Well, if you
Robert Haas writes:
> On Sat, May 9, 2015 at 1:05 PM, Tom Lane 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 probably dangerously broken.
>> S
> 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
brin-in
On Sat, May 9, 2015 at 1:05 PM, Tom Lane 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 table. In
On Fri, May 8, 2015 at 5:39 PM, Alvaro Herrera 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
>> http://www.postgresql.org/message-
36 matches
Mail list logo
