On Fri, Jul 25, 2014 at 12:48 PM, Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
> > I think there is one more disadvantage in the way current patch is
> > done which is that you need to collect index path keys for all relations
> > irrespective of whether they will be of any use to el
On Fri, Jul 25, 2014 at 6:11 PM, Fujii Masao wrote:
> On Wed, Jul 9, 2014 at 11:05 PM, Amit Kapila
wrote:
> > Okay. As mentioned upthread, I have fixed by ensuring that for duplicate
> > config params, retain only which comes later during parsing.
> > I think it might have been bit simpler to fix
On Wed, 2014-07-23 at 12:31 +0200, Magnus Hagander wrote:
> Do we actually have any buildfarm boxes building the PDFs? And if so,
> any idea why they didn't catch it?
My jenkins does that, and I reported the problem here
http://www.postgresql.org/message-id/1400206646.15189.3.ca...@vanquo.pezone.
Attached is a contrib module that lets you launch arbitrary command in
a background worker, and supporting infrastructure patches for core.
You can launch queries and fetch the results back, much as you could
do with a dblink connection back to the local database but without the
hassles of dealing
On Fri, Jul 25, 2014 at 02:11:32PM -0400, Robert Haas wrote:
> + pq_mq_busy = true;
> +
> + iov[0].data = &msgtype;
> + iov[0].len = 1;
> + iov[1].data = s;
> + iov[1].len = len;
> +
> + Assert(pq_mq_handle != NULL);
> + result = shm_mq_sendv(pq_mq_handle, iov, 2, false
On Fri, Jul 25, 2014 at 7:38 PM, Josh Berkus wrote:
> On 07/25/2014 11:49 AM, Claudio Freire wrote:
>>> I agree with much of that. However, I'd question whether we can
>>> > really seriously expect to rely on file modification times for
>>> > critical data-integrity operations. I wouldn't like i
On 07/25/2014 11:49 AM, Claudio Freire wrote:
>> I agree with much of that. However, I'd question whether we can
>> > really seriously expect to rely on file modification times for
>> > critical data-integrity operations. I wouldn't like it if somebody
>> > ran ntpdate to fix the time while the b
"Baker, Keith [OCDUS Non-J&J]" writes:
> I propose that a QNX 6.5 port be introduced to PostgreSQL.
Hmm ... you're aware that there used to be a QNX port? We removed it
back in 2006 for lack of interest and maintainers, and AFAIR you're
the first person to show any interest in reintroducing it s
I propose that a QNX 6.5 port be introduced to PostgreSQL.
I am new to PostgreSQL development, so please bear with me.
I have made good progress (with 1 outstanding issue, details below):
* I created a QNX 6.5 port of PostgreSQL 9.3.4 which passes regression
tests.
* I merged m
Magnus Hagander writes:
> On Fri, Jul 25, 2014 at 7:15 PM, Alexey Klyukin wrote:
>> On Fri, Jul 25, 2014 at 6:34 PM, Magnus Hagander
>>> Why keep looping once you've found a match? When you set result=true
>>> you should break; from the loop I think. Not necessarily for
>>> performance, but ther
I looked into the performance issue Joe Van Dyk reported in bug #11033.
It turns out this is basically a consequence of the "section boundary"
pseudo-objects I added in commit a1ef01fe163b304760088e3e30eb22036910a495.
(I'd worried about performance consequences at the time, but hadn't
seen any actu
On a Windows or other EXEC_BACKEND build, the following eventually gets
failures because all, or all but one, max_connections slot is consumed:
for run in `seq 1 100`; do make -C contrib/test_shm_mq installcheck; done
When I use max_connections=40, it fails on the sixth iteration. Only the six
On Fri, Jul 25, 2014 at 3:44 PM, Robert Haas wrote:
> On Fri, Jul 25, 2014 at 2:21 PM, Claudio Freire
> wrote:
>> On Fri, Jul 25, 2014 at 10:14 AM, Marco Nenciarini
>> wrote:
>>> 1. Proposal
>>> =
>>> Our proposal is to introduce the concept of a backup profile.
On Fri, Jul 25, 2014 at 2:21 PM, Claudio Freire wrote:
> On Fri, Jul 25, 2014 at 10:14 AM, Marco Nenciarini
> wrote:
>> 1. Proposal
>> =
>> Our proposal is to introduce the concept of a backup profile. The backup
>> profile consists of a file with one line per file
On Fri, Jul 25, 2014 at 10:14 AM, Marco Nenciarini
wrote:
> 1. Proposal
> =
> Our proposal is to introduce the concept of a backup profile. The backup
> profile consists of a file with one line per file detailing tablespace,
> path, modification time, size and check
On Fri, Jul 25, 2014 at 7:15 PM, Alexey Klyukin wrote:
> On Fri, Jul 25, 2014 at 6:34 PM, Magnus Hagander
> wrote:
>>
>>
>> I just took a very quick look at the code, and just noticed one thing:
>>
>> Why keep looping once you've found a match? When you set result=true
>> you should break; from t
On Fri, Jul 25, 2014 at 6:34 PM, Magnus Hagander
wrote:
>
> I just took a very quick look at the code, and just noticed one thing:
>
> Why keep looping once you've found a match? When you set result=true
> you should break; from the loop I think. Not necessarily for
> performance, but there might
On Fri, Jul 25, 2014 at 6:10 PM, Alexey Klyukin wrote:
> Greetings,
>
> I'd like to propose a patch for checking subject alternative names entry in
> the SSL certificate for DNS names during SSL authentication.
>
> When the client PGSSLMODE is set to verify-full, the common name (CN) of the
> Post
Thanks for your modify the patch! I confirmed that It seems to be fine.
I think that our latest patch fill all community comment.
So it is really ready for committer now.
Best regards,
--
Mitsumasa KONDO
Greetings,
I'd like to propose a patch for checking subject alternative names entry in
the SSL certificate for DNS names during SSL authentication.
When the client PGSSLMODE is set to verify-full, the common name (CN) of
the PostgreSQL server in the certificate is matched against the actual
host
On Fri, Jul 25, 2014 at 10:14 PM, Marco Nenciarini
wrote:
> 0. Introduction:
> =
> This is a proposal for adding incremental backup support to streaming
> protocol and hence to pg_basebackup command.
Not sure that incremental is a right word as the existing backup
m
Emre Hasegeli writes:
>> Well, I think the number of tabs that makes them look best depends on
>> your tab-stop setting. At present, I find that with 8-space tabs
>> things seem to line up pretty well, whereas with your patch, 4-space
>> tabs line up well.
> 4 space tab-stop is not the project s
0. Introduction:
=
This is a proposal for adding incremental backup support to streaming
protocol and hence to pg_basebackup command.
1. Proposal
=
Our proposal is to introduce the concept of a backup profile. The backup
profile consi
On Wed, Jul 9, 2014 at 11:05 PM, Amit Kapila wrote:
> On Wed, Jul 9, 2014 at 10:14 AM, Tom Lane wrote:
>>
>> Amit Kapila writes:
>> > On Wed, Jul 9, 2014 at 6:40 AM, Mark Kirkwood
>> >
>> > wrote:
>> >> Yes, but even well behaved users will see this type of error, because
>> >> initdb uncomment
In order to minimize the impact, what can be done is to execute
fetch_more_data() in asynchronous mode every time, when there only few rows
left to be consumed. So in current code below
1019 /*
1020 * Get some more tuples, if we've run out.
1021 */
1022 if (fsstate->next_tuple >=
Hi Kyotaro,
fetch_more_rows() always runs "FETCH 100 FROM " on the foreign
server to get the next set of rows. The changes you have made seem to run
only the first FETCHes from all the nodes but not the subsequent ones. The
optimization will be helpful only when there are less than 100 rows per
pos
Hi,
I’m implementing the functionality that will pass all the queries native to
postgresql (that asks about structures and versions) to the hidden postgresql
and other queries I would like to parse myself. I have a big problem with
outputing PG_TYPE_INT[248] value. I’m doing it because in my sy
This patch was made by the following process.
1. post patch for additional pg_receivexlog synchronous mode.
2. In response to comment for the flush frequency, I revise the patch to do
flush every consecutive message in reference to walreceiver.
3. The synchronization mode was necessary to reply
(2014/06/13 1:37), Tom Lane wrote:
> I wrote:
>> We have a couple votes for this patch and no one has spoken against it,
>> so I'll go ahead and push it into HEAD.
>
> BTW, I forgot to mention that while working on this patch I was thinking
> it's past time to separate out the subquery support in
> Well, I think the number of tabs that makes them look best depends on
> your tab-stop setting. At present, I find that with 8-space tabs
> things seem to line up pretty well, whereas with your patch, 4-space
> tabs line up well. Either way, I have no idea what the picture is
> supposed to mean,
Hello,
I noticed that postgresql_fdw can run in parallel by very small
change. The attached patch let scans by postgres_fdws on
different foreign servers run sumiltaneously. This seems a
convenient entry point to parallel execution.
For the testing configuration which the attched sql script make
Shigeru Hanada wrote:
> * Naming of new behavior
> You named this optimization "Direct Update", but I'm not sure that
> this is intuitive enough to express this behavior. I would like to
> hear opinions of native speakers.
How about "batch foreign update" or "batch foreign modification"?
(Disclai
(2014/07/24 18:30), Shigeru Hanada wrote:
My coworker Takaaki EITOKU reviewed the patch, and here are some
comments from him.
Thank you for the review, Eitoku-san!
2014-07-08 16:07 GMT+09:00 Etsuro Fujita :
In the patch postgresPlanForeignModify has been modified so that if, in
addition to t
Hi, I'm not so confident whether it's the time to do this...
I mark this as 'Ready for Committer' since no additional comment
or objection was put by others on this patch.
> After all, I have no more comment about this patch. I will mark
> this as 'Ready for committer' unless no comment comes fr
Hello.
I've been cooled off and convinced that this patch has become
quite useless by itself. It improves almost only UNIONs with
ORDER BY on tables that have unioform primary keys, and needs my
another patch to work.
I'll try to reintegrate this patch into my 'another patch' as
mentioned below
35 matches
Mail list logo
