On Sun, Feb 2, 2014 at 1:03 AM, Tom Lane wrote:
> I happened to notice today that the owner of buildfarm member narwhal
> is trying to revive it after a long time offline, but it's failing in
> the 9.3 branch (and not attempting to build HEAD, yet). The cause
> appears to be that contrib/postgres
On Sat, Feb 1, 2014 at 1:41 PM, Andres Freund wrote:
>> However, I tested the
>> most recent revision from your git remote on the AWS instance.
> But that was before my fix, right. Except you managed to timetravel :)
Heh, okay. So Nathan Boley has generously made available a machine
with 4 AMD O
On 2014-02-01 21:04:44 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I don't know why it didn't fail for postgres_fdw. Hm, maybe it's because
> > Mkvcbuild.pm links postgres_fdw with libpq, but not test_shm_mq?
>
> Hard to see how libpq as such could have anything to do with it.
> I wonder t
Andres Freund writes:
> I don't know why it didn't fail for postgres_fdw. Hm, maybe it's because
> Mkvcbuild.pm links postgres_fdw with libpq, but not test_shm_mq?
Hard to see how libpq as such could have anything to do with it.
I wonder though if adding libpq causes some different link-time
swit
Andres Freund writes:
> On 2014-02-01 20:03:58 -0500, Tom Lane wrote:
>> I think we should give serious consideration to desupporting this
>> combination so that we can get rid of the plague of PGDLLIMPORT
>> marks. Obviously this would depend on confirming that there are
>> no more-interesting W
On 2014-02-02 02:15:39 +0100, Andres Freund wrote:
> On 2014-02-01 20:03:58 -0500, Tom Lane wrote:
> > I think we should give serious consideration to desupporting this
> > combination so that we can get rid of the plague of PGDLLIMPORT
> > marks. Obviously this would depend on confirming that the
On 02/01/2014 08:03 PM, Tom Lane wrote:
I happened to notice today that the owner of buildfarm member narwhal
is trying to revive it after a long time offline, but it's failing in
the 9.3 branch (and not attempting to build HEAD, yet). The cause
appears to be that contrib/postgres_fdw is refere
On 2014-02-01 20:03:58 -0500, Tom Lane wrote:
> I think we should give serious consideration to desupporting this
> combination so that we can get rid of the plague of PGDLLIMPORT
> marks. Obviously this would depend on confirming that there are
> no more-interesting Windows build methods that req
On Sun, Feb 2, 2014 at 2:43 AM, Gabriele Bartolini
wrote:
> Hi Michael and Fujii,
>
> Il 01/02/14 17:46, Fujii Masao ha scritto:
>> I think that it's OK to add that as TODO item. There might be
>> the system that the speed of WAL archiving is slower than
>> that of WAL generation, at peak time. Th
I happened to notice today that the owner of buildfarm member narwhal
is trying to revive it after a long time offline, but it's failing in
the 9.3 branch (and not attempting to build HEAD, yet). The cause
appears to be that contrib/postgres_fdw is referencing the DateStyle
and IntervalStyle varia
On 02/01/2014 06:15 PM, Andres Freund wrote:
Hi,
On 2014-02-01 18:13:42 -0500, Andrew Dunstan wrote:
[Long review]
Most of these comments actually refer to Teodor and Oleg's code.
I will attend to the parts that apply to my code.
Well, somebody will need to address them nonetheless :/
Y
Hi,
On 2014-02-01 18:13:42 -0500, Andrew Dunstan wrote:
> [Long review]
>
> Most of these comments actually refer to Teodor and Oleg's code.
>
> I will attend to the parts that apply to my code.
Well, somebody will need to address them nonetheless :/
Greetings,
Andres Freund
--
Andres Freu
On 02/01/2014 05:20 PM, Andres Freund wrote:
[Long review]
Most of these comments actually refer to Teodor and Oleg's code.
I will attend to the parts that apply to my code.
Thanks for the review.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Andrew Dunstan writes:
> On 02/01/2014 05:12 PM, Marco Atzeri wrote:
>> is it possible the tsearch test never worked on en_US.utf8
>> but only on C locale ?
> Yes, that's more or less what I said, I thought.
> Maybe we need to test this on other Windows systems in non-C encodings.
> Let's make
On 02/01/2014 05:12 PM, Marco Atzeri wrote:
On 01/02/2014 22:57, Andrew Dunstan wrote:
On 01/25/2014 01:23 PM, Andrew Dunstan wrote:
* isolation tests fail with an indefinite hang on newer Cygwin
* prepared_xacts test fails with an indefinite hang on newer Cygwin if
run in parall
On 2014-01-30 14:07:42 -0500, Andrew Dunstan wrote:
> +
> +shows the functions that
> are
> + available for creating json values.
> + (see )
>
>
> -
> -JSON Support Functions
> +
> + array_to_json
> +
> +
> + row_to_json
> +
> +
> + to_json
> +
> +
> + j
On 01/02/2014 22:57, Andrew Dunstan wrote:
On 01/25/2014 01:23 PM, Andrew Dunstan wrote:
* isolation tests fail with an indefinite hang on newer Cygwin
* prepared_xacts test fails with an indefinite hang on newer Cygwin if
run in parallel with other tests
* tsearch tests fail o
On 01/25/2014 01:23 PM, Andrew Dunstan wrote:
I have now tested the central part of the proposed changes on both old
and new Cygwin installations, and they appear to work.
I'm going to commit them and backpatch back to 9.0, which is where we
currently have buildfarm coverage (and 8.4 will
On 2014-02-01 13:40:20 -0800, Peter Geoghegan wrote:
> On Sat, Feb 1, 2014 at 4:57 AM, Andres Freund wrote:
> >> I'm looking at alternative options, because this is not terribly
> >> helpful. With those big caveats in mind, consider the results of the
> >> benchmark, which show the patch performin
On Sat, Feb 1, 2014 at 4:57 AM, Andres Freund wrote:
>> I'm looking at alternative options, because this is not terribly
>> helpful. With those big caveats in mind, consider the results of the
>> benchmark, which show the patch performing somewhat worse than the
>> master baseline at higher client
On 2014-01-24 22:31:17 +0900, MauMau wrote:
> From: "Fujii Masao"
> >On Wed, Jan 22, 2014 at 6:37 AM, Heikki Linnakangas
> >>>Thanks! The patch looks good to me. Attached is the updated version of
> >>>the patch. I added the comments.
>
> Thank you very much. Your comment looks great. I tested
On 2014-01-21 23:37:43 +0200, Heikki Linnakangas wrote:
> On 01/21/2014 07:31 PM, Fujii Masao wrote:
> >On Fri, Dec 20, 2013 at 9:21 PM, MauMau wrote:
> >>From: "Fujii Masao"
> >>
> >>>! if (source == XLOG_FROM_ARCHIVE && StandbyModeRequested)
> >>>
> >>>Even when standby_mode is not enabled,
On 02/01/2014 08:01 AM, Peter Eisentraut wrote:
On 1/31/14, 12:47 PM, Andrew Dunstan wrote:
Hmm, looks like it got dropped. I think my original patch is probably
about the the right thing to do, and given that it's already done by
the MSVC build it's a bug and should be backported, as Alvaro s
Robert Haas writes:
> On Sat, Jan 25, 2014 at 5:04 PM, Tom Lane wrote:
>> Yeah. If Robert's diagnosis is correct, and it sounds pretty plausible,
>> then this is really just one instance of a bug that's probably pretty
>> widespread in our signal handlers. Somebody needs to go through 'em
>> al
Hi Michael and Fujii,
Il 01/02/14 17:46, Fujii Masao ha scritto:
> I think that it's OK to add that as TODO item. There might be
> the system that the speed of WAL archiving is slower than
> that of WAL generation, at peak time. The DBA of that system
> might want to monitor the size of archive qu
On Sat, Feb 1, 2014 at 9:32 PM, Michael Paquier
wrote:
> On Wed, Jan 29, 2014 at 3:03 AM, Fujii Masao wrote:
>> On Tue, Jan 28, 2014 at 3:42 AM, Fujii Masao wrote:
>>> On Sat, Jan 25, 2014 at 3:19 PM, Michael Paquier
>>> wrote:
On Sat, Jan 25, 2014 at 5:41 AM, Fujii Masao wrote:
> On
Him
On 2014-02-01 17:03:46 +0100, Christian Kruse wrote:
> diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
> index a37e6b6..bef5912 100644
> --- a/doc/src/sgml/monitoring.sgml
> +++ b/doc/src/sgml/monitoring.sgml
> @@ -629,6 +629,16 @@ postgres: user database
> host
Hi,
While looking at a profile I noticed that non-concurrent index builds
use the page at a time mode. Since that causes more buffer lwlocks to be
taken, that's a noticeable slowdown according to a completely
unscientific hack.
The reason for not using the page at a time mode is that we only allow
On 2014-02-02 00:04:41 +0900, Michael Paquier wrote:
> On Fri, Dec 13, 2013 at 2:47 AM, Tom Lane wrote:
> > Andres Freund writes:
> >> On 2013-12-12 11:55:51 -0500, Tom Lane wrote:
> >>> I'm not, however, terribly thrilled with the suggestions to add implicit
> >>> casts associated with this type
On Fri, Dec 13, 2013 at 2:47 AM, Tom Lane wrote:
> Andres Freund writes:
>> On 2013-12-12 11:55:51 -0500, Tom Lane wrote:
>>> I'm not, however, terribly thrilled with the suggestions to add implicit
>>> casts associated with this type. Implicit casts are generally dangerous.
>
>> It's a tradeof.
Hi,
On 31/01/14 11:24, Robert Haas wrote:
> > what do you think about the approach the attached patch implements?
> > I'm not really sure if this is what you had in mind, especially if
> > this is the right lock.
>
> The attached patch seems not to be attached, […]
*sighs*
I'm at FOSDEM right no
Hi,
On 31/01/14 22:17, MauMau wrote:
> Thanks for reviewing the patch. Fixed. I'll add this revised patch to the
> CommitFest entry soon.
Looks fine for me. Set it to „waiting for commit.“
Best regards,
--
Christian Kruse http://www.2ndQuadrant.com/
PostgreSQL Development, 24
Hi,
On 01/02/14 02:45, Fujii Masao wrote:
> LOG: process 33662 still waiting for ShareLock on transaction
> 1011 after 1000.184 ms
> DETAIL: Process holding the lock: 33660. Request queue: 33662.
> [… snip …]
> LOG: process 33665 still waiting for ExclusiveLock on tuple (0,4)
> of
From: "Craig Ringer"
I'm reasonably persuaded that there's a need for this, though IFEO (see
below) can be used at or after install-time as a workaround.
I see. And I also found it effective as another workaround to set the below
registry key. This disables ASLR for all executables, so it w
On 1/31/14, 6:32 PM, Bruce Momjian wrote:
> On Mon, Oct 21, 2013 at 01:31:26PM +, Albe Laurenz wrote:
>> Bind attempts to an LDAP server should time out after two seconds,
>> allowing additional lines in the service control file to be parsed
>> (which provide a fall back to a secondary LDAP ser
On 1/31/14, 12:47 PM, Andrew Dunstan wrote:
> Hmm, looks like it got dropped. I think my original patch is probably
> about the the right thing to do, and given that it's already done by
> the MSVC build it's a bug and should be backported, as Alvaro said in
> the original discussion.
>
> I'll ge
On 2014-01-31 17:52:58 -0800, Peter Geoghegan wrote:
> On Fri, Jan 31, 2014 at 1:54 AM, Andres Freund wrote:
> > I plan to split the atomics patch into smaller chunks before
> > reposting. Imo the "Convert the PGPROC->lwWaitLink list into a dlist
> > instead of open coding it." is worth being appl
On Wed, Jan 29, 2014 at 3:03 AM, Fujii Masao wrote:
> On Tue, Jan 28, 2014 at 3:42 AM, Fujii Masao wrote:
>> On Sat, Jan 25, 2014 at 3:19 PM, Michael Paquier
>> wrote:
>>> On Sat, Jan 25, 2014 at 5:41 AM, Fujii Masao wrote:
On Thu, Jan 23, 2014 at 4:10 PM, Michael Paquier
wrote:
31.01.2014 10:59, Sawada Masahiko kirjoitti:
On Tue, Jan 21, 2014 at 7:17 AM, Oskari Saarenmaa wrote:
18.11.2013 07:53, Sawada Masahiko kirjoitti:
On 13 Nov 2013, at 20:51, Mika Eloranta wrote:
Prevent excessive progress reporting that can grow to gigabytes
of output with large databases.
The plot thickens...
Looking at the next relation I see a similar symptom of a single valid
block at the end of several segments of nuls. This relation is also a
btree on the same table and has a header in the near vicinity of the
xlog:
d9de7pcqls4ib6=# select
(page_header(get_raw_page('event_dat
On Fri, Jan 31, 2014 at 8:21 PM, Tom Lane wrote:
> So on a filesystem that supports "holes"
> in files, I'd expect that the added segments would be fully allocated
> if XLogReadBufferExtended did the deed, but they'd be quite small if
> _mdfd_getseg did so. The du results you started with sugges
I thought I'd try out what I was in an immediate position to do
without having access to dedicated multi-socket hardware: A benchmark
on AWS. This was a "c3.8xlarge" instance, which are reportedly backed
by Intel Xeon E5-2680 processors. Since the Intel ARK website reports
that these CPUs have 16 "
42 matches
Mail list logo
