On Thu, June 25, 2015 06:14, Michael Paquier wrote:
>
> I have developed a patch to improve log capture of the TAP tests by
> being able to collect stderr and stdout output of each command run in
> the tests by using more extensively IPC::Run::run (instead of system()
IPC::Run is not in perl core
On Thu, Jun 25, 2015 at 3:59 PM, Erik Rijkers wrote:
> IPC::Run is not in perl core and will not always be available.
> It looks like this patch doesn't take this into account (when no IPC::Run
> skip the test or whatever)
> Shouldn't that be changed?
Yes, there have been discussions on the matt
> On 06/23/2015 04:44 PM, Tom Lane wrote:
>> Chasing a problem identified by my Salesforce colleagues led me to the
>> conclusion that my commit f3b5565dd ("Use a safer method for determining
>> whether relcache init file is stale") is rather borked. It causes
>> pg_trigger_tgrelid_tgname_index to
On Tue, Jun 23, 2015 at 2:33 AM, Robert Haas wrote:
>
> On Mon, Jun 22, 2015 at 4:40 PM, Merlin Moncure
wrote:
> > Instead of changing the column, can't we add a new one? Adjusting
> > columns in PSA requires the innumerable queries written against it to
> > be adjusted along with all the wiki i
On 2015-06-25 16:07:45 +0530, Amit Kapila wrote:
> On Tue, Jun 23, 2015 at 2:33 AM, Robert Haas wrote:
> > If people feel strongly about backward compatibility, yes, we can do
> > that. However, if waiting continues to mean "on a heavyweight lock"
> > for backward compatibility, then you could so
On Thu, Jun 25, 2015 at 4:16 PM, Andres Freund wrote:
>
> On 2015-06-25 16:07:45 +0530, Amit Kapila wrote:
> > On Tue, Jun 23, 2015 at 2:33 AM, Robert Haas
wrote:
> > > If people feel strongly about backward compatibility, yes, we can do
> > > that. However, if waiting continues to mean "on a he
Hi all
On Thu, Jun 25, 2015 at 12:37 PM, Amit Kapila wrote:
> 2. Add 2 new columns to pg_stat_activity
> waiting_resource - true for waits other heavy wait locks, false
>otherwise
> wait_event - description code for the wait event
>
> 3. Add new view 'pg_st
On 2015-06-25 16:26:39 +0530, Amit Kapila wrote:
> Won't leaving former contents as it is (until the next thing is being
> blocked) could give misleading information. Currently we mark 'waiting'
> as false as soon as Heavy Weight Lock is over, so following that way
> sounds more appropriate, is th
On Jun 24, 2015 7:40 PM, "Andres Freund" wrote:
>
> On 2015-06-24 12:57:03 -0400, Robert Haas wrote:
> > On Wed, Jun 24, 2015 at 11:11 AM, Tom Lane wrote:
> > > Andres Freund writes:
> > >> I, by now, have come to a different conclusion. I think it's time to
> > >> entirely drop the renegotiatio
On 25 June 2015 at 05:01, Michael Paquier wrote:
> On Thu, Jun 25, 2015 at 12:57 PM, Fujii Masao wrote:
> > On Thu, Jun 25, 2015 at 12:15 PM, Michael Paquier wrote:
> >> and that's actually equivalent to that in
> >> the grammar: 1(AAA,BBB,CCC).
> >
> > I don't think that they are the same. In th
On Thu, Jun 25, 2015 at 4:28 PM, Andres Freund wrote:
>
> On 2015-06-25 16:26:39 +0530, Amit Kapila wrote:
> > Won't leaving former contents as it is (until the next thing is being
> > blocked) could give misleading information. Currently we mark 'waiting'
> > as false as soon as Heavy Weight Loc
On Thu, Jun 25, 2015 at 4:28 PM, Ilya Kosmodemiansky <
ilya.kosmodemian...@postgresql-consulting.com> wrote:
>
> On Thu, Jun 25, 2015 at 12:37 PM, Amit Kapila
wrote:
> > 2. Add 2 new columns to pg_stat_activity
> > waiting_resource - true for waits other heavy wait locks, false
> >
On 2015-06-24 17:20:31 -0400, Robert Haas wrote:
> On Wed, Jun 24, 2015 at 3:49 PM, Andres Freund wrote:
> > On 2015-06-24 15:41:22 -0400, Peter Eisentraut wrote:
> >> On 6/24/15 3:13 PM, Andres Freund wrote:
> >> > Meh. The relevant branches already exist, as you can disable it today.
> >> >
> >>
On Thu, Jun 25, 2015 at 1:49 PM, Amit Kapila wrote:
>> Personally I think, that tracking waits is a not a good idea for
>> pg_stat_activity (at least in that straight-forward manner).
>
> As mentioned in the initial mail by Robert, that sometimes system becomes
> slow (either due to contention on
On 06/25/2015 03:03 PM, Andres Freund wrote:
The situation is this: We have broken code using broken code. I think we
either got to apply, darn nontrivial, fixes from
http://archives.postgresql.org/message-id/54DE6FAF.6050005%40vmware.com
or we got to cripple the options.
It's also not the first
On 6/25/15 8:03 AM, Andres Freund wrote:
> Right now if you use streaming rep over ssl, it breaks after a couple
> hundred megabytes with obscure errors.
If it's that bad, then I tend to agree we should turn it off by default.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
On Thu, Jun 25, 2015 at 6:10 PM, Ilya Kosmodemiansky <
ilya.kosmodemian...@postgresql-consulting.com> wrote:
>
> On Thu, Jun 25, 2015 at 1:49 PM, Amit Kapila
wrote:
> >> Personally I think, that tracking waits is a not a good idea for
> >> pg_stat_activity (at least in that straight-forward manner
On 6/22/15 1:37 PM, Robert Haas wrote:
> Currently, the only time we report a process as waiting is when it is
> waiting for a heavyweight lock. I'd like to make that somewhat more
> fine-grained, by reporting the type of heavyweight lock it's awaiting
> (relation, relation extension, transaction,
> Look, how many people in the world develop their own pgbench scripts?
> And how many of those aren't on this list right now, reading this
> thread? I expect I could count them on my fingers and toes.
I'm not against you break the backward compatibility of pgbench custom
scripts.
However I just
Andres Freund writes:
> On 2015-06-25 16:26:39 +0530, Amit Kapila wrote:
>> Won't leaving former contents as it is (until the next thing is being
>> blocked) could give misleading information. Currently we mark 'waiting'
>> as false as soon as Heavy Weight Lock is over, so following that way
>> s
On 2015-06-25 10:01:39 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2015-06-25 16:26:39 +0530, Amit Kapila wrote:
> >> Won't leaving former contents as it is (until the next thing is being
> >> blocked) could give misleading information. Currently we mark 'waiting'
> >> as false as soon
On 3/24/15 9:04 PM, Bruce Momjian wrote:
> psql: show proper row count in \x mode for zero-column output
>
> Also, fix pager enable selection for such cases, and other cleanups for
> zero-column output.
>
> Report by Thom Brown
>
> Branch
> --
> master
>
> Details
> ---
> http://git.po
There was agreement at the PGCon dev meeting that we should put out a
9.5alpha1 release as soon as possible, to encourage wider testing
(and that it should be called an "alpha", because people aren't convinced
it's up to beta quality yet). After a little back and forth, that release
has been set f
Andres Freund writes:
> On 2015-06-25 10:01:39 -0400, Tom Lane wrote:
>> The problem with the query analogy is that it's possible to tell whether
>> the query is active or not, by looking at the status column. We need to
>> avoid a situation where you can't tell if the wait status is current or
>
Paul A Jungwirth writes:
> I'm interested in adding GiST support for the UUID column type from
> the uuid-ossp extension. This has been requested and attempted before:
> I've used Postgres for a long time, but I've only dabbled a bit in the
> source code. So I'm curious where this change would go?
Tatsuo Ishii writes:
>>> That means that load_relcache_init_file *always* decides that the init
>>> file is busted and silently(!) ignores it. So we're taking a nontrivial
>>> hit in backend startup speed as of the last set of minor releases.
>> OK, this is pretty bad in its real performance eff
On Thu, Jun 25, 2015 at 8:06 AM, Tom Lane wrote:
> Paul A Jungwirth writes:
>> I'm interested in adding GiST support for the UUID column type
>> . . . . So I'm curious where this change would go?
> btree_gist, I'd think
Okay, thank you for your answer! I was worried about the effects of
having b
On Wed, Jun 24, 2015 at 3:36 PM, Alvaro Herrera
wrote:
>
> Fabrízio de Royes Mello wrote:
>
> > Another rebased version.
>
> There are a number of unrelated whitespace changes in this patch; also
> please update the comment on top of check_for_column_name_collision.
>
Sorry, bad merging after a p
On Thu, Jun 25, 2015 at 7:32 AM, Simon Riggs wrote:
> On 25 June 2015 at 05:01, Michael Paquier wrote:
>>
>> On Thu, Jun 25, 2015 at 12:57 PM, Fujii Masao wrote:
>> > On Thu, Jun 25, 2015 at 12:15 PM, Michael Paquier wrote:
>> >> and that's actually equivalent to that in
>> >> the grammar: 1(AAA,
Some time ago we upgraded from v. 8.4.4 to 9.4.0 and we are seeing errors in
some regression tests.
LOCATION: exec_simple_query, postgres.c:887
ERROR: 40001: could not serialize access due to read/write dependencies among
transactions
Detail can be one of these:
DETAIL: Reason code: Cance
On Wed, Jun 24, 2015 at 1:22 PM, Josh Berkus wrote:
> On 06/21/2015 01:37 PM, Fabien COELHO wrote:
> >
> >> The worst case with pgbench is that we break two people's test scripts,
> >> they read the release notes, and fix them.
> >
> > Sure, I agree that breaking pgbench custom scripts compatibil
Paul A Jungwirth writes:
> On Thu, Jun 25, 2015 at 8:06 AM, Tom Lane wrote:
>> Paul A Jungwirth writes:
>>> I'm interested in adding GiST support for the UUID column type
>>> . . . . So I'm curious where this change would go?
>> btree_gist, I'd think
> Okay, thank you for your answer! I was wo
On Thu, Jun 25, 2015 at 04:02:33PM +, BRUSSER Michael wrote:
> Some time ago we upgraded from v. 8.4.4 to 9.4.0 and we are seeing errors in
> some regression tests.
>
> LOCATION: exec_simple_query, postgres.c:887
> ERROR: 40001: could not serialize access due to read/write dependencies
> a
BRUSSER Michael writes:
> Some time ago we upgraded from v. 8.4.4 to 9.4.0 and we are seeing errors in
> some regression tests.
> LOCATION: exec_simple_query, postgres.c:887
> ERROR: 40001: could not serialize access due to read/write dependencies
> among transactions
9.1 substantially tighte
On 06/25/2015 06:15 AM, Peter Eisentraut wrote:
On 6/25/15 8:03 AM, Andres Freund wrote:
Right now if you use streaming rep over ssl, it breaks after a couple
hundred megabytes with obscure errors.
If it's that bad, then I tend to agree we should turn it off by default.
From an "in the wi
On 06/25/2015 08:12 AM, Tom Lane wrote:
> Tatsuo Ishii writes:
That means that load_relcache_init_file *always* decides that the init
file is busted and silently(!) ignores it. So we're taking a nontrivial
hit in backend startup speed as of the last set of minor releases.
>
>>> OK
On Wed, Jun 24, 2015 at 2:52 PM, Josh Berkus wrote:
> OK, this is pretty bad in its real performance effects. On a workload
> which is dominated by new connection creation, we've lost about 17%
> throughput.
Mistakes happen, but this is the kind of regression that automated
performance testing c
On 06/25/2015 10:47 AM, Peter Geoghegan wrote:
> On Wed, Jun 24, 2015 at 2:52 PM, Josh Berkus wrote:
>> OK, this is pretty bad in its real performance effects. On a workload
>> which is dominated by new connection creation, we've lost about 17%
>> throughput.
>
> Mistakes happen, but this is the
Josh Berkus writes:
> On 06/25/2015 08:12 AM, Tom Lane wrote:
>> I can't see doing a release just for this. If we were due for releases
>> anyway, sure, but we've considerably overstressed our poor packagers of
>> late. Previous discussion was to the effect that we'd anticipate another
>> set of
On Thu, Jun 25, 2015 at 8:00 AM, Tom Lane wrote:
> If there are any open 9.5 issues you can fix before Monday, please do.
I have 3 pending bug fixes for UPSERT, including 2 trivial ones. This
does not include my "minor refactoring" patch, which is not a bugfix.
The last of those 3 was posted on 2
On June 25, 2015 9:35:27 PM GMT+02:00, Peter Geoghegan wrote:
>On Thu, Jun 25, 2015 at 8:00 AM, Tom Lane wrote:
>> If there are any open 9.5 issues you can fix before Monday, please
>do.
>
>I have 3 pending bug fixes for UPSERT, including 2 trivial ones. This
>does not include my "minor refactori
On Thu, Jun 25, 2015 at 12:39 PM, Andres Freund wrote:
> It'd have been easier if you'd done it the way I asked. This way I have to
> look much closer...
Well, I actually prototyped your approach to that and decided against
it only after having gone to the trouble of doing so. In any case, I
thi
Patch reviewed following the instructions on
https://wiki.postgresql.org/wiki/Reviewing_a_Patch
# Submission review
- Is the patch in a patch format which has context?
Yes. Note to other reviewers: `git diff —patience` yields patch better
suited for readability
- Does it apply cleanly to the curr
On 06/25/2015 11:04 AM, Tom Lane wrote:
> Josh Berkus writes:
>> On 06/25/2015 08:12 AM, Tom Lane wrote:
>>> I can't see doing a release just for this. If we were due for releases
>>> anyway, sure, but we've considerably overstressed our poor packagers of
>>> late. Previous discussion was to the
On Thu, May 21, 2015 at 11:47 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> On Fri, May 15, 2015 at 4:15 PM, Alvaro Herrera
>> wrote:
>> >> Really? I was thinking of the test code as throwaway. I just wanted
>> >> to fix the bug.
>> >
>> > Oh, that's fine then. I thought you wanted to push
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane
> Sent: Friday, June 26, 2015 12:00 AM
> To: pgsql-hackers@postgreSQL.org
> Subject: [HACKERS] Schedule for 9.5alpha1
>
> There was agreement at the PGCon dev
On Thu, Jun 25, 2015 at 3:25 PM, Kouhei Kaigai wrote:
> It is nearly obvious problem, and bugfix patch already exists.
My current strategy is to post these items on the "PostgreSQL 9.5 Open
Items" page, even when the issue is totally trivial -- maybe that
makes a small difference, even if it some
On Fri, Jun 26, 2015 at 8:03 AM, Peter Geoghegan wrote:
> On Thu, Jun 25, 2015 at 3:25 PM, Kouhei Kaigai wrote:
>> It is nearly obvious problem, and bugfix patch already exists.
>
> My current strategy is to post these items on the "PostgreSQL 9.5 Open
> Items" page, even when the issue is totall
On Thu, Jun 25, 2015 at 10:51 PM, Tatsuo Ishii wrote:
>> Look, how many people in the world develop their own pgbench scripts?
>> And how many of those aren't on this list right now, reading this
>> thread? I expect I could count them on my fingers and toes.
>
> I'm not against you break the back
>> I'm not against you break the backward compatibility of pgbench custom
>> scripts.
>>
>> However I just want to let you know that PostgreSQL Enterprise
>> Consortium has been published couple of scripts along with reports on
>> evaluating PostgreSQL, which have been downloaded considerable
>> nu
On Wed, Jun 24, 2015 at 3:50 PM, Peter Eisentraut wrote:
> On 6/24/15 12:55 PM, Robert Haas wrote:
>>> FWIW, I have been doing that, and I have not considered it a problem.
>>> If the patch was submitted three months ago, reviewed, and then
>>> committed unchanged, the date is what it is. Also, w
On Thu, Jun 25, 2015 at 4:30 PM, Michael Paquier
wrote:
>> I'm tired of having to chase down known bugs when a patch has been
>> around for a long time, and an actual fix is blocking on committer
>> availability -- sometimes I feel the need to privately twist someone's
>> arm just to get something
On Fri, Jun 26, 2015 at 9:01 AM, Tatsuo Ishii wrote:
>>> I'm not against you break the backward compatibility of pgbench custom
>>> scripts.
>>>
>>> However I just want to let you know that PostgreSQL Enterprise
>>> Consortium has been published couple of scripts along with reports on
>>> evaluati
On Thu, Jun 25, 2015 at 8:20 PM, Tom Lane wrote:
>
> Andres Freund writes:
> > On 2015-06-25 10:01:39 -0400, Tom Lane wrote:
> >> The problem with the query analogy is that it's possible to tell
whether
> >> the query is active or not, by looking at the status column. We need
to
> >> avoid a sit
BRIN index WAL is broken in HEAD.
Commit 2c03216d831160bedd72d4, the Revamp the WAL record format, is the
culprit.
The easiest way to see this is via streaming replication.
On master:
create table foobar as select * from generate_series(1,1);
create index on foobar using brin (generate_seri
Jeff Janes wrote:
> BRIN index WAL is broken in HEAD.
Thanks for all the details. Looking into it.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
On 06/25/2015 05:09 PM, Peter Geoghegan wrote:
On Thu, Jun 25, 2015 at 4:30 PM, Michael Paquier
wrote:
I'm tired of having to chase down known bugs when a patch has been
around for a long time, and an actual fix is blocking on committer
availability -- sometimes I feel the need to privately t
On Thu, Jun 25, 2015 at 6:46 AM, Andres Freund wrote:
>> 1. Remove/Change 'waiting' in pg_stat_activity and break the backward
>> compatibility. I think we should try to avoid going via this route.
>>
>> 2. Add 2 new columns to pg_stat_activity
>> waiting_resource - true for waits other heavy
On Thu, Jun 25, 2015 at 6:58 AM, Ilya Kosmodemiansky
wrote:
> 1. Some sort of histogram of top waits within entire database by pid.
> That will be an approximate one, because I hardly believe there is a
> possibility to make a precise one without significant overhead.
You could compute that his
On Thu, Jun 25, 2015 at 9:23 AM, Peter Eisentraut wrote:
> On 6/22/15 1:37 PM, Robert Haas wrote:
>> Currently, the only time we report a process as waiting is when it is
>> waiting for a heavyweight lock. I'd like to make that somewhat more
>> fine-grained, by reporting the type of heavyweight l
On Fri, 26 Jun 2015 at 06:03 Gurjeet Singh wrote:
> Patch reviewed following the instructions on
> https://wiki.postgresql.org/wiki/Reviewing_a_Patch
>
>
Thank you for your review, Gurjeet.
> s/proportion/fraction/
>
I think of these as synonymous -- do you have any particular reason to
prefe
On Thu, Jun 25, 2015 at 6:25 PM, Kouhei Kaigai wrote:
> I have a serious open item reported 1.5 month ago then reminded
> several times has not been fixed up yet.
>
> 9a28c8860f777e439aa12e8aea7694f8010f3...@bpxm15gp.gisp.nec.co.jp
>
> Patch is less than 100 lines, entirely designed according to T
On Fri, Jun 26, 2015 at 9:01 AM, Robert Haas wrote:
>
> On Thu, Jun 25, 2015 at 6:46 AM, Andres Freund wrote:
> >> 1. Remove/Change 'waiting' in pg_stat_activity and break the backward
> >> compatibility. I think we should try to avoid going via this route.
> >>
> >> 2. Add 2 new columns to pg_s
On Thu, Jun 25, 2015 at 8:32 PM, Simon Riggs wrote:
> Let's start with a complex, fully described use case then work out how to
> specify what we want.
Well, one of the most simple cases where quorum commit and this
feature would be useful for is that, with 2 data centers:
- on center 1, master A
Hi,
On 2015-06-26 AM 12:49, Sawada Masahiko wrote:
> On Thu, Jun 25, 2015 at 7:32 AM, Simon Riggs wrote:
>>
>> Let's start with a complex, fully described use case then work out how to
>> specify what we want.
>>
>> I'm nervous of "it would be good ifs" because we do a ton of work only to
>> fin
On Fri, Jun 26, 2015 at 2:59 PM, Amit Langote wrote:
> Do we really need to add a number like '1' in '1(a, b), c, d'?
> The order of writing names already implies priorities like 2 & 3 for c & d,
> respectively, like in your example. Having to write '1' for the group '(a, b)'
> seems unnecessary, I
On 2015-06-26 PM 02:59, Amit Langote wrote:
> On 2015-06-26 AM 12:49, Sawada Masahiko wrote:
>>
>> For example,
>> - s_s_name = '1(a, b), c, d'
>> The priority of both 'a' and 'b' are 1, and 'c' is 2, 'd' is 3.
>> i.g, 'b' and 'c' are potential sync node, and the quorum commit is
>> enable only bet
Hi all
Attached is a patch to implement ALTER TABLE ... ALTER CONSTRAINT ...
SET DEFERRABLE on UNIQUE or PRIMARY KEY constraints.
Currently only FOREIGN KEY constraints are supported. Others are rejected with:
constraint \"%s\" of relation \"%s\" is not a foreign key constraint
The patch also a
68 matches
Mail list logo
