Hi,
On 2015-06-26 AM 12:49, Sawada Masahiko wrote:
On Thu, Jun 25, 2015 at 7:32 AM, Simon Riggs si...@2ndquadrant.com 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
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 adds
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 between 'a' and
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, IMHO.
On 26 June 2015 at 07:20, Craig Ringer cr...@2ndquadrant.com wrote:
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:
+1
I was
Hi,
On 2015-06-25 PM 01: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 the case of
On Fri, Jun 26, 2015 at 5:04 PM, Amit Langote
langote_amit...@lab.ntt.co.jp wrote:
Hi,
On 2015-06-25 PM 01: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
I configured the dingo and binturong Solaris 10 animals to build 9.3
some time ago but apparently they always failed the configure phase.
Turns out this is caused by thread_test's usage of sched_yield which is
in librt on Solaris but which is not pulled in by anything on 9.3 and
earlier on my box.
On Wed, Jun 24, 2015 at 4:53 AM, Peter Geoghegan p...@heroku.com wrote:
On Wed, Jun 24, 2015 at 1:45 AM, Craig Ringer cr...@2ndquadrant.com wrote:
WARNING: hash indexes are not crash-safe, not replicated, and their
use is discouraged
+1
I'm not wild about this rewording; I think that if
I looked into bug #13471, which states that we gripe about multiple
occurrences of the same variable in postgresql.conf + related files.
Now, that had clearly been fixed some time ago:
Author: Fujii Masao fu...@postgresql.org
Branch: master [e3da0d4d1] 2014-08-06 14:49:43 +0900
Branch:
On Wed, Jun 24, 2015 at 6:47 PM, Peter Geoghegan p...@heroku.com wrote:
On Sun, Jun 14, 2015 at 2:08 PM, Peter Geoghegan p...@heroku.com wrote:
Really? The pre-check thing wasn't too complex for Magnus to have a
couple of bullet points on it *specifically* in his high level NYC
talk on
On Thu, Jun 25, 2015 at 12:09 AM, Amit Langote
langote_amit...@lab.ntt.co.jp wrote:
On 2015-06-11 PM 01:15, Bruce Momjian wrote:
I have committed the first draft of the 9.5 release notes. You can view
the output here:
http://momjian.us/pgsql_docs/release-9-5.html
and it will
Robert Haas robertmh...@gmail.com writes:
On Fri, Jun 26, 2015 at 10:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I agree that the correct handling of this particular case is to mark it
as not-a-bug. We have better things to do.
Well, I find that a disappointing conclusion, but I'm not going to
On Fri, Jun 26, 2015 at 7:08 AM, Heikki Linnakangas hlinn...@iki.fi wrote:
I'm not sure what to do about this. With the attached patch, you get the
same leisurely pacing with restartpoints as you get with checkpoints, but
you exceed max_wal_size during recovery, by the amount determined by
On Tue, Jun 23, 2015 at 1:31 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
I tracked the dangerous -rf to come from Makefile.global and it's empty
string being due to abs_top_builddir not being define in my own Makefile.
But beside that, which I can probably fix, it doesn't sound correct
On Thu, Jun 25, 2015 at 11:55 PM, Robert Haas robertmh...@gmail.com wrote:
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.
On Fri, Jun 26, 2015 at 11:22 AM, Uriy Zhuravlev u.zhurav...@postgrespro.ru
wrote:
Hello hackers.
I found a strange thing. I hope it's not on purpose.
Example:
git clone git://git.postgresql.org/git/postgresql.git
cd postgresql
git checkout -b remotes/origin/REL9_4_STABLE
git merge
On Fri, Jun 26, 2015 at 1:46 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
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
On Wed, Jun 24, 2015 at 3:06 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Wed, Jun 24, 2015 at 12:27 AM, Robert Haas wrote:
I think you should be testing RelationNeedsWAL(), not the
relpersistence directly. The same point applies for temporary
indexes.
Indeed. Patch updated
On Fri, Jun 26, 2015 at 7:13 AM, Heikki Linnakangas hlinn...@iki.fi wrote:
On 06/24/2015 11:11 PM, Jeff Janes wrote:
Is there a way to implement triConsistent for only some of the strategy
numbers?
No.
It looks like I would have to internally re-implement something like
On Fri, Jun 26, 2015 at 9:49 AM, Andres Freund and...@anarazel.de wrote:
On 2015-06-26 09:44:14 -0400, Robert Haas wrote:
I don't mind committing patches for this kind of thing if it makes the
Coverity reports easier to deal with, which I gather that it does.
It takes about three seconds to
On 06/24/2015 11:11 PM, Jeff Janes wrote:
Is there a way to implement triConsistent for only some of the strategy
numbers?
No.
It looks like I would have to internally re-implement something like
shimTriConsistentFn for each strategy number for which I don't want to
implement the ternary
Robert Haas robertmh...@gmail.com writes:
On Fri, Jun 26, 2015 at 9:49 AM, Andres Freund and...@anarazel.de wrote:
It takes about three seconds to mark it as ignored which will hide it
going forward.
So what? That doesn't help if someone *else* sets up a Coverity run
on this code base, or
On Wed, Jun 24, 2015 at 5:53 PM, Peter Geoghegan p...@heroku.com wrote:
I worry that 8.14.3. jsonb Containment and Existence is not
sufficiently clear in explaining that jsonb containment is nested.
I've seen anecdata suggesting that this is unclear to users. We do
say:
The general
Hello hackers.
I found a strange thing. I hope it's not on purpose.
Example:
git clone git://git.postgresql.org/git/postgresql.git
cd postgresql
git checkout -b remotes/origin/REL9_4_STABLE
git merge master
MANY CONFLICTS
Why?
Thanks.
--
Uriy Zhuravlev
Postgres Professional:
On Fri, Jun 26, 2015 at 11:22 AM, Uriy Zhuravlev
u.zhurav...@postgrespro.ru wrote:
Hello hackers.
I found a strange thing. I hope it's not on purpose.
Example:
git clone git://git.postgresql.org/git/postgresql.git
cd postgresql
git checkout -b remotes/origin/REL9_4_STABLE
This is an
Il 26/06/15 15:43, marco.nenciar...@2ndquadrant.it ha scritto:
The following bug has been logged on the website:
Bug reference: 13473
Logged by: Marco Nenciarini
Email address: marco.nenciar...@2ndquadrant.it
PostgreSQL version: 9.4.4
Operating system: all
On Fri, Jun 26, 2015 at 9:59 AM, Andres Freund and...@anarazel.de wrote:
Generally I'd agree that that is a bad thing. But there's really not
much of a observable behaviour change in this case? Except that
connections using ssl break less often.
Well, SSL renegotiation exists for a reason: to
Robert Haas robertmh...@gmail.com writes:
On Fri, Jun 26, 2015 at 9:59 AM, Andres Freund and...@anarazel.de wrote:
Generally I'd agree that that is a bad thing. But there's really not
much of a observable behaviour change in this case? Except that
connections using ssl break less often.
On 2015-06-26 10:26:58 -0400, Robert Haas wrote:
On Fri, Jun 26, 2015 at 9:59 AM, Andres Freund and...@anarazel.de wrote:
Generally I'd agree that that is a bad thing. But there's really not
much of a observable behaviour change in this case? Except that
connections using ssl break less
On Thu, Jun 25, 2015 at 8:03 AM, Andres Freund and...@anarazel.de wrote:
I don't accept the argument that there are not ways to tell users
about things they might want to do.
We probably could do that. But why would we want to? It's just as much
work, and puts the onus on more people?
On 2015-06-26 09:53:30 -0400, Robert Haas wrote:
On Thu, Jun 25, 2015 at 8:03 AM, Andres Freund and...@anarazel.de wrote:
I don't accept the argument that there are not ways to tell users
about things they might want to do.
We probably could do that. But why would we want to? It's just as
On Wed, Jun 24, 2015 at 7:30 AM, Uriy Zhuravlev
u.zhurav...@postgrespro.ru wrote:
Because change the commutator and negator raised questions I suggest 3 version
of the patch without them. In addition, for us now is much more important
restrict and join (for Selectivity estimation for intarray
On 06/26/2015 04:53 PM, Robert Haas wrote:
On Thu, Jun 25, 2015 at 8:03 AM, Andres Freund and...@anarazel.de wrote:
I don't accept the argument that there are not ways to tell users
about things they might want to do.
We probably could do that. But why would we want to? It's just as much
On Fri, Jun 26, 2015 at 9:47 AM, Heikki Linnakangas hlinn...@iki.fi wrote:
On 06/26/2015 03:40 PM, Robert Haas wrote:
Actually, I've seen a number of presentations indicating
that the pacing of checkpoints is already too aggressive near the
beginning, because as soon as we initiate the
On Fri, Jun 26, 2015 at 10:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jun 26, 2015 at 9:49 AM, Andres Freund and...@anarazel.de wrote:
It takes about three seconds to mark it as ignored which will hide it
going forward.
So what? That doesn't
On Wed, Jun 24, 2015 at 7:39 PM, Jim Nasby jim.na...@bluetreble.com wrote:
I think it's a whole separate topicto Pavel's original proposal
though, and really merits a separate thread. For Pavel's issue I'm all
in favour of just changing the log message, I think LOG is way too
high for
Under high load against f7bb7f0625771bc71869cda, I occasionally get:
PANIC: XLogBeginInsert was not called
It seems to only come from vacuuming.
Here is an example back-trace:
#0 0x003dcb632625 in raise () from /lib64/libc.so.6
#1 0x003dcb633e05 in abort () from /lib64/libc.so.6
#2
On Fri, Jun 26, 2015 at 11:29 AM, Robert Haas robertmh...@gmail.com wrote:
OK, but how about this wording instead?
That seems fine.
BTW, shouldn't Andrew also be credited here, since he did the work on
datum sorts?
Andrew's work was entirely confined to making datum sorts work with
Bruce Momjian wrote:
I have run a script to count the number of listitem items in the
major release notes of each major version of Postgres back to 7.4:
7.4280
8.0238
8.1187
8.2230
8.3237
8.4330
9.0252
9.1
On Fri, Jun 26, 2015 at 9:29 AM, Robert Haas robertmh...@gmail.com wrote:
Can you put your suggestions here in the form of a patch to the release notes?
The attached patch generalizes from the 9.2 release note wording. I
use the word inlined here too, even though commit 5ea86e6e6 did not
do too
On Fri, Jun 26, 2015 at 1:12 PM, Josh Berkus j...@agliodbs.com wrote:
This really feels like we're going way beyond what we want a single
string GUC. I feel that this feature, as outlined, is a terrible hack
which we will regret supporting in the future. You're taking something
which was
On 06/26/2015 11:32 AM, Robert Haas wrote:
I think your proposal is worth considering, but you would need to fill
in a lot more details and explain how it works in detail, rather than
just via a set of example function calls. The GUC-based syntax
proposal covers cases like multi-level rules
On Fri, Jun 26, 2015 at 2:01 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Robert Haas wrote:
On Thu, Jun 25, 2015 at 12:09 AM, Amit Langote
langote_amit...@lab.ntt.co.jp wrote:
Is it intentional that the following items are separate?
[...]
Or could they made into one item?
I
On Fri, Jun 26, 2015 at 10:54 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, if you find this to be good code cleanup on its own merits,
you have a commit bit, you can go commit it. I'm just saying that
Coverity is not a good judge of code readability and even less of
a judge of likely future
This needs more performance testing.
Definitely. I may do that some day. However I'm not sure that this is
currently the main issue in the checkpointer.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 06/26/2015 09:42 AM, Robert Haas wrote:
On Fri, Jun 26, 2015 at 1:46 AM, Michael Paquier
That's where the micro-language idea makes sense to use. For example,
we can define a group using separators and like (elt1,...eltN) or
[elt1,elt2,eltN]. Appending a number in front of a group is
Robert Haas wrote:
On Thu, Jun 25, 2015 at 12:09 AM, Amit Langote
langote_amit...@lab.ntt.co.jp wrote:
Is it intentional that the following items are separate?
[...]
Or could they made into one item?
I think one item would be fine.
I suggested the same a couple of weeks ago.
--
On Fri, Jun 26, 2015 at 2:25 PM, Peter Geoghegan p...@heroku.com wrote:
On Fri, Jun 26, 2015 at 9:29 AM, Robert Haas robertmh...@gmail.com wrote:
Can you put your suggestions here in the form of a patch to the release
notes?
The attached patch generalizes from the 9.2 release note wording. I
Jeff Janes wrote:
On replica:
set enable_seqscan TO off;
explain (analyze) select count(*) from foobar ;
ERROR: corrupted BRIN index: inconsistent range map
Nice. As I understand it, the problem is that the replay is using the
block number of the revmap page as target blkno of the revmap
On 06/26/2015 08:02 PM, Jeff Janes wrote:
Under high load against f7bb7f0625771bc71869cda, I occasionally get:
PANIC: XLogBeginInsert was not called
It seems to only come from vacuuming.
Here is an example back-trace:
#0 0x003dcb632625 in raise () from /lib64/libc.so.6
#1
Andres Freund wrote:
Rework the way multixact truncations work.
I spent some time this morning reviewing this patch and had some
comments that I relayed over IM to Andres. The vast majority is
cosmetic, but there are two larger things:
1. I think this part of PerformMembersTruncation() is
On Fri, Jun 26, 2015 at 11:09 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Maybe there's a reasonable way to measure releases (my 8.0 is bigger
than your 9.1!), but I don't think this is it.
I agree with the sentiment, but I don't think that anyone actually
thinks of it that way. Most
On Fri, Jun 26, 2015 at 7:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I agree that the correct handling of this particular case is to mark it
as not-a-bug. We have better things to do.
+1
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Andres Freund and...@anarazel.de writes:
On 2015-06-24 16:41:48 +0200, Andres Freund wrote:
I, by now, have come to a different conclusion. I think it's time to
entirely drop the renegotiation support.
I think by now we essentially concluded that we should do that. What I'm
not sure yet is
Jeff Janes wrote:
The way the blkno and buffer refer to different block/buffers is pretty
confusing. Could we rename a variable to make it clearer which buffer's
number is contained in blkno?
Sure thing. Pushed that way.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
On 2015-06-24 16:41:48 +0200, Andres Freund wrote:
I, by now, have come to a different conclusion. I think it's time to
entirely drop the renegotiation support.
I think by now we essentially concluded that we should do that. What I'm
not sure yet is how: Do we want to rip it out in master and
On Mon, Jun 15, 2015 at 2:52 PM, Amit Kapila amit.kapil...@gmail.com wrote:
Attached patch provides a fix as per above discussion.
I think we should emit some LOG messages here. When we detect the
file is there:
LOG: ignoring tablespace_map file because no backup_label file exists
If the
On 6/25/15 8:08 PM, Robert Haas wrote:
Because I don't want to have to do git log --format=fuller to see when
the thing was committed, basically.
Then I suggest to you the following configuration settings:
[format]
pretty=cmedium
[pretty]
cmedium=format:%C(auto,yellow)commit
On Wed, Jun 24, 2015 at 9:41 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Wed, Jun 24, 2015 at 3:43 PM, Michael Paquier wrote:
I just realized another problem: We recently learned the hard way that some
people have files in the data directory that are not writeable by the
'postgres'
On Fri, Jun 26, 2015 at 3:10 PM, Andres Freund and...@anarazel.de wrote:
On 2015-06-26 15:07:59 -0400, Robert Haas wrote:
I realize that the recent fsync fiasco demonstrated that people keep
files not readable by PG in the data directory
It wasn't unreadable files that were the primary
On 2015-06-26 15:07:59 -0400, Robert Haas wrote:
I realize that the recent fsync fiasco demonstrated that people keep
files not readable by PG in the data directory
It wasn't unreadable files that were the primary problem, it was files
with read only permissions, no?
oops, I can't read this,
On Fri, Jun 26, 2015 at 3:09 PM, Andres Freund and...@anarazel.de wrote:
On 2015-06-24 16:41:48 +0200, Andres Freund wrote:
I, by now, have come to a different conclusion. I think it's time to
entirely drop the renegotiation support.
I think by now we essentially concluded that we should
On 6/25/15 11:39 PM, Robert Haas wrote:
Could that also cover waiting on network?
Possibly. My approach requires that the number of wait states be kept
relatively small, ideally fitting in a single byte. And it also
requires that we insert pgstat_report_waiting() calls around the thing
On Fri, Jun 26, 2015 at 4:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Combining this with my idea about preserving the ConfigVariable list,
I'm thinking that it would be a good idea for ProcessConfigFile() to
run in a context created for the purpose of processing the config files,
rather than
On Fri, Jun 26, 2015 at 3:52 AM, Oskari Saarenmaa o...@ohmu.fi wrote:
I configured the dingo and binturong Solaris 10 animals to build 9.3
some time ago but apparently they always failed the configure phase.
Turns out this is caused by thread_test's usage of sched_yield which is
in librt on
On Fri, Jun 26, 2015 at 11:35 AM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Jeff Janes wrote:
On replica:
set enable_seqscan TO off;
explain (analyze) select count(*) from foobar ;
ERROR: corrupted BRIN index: inconsistent range map
Nice. As I understand it, the problem is
On 2015-06-26 15:36:53 -0400, David G. Johnston wrote:
On Fri, Jun 26, 2015 at 3:09 PM, Andres Freund and...@anarazel.de wrote:
On 2015-06-24 16:41:48 +0200, Andres Freund wrote:
I, by now, have come to a different conclusion. I think it's time to
entirely drop the renegotiation
On 2015-06-26 21:47:30 +0200, Fabien COELHO wrote:
tps stddev full speed:
HEAD OFF/OFF
tiny 1 client 727 +- 227 221 +- 246
Huh?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Wed, Jun 10, 2015 at 3:34 AM, Amit Kapila amit.kapil...@gmail.com wrote:
Okay, I have updated the patch to destroy_tablespace_directories() code
as well in the attached patch. I have tried to modify
remove_tablespace_symlink(), so that it can be called from
destroy_tablespace_directories(),
I wrote:
The simplest change would be to move the whole thing to around line 208 in
guc-file.l, just after the stanza that loads PG_AUTOCONF_FILENAME. Or you
could argue that the approach is broken altogether, and that we should
capture the data while we read the files, so that you have some
On Fri, Jun 26, 2015 at 2:37 PM, Peter Geoghegan p...@heroku.com wrote:
On Fri, Jun 26, 2015 at 11:29 AM, Robert Haas robertmh...@gmail.com wrote:
OK, but how about this wording instead?
That seems fine.
BTW, shouldn't Andrew also be credited here, since he did the work on
datum sorts?
Note that I'm not comparing to HEAD in the above tests, but with the new
options desactivated, which should be more or less comparable to current
HEAD, i.e. there is no sorting nor flushing done, but this is not strictly
speaking HEAD behavior. Probably I should get some figures with HEAD as
On Fri, Jun 26, 2015 at 11:40 AM, Heikki Linnakangas hlinn...@iki.fi
wrote:
On 06/26/2015 08:02 PM, Jeff Janes wrote:
Under high load against f7bb7f0625771bc71869cda, I occasionally get:
PANIC: XLogBeginInsert was not called
It seems to only come from vacuuming.
Here is an example
Hello Andres,
HEAD OFF/OFF
tiny 1 client 727 +- 227 221 +- 246
Huh?
Indeed, just to check that someone was reading this magnificent mail:-)
Just a typo because I reformated the figures for simpler comparison. 221
is really 721, quite
On Fri, Jun 26, 2015 at 4:11 PM, Peter Eisentraut pete...@gmx.net wrote:
On 6/25/15 8:08 PM, Robert Haas wrote:
Because I don't want to have to do git log --format=fuller to see when
the thing was committed, basically.
Then I suggest to you the following configuration settings:
[format]
I spent much of today going through here:
https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items
Here's what I did:
* Committed patches for four of the items, hopefully resolving those items.
* Moved three items from open to either resolved or a new section
don't need fixing.
* Added
On Fri, Jun 26, 2015 at 3:39 PM, Peter Geoghegan p...@heroku.com wrote:
On Wed, Jun 10, 2015 at 9:15 PM, Bruce Momjian br...@momjian.us wrote:
I am ready to make suggested adjustments
Also, I attach a new description of the UPSERT feature. For me, UPSERT
was always about guarantees that make
On Sat, Jun 27, 2015 at 1:32 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jun 10, 2015 at 3:34 AM, Amit Kapila amit.kapil...@gmail.com
wrote:
Okay, I have updated the patch to destroy_tablespace_directories() code
as well in the attached patch. I have tried to modify
On Fri, Jun 26, 2015 at 04:23:28PM -0400, Robert Haas wrote:
https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items
Here's what I did:
* Split up the remaining open items into sections.
* Added a comment with current status to many, but not all, of the
items. (I would have done them
On 06/27/2015 12:30 AM, Jim Nasby wrote:
On 6/24/15 6:41 PM, Tomas Vondra wrote:
Were the stories (or the experience which lead to the stories) on
9.3 or later? Do they have a good way to reproduce it for testing
purposes?
The per-db split can only improve things if there actually are
On 6/24/15 2:11 PM, Robert Haas wrote:
Fixing this is easy, but ISTM that we need to insert some sort of a
guard to prevent people from continuing to forget this, because it's
apparently quite easy to do. Perhaps add_object_address should
Assert(OidIsValid(object_classes[oclass])), plus a
On 6/24/15 6:41 PM, Tomas Vondra wrote:
Were the stories (or the experience which lead to the stories) on 9.3 or
later? Do they have a good way to reproduce it for testing purposes?
The per-db split can only improve things if there actually are multiple
databases, and if the objects are
On 6/24/15 1:03 PM, Peter Geoghegan wrote:
On Wed, Jun 24, 2015 at 11:02 AM, Peter Geoghegan p...@heroku.com wrote:
I think that the real way to fix this is, as you say, to make it so
that it isn't necessary in general to write trigger functions like
this to make inheritance work.
Excuse me
On 6/25/15 12:51 PM, Josh Berkus wrote:
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
On 6/26/15 8:50 AM, Marco Nenciarini wrote:
In the heap_xlog_freeze we need to subtract one to the value of cutoff_xid
before passing it to ResolveRecoveryConflictWithSnapshot.
Attached a proposed patch that solves the issue.
FWIW, I've reviewed the usage and the new logic looks correct.
On 6/25/15 9:42 AM, Peter Eisentraut wrote:
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
On Wed, Jun 10, 2015 at 9:15 PM, Bruce Momjian br...@momjian.us wrote:
I am ready to make suggested adjustments
I attach a compatibility note that is clearly needed; adding this is
an open item of mine for 9.5. This concerns foreign data wrappers and
UPSERT.
--
Peter Geoghegan
diff --git
On 24 June 2015 at 15:05, Fujii Masao masao.fu...@gmail.com wrote:
How should we treat this problem for 9.5? If we want to fix this problem
completely, probably we would need to make constraint_exclusion work with
even UPSERT. Which sounds difficult to do at least for 9.5. Any other idea?
Or
On Fri, Jun 26, 2015 at 9:06 AM, Andres Freund and...@anarazel.de wrote:
On 2015-06-26 22:03:05 +0900, Michael Paquier wrote:
Hi,
Coverity is nitpickingly pointing out the following thing:
--- a/src/bin/pg_upgrade/controldata.c
+++ b/src/bin/pg_upgrade/controldata.c
@@ -402,8 +402,7 @@
On 05/27/2015 12:26 AM, Jeff Janes wrote:
On Thu, May 21, 2015 at 8:40 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, May 21, 2015 at 3:53 PM, Jeff Janes jeff.ja...@gmail.com wrote:
One of the points of max_wal_size and its predecessor is to limit how big
pg_xlog can grow. But running
Hi,
Coverity is nitpickingly pointing out the following thing:
--- a/src/bin/pg_upgrade/controldata.c
+++ b/src/bin/pg_upgrade/controldata.c
@@ -402,8 +402,7 @@ get_control_data(ClusterInfo *cluster, bool live_check)
}
}
- if (output)
- pclose(output);
Hi,
On 2015-06-26 22:03:05 +0900, Michael Paquier wrote:
Hi,
Coverity is nitpickingly pointing out the following thing:
--- a/src/bin/pg_upgrade/controldata.c
+++ b/src/bin/pg_upgrade/controldata.c
@@ -402,8 +402,7 @@ get_control_data(ClusterInfo *cluster, bool live_check)
On 06/26/2015 03:40 PM, Robert Haas wrote:
Actually, I've seen a number of presentations indicating
that the pacing of checkpoints is already too aggressive near the
beginning, because as soon as we initiate the checkpoint we have a
storm of full page writes. I'm sure we can come up with
On Thu, Jun 25, 2015 at 11:57 PM, Amit Kapila amit.kapil...@gmail.com wrote:
3. Add new view 'pg_stat_wait_event' with following info:
pid - process id of this backend
waiting - true for any form of wait, false otherwise
wait_event_type - Heavy Weight Lock, Light Weight Lock, I/O wait,
This needs more performance testing.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2015-06-26 09:44:14 -0400, Robert Haas wrote:
I don't mind committing patches for this kind of thing if it makes the
Coverity reports easier to deal with, which I gather that it does.
It takes about three seconds to mark it as ignored which will hide it
going forward.
--
Sent via
97 matches
Mail list logo
