On Sat, Jun 18, 2016 at 10:06 AM, Tom Lane wrote:
>
> Amit Kapila writes:
> > On Sat, Jun 18, 2016 at 8:56 AM, Tom Lane wrote:
> >> I think the two lines in question are just a poorly-thought-through
case
> >> of premature optimization. If removing them makes the failures go away
> >> for me, t
On Fri, Jun 17, 2016 at 11:08 PM, Tom Lane wrote:
> Fix parallel-safety markings for contrib/dblink.
>
> As shown by buildfarm reports, dblink_build_sql_insert and
> dblink_build_sql_update are *not* parallel safe, because they
> may attempt to access temporary tables of the local session.
>
> Alt
Amit Kapila writes:
> On Sat, Jun 18, 2016 at 8:56 AM, Tom Lane wrote:
>> I think the two lines in question are just a poorly-thought-through case
>> of premature optimization. If removing them makes the failures go away
>> for me, that's what I plan to do.
> That should make the failure go-awa
Still another try at fixing scanjoin_target insertion into parallel plans.
The previous code neglected the fact that the scanjoin_target might
carry sortgroupref labelings that we need to absorb. Instead, do
create_projection_path() unconditionally, and tweak the path's cost
estimate after the fa
On Sat, Jun 18, 2016 at 8:56 AM, Tom Lane wrote:
>
> Amit Kapila writes:
> > Patch fixing the failures along with a new test case is attached with
this
> > mail
>
> That can't possibly be right, because the PathTarget.sortgrouprefs field
> is not a pointer to a Node.
>
Right.
>
> I think the tw
Amit Kapila writes:
> Patch fixing the failures along with a new test case is attached with this
> mail
That can't possibly be right, because the PathTarget.sortgrouprefs field
is not a pointer to a Node.
I think the two lines in question are just a poorly-thought-through case
of premature optim
On Sat, Jun 18, 2016 at 7:44 AM, Amit Kapila
wrote:
>
> On Sat, Jun 18, 2016 at 7:06 AM, Tom Lane wrote:
> >
> > Amit Kapila writes:
> > > On Sat, Jun 18, 2016 at 6:11 AM, Tom Lane wrote:
> > >> Was this supposed to fix the "ORDER/GROUP BY expression not found in
> > >> targetlist" problem?
> >
Fix parallel-safety markings for contrib/dblink.
As shown by buildfarm reports, dblink_build_sql_insert and
dblink_build_sql_update are *not* parallel safe, because they
may attempt to access temporary tables of the local session.
Although dblink_build_sql_delete doesn't actually touch the
conten
On Sat, Jun 18, 2016 at 7:06 AM, Tom Lane wrote:
>
> Amit Kapila writes:
> > On Sat, Jun 18, 2016 at 6:11 AM, Tom Lane wrote:
> >> Was this supposed to fix the "ORDER/GROUP BY expression not found in
> >> targetlist" problem?
> >> If so, it hasn't ...
>
> > Can you please share why you think so?
Fix handling of argument and result datatypes for partial aggregation.
When doing partial aggregation, the args list of the upper (combining)
Aggref node is replaced by a Var representing the output of the partial
aggregation steps, which has either the aggregate's transition data type
or a serial
Amit Kapila writes:
> On Sat, Jun 18, 2016 at 6:11 AM, Tom Lane wrote:
>> Was this supposed to fix the "ORDER/GROUP BY expression not found in
>> targetlist" problem?
>> If so, it hasn't ...
> Can you please share why you think so?
Run the regression tests with the settings mentioned in
https:/
On Sat, Jun 18, 2016 at 6:11 AM, Tom Lane wrote:
>
> Robert Haas writes:
> > Try again to fix the way the scanjoin_target is used with partial paths.
>
> Was this supposed to fix the "ORDER/GROUP BY expression not found in
> targetlist" problem?
Yes.
>
> If so, it hasn't ...
>
Can you please
Robert Haas writes:
> Try again to fix the way the scanjoin_target is used with partial paths.
Was this supposed to fix the "ORDER/GROUP BY expression not found in
targetlist" problem? If so, it hasn't ...
regards, tom lane
--
Sent via pgsql-committers mailing list (p
Docs typo fix.
Guillaume Lelarge
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/d30d1acf904b823a7cca59e5d403ae3b299773e9
Modified Files
--
doc/src/sgml/catalogs.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
Sent via pgsql-committers ma
Robert Haas writes:
> Update dblink extension for parallel query.
Buildfarm results from mandrill and lapwing say that these markings
weren't thought through carefully enough. Or else we've got yet another
hole in the logic that's supposed to prevent PARALLEL RESTRICTED functions
from being sent
Finish up XLOG_HINT renaming
Commit b8fd1a09f3 renamed XLOG_HINT to XLOG_FPI, but neglected two
places.
Backpatch to 9.3, like that commit.
Branch
--
REL9_4_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/1449b6ced5ba375fed814fda537718c2cd95a9b4
Modified Files
--
Finish up XLOG_HINT renaming
Commit b8fd1a09f3 renamed XLOG_HINT to XLOG_FPI, but neglected two
places.
Backpatch to 9.3, like that commit.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/1ca4a1b5d2c633d33161792af1c70e397f879ed9
Modified Files
--
src/ba
Finish up XLOG_HINT renaming
Commit b8fd1a09f3 renamed XLOG_HINT to XLOG_FPI, but neglected two
places.
Backpatch to 9.3, like that commit.
Branch
--
REL9_3_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/d300b8cf7bad3e57b41e7049406b89868d18f7d1
Modified Files
--
Finish up XLOG_HINT renaming
Commit b8fd1a09f3 renamed XLOG_HINT to XLOG_FPI, but neglected two
places.
Backpatch to 9.3, like that commit.
Branch
--
REL9_5_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/6fce92a7d7090fe02c39837908b4feb55806b3ee
Modified Files
--
pg_visibility: Add pg_truncate_visibility_map function.
This requires some core changes as well so that we can properly
WAL-log the truncation. Specifically, it changes the format of the
XLOG_SMGR_TRUNCATE WAL record, so bump XLOG_PAGE_MAGIC.
Patch by me, reviewed but not fully endorsed by Andre
Try again to fix the way the scanjoin_target is used with partial paths.
Commit 04ae11f62e643e07c411c4935ea6af46cb112aa9 removed some broken
code to apply the scan/join target to partial paths, but its theory
that this processing step is totally unnecessary turns out to be wrong.
Put similar code
Add VACUUM (DISABLE_PAGE_SKIPPING) for emergencies.
If you really want to vacuum every single page in the relation,
regardless of apparent visibility status or anything else, you can use
this option. In previous releases, this behavior could be achieved
using VACUUM (FREEZE), but because we can n
Update dblink extension for parallel query.
Almost all functions provided by this extension are PARALLEL
RESTRICTED. Mostly, that's because the leader's TCP connections won't
be shared with the workers, but in some cases like dblink_get_pkey
it's because they obtain locks which might be released
On 2016-06-17 08:41:31 -0400, Robert Haas wrote:
> On Fri, Jun 17, 2016 at 12:55 AM, Amit Kapila wrote:
> > Isn't it possible that the below statement used in parallel restricted
> > function fails in leader backend itself:
> > + perform * from pg_stat_activity where client_port is null;
> > + i
postgres_fdw: Rephrase comment.
Per gripe from Thomas Munro, who only complained about a more
localized problem, but I couldn't resist a bit more wordsmithing.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/177c56d608d834ee1b0869e4e6a5b73de4227ea4
Modified Files
--
Fix typo.
Thomas Munro
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/9c188a8454e514e43614e47d69f5eaea820af8c4
Modified Files
--
src/backend/access/heap/heapam.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
Sent via pgsql-committers mailin
Remove PID from 'parallel worker' context message.
Discussion:
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/292794f82b4ebde33ec7f2a572ddd1dedba8ce37
Modified Files
--
src/backend/access/transam/parallel.c | 4 ++--
src/test/regress/expected/se
On Fri, Jun 17, 2016 at 12:55 AM, Amit Kapila wrote:
> Isn't it possible that the below statement used in parallel restricted
> function fails in leader backend itself:
> + perform * from pg_stat_activity where client_port is null;
> + if (found) then
> +raise 'parallel restricted function r
Attempt to fix broken regression test.
In commit 8c1d9d56e9a00680a035b8b333a98ea16b121eb7, I attempted to
add a regression test that would fail if the target list was pushed
into a parallel worker, but due to brain fade on my part, it just
randomly fails whether anything bad or not, because the er
29 matches
Mail list logo
