On Fri, Dec 9, 2016 at 4:11 PM, Michael Paquier
wrote:
> On Fri, Dec 9, 2016 at 3:23 PM, Michael Paquier
> wrote:
>> This basically means that if the latch is set, we don't wait at all
>> and drop the ball. I am wondering: isn't that a problem even if
>> WL_LATCH_SET is *not* set? If I read this
On Mon, Dec 12, 2016 at 4:32 PM, Heikki Linnakangas wrote:
> That test is broken. It looks like the x"$VAR" = x"constant" idiom, but the
> left side of the comparison doesn't have the 'x'. Oops.
Good catch.
> This makes me wonder if we should work a bit harder to get a good error
> message, if
On 12/12/2016 05:58 AM, Michael Paquier wrote:
On Sun, Dec 11, 2016 at 9:06 AM, Andrew Dunstan wrote:
jascana (mingw, 64 bit compiler, no openssl) is currently hung on "make
check". After starting the autovacuum launcher there are 120 messages on its
log about "Could not acquire random number"
Hello all,
This is to propose a patch for enabling parallel index-only scans. With the
patch of parallel index scan around [1], adding the mechanism for
parallelising index-only scans makes sense. Without this mechanism for the
queries preferring index-only scans, it is likely that at higher scale
Hi Tomas,
On 2016/12/12 10:02, Tomas Vondra wrote:
> On 12/07/2016 07:20 PM, Robert Haas wrote:
>> I've committed 0001 - 0006 with that correction and a few other
>> adjustments. There's plenty of room for improvement here, and almost
>> certainly some straight-up bugs too, but I think we're at
On 12/01/2016 09:45 PM, Andres Freund wrote:
And nobody has added a buildfarm module to run it manually on their
servers either :(
I just added a module to run "make -C src/test/ssl check" in chipmunk.
So at least that's covered now.
http://pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=chipmu
2016-12-11 18:23 GMT+01:00 Pavel Stehule :
> Hi
>
> 2016-12-09 18:39 GMT+01:00 Pavel Stehule :
>
>> Hi
>>
>> Long time I am pushing a COPY RAW - without success.
>>
>> Now I propose functionally similar solution - reduced to only to psql
>> console
>>
>> Now we have a statement \g for execution qu
On Fri, Dec 9, 2016 at 10:22 AM, Michael Paquier
wrote:
> Thanks for looking at the patch. Looking forward to hearing more!
Here is an updated patch based on which reviews should be done. I have
fixed the issue you have reported, and upon additional lookup I have
noticed that returning -1 when fa
On 2016/12/10 7:55, Keith Fiske wrote:
> Working on a blog post for this feature and just found some more
> inconsistencies with the doc examples. Looks like the city_id column was
> defined in the measurements table when it should be in the cities table.
> The addition of the partition to the citi
On 12 December 2016 at 12:52, Tom Lane wrote:
> Craig Ringer writes:
>> It's definitely annoying, in both directions. ? wasn't a great choice
>> for an operator character but it's logical and was grandfathered over
>> from hstore.
>
> It was grandfathered from a lot further back than that. A qui
On Mon, Dec 12, 2016 at 10:25 AM, Jeff Janes wrote:
> On Sun, Dec 11, 2016 at 8:37 PM, Amit Kapila
> wrote:
>>
>> On Sun, Dec 11, 2016 at 11:54 AM, Amit Kapila
>> wrote:
>> > On Wed, Dec 7, 2016 at 2:02 AM, Jeff Janes wrote:
>> >
>> > With above fixes, the test ran successfully for more than a
On Sun, Dec 11, 2016 at 8:37 PM, Amit Kapila
wrote:
> On Sun, Dec 11, 2016 at 11:54 AM, Amit Kapila
> wrote:
> > On Wed, Dec 7, 2016 at 2:02 AM, Jeff Janes wrote:
> >
> > With above fixes, the test ran successfully for more than a day.
> >
>
> There was a small typo in the previous patch which
Craig Ringer writes:
> It's definitely annoying, in both directions. ? wasn't a great choice
> for an operator character but it's logical and was grandfathered over
> from hstore.
It was grandfathered from a lot further back than that. A quick look
into the system catalogs says that core Postgre
On Tue, Dec 6, 2016 at 1:29 PM, Jeff Janes wrote:
> On Thu, Dec 1, 2016 at 10:54 PM, Amit Kapila
> wrote:
>
> With the latest HASH WAL patch applied, I get different but apparently
> related errors
>
> 41993 UPDATE XX002 2016-12-05 22:28:45.333 PST:ERROR: index "foo_index_idx"
> contains corrupt
On Tue, Dec 6, 2016 at 9:19 AM, Andres Freund wrote:
> 0009 WIP: Add minimal keytest implementation.
>
> More or less experimental patch that tries to implement simple
> expression of the OpExpr(ScalarVar, Const) into a single expression
> evaluation step. The benefits probably aren't big enough
On Sun, Dec 11, 2016 at 11:54 AM, Amit Kapila wrote:
> On Wed, Dec 7, 2016 at 2:02 AM, Jeff Janes wrote:
>
> With above fixes, the test ran successfully for more than a day.
>
There was a small typo in the previous patch which is fixed in
attached. I don't think it will impact the test results
On 11 December 2016 at 18:52, Geoff Winkless wrote:
> On 9 Dec 2016 17:54, "Andres Freund" wrote:
>
> On 2016-12-09 12:17:32 -0500, Robert Haas wrote:
>> As Geoff says, you don't have to use the operators; you could use the
>> equivalent functions instead. Every operator just gets turned into a
Hi,
On 2016/12/11 10:02, Venkata B Nagothi wrote:
> On Fri, Dec 9, 2016 at 11:11 PM, Amit Langote
> wrote:
>> On Fri, Dec 9, 2016 at 3:16 PM, Venkata B Nagothi
>> wrote:
>>> I am testing the partitioning feature from the latest master and got the
>>> following error while loading the data -
>>>
On 01/12/16 03:26, Tomas Vondra wrote:
>
> Dne 11/27/2016 v 11:02 PM Andres Freund napsal(a):
>> On 2016-11-27 22:21:49 +0100, Petr Jelinek wrote:
>>> On 27/11/16 21:47, Andres Freund wrote:
Hi,
>> +typedef struct SlabBlockData *SlabBlock;/* forward
>> reference */
>>
On Sun, Dec 11, 2016 at 9:06 AM, Andrew Dunstan wrote:
>
> jascana (mingw, 64 bit compiler, no openssl) is currently hung on "make
> check". After starting the autovacuum launcher there are 120 messages on its
> log about "Could not acquire random number". Then nothing.
>
>
> So I suspect the prob
On 12 December 2016 at 00:36, Kevin Grittner wrote:
> On Sun, Dec 11, 2016 at 1:17 AM, Craig Ringer
> wrote:
>> On 11 Dec. 2016 06:50, "Petr Jelinek" wrote:
>>> On 10/12/16 23:10, Petr Jelinek wrote:
>>>
The attached 0002-Skip-unnecessary-snapshot-builds.patch changes this
behavior so
Hi,
On 12/07/2016 07:20 PM, Robert Haas wrote:
> On Wed, Dec 7, 2016 at 11:53 AM, Erik Rijkers wrote:
>>> My bad. The fix I sent last night for one of the cache flush issues
>>> wasn't quite right. The attached seems to fix it.
>> Yes, fixed here too. Thanks.
>
> Thanks for the report - that
On 12/9/16 9:53 AM, Heikki Linnakangas wrote:
I'm not sure what --no-recursion does, but I would say that we'd
consider that unsupported as well.
Interesting. Running config.status adds those --no-create --no-recursion
flags automatically. You can see them in the command-line at the top of
con
Mateusz Stefek writes:
> Attached is a patch, which changes the order of the checks. I.e. the
> visibility of the row is confirmed only after the qual condition is
> evaluated to true.
This cannot be accepted, because it's unsafe to try to apply user
code to a dead tuple. The tuple might referen
Artur Zakirov writes:
> 2016-12-07 9:06 GMT+03:00 Andreas Seltenreich :
>> the following query crashes master as of 4212cb7.
> It happens because 'I' is stop word and substitute query becomes
> empty. And for queries above we need recursive dropvoidsubtree()
> function. Without this patch this fu
Hi,
I noticed that during an index-only scan the filter check is executed
after the visibility of a tuple is confirmed. This means a lot of
unnecessary heap fetches, if the filter condition is highly selective.
In the application I'm maintaining, the visibility map is mostly
dirty. Index-only sca
Hi
2016-12-09 18:39 GMT+01:00 Pavel Stehule :
> Hi
>
> Long time I am pushing a COPY RAW - without success.
>
> Now I propose functionally similar solution - reduced to only to psql
> console
>
> Now we have a statement \g for execution query, \gset for exec and store
> result in memory and I pro
On Sun, Dec 11, 2016 at 1:17 AM, Craig Ringer
wrote:
> On 11 Dec. 2016 06:50, "Petr Jelinek" wrote:
>> On 10/12/16 23:10, Petr Jelinek wrote:
>>
>>> The attached 0002-Skip-unnecessary-snapshot-builds.patch changes this
>>> behavior so that we don't make snapshots for transactions that we seen
>>>
On 9 Dec 2016 17:54, "Andres Freund" wrote:
On 2016-12-09 12:17:32 -0500, Robert Haas wrote:
> As Geoff says, you don't have to use the operators; you could use the
> equivalent functions instead. Every operator just gets turned into a
> function call internally, so this is always possible.
Wel
Hi!
I'm planning to review this patch.
I have some questions, maybe answers could help me understand patch better.
1. As far as I can see, we connot use COPY FROM STDIN in bg session?
Since one of purposes is to orchestrate transactions, may be that
would be valuable.
2. From my point of view the
Hi,
I found a minor typo at
https://www.postgresql.org/docs/9.6/static/catalog-pg-am.html.
pg_catalog.pg_am. amhandler is of type "oid" according to the
documentation, but it's actually of type "regproc" in reality.
Compare with e.g. pg_aggregate where the columns of type "regproc" is
both "regp
2016-12-09 18:00 GMT+05:00 Robert Haas :
> It looks like this could be reworked as a client of Peter Eisentraut's
> background sessions code, which I think is also derived from
> pg_background:
>
> http://archives.postgresql.org/message-id/e1c2d331-ee6a-432d-e9f5-dcf85cffa...@2ndquadrant.com
>
> Th
32 matches
Mail list logo
