On Sun, Aug 10, 2014 at 11:48 PM, David Rowley dgrowle...@gmail.com wrote:
I've attached an updated version of the patch which fixes up some
incorrect logic in the foreign key matching code, plus various comment
improvements.
I've made a few updated to the patch to simplify some logic in
Alvaro, all,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Can you be more specific on the exact grammar you're considering? The
proposal above,
ALTER TABLE ON ALL TABLES IN TABLESPACE xyz
doesn't seem very good to me. I would think it'd be more like
ALTER ALL TABLES IN TABLESPACE xyz
2014-08-07 0:30 GMT+04:00 Heikki Linnakangas hlinnakan...@vmware.com:
* I'm getting two regression failures with this (opr_sanity and join).
opr_sanity failure is corrected.
But there is remain question with join.
I check the latest version of my github repo and there's no fail in join
On 10.8.2014 23:26, Jeff Davis wrote:
This patch is requires the Memory Accounting patch, or something similar
to track memory usage.
The attached patch enables hashagg to spill to disk, which means that
hashagg will contain itself to work_mem even if the planner makes a
bad misestimate of
On 15.8.2014 19:53, Robert Haas wrote:
On Thu, Aug 14, 2014 at 2:21 PM, Jeff Davis pg...@j-davis.com wrote:
On Thu, 2014-08-14 at 12:53 -0400, Tom Lane wrote:
Oh? So if we have aggregates like array_agg whose memory footprint
increases over time, the patch completely fails to avoid bloat?
On Mon, Jul 28, 2014 at 2:24 PM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
On Mon, Jul 28, 2014 at 1:41 PM, Christoph Berg c...@df7cb.de wrote:
Re: Fabrízio de Royes Mello 2014-07-28
CAFcNs+pctx4Q2UYsLOvVFWaznO3U0XhPpkMx5DRhR=jw8w3...@mail.gmail.com
There are something that
Alvaro, all,
* Stephen Frost (sfr...@snowman.net) wrote:
As mentioned, I'll add this to the ALTER TABLE documentation and remove
it from the TABLESPACE docs. That's not done yet but I should have time
in the next few days to get that done also and will then commit it all
to master and
On 15 Aug 2014 19:06, Robert Haas robertmh...@gmail.com wrote:
As for the expanded-mode changes, I thought there was consensus to
revert that from 9.4.
Me too. In fact, I think that's been the consensus for many months,
but unless I'm mistaken it ain't done.
Yeah, this is entirely my
Hi Hackers,
This is the first piece of file level incremental backup support, as
described on wiki page https://wiki.postgresql.org/wiki/Incremental_backup
It is not yet complete, but I wish to share it on the list to receive
comments and suggestions.
The point of the patch is adding an option
On 8/17/14 5:19 PM, Stephen Frost wrote:
Alvaro, all,
* Stephen Frost (sfr...@snowman.net) wrote:
As mentioned, I'll add this to the ALTER TABLE documentation and remove
it from the TABLESPACE docs. That's not done yet but I should have time
in the next few days to get that done also and
On 8/16/14 8:46 AM, Amit Kapila wrote:
On Fri, Aug 15, 2014 at 1:03 PM, MauMau maumau...@gmail.com
mailto:maumau...@gmail.com wrote:
Thank you. The code looks correct. I confirmed that the
pg_basebackup could relocate the tablespace directory on Windows.
I marked this patch as ready for
I was just going over the release notes, and noticed the bit about
timestamp and timestamptz now being rendered in a fixed ISO-8601-compliant
format rather than whatever random DateStyle is in use. That's fine,
but I wonder why the same approach wasn't applied to type date?
regression=# set
On Mon, Aug 18, 2014 at 9:37 AM, Peter Eisentraut pete...@gmx.net wrote:
It's not ready for committer if the current patch does not apply.
FWIW, the latest version sent by Amit here applies correctly:
On 08/17/2014 08:42 PM, Tom Lane wrote:
I was just going over the release notes, and noticed the bit about
timestamp and timestamptz now being rendered in a fixed ISO-8601-compliant
format rather than whatever random DateStyle is in use. That's fine,
but I wonder why the same approach wasn't
Andrew Dunstan and...@dunslane.net writes:
On 08/17/2014 08:42 PM, Tom Lane wrote:
I was just going over the release notes, and noticed the bit about
timestamp and timestamptz now being rendered in a fixed ISO-8601-compliant
format rather than whatever random DateStyle is in use. That's fine,
On Fri, Aug 15, 2014 at 11:25 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Aug 15, 2014 at 4:59 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Aug 14, 2014 at 12:59 PM, Fujii Masao masao.fu...@gmail.com wrote:
Since I sometimes try to search the replication command in the index,
On Sat, Aug 16, 2014 at 4:23 PM, Sawada Masahiko sawada.m...@gmail.com wrote:
On Fri, Aug 8, 2014 at 11:45 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Aug 8, 2014 at 11:43 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Apr 14, 2014 at 11:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
On 08/17/2014 09:53 PM, Tom Lane wrote:
OK. I think I can fix it, if you don't have time.
[offlist]
Thanks. FYI I am still recovering from treatment for prostate cancer I
had not long after pgcon ... it's taken more out of me that I expected,
so time is
On Mon, Aug 18, 2014 at 7:08 AM, Michael Paquier michael.paqu...@gmail.com
wrote:
On Mon, Aug 18, 2014 at 9:37 AM, Peter Eisentraut pete...@gmx.net wrote:
It's not ready for committer if the current patch does not apply.
FWIW, the latest version sent by Amit here applies correctly:
On 08/17/2014 10:50 PM, Andrew Dunstan wrote:
On 08/17/2014 09:53 PM, Tom Lane wrote:
OK. I think I can fix it, if you don't have time.
[offlist]
Thanks. FYI I am still recovering from treatment for prostate cancer I
had not long after pgcon ... it's taken more out of me that I
On Mon, Aug 18, 2014 at 11:51 AM, Amit Kapila amit.kapil...@gmail.com wrote:
On Mon, Aug 18, 2014 at 7:08 AM, Michael Paquier michael.paqu...@gmail.com
wrote:
On Mon, Aug 18, 2014 at 9:37 AM, Peter Eisentraut pete...@gmx.net wrote:
It's not ready for committer if the current patch does not
On Sat, Aug 16, 2014 at 6:51 PM, Rahila Syed rahilasye...@gmail.com wrote:
So, you're compressing backup blocks one by one. I wonder if that's the
right idea and if we shouldn't instead compress all of them in one run to
increase the compression ratio
Please find attached patch for compression
Marco Nenciarini wrote:
To calculate the md5 checksum I've used the md5 code present in pgcrypto
contrib as the code in src/include/libpq/md5.h is not suitable for large
files. Since a core feature cannot depend on a piece of contrib, I've
moved the files
contrib/pgcrypto/md5.c
On Fri, Aug 15, 2014 at 5:17 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
Thanks for your review.
On Fri, Aug 15, 2014 at 12:56 AM, furu...@pm.nttdata.co.jp wrote:
At consistency with pg_recvlogical, do you think about --start?
I did not add that for the sake of
Pavel Stehule wrote:
2014-08-13 15:22 GMT+02:00 MauMau maumau...@gmail.com:
I didn't mean performance statistics data to be stored in database tables.
I just meant:
* pg_stat_system_events is a view to show data on memory, which returns
one row for each event across the system. This
25 matches
Mail list logo
