On Wed, Apr 12, 2017 at 02:41:09PM -0400, Tom Lane wrote:
> While poking at the question of parallel_safe marking for Plans,
> I noticed that max_parallel_hazard_walker() does this:
>
> /* We can push the subplans only if they are parallel-safe. */
> else if (IsA(node, SubPlan))
>
On Fri, Apr 14, 2017 at 04:47:12AM +0900, Fujii Masao wrote:
> Though I've read only a part of the logical rep code yet, I'd like to
> share some (relatively minor) review comments that I got so far.
>
> In ApplyWorkerMain(), DatumGetInt32() should be used to get integer
> value from the argument,
On Wed, Apr 12, 2017 at 10:55:08PM +0900, Fujii Masao wrote:
> When I shut down the publisher while I repeated creating and dropping
> the subscription in the subscriber, the publisher emitted the following
> PANIC error during shutdown checkpoint.
>
> PANIC: concurrent transaction log activity w
On Thu, Apr 06, 2017 at 11:33:22AM +0900, Masahiko Sawada wrote:
> While testing table sync worker for logical replication I noticed that
> if the table sync worker of logical replication failed to insert the
> data for whatever reason, the table sync worker process exits with
> error. And then the
On Thu, Apr 13, 2017 at 11:38:08AM -0400, Robert Haas wrote:
> On Thu, Apr 13, 2017 at 11:05 AM, Stephen Frost wrote:
> > Sure, though I won't be able to today and I've got some doubts about the
> > other patches. I'll have more time tomorrow though.
>
> OK, cool. I'll mark you down as the owne
On Sat, Apr 15, 2017 at 12:01 AM, Tom Lane wrote:
> Maybe we need to rethink the division of labor between parallel.c
> and execParallel.c, but that would depend on somebody explaining
> what the difference is in the first place.
parallel.c handles general concerns related to any sort of
parallel
On 16 April 2017 07:14:21 EEST, Noah Misch wrote:
>This PostgreSQL 10 open item is past due for your status update.
>Kindly send
>a status update within 24 hours, and include a date for your subsequent
>status
>update.
I will pick this up on Tuesday. The consensus seems to be to change the o
On Wed, Apr 05, 2017 at 08:58:54AM -0300, Alvaro Herrera wrote:
> Noah Misch wrote:
> > The above-described topic is currently a PostgreSQL 10 open item. Álvaro,
> > since you committed the patch believed to have created it, you own this open
> > item.
>
> I'll commit a fix for this problem no la
On Fri, Apr 14, 2017 at 11:58:23PM -0400, Noah Misch wrote:
> On Wed, Apr 05, 2017 at 09:51:02PM -0400, Noah Misch wrote:
> > On Thu, Apr 06, 2017 at 12:48:56AM +0900, Fujii Masao wrote:
>
> > > > On Mon, Dec 19, 2016 at 09:49:58PM +0900, Fujii Masao wrote:
> > > >> (2)
> > > >> There will be stil
On Wed, Apr 12, 2017 at 02:33:27AM -0400, Noah Misch wrote:
> On Tue, Apr 11, 2017 at 08:10:23AM +0300, Heikki Linnakangas wrote:
> > On 04/11/2017 04:52 AM, Peter Eisentraut wrote:
> > >On 4/10/17 04:27, Heikki Linnakangas wrote:
> > >>One thing to consider is that we just made the decision that "
I wrote:
> If we want to go any further back with 1.1 support, we have a range
> of options:
> 1. Back-patch that patch, probably also including the followup adjustments
> in 86029b31e and 36a3be654.
> 2. Add #if's to use 31cf1a1a4's coding with OpenSSL >= 1.1, while keeping
>the older code f
Andreas Karlsson writes:
> On 09/15/2016 05:38 PM, Alvaro Herrera wrote:
>> I suppose some interested party could grab the patch that Heikki
>> committed to the new branches and produce a back-patch that can be
>> applied to the older branches.
> Here is the result of backporting the sum of the t
Andres Freund writes:
> On 2017-04-15 18:04:00 -0400, Tom Lane wrote:
>> I see that buildfarm member anchovy has been failing in pre-9.5
>> branches for the last several weeks, with symptoms suggesting that
>> it's been updated to openssl 1.1.0 or later. The failures are
>> unsurprising given tha
After this commit, I get crash recovery failures when using prepared
transactions.
commit 728bd991c3c4389fb39c45dcb0fe57e4a1dccd71
Author: Simon Riggs
Date: Tue Apr 4 15:56:56 2017 -0400
Speedup 2PC recovery by skipping two phase state files in normal path
After the induced crash, I get
On 2017-04-15 18:04:00 -0400, Tom Lane wrote:
> I see that buildfarm member anchovy has been failing in pre-9.5
> branches for the last several weeks, with symptoms suggesting that
> it's been updated to openssl 1.1.0 or later. The failures are
> unsurprising given that commit 593d4e47d wasn't bac
I see that buildfarm member anchovy has been failing in pre-9.5
branches for the last several weeks, with symptoms suggesting that
it's been updated to openssl 1.1.0 or later. The failures are
unsurprising given that commit 593d4e47d wasn't back-patched further
than 9.5, but I wonder whether it is
On 2017-04-15 17:30:21 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2017-04-15 16:48:05 -0400, Tom Lane wrote:
> >> Concretely, I propose the attached patch. We'd have to put it into
> >> all supported branches, since culicidae is showing intermittent
> >> "could not reattach to shared m
Andres Freund writes:
> On 2017-04-15 17:24:54 -0400, Tom Lane wrote:
>> I wonder whether we could work around that by just destroying the created
>> process and trying again if we get a collision. It'd be a tad
>> inefficient, but hopefully collisions wouldn't happen often enough to be a
>> big
Andres Freund writes:
> On 2017-04-15 16:48:05 -0400, Tom Lane wrote:
>> Concretely, I propose the attached patch. We'd have to put it into
>> all supported branches, since culicidae is showing intermittent
>> "could not reattach to shared memory" failures in all the branches.
> That seems quite
On 2017-04-15 17:24:54 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2017-04-15 17:09:38 -0400, Tom Lane wrote:
> >> Why doesn't Windows' ability to map the segment into the new process
> >> before it executes take care of that?
>
> > Because of ASLR of the main executable (i.e. something
Andres Freund writes:
> On 2017-04-15 17:09:38 -0400, Tom Lane wrote:
>> Why doesn't Windows' ability to map the segment into the new process
>> before it executes take care of that?
> Because of ASLR of the main executable (i.e. something like PIE).
Not following. Are you saying that the main
On 2017-04-15 17:09:38 -0400, Tom Lane wrote:
> Andres Freund writes:
> > That seems quite reasonable. I'm afraid we're going to have to figure
> > out something similar, but more robust, for windows soon-ish :/
>
> Why doesn't Windows' ability to map the segment into the new process
> before it
Andres Freund writes:
> That seems quite reasonable. I'm afraid we're going to have to figure
> out something similar, but more robust, for windows soon-ish :/
Why doesn't Windows' ability to map the segment into the new process
before it executes take care of that?
> As a minor point, it'd pro
On 2017-04-15 16:48:05 -0400, Tom Lane wrote:
> I wrote:
> > I think what may be the most effective way to proceed is to provide
> > a way to force the shmem segment to be mapped at a chosen address.
> > It looks like, at least on x86_64 Linux, mapping shmem at
> > 0x7E00 would work rel
I wrote:
> I think what may be the most effective way to proceed is to provide
> a way to force the shmem segment to be mapped at a chosen address.
> It looks like, at least on x86_64 Linux, mapping shmem at
> 0x7E00 would work reliably.
> Since we only care about this for testing purp
On 04/15/2017 02:13 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Sure. Just means putting this code a bit later in the file. "make check"
>> is only one initdb, so it won't cost much. I'm still inclined to force a
>> TAP test for initdb with no TZ set, though.
> I'd like that to be an additio
On Fri, Apr 14, 2017 at 9:33 PM, Pavan Deolasee
wrote:
> Since all those offsets fall on a page boundary, my guess is that we're
> somehow failing to handle a new page correctly.
>
> Looking at the patch itself, my feeling is that the following code
> in src/backend/access/transam/twophase.c mig
Petr Jelinek writes:
> On 15/04/17 06:01, Tom Lane wrote:
>> I've had more than enough of seeing buildfarm failures from culicidae,
>> so I whacked this around until I was happy with it and pushed it.
>> Further adjustments welcome of course.
> Thanks. Seems like culicidae is finally happy with m
Amit Kapila writes:
> Attached patch to fix $SUBJECT.
Pushed, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andrew Dunstan writes:
> Sure. Just means putting this code a bit later in the file. "make check"
> is only one initdb, so it won't cost much. I'm still inclined to force a
> TAP test for initdb with no TZ set, though.
I'd like that to be an additional tweak for some existing test case
rather tha
On Sat, Apr 15, 2017 at 7:54 PM, Tom Lane wrote:
> Andrew Dunstan writes:
> > The instructions on how to create a self-signed certificate in s 18.9.3
> > of the docs seem unduly cumbersome.
>
> Yeah, I noticed that they seemed unnecessarily manual. +1 for
> simplifying.
>
Seems reasonable, +1
Andrew Dunstan writes:
> The instructions on how to create a self-signed certificate in s 18.9.3
> of the docs seem unduly cumbersome.
Yeah, I noticed that they seemed unnecessarily manual. +1 for
simplifying.
regards, tom lane
--
Sent via pgsql-hackers mailing list (
Andres Freund writes:
> On April 14, 2017 9:42:41 PM PDT, Tom Lane wrote:
>> 2017-04-15 04:31:21.657 GMT [16792] FATAL: could not reattach to
>> shared memory (key=6280001, addr=0x7f692fece000): Invalid argument
>>
>> Presumably, this is the same issue we've seen on Windows where the
>> shmem a
Hi all, I am interested in getting simple statistics of a GiST index structure.
For example, height of tree.
It seems that the other indexes have a metapage for this. I am still unsure but
it looks to me like the GiST access method internal does not work exactly in
this way so it is a bit more
On Sat, Apr 15, 2017 at 7:38 AM, Simon Riggs wrote:
>> I waited quite a while for you to review Amit's patches on that
>> thread, but as you never did, I eventually picked it up.
>
> Sorry about that, I guess I was concentrating on things listed on the
> CF app at that time.
No problem from my en
On 14 April 2017 at 20:20, Peter Eisentraut
wrote:
>
> Yeah, I think if you're concerned about MITM then you would also be
> concerned about MITM siphoning off your data. So you should be using
> TLS and then you don't need channel binding.
No. You can use TLS for authentication (by verifying SS
On Fri, Apr 14, 2017 at 6:52 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> If we're talking about making things easier to understand, wouldn't a
>> random user rather know what a WAL "location" is instead of a WAL "LSN"?
>
> I wouldn't object to standardizing on "location" instead of "lsn" in
On 04/15/2017 12:13 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> What I had in mind was the attached plus roughly this in the buildfarm
>> client:
>> $ENV{TZ} ||= 'US/Eastern';
>> or whatever zone we choose to use.
> How about letting the first "make check" run with whatever is in the
> e
Andrew Dunstan writes:
> What I had in mind was the attached plus roughly this in the buildfarm
> client:
> $ENV{TZ} ||= 'US/Eastern';
> or whatever zone we choose to use.
How about letting the first "make check" run with whatever is in the
environment, and then forcing TZ to become set (much
On 04/15/2017 11:44 AM, Alvaro Herrera wrote:
> Andrew Dunstan wrote:
>
>> Alternatively, we could have an initdb TAP test that explicitly removed
>> the environment setting so we'd get coverage of select_default_timezone,
>> and have the buildfarm set TZ to something if it's not already set.
> W
Andrew Dunstan wrote:
> Alternatively, we could have an initdb TAP test that explicitly removed
> the environment setting so we'd get coverage of select_default_timezone,
> and have the buildfarm set TZ to something if it's not already set.
What about having an initdb option that runs select_defa
Noah Misch wrote:
> On Fri, Apr 14, 2017 at 09:38:32PM +0200, Magnus Hagander wrote:
> > On Fri, Apr 14, 2017 at 9:36 PM, Peter Eisentraut
> > wrote:
> > > On 4/14/17 14:45, Magnus Hagander wrote:
> > > > Attached is a patch that can be applied to pgweb which should fix
> > > > all of
> > >
Hi,
Attached patch for $subject.
s/apruptly/abruptly
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
fix_typo_in_xlogutils_c.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
On 04/15/2017 09:58 AM, Andrew Dunstan wrote:
> The instructions on how to create a self-signed certificate in s 18.9.3
> of the docs seem unduly cumbersome. AFAICT we could replace all the
> commands (except the chmod) with something like this:
>
> |openssl req -new-x509 -days 365-nodes \ -t
On 15/04/17 06:01, Tom Lane wrote:
> Petr Jelinek writes:
>> So this is what I came up with on plane. Generalized the loading
>> functionality into load_library_function which that can load either
>> known postgres functions or call load_external_function.
>
> I've had more than enough of seeing
Attached patch to fix $SUBJECT.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
typo_htup_details.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpr
The instructions on how to create a self-signed certificate in s 18.9.3
of the docs seem unduly cumbersome. AFAICT we could replace all the
commands (except the chmod) with something like this:
|openssl req -new-x509 -days 365-nodes \ -text -outserver.crt\
-keyout server.key\ -subj "/C=XY
On 04/15/2017 12:07 AM, Tom Lane wrote:
> Andreas Karlsson writes:
>> Looked some at this and what take time now for me seems to mainly be
>> these four things (out of a total runtime of 560 ms).
>> 1. setup_conversion:140 ms
>> 2. select_default_timezone: 90 ms
>> 3. bootstrap_templat
On 14 April 2017 at 09:18, Amit Langote wrote:
>> Where shall I mention BRIN in that chapter?
>
> Maybe just append a new right below where id="ddl-partitioning-constraint-exclusion"> ends?
>
> I had included both BRIN and UNION ALL views under a sub-section titled
> "Alternative Methods" in my
On 14 April 2017 at 14:02, Robert Haas wrote:
> On Fri, Apr 14, 2017 at 3:43 AM, Simon Riggs wrote:
>> Oh, just looks very different to what we discussed, so I presumed more
>> changes were coming.
>
> I waited quite a while for you to review Amit's patches on that
> thread, but as you never did,
50 matches
Mail list logo
