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 and
On June 25, 2015 9:35:27 PM GMT+02:00, Peter Geoghegan p...@heroku.com wrote:
On Thu, Jun 25, 2015 at 8:00 AM, Tom Lane t...@sss.pgh.pa.us 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
On Thu, Jun 25, 2015 at 12:39 PM, Andres Freund and...@anarazel.de 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.
On 06/25/2015 11:04 AM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com 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
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
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 amit.kapil...@gmail.com
wrote:
2. Add 2 new columns to pg_stat_activity
waiting_resource - true for waits other heavy wait locks, false
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
On 2015-06-25 16:07:45 +0530, Amit Kapila wrote:
On Tue, Jun 23, 2015 at 2:33 AM, Robert Haas robertmh...@gmail.com 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
On 25 June 2015 at 05:01, Michael Paquier michael.paqu...@gmail.com 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
On Thu, Jun 25, 2015 at 1:49 PM, Amit Kapila amit.kapil...@gmail.com 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
On Tue, Jun 23, 2015 at 2:33 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jun 22, 2015 at 4:40 PM, Merlin Moncure mmonc...@gmail.com
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
On Thu, Jun 25, 2015 at 4:16 PM, Andres Freund and...@anarazel.de wrote:
On 2015-06-25 16:07:45 +0530, Amit Kapila wrote:
On Tue, Jun 23, 2015 at 2:33 AM, Robert Haas robertmh...@gmail.com
wrote:
If people feel strongly about backward compatibility, yes, we can do
that. However, if
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 there
Hi all
On Thu, Jun 25, 2015 at 12:37 PM, Amit Kapila amit.kapil...@gmail.com 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.
On Jun 24, 2015 7:40 PM, Andres Freund and...@anarazel.de wrote:
On 2015-06-24 12:57:03 -0400, Robert Haas wrote:
On Wed, Jun 24, 2015 at 11:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@anarazel.de writes:
I, by now, have come to a different conclusion. I think it's
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
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 amit.kapil...@gmail.com
wrote:
Personally I think, that tracking waits is a not a good idea for
pg_stat_activity (at least in that
On Thu, Jun 25, 2015 at 4:28 PM, Andres Freund and...@anarazel.de 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
On 2015-06-24 17:20:31 -0400, Robert Haas wrote:
On Wed, Jun 24, 2015 at 3:49 PM, Andres Freund and...@anarazel.de 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 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
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,
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
On Thu, Jun 25, 2015 at 8:00 AM, Tom Lane t...@sss.pgh.pa.us 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
On Thu, May 21, 2015 at 11:47 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Robert Haas wrote:
On Fri, May 15, 2015 at 4:15 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Really? I was thinking of the test code as throwaway. I just wanted
to fix the bug.
Oh, that's fine then.
On Thu, Jun 25, 2015 at 7:32 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 25 June 2015 at 05:01, Michael Paquier michael.paqu...@gmail.com 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
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
On Wed, Jun 24, 2015 at 3:36 PM, Alvaro Herrera alvhe...@2ndquadrant.com
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
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
---
Paul A Jungwirth p...@illuminatedcomputing.com 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
Tatsuo Ishii is...@postgresql.org 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
Andres Freund and...@anarazel.de 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
On 2015-06-25 10:01:39 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de 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
Andres Freund and...@anarazel.de 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
On Thu, Jun 25, 2015 at 8:06 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Paul A Jungwirth p...@illuminatedcomputing.com 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
On 06/25/2015 08:12 AM, Tom Lane wrote:
Tatsuo Ishii is...@postgresql.org 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.
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
among
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
On Wed, Jun 24, 2015 at 1:22 PM, Josh Berkus j...@agliodbs.com 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
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:
Paul A Jungwirth p...@illuminatedcomputing.com writes:
On Thu, Jun 25, 2015 at 8:06 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Paul A Jungwirth p...@illuminatedcomputing.com writes:
I'm interested in adding GiST support for the UUID column type
. . . . So I'm curious where this change would go?
BRUSSER Michael michael.brus...@3ds.com 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
On Wed, Jun 24, 2015 at 2:52 PM, Josh Berkus j...@agliodbs.com 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
Josh Berkus j...@agliodbs.com 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
On 06/25/2015 10:47 AM, Peter Geoghegan wrote:
On Wed, Jun 24, 2015 at 2:52 PM, Josh Berkus j...@agliodbs.com 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
On Fri, Jun 26, 2015 at 8:03 AM, Peter Geoghegan p...@heroku.com wrote:
On Thu, Jun 25, 2015 at 3:25 PM, Kouhei Kaigai kai...@ak.jp.nec.com 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,
-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 kai...@ak.jp.nec.com 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
On Thu, Jun 25, 2015 at 6:58 AM, Ilya Kosmodemiansky
ilya.kosmodemian...@postgresql-consulting.com 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
On Thu, Jun 25, 2015 at 9:23 AM, Peter Eisentraut pete...@gmx.net 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
On 06/25/2015 05:09 PM, Peter Geoghegan wrote:
On Thu, Jun 25, 2015 at 4:30 PM, Michael Paquier
michael.paqu...@gmail.com 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
On Fri, 26 Jun 2015 at 06:03 Gurjeet Singh gurj...@singh.im 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
On Fri, Jun 26, 2015 at 9:01 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jun 25, 2015 at 6:46 AM, Andres Freund and...@anarazel.de 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.
On Thu, Jun 25, 2015 at 6:46 AM, Andres Freund and...@anarazel.de 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
On Thu, Jun 25, 2015 at 6:25 PM, Kouhei Kaigai kai...@ak.jp.nec.com 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
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
numbers.
On Wed, Jun 24, 2015 at 3:50 PM, Peter Eisentraut pete...@gmx.net 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.
On Thu, Jun 25, 2015 at 4:30 PM, Michael Paquier
michael.paqu...@gmail.com 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
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
On Thu, Jun 25, 2015 at 10:51 PM, Tatsuo Ishii is...@postgresql.org 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
On Fri, Jun 26, 2015 at 9:01 AM, Tatsuo Ishii is...@postgresql.org 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
On Thu, Jun 25, 2015 at 8:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@anarazel.de 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.
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
On Thu, Jun 25, 2015 at 12:15 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Wed, Jun 24, 2015 at 11:30 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, May 15, 2015 at 9:18 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Fri, May 15, 2015 at 8:55 PM, Beena Emerson
Hi KaiGai-san,
I'd like to work on this issue with you!
On 2015/06/25 10:48, Kouhei Kaigai wrote:
I'd like to suggest a solution that re-construct remote tuple according
to the fdw_scan_tlist on ExecScanFetch, if given scanrelid == 0.
It enables to run local qualifier associated with the
On Thu, Jun 25, 2015 at 3:59 PM, Erik Rijkers e...@xs4all.nl 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 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 be
66 matches
Mail list logo
