On Sun, Jun 26, 2016 at 10:22:26PM -0400, Noah Misch wrote:
> On Wed, Jun 15, 2016 at 11:08:54AM -0400, Noah Misch wrote:
> > On Wed, Jun 15, 2016 at 03:02:15PM +0300, Teodor Sigaev wrote:
> > > On Wed, Jun 15, 2016 at 02:54:33AM -0400, Noah Misch wrote:
> > > > On Mon, Jun 13, 2016 at 10:44:06PM -
On Tue, Jun 28, 2016 at 11:43 AM, Etsuro Fujita wrote:
> On 2016/06/28 13:53, Ashutosh Bapat wrote:
>
>> Ideally, we should point out the specific column that faced the
>> conversion problem and report it, instead of saying the whole row
>> reference conversion caused the problem. But that may be
On 2016/06/28 13:53, Ashutosh Bapat wrote:
Ideally, we should point out the specific column that faced the
conversion problem and report it, instead of saying the whole row
reference conversion caused the problem. But that may be too difficult.
I think so too.
Or at least the error message sh
Hi,
Consider the below testcase:
CREATE TABLE tab(
c1 INT NOT NULL,
c2 INT NOT NULL
);
INSERT INTO tab VALUES (1, 2);
INSERT INTO tab VALUES (2, 1);
INSERT INTO tab VALUES (1, 2);
case 1:
SELECT c.c1, c.c2 from tab C WHERE c.c2 = ANY (
SELECT 1 FROM tab A WHERE a.c2 IN (
SELECT 1
On Tue, Jun 28, 2016 at 9:00 AM, Etsuro Fujita
wrote:
> On 2016/06/27 18:56, Ashutosh Bapat wrote:
>
>> On Mon, Jun 27, 2016 at 3:06 PM, Etsuro Fujita
>> mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
>>
>
> I found another bug in error handling of whole-row references in
>> join pushdown; c
On Tue, Jun 28, 2016 at 6:49 AM, Robert Haas wrote:
> On Sun, Jun 26, 2016 at 6:19 AM, Piotr Stefaniak
> wrote:
>>> while investigating the shm_mq code and its testing module I made some
>>> cosmetic improvements there. You can see them in the attached diff file.
>>
>> Revised patch attached.
>
>
On 2016/06/27 18:56, Ashutosh Bapat wrote:
On Mon, Jun 27, 2016 at 3:06 PM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
I found another bug in error handling of whole-row references in
join pushdown; conversion_error_callback fails to take into account
that get_relid_
On Tue, Jun 28, 2016 at 3:22 AM, Christoph Berg wrote:
> Re: Tom Lane 2016-06-27 <31398.1467036...@sss.pgh.pa.us>
>> Bjorn Munch reported off-list that this sequence:
>>
>> unpack tarball, cd into it
>> ./configure ...
>> cd src/test/regress
>> make
>>
>> no longer works in 9.6beta2, where it did
Amit Kapila writes:
> I had couple of questions [1] related to that patch. See if you find
> those as relevant?
I do not think those cases are directly relevant: you're talking about
appendrels not single, unflattened RTE_SUBQUERY rels.
In the subquery case, my view of how it ought to work is t
On Mon, Jun 27, 2016 at 10:35 PM, Julien Rouhaud
wrote:
> On 27/06/2016 07:18, Amit Kapila wrote:
>> On Mon, Jun 27, 2016 at 10:21 AM, Amit Kapila
>> wrote:
>>>
>>> I think as the parallel_terminate_count is only modified by postmaster
>>> and read by other processes, such an operation will be c
On Tue, Jun 28, 2016 at 1:42 AM, Robert Haas wrote:
> On Mon, Jun 27, 2016 at 4:03 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Sun, Jun 26, 2016 at 10:39 PM, Noah Misch wrote:
On Mon, Jun 13, 2016 at 04:46:19PM -0400, Tom Lane wrote:
The above-described topic is currently a Post
On Tue, Jun 28, 2016 at 3:21 AM, Andreas Karlsson wrote:
> Yes, we could do that, but I do not think we should check for the existence
> of a backwards compatibility macro. Actually I think we may want to skip
> much of the OpenSSL initialization code when compiling against OpenSSL 1.1
> since the
On 28 June 2016 at 02:27, Akash Agrawal wrote:
> Hi,
>
> I've created a background worker and I am using Postgresql-9.4. This
> bgworker handles the job queue dynamically and goes to sleep if there is no
> job to process within the next 1 hour.
>
> Now, I want to have a mechanism to wake the bgwo
On Tue, Jun 28, 2016 at 3:27 AM, Akash Agrawal wrote:
> I've created a background worker and I am using Postgresql-9.4. This
> bgworker handles the job queue dynamically and goes to sleep if there is no
> job to process within the next 1 hour.
>
> Now, I want to have a mechanism to wake the bgwork
On Mon, Jun 27, 2016 at 5:56 PM, Michael Paquier
wrote:
>> Under what circumstances would you wish to check only one page of a relation?
>
> What I'd like to be able to do is to stop scanning the relation once
> one defective tuple has been found: if there is at least one problem,
> the whole vm n
Robert Haas writes:
> On Mon, Jun 27, 2016 at 5:28 PM, Tom Lane wrote:
>> Seems to me that it should generally be the case that consider_parallel
>> would already be clear on the parent rel if the tlist isn't parallel safe,
>> and if it isn't we probably have a bug elsewhere. If it makes you fee
On Thu, Jun 23, 2016 at 12:46 AM, Michael Paquier
wrote:
> On Thu, Jun 23, 2016 at 1:42 PM, Michael Paquier
> wrote:
>> While looking at the module I found two mistakes in the docs:
>> pg_visibility_map and pg_visibility *not* taking in input a block
>> number are SRFs, and return a set of record
On Tue, Jun 28, 2016 at 6:51 AM, Robert Haas wrote:
> On Thu, Jun 23, 2016 at 12:53 AM, Michael Paquier
> wrote:
>> On Thu, Jun 23, 2016 at 1:46 PM, Michael Paquier
>> wrote:
>>> On Thu, Jun 23, 2016 at 1:42 PM, Michael Paquier
>>> wrote:
While looking at the module I found two mistakes in
On Thu, Jun 23, 2016 at 12:53 AM, Michael Paquier
wrote:
> On Thu, Jun 23, 2016 at 1:46 PM, Michael Paquier
> wrote:
>> On Thu, Jun 23, 2016 at 1:42 PM, Michael Paquier
>> wrote:
>>> While looking at the module I found two mistakes in the docs:
>>> pg_visibility_map and pg_visibility *not* takin
On Sun, Jun 26, 2016 at 6:19 AM, Piotr Stefaniak
wrote:
>> while investigating the shm_mq code and its testing module I made some
>> cosmetic improvements there. You can see them in the attached diff file.
>
> Revised patch attached.
The first hunk of this corrects an outdated comment, so we shou
On Mon, Jun 27, 2016 at 5:29 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> On Mon, Jun 20, 2016 at 5:41 PM, Hafez Kamal wrote:
>> > See you in Singapore!
>>
>> This seems totally off-topic. Shouldn't a post like this result in a ban?
>
> It is off-topic. Sorry that it got through. We get d
On Mon, Jun 27, 2016 at 5:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 27, 2016 at 4:49 PM, Tom Lane wrote:
>>> * Not following what you did to apply_projection_to_path, and the comment
>>> therein isn't helping.
>
>> Gee, I wonder why not? :-)
>
>> The basic problem here is that
On Fri, Jun 24, 2016 at 05:25:27PM -0700, Peter Geoghegan wrote:
> On Fri, Jun 24, 2016 at 4:29 PM, Andres Freund wrote:
> > As a motivation, here's a somewhat juicy example of the benefits that
> > can be gained (disabled parallelism, results vary too much):
> > SELECT l_linestatus, SUM(l_quantit
On Mon, Jun 27, 2016 at 12:53 PM, Robert Haas wrote:
> On Mon, Jun 13, 2016 at 10:27 PM, Peter Eisentraut
> wrote:
>> Modulo that last point, here is a patch that shows how I think this could
>> work, in combination with the patch I posted previously that sets the
>> "client encoding" in the para
Robert Haas wrote:
> On Mon, Jun 20, 2016 at 5:41 PM, Hafez Kamal wrote:
> > See you in Singapore!
>
> This seems totally off-topic. Shouldn't a post like this result in a ban?
It is off-topic. Sorry that it got through. We get dozens of these
every week, and the vast majority are rejected;
Robert Haas writes:
> On Mon, Jun 27, 2016 at 4:49 PM, Tom Lane wrote:
>> * Not following what you did to apply_projection_to_path, and the comment
>> therein isn't helping.
> Gee, I wonder why not? :-)
> The basic problem here is that applying a projection to a path can
> render a formerly pa
On Fri, Jun 24, 2016 at 02:26:18PM -0700, Peter Geoghegan wrote:
> On Fri, Jun 24, 2016 at 2:18 PM, Tom Lane wrote:
> > Uh, why? It's not a large amount of code and it seems like removing
> > it puts a fair-size hole in the symmetry of tuplesort's capabilities.
>
> It's not a small amount of cod
On Mon, Jun 20, 2016 at 5:41 PM, Hafez Kamal wrote:
> Videos from the 7th annual HITB Security Conference are being released
> this week!
>
> HITBSecConf Youtube channel: http://youtube.com/hitbsecconf
>
> Talks from the #HITB2016AMS CommSec track have already been uploaded and
> linked to their i
On Mon, Jun 27, 2016 at 4:49 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 27, 2016 at 3:35 PM, Tom Lane wrote:
>>> Oh, I thought you were still actively working on it. What patch do
>>> you want me to review?
>
>> I'm looking for an opinion on the WIP patch attached to:
>> https://w
On Thu, Jun 23, 2016 at 02:00:49PM -0400, Robert Haas wrote:
> > Ok. I'm having trouble seeing this justified as a bug fix - the docs
> > clearly state our behavior is intentional. Improved behavior, yes, but
> > that's a feature and we're in beta2. Please be specific if you believe I've
> > mis
Robert Haas writes:
> On Mon, Jun 27, 2016 at 3:35 PM, Tom Lane wrote:
>> Oh, I thought you were still actively working on it. What patch do
>> you want me to review?
> I'm looking for an opinion on the WIP patch attached to:
> https://www.postgresql.org/message-id/ca+tgmozwjb9eaibj-meeaq913wkk
Hi,
I've created a background worker and I am using Postgresql-9.4. This
bgworker handles the job queue dynamically and goes to sleep if there is no
job to process within the next 1 hour.
Now, I want to have a mechanism to wake the bgworker up in case if someone
adds a new job while the bgworker
On Mon, Jun 27, 2016 at 4:03 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Jun 26, 2016 at 10:39 PM, Noah Misch wrote:
>>> On Mon, Jun 13, 2016 at 04:46:19PM -0400, Tom Lane wrote:
>>> The above-described topic is currently a PostgreSQL 9.6 open item ("fix
>>> possible confusion between s
Robert Haas writes:
> On Sun, Jun 26, 2016 at 10:39 PM, Noah Misch wrote:
>> On Mon, Jun 13, 2016 at 04:46:19PM -0400, Tom Lane wrote:
>> The above-described topic is currently a PostgreSQL 9.6 open item ("fix
>> possible confusion between subqueries and subplans").
> This open item comes with a
On Mon, Jun 27, 2016 at 3:35 PM, Tom Lane wrote:
> Robert Haas writes:
>> I'm not sure how to proceed here. I have asked Tom several times to
>> look at the WIP patch and offer comments, but he so far has not done
>> so.
>
> Oh, I thought you were still actively working on it. What patch do
> y
On Mon, Jun 27, 2016 at 3:33 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Jun 26, 2016 at 10:35 PM, Noah Misch wrote:
>>> The above-described topic is currently a PostgreSQL 9.6 open item ("consider
>>> whether MinMaxAggPath might fail to be parallel-safe").
>
>> Currently, MinMaxAggPath
On Sun, Jun 26, 2016 at 10:39 PM, Noah Misch wrote:
> On Mon, Jun 13, 2016 at 04:46:19PM -0400, Tom Lane wrote:
>> Robert Haas writes:
>> > In practice, we don't yet have the ability for
>> > parallel-safe paths from subqueries to affect planning at higher query
>> > levels, but that's because th
Robert Haas writes:
> I'm not sure how to proceed here. I have asked Tom several times to
> look at the WIP patch and offer comments, but he so far has not done
> so.
Oh, I thought you were still actively working on it. What patch do
you want me to review?
regards, tom
Robert Haas writes:
> On Sun, Jun 26, 2016 at 10:35 PM, Noah Misch wrote:
>> The above-described topic is currently a PostgreSQL 9.6 open item ("consider
>> whether MinMaxAggPath might fail to be parallel-safe").
> Currently, MinMaxAggPath is never parallel-safe; the question is
> whether we cou
On Sun, Jun 26, 2016 at 10:42 PM, Noah Misch wrote:
> On Mon, Jun 13, 2016 at 05:27:13PM -0400, Robert Haas wrote:
>> One problem that I've realized that is related to this is that the way
>> that the consider_parallel flag is being set for upper rels is almost
>> totally bogus, which I believe ac
On Sun, Jun 26, 2016 at 10:35 PM, Noah Misch wrote:
>> I looked into this and found that the costs are considered fuzzily the
>> same, and then add_path prefers the slightly-worse path on the grounds
>> that it is marked parallel_safe while the MinMaxAgg path is not. It seems
>> to me that there
Re: Tom Lane 2016-06-27 <31398.1467036...@sss.pgh.pa.us>
> Bjorn Munch reported off-list that this sequence:
>
> unpack tarball, cd into it
> ./configure ...
> cd src/test/regress
> make
>
> no longer works in 9.6beta2, where it did work in previous releases.
> I have confirmed both statements.
On 06/27/2016 08:12 PM, Christoph Berg wrote:
Re: Andreas Karlsson 2016-06-27 <8a0a5959-0b83-3dc8-d9e7-66ce8c1c5...@proxel.se>
The errors you report make it sound like they broke API compatibility
wholesale. Was that really their intent? If so, where are the changes
documented?
I do not see
Re: Andreas Karlsson 2016-06-27 <8a0a5959-0b83-3dc8-d9e7-66ce8c1c5...@proxel.se>
> > The errors you report make it sound like they broke API compatibility
> > wholesale. Was that really their intent? If so, where are the changes
> > documented?
>
> I do not see that they have documented the remo
On 06/27/2016 05:24 PM, Tom Lane wrote:
Christoph Berg writes:
as reported by Debian's OpenSSL maintainers, PostgreSQL is failing to
build against a snapshot of the upcoming 1.1.0 version.
The errors you report make it sound like they broke API compatibility
wholesale. Was that really their
On 27/06/2016 07:18, Amit Kapila wrote:
> On Mon, Jun 27, 2016 at 10:21 AM, Amit Kapila wrote:
>>
>> I think as the parallel_terminate_count is only modified by postmaster
>> and read by other processes, such an operation will be considered
>> atomic. We don't need to specifically make it atomic
On Mon, Jun 27, 2016 at 2:47 AM, Ashutosh Bapat
wrote:
> On Sat, Jun 25, 2016 at 12:44 AM, Robert Haas wrote:
>> On Wed, Jun 22, 2016 at 4:11 AM, Amit Langote
>> wrote:
>> >> In an outer join we have to differentiate between a row being null
>> >> (because
>> >> there was no joining row on nulla
On Mon, Jun 13, 2016 at 10:27 PM, Peter Eisentraut
wrote:
> Modulo that last point, here is a patch that shows how I think this could
> work, in combination with the patch I posted previously that sets the
> "client encoding" in the parallel worker to the server encoding.
>
> This patch disassembl
On Fri, Jun 24, 2016 at 5:16 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jun 24, 2016 at 12:26 PM, Steve Crawford
>> wrote:
>>> To me, 2016-02-30 is an invalid date that should generate an error.
>
>> I don't particularly disagree with that, but on the other hand, as
>> mentioned earlie
On Sun, Jun 26, 2016 at 4:25 PM, Tom Lane wrote:
> I noticed that the EXPLAIN code is set up so that in non-text output
> modes, you get output like this for partial-aggregate plans:
>
>"Node Type": "Aggregate", +
>"Strategy": "Plain", +
>
Christoph Berg writes:
> as reported by Debian's OpenSSL maintainers, PostgreSQL is failing to
> build against a snapshot of the upcoming 1.1.0 version.
The errors you report make it sound like they broke API compatibility
wholesale. Was that really their intent? If so, where are the changes
do
Hi,
as reported by Debian's OpenSSL maintainers, PostgreSQL is failing to
build against a snapshot of the upcoming 1.1.0 version. The report was
for 9.5.3, but I can reproduce it in HEAD as well:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828510
> OpenSSL 1.1.0 is about to released. Durin
Noah Misch writes:
> What, if anything, is yet required to close this 9.6 open item?
The original complaint about polymorphic aggs is fixed to my satisfaction.
The business about how non-text-format EXPLAIN reports parallel plans
(<16002.1466972...@sss.pgh.pa.us>) remains, but perhaps we should v
David Rowley writes:
> I can't help wonder how plan to allow future expansions of
> non-serialized partial aggregates giving that in setrefs.c you're
> making a hard assumption that mark_partial_aggref() should always
> receive the SERIAL versions of the aggsplit.
What I was imagining, but didn't
Bjorn Munch reported off-list that this sequence:
unpack tarball, cd into it
./configure ...
cd src/test/regress
make
no longer works in 9.6beta2, where it did work in previous releases.
I have confirmed both statements. The failure looks like
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wde
On Mon, Jun 27, 2016 at 3:06 PM, Etsuro Fujita
wrote:
> On 2016/06/25 4:14, Robert Haas wrote:
>
>> Committed that way.
>>
>
> Thanks for taking care of this!
>
> I found another bug in error handling of whole-row references in join
> pushdown; conversion_error_callback fails to take into account
On 2016/06/25 4:14, Robert Haas wrote:
Committed that way.
Thanks for taking care of this!
I found another bug in error handling of whole-row references in join
pushdown; conversion_error_callback fails to take into account that
get_relid_attribute_name(Oid relid, AttrNumber attnum) can't ha
On 2016/06/25 3:39, Robert Haas wrote:
Seems like a good cleanup. Committed.
Thanks for committing the patch!
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ha
58 matches
Mail list logo
