On Sat, Jan 17, 2015 at 10:09 AM, Robert Haas wrote:
> On Fri, Jan 16, 2015 at 11:27 PM, Amit Kapila
wrote:
> > Assuming we will increment next_prefetch_block only after prefetching
> > blocks (equivalent to prefetch_increment), won't 2 workers can
> > simultaneously see the same value for next_p
On Mon, Jan 19, 2015 at 4:10 PM, Michael Paquier
wrote:
> On Sat, Jan 17, 2015 at 2:44 AM, Andres Freund wrote:
>> Am I missing something or does this handle/affect streaming failures
>> just the same? That might not be a bad idea, because the current
>> interval is far too long for e.g. a sync r
On Sat, Jan 17, 2015 at 2:44 AM, Andres Freund wrote:
> On 2015-01-05 17:16:43 +0900, Michael Paquier wrote:
>> + > xreflabel="restore_command_retry_interval">
>> + restore_command_retry_interval
>> (integer)
>> +
>> +restore_command_retry_interval recovery
>> parameter
>>
2015-01-19 4:54 GMT+01:00 Robert Haas :
> On Sat, Jan 17, 2015 at 8:27 PM, Pavel Stehule
> wrote:
> > two years a operator "=>" is marked as deprecated (from PostgreSQL 9.2).
> >
> > Isn't time to use it for named parameters now (for PostgreSQL 9.5) ?
>
> I'm cool with that. It's possible that t
Hello Stephen.
Thanks very much for having a look at the revised pgaudit.
At 2015-01-18 22:28:37 -0500, sfr...@snowman.net wrote:
>
> > 2. Set pgaudit.roles = 'r1, r2, …', which logs everything done by r1,
> >r2, and any of their descendants.
>
> If these roles were the 'audit' roles as consi
Hello, that's a silly mistake. fetch_seize = 1 in the v4
patch. This v5 patch is fixed at the point.
> But the v4 patch mysteriously accelerates this query, 6.5 seconds.
>
> > =# EXPLAIN (ANALYZE ON, COSTS OFF) SELECT x.a, x.c, y.c
> >FROM ft1 AS x JOIN ft1 AS y on x.a = y.a;
...
> > Exe
On Sun, Jan 18, 2015 at 12:46 AM, Petr Jelinek wrote:
> On 17/01/15 13:46, Amit Kapila wrote:
>
>
>> 3.
>> @@ -332,6 +334,11 @@ set_rel_pathlist(PlannerInfo *root, RelOptInfo *rel,
>> /* Foreign table */
>> set_foreign_pathlist(root, rel, rte);
>> }
>> +else if (rte->tablesample != NULL)
>> +{
>>
On Mon, Jan 19, 2015 at 2:38 PM, Michael Paquier
wrote:
> Heikki Linnakangas wrote:
>> Addressed most of your comments, and Michael's. Another version attached.
Extra thing: src/bin/pg_rewind/Makefile surely forgets to clean up the
stuff from the regression tests:
+clean distclean maintainer-clea
Heikki Linnakangas wrote:
> Addressed most of your comments, and Michael's. Another version attached.
Looking at the set of TAP tests, I think that those lines open again
the door of CVE-2014-0067 (vulnerability with make check) on Windows:
# Initialize master, data checksums are mandatory
Andrew Dunstan writes:
> On 01/18/2015 09:20 PM, Tom Lane wrote:
>> What I see on dromedary, which has been around a bit less than a year,
>> is that the at-rest space consumption for all 6 active branches is
>> 2.4G even though a single copy of the git repo is just over 400MB:
>> $ du -hsc pgmirr
On 9 January 2015 at 22:53, Tom Lane wrote:
> Craig Ringer writes:
> > While looking into client code that relies on parsing server_version
> > instead of checking server_version_num, I was surprised to discover that
> > server_version_num isn't sent to the client by the server as part of the
>
On Mon, Jan 19, 2015 at 12:41 PM, Peter Eisentraut wrote:
> I have committed my mingw portion, but I cannot take on the MSVC part.
OK, no problem. Perhaps I should add a new entry in the next CF for
the MSVC portion?
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
On 19-01-2015 PM 12:37, Ashutosh Bapat wrote:
> On Fri, Jan 16, 2015 at 11:04 PM, Robert Haas wrote:
>
>> On Wed, Jan 14, 2015 at 9:07 PM, Amit Langote
>> wrote:
>>
>>> I wonder if we could add a clause like DISTRIBUTED BY to complement
>>> PARTITION ON that represents a hash distributed/partiti
On 01/18/2015 09:20 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 01/18/2015 05:48 PM, Tom Lane wrote:
One of the biggest causes of buildfarm run failures is "out of disk
space". That's not just because people are running buildfarm critters
on small slow machines; it's because "make check-wo
On Sat, Jan 17, 2015 at 12:19 AM, Amit Kapila wrote:
> So are you telling that whenever we read, save the settings
> to some catalog (probably a new one)?
Which process are you imagining would do this? Certainly not the postmaster.
Independently of that, it sounds like solving the problem from
On Sat, Jan 17, 2015 at 8:27 PM, Pavel Stehule wrote:
> two years a operator "=>" is marked as deprecated (from PostgreSQL 9.2).
>
> Isn't time to use it for named parameters now (for PostgreSQL 9.5) ?
I'm cool with that. It's possible that there are installations out
there that still have => op
On 1/15/15 2:37 AM, Michael Paquier wrote:
> On Wed, Dec 24, 2014 at 3:08 PM, Michael Paquier
> wrote:
>> Attached are two patches, one for MinGW/cygwin, a slightly modified
>> version from Peter and the second implementing the same thing but for
>> the MSVC scripts. The method for MSVC is similar
On Fri, Jan 16, 2015 at 11:04 PM, Robert Haas wrote:
> On Wed, Jan 14, 2015 at 9:07 PM, Amit Langote
> wrote:
> > * It has been repeatedly pointed out that we may want to decouple
> > partitioning from inheritance because implementing partitioning as an
> > extension of inheritance mechanism mea
Abhijit,
Apologies, I've been meaning to go through this for quite some time.
* Abhijit Menon-Sen (a...@2ndquadrant.com) wrote:
> I've changed pgaudit to work as you suggested.
Great, glad to see that.
> A quick note on the implementation: pgaudit was already installing an
> ExecutorCheckPerms_
On Sun, Jan 18, 2015 at 4:09 PM, Tom Lane wrote:
> After looking at the code, the minimum-change alternative would be more or
> less as attached: first, get rid of the long-obsolete proposition that
> autovacuum workers need fresher-than-usual stats; second, allow
> pgstat_vacuum_stat to accept st
Andrew Dunstan writes:
> On 01/18/2015 05:48 PM, Tom Lane wrote:
>> One of the biggest causes of buildfarm run failures is "out of disk
>> space". That's not just because people are running buildfarm critters
>> on small slow machines; it's because "make check-world" is an enormous
>> space hog.
On Tue, Jan 13, 2015 at 2:35 PM, Magnus Hagander wrote:
> Further status updates to come as we start working on it...
Things are looking good so far. All the information has been synced up
between both apps for the current CF and the next one. One the switch
is done, I would recommend to each pat
Hello.
Sorry about giving corrupted reports.
We examine what it is caused by now.
regards,
---
TAKATSUKA Haruka haru...@sraoss.co.jp
SRA OSS, Inc. http://www.sraoss.co.jp
On Fri, 16 Jan 2015 03:25:00 -0500
Noah Misch wrote:
> Buildfarm member hamerkop stopped reporting in after commit f6
On Sun, Jan 18, 2015 at 07:02:54PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > On Sun, Jan 18, 2015 at 04:09:29PM -0500, Tom Lane wrote:
> >> After looking at the code, the minimum-change alternative would be more or
> >> less as attached: first, get rid of the long-obsolete proposition that
>
On Sun, Jan 18, 2015 at 10:21 PM, Andres Freund wrote:
> On 2015-01-18 21:05:29 +0900, Michael Paquier wrote:
>> On Sat, Jan 17, 2015 at 10:08 PM, Andres Freund
>> wrote:
>> > Observations:
>> > 1) Are we sure it's a good idea to rely on pgxs.mk in src/bin programs?
>
>> Yeah, this seems like a
On 01/18/2015 05:48 PM, Tom Lane wrote:
One of the biggest causes of buildfarm run failures is "out of disk
space". That's not just because people are running buildfarm critters
on small slow machines; it's because "make check-world" is an enormous
space hog. Some numbers from current HEAD:
c
Michael Paquier writes:
> On Mon, Jan 19, 2015 at 2:38 AM, David Fetter wrote:
>> On Sun, Jan 18, 2015 at 06:05:05PM +0700, Ali Akbar wrote:
>>> 2015-01-18 10:44 GMT+07:00 Peter Eisentraut :
Btw, for bug-fix patches like this, should the patch creator (me) also
create patches for back b
Noah Misch writes:
> On Sun, Jan 18, 2015 at 04:09:29PM -0500, Tom Lane wrote:
>> After looking at the code, the minimum-change alternative would be more or
>> less as attached: first, get rid of the long-obsolete proposition that
>> autovacuum workers need fresher-than-usual stats; second, allow
On Mon, Jan 19, 2015 at 2:38 AM, David Fetter wrote:
> On Sun, Jan 18, 2015 at 06:05:05PM +0700, Ali Akbar wrote:
>> 2015-01-18 10:44 GMT+07:00 Peter Eisentraut :
>> Btw, for bug-fix patches like this, should the patch creator (me) also
>> create patches for back branches?
>
> As I understand it,
On Sun, Jan 18, 2015 at 04:09:29PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > On Sat, Dec 27, 2014 at 07:55:05PM -0500, Tom Lane wrote:
> >> Or, much more simply, we could conclude that it's not that important
> >> if pgstat_vacuum_stat() is unable to get up-to-date stats, and rejigger
> >> t
On Mon, Jan 19, 2015 at 7:48 AM, Tom Lane wrote:
> To make things better in the buildfarm, we'd have to back-patch this into
> all active branches, but I don't see any big problem with doing so.
> Any objections?
Back-patching sounds like a good idea to me. At least this will allow
hamster to buil
One of the biggest causes of buildfarm run failures is "out of disk
space". That's not just because people are running buildfarm critters
on small slow machines; it's because "make check-world" is an enormous
space hog. Some numbers from current HEAD:
clean source tree: 120MB
built
Noah Misch writes:
> On Sat, Dec 27, 2014 at 07:55:05PM -0500, Tom Lane wrote:
>> To get back to that original complaint about buildfarm runs failing,
>> I notice that essentially all of those failures are coming from "wait
>> timeout" warnings reported by manual VACUUM commands. Now, VACUUM itse
2015-01-17 7:26 GMT+01:00 Pavel Stehule :
>
> 2015-01-16 22:35 GMT+01:00 Andrew Dunstan :
>
>>
>> On 01/16/2015 12:22 PM, Pavel Stehule wrote:
>>
>>>
>>>
>>> There two possible transformations:
>>>
>>> row_to_array --> [[key1, value1],[key2, value2], ...]
>>> row_to_row_arr
On Sat, Dec 27, 2014 at 07:55:05PM -0500, Tom Lane wrote:
> To get back to that original complaint about buildfarm runs failing,
> I notice that essentially all of those failures are coming from "wait
> timeout" warnings reported by manual VACUUM commands. Now, VACUUM itself
> has no need to read
On Sun, Jan 18, 2015 at 06:05:05PM +0700, Ali Akbar wrote:
> 2015-01-18 10:44 GMT+07:00 Peter Eisentraut :
>
> > On 1/7/15 8:51 PM, Ali Akbar wrote:
> > > So now +1 for back-patching this.
> >
> > Done. Was a bit of work to get it into all the old versions.
> >
>
> Wow. Thanks.
>
> Btw, for bug
On 1/18/15 8:16 AM, Andres Freund wrote:
> On 2015-01-18 22:02:13 +0900, Michael Paquier wrote:
>> On Sun, Jan 18, 2015 at 9:56 PM, Andrew Gierth
>>> 2) in any event it is essentially deprecated in favour of standby_mode
>>> and therefore moving it to src/bin seems like a wrong move on two counts?
On 1/17/15 8:08 AM, Andres Freund wrote:
> 1) Are we sure it's a good idea to rely on pgxs.mk in src/bin programs?
I am. Why not?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Is your PGCon 2015 submission going in today or tomorrow?
--
Dan Langille
http://langille.org/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andres Freund wrote:
> Hi,
>
> On 2015-01-18 12:56:59 +, Andrew Gierth wrote:
> > and therefore moving it to src/bin seems like a wrong move on two counts?
>
> I personally agree that that pg_standby shouldn't be moved. Even if we
> could not find agreement to remove it, there's little reaso
On 2015-01-18 21:05:29 +0900, Michael Paquier wrote:
> On Sat, Jan 17, 2015 at 10:08 PM, Andres Freund
> wrote:
> > Observations:
> > 1) Are we sure it's a good idea to rely on pgxs.mk in src/bin programs?
> Yeah, this seems like a bad dependency, PGXS being made for contrib
> modules... So corr
On 2015-01-18 22:02:13 +0900, Michael Paquier wrote:
> On Sun, Jan 18, 2015 at 9:56 PM, Andrew Gierth
> > 2) in any event it is essentially deprecated in favour of standby_mode
> > and therefore moving it to src/bin seems like a wrong move on two counts?
> There were some discussions about that a c
Hi,
On 2015-01-18 12:56:59 +, Andrew Gierth wrote:
> Correct me if I'm wrong, but is it not the case that:
> 1) pg_standby was intended to be customizable code, even if usable as
> distributed, and
I don't think that really happened in reality though...
> 2) in any event it is essentially d
On Sun, Jan 18, 2015 at 9:56 PM, Andrew Gierth
wrote:
> Correct me if I'm wrong, but is it not the case that:
> 1) pg_standby was intended to be customizable code, even if usable as
> distributed, and
I am not sure about that.
> 2) in any event it is essentially deprecated in favour of standby_mo
Correct me if I'm wrong, but is it not the case that:
1) pg_standby was intended to be customizable code, even if usable as
distributed, and
2) in any event it is essentially deprecated in favour of standby_mode
and therefore moving it to src/bin seems like a wrong move on two counts?
--
Andre
Simon, Bruce, Ants,
(CCing..)
On Sun, Jan 18, 2015 at 9:05 PM, Michael Paquier
wrote:
> On Sat, Jan 17, 2015 at 10:08 PM, Andres Freund
> wrote:
>> 7) Are we sure that the authors in the affected contrib modules are ok
>>with their authorship notice being removed? I don't think Ants, Bruce
On Sat, Jan 17, 2015 at 10:08 PM, Andres Freund wrote:
> Observations:
> 1) Are we sure it's a good idea to rely on pgxs.mk in src/bin programs?
Yeah, this seems like a bad dependency, PGXS being made for contrib
modules... So corrected in the patch attached (the headers of the
Makefiles are impro
2015-01-18 10:44 GMT+07:00 Peter Eisentraut :
> On 1/7/15 8:51 PM, Ali Akbar wrote:
> > So now +1 for back-patching this.
>
> Done. Was a bit of work to get it into all the old versions.
>
Wow. Thanks.
Btw, for bug-fix patches like this, should the patch creator (me) also
create patches for bac
48 matches
Mail list logo
