Hi,
Commit 63f1ccd got rid of src/tool/backend and hence
src/tool/backend/index.html. But lmgr README still directs reader to the
aforementioned file. Attached removes this obsolete reference.
Thanks,
Amit
diff --git a/src/backend/storage/lmgr/README b/src/backend/storage/lmgr/README
index
On 7 May 2015 at 21:40, Michael Paquier michael.paqu...@gmail.com wrote:
Hi all,
Coverity is complaining about the following assertion introduced in
commit 924bcf4 (parallel stuff, SerializeSnapshot@snapmgr.c):
+ Assert(snapshot-xcnt = 0);
Now the thing is that this assertion does
On 7 May 2015 at 18:37, Andres Freund and...@anarazel.de wrote:
I don't see a problem at all, with one exception: If we want the AS to
be optional like in a bunch of other places, we have to either promote
VALUES to a reserved keyword, only accept unreserved keywords, or play
precedence
ISTM that an additional Duplicate or To remove status could be a tag for
admins to remove the entries?
This looks like an overkill to me. Entries with the same description
headline mean the same thing.
Sure.
My point was to provide a mean to signal explicitely that an entry can be
Amit,
* Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
Commit 63f1ccd got rid of src/tool/backend and hence
src/tool/backend/index.html. But lmgr README still directs reader to the
aforementioned file. Attached removes this obsolete reference.
Pushed, thanks!
Stephen
So I've committed the patch yesterday evening. I'm pretty sure there'll
be some more minor things to change. But overall I feel good about the
current state.
It'd be quite helpful if others could read the docs, specifically for
insert, and comment whether they're understandable. I've spent a fair
Christian Ullrich ch...@chrullrich.net writes:
* Peter Eisentraut wrote:
On 4/30/15 2:49 PM, Andrew Dunstan wrote:
friarbird is a FreeBSD buildfarm animal running with
-DCLOBBER_CACHE_ALWAYS. It usually completes a run in about 6.5 hours.
However, it's been stuck since Monday running the
On 04/22/2015 10:07 AM, Michael Paquier wrote:
On Wed, Apr 22, 2015 at 3:38 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
I feel that the best approach is to archive the last, partial segment, but
with the .partial suffix. I don't see any plausible real-wold setup where
the current behavior
8 мая 2015 г., в 16:11, Stephen Frost sfr...@snowman.net написал(а):
* Heikki Linnakangas (hlinn...@iki.fi mailto:hlinn...@iki.fi) wrote:
On 05/08/2015 03:39 PM, Michael Paquier wrote:
On Fri, May 8, 2015 at 9:34 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
On 05/08/2015 03:25 PM,
Hi,
Commit 63f1ccd got rid of src/tool/backend and hence
src/tool/backend/index.html. But lmgr README still directs reader to the
aforementioned file. Attached removes this obsolete reference.
Thanks,
Amit
diff --git a/src/backend/storage/lmgr/README b/src/backend/storage/lmgr/README
index
Stephen Frost wrote:
As I mentioned on another thread, you're certainly right about that, and
here's the first broken-out patch, which just changes
pg_stat_get_activity to build and return a tuplestore in a single
function call instead of using the old-style multiple-invokation call
method.
Peter Eisentraut pete...@gmx.net writes:
On 5/3/15 2:27 PM, Tom Lane wrote:
2. Preventing undefined-symbol errors at link time will hide actual coding
errors, not only the intended cross-plugin reference cases. We have
repeatedly seen the buildfarm members that complain about this find actual
On 8 May 2015 at 16:03, Andres Freund and...@anarazel.de wrote:
So I've committed the patch yesterday evening. I'm pretty sure there'll
be some more minor things to change. But overall I feel good about the
current state.
It'd be quite helpful if others could read the docs, specifically for
8 мая 2015 г., в 16:39, Vladimir Borodin r...@simply.name написал(а):8 мая 2015 г., в 16:11, Stephen Frost sfr...@snowman.net написал(а):* Heikki Linnakangas (hlinn...@iki.fi) wrote:On 05/08/2015 03:39 PM, Michael Paquier wrote:On Fri, May 8, 2015 at 9:34 PM, Heikki Linnakangas hlinn...@iki.fi
* Peter Eisentraut wrote:
On 4/30/15 2:49 PM, Andrew Dunstan wrote:
friarbird is a FreeBSD buildfarm animal running with
-DCLOBBER_CACHE_ALWAYS. It usually completes a run in about 6.5 hours.
However, it's been stuck since Monday running the plpython regression
tests. The only relevant
--On 6. Mai 2015 16:28:43 -0400 Andrew Dunstan and...@dunslane.net wrote:
Single user sessions would work, but the peer authentication is also
still available and should be the preferred method to reset passwords
when trust is disabled, so this should not be an issue.
(Personally I
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Stephen Frost wrote:
As I mentioned on another thread, you're certainly right about that, and
here's the first broken-out patch, which just changes
pg_stat_get_activity to build and return a tuplestore in a single
function call instead
On 8 May 2015 at 13:02, Michael Paquier michael.paqu...@gmail.com wrote:
On Fri, May 8, 2015 at 3:55 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 7 May 2015 at 21:40, Michael Paquier michael.paqu...@gmail.com
wrote:
Hi all,
Coverity is complaining about the following assertion
On 8 May 2015 at 16:51, Andres Freund and...@anarazel.de wrote:
On 2015-05-08 16:36:07 +0100, Geoff Winkless wrote:
I thought the previous version suggested multiple possible targets and
actions, this suggests that while there can be multiple targets the
action is always the same.
I
On 2015-05-08 12:32:10 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
So I've committed the patch yesterday evening. I'm pretty sure there'll
be some more minor things to change. But overall I feel good about the
current state.
Looks like there's a CLOBBER_CACHE_ALWAYS
Kouhei Kaigai kai...@ak.jp.nec.com writes:
I've been trying to code-review this patch, because the documentation
seemed several bricks shy of a load, and I find myself entirely confused
by the fdw_ps_tlist and custom_ps_tlist fields.
Main-point of your concern is lack of
* Tom Lane wrote:
Christian Ullrich ch...@chrullrich.net writes:
* Peter Eisentraut wrote:
On 4/30/15 2:49 PM, Andrew Dunstan wrote:
friarbird is a FreeBSD buildfarm animal running with
-DCLOBBER_CACHE_ALWAYS. It usually completes a run in about 6.5 hours.
However, it's been stuck since
Andres Freund and...@anarazel.de writes:
So I've committed the patch yesterday evening. I'm pretty sure there'll
be some more minor things to change. But overall I feel good about the
current state.
Looks like there's a CLOBBER_CACHE_ALWAYS issue ...
Robert Haas rh...@postgresql.org wrote:
This patch leaves unsolved the problem of ensuring that emergency
autovacuums are triggered even when autovacuum=off. We'll need
to fix that via a separate patch.
I think we also need something like your previously-posted
multixact-truncate-race.patch
On 2015-05-08 19:32:02 +0200, Andres Freund wrote:
If the failure is indeed caused by checkxmin (trying to reproduce
right now), we can just remove the updates in that subsection of the
tests. They're not relevant.
Hm. Or easier and uglier, replace the CREATE INDEX statements with
CREATE
On 05/08/2015 08:25 PM, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On 2015-05-08 12:32:10 -0400, Tom Lane wrote:
Looks like there's a CLOBBER_CACHE_ALWAYS issue ...
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguarundidt=2015-05-08%2011%3A52%3A00
Currently index
On 2015-05-08 16:36:07 +0100, Geoff Winkless wrote:
Omitted only has one m.
There's an extra space in error . (See.
Otherwise it reads fine to me, although I've only skimmed it.
Thanks, I'll push fixes for those.
I may have misunderstood: there is only one ON CONFLICT action
allowed?
On Fri, May 8, 2015 at 1:23 PM, Kevin Grittner kgri...@ymail.com wrote:
Robert Haas rh...@postgresql.org wrote:
This patch leaves unsolved the problem of ensuring that emergency
autovacuums are triggered even when autovacuum=off. We'll need
to fix that via a separate patch.
I think we also
Andres Freund and...@anarazel.de writes:
On 2015-05-08 12:32:10 -0400, Tom Lane wrote:
Looks like there's a CLOBBER_CACHE_ALWAYS issue ...
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguarundidt=2015-05-08%2011%3A52%3A00
Currently index inferrence ignores indexes that aren't yet
On 2015-05-08 13:25:22 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On 2015-05-08 12:32:10 -0400, Tom Lane wrote:
Looks like there's a CLOBBER_CACHE_ALWAYS issue ...
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguarundidt=2015-05-08%2011%3A52%3A00
Greetings,
While working through the pg_file_settings patch, I came across this
comment above ParseConfigFp() (which is called by ParseConfigFile()):
src/backend/utils/misc/guc-file.l:603
--
* Output parameters:
* head_p, tail_p: head
Stephen Frost sfr...@snowman.net writes:
Greetings,
While working through the pg_file_settings patch, I came across this
comment above ParseConfigFp() (which is called by ParseConfigFile()):
src/backend/utils/misc/guc-file.l:603
--
*
Andres Freund and...@anarazel.de writes:
On 2015-05-08 11:10:00 -0700, Peter Geoghegan wrote:
+1. I knew we should have done this before commit.
Hrmpf.
I couldn't hit the problem with CCA unfortunately, even after a bunch of
tries; quite possibly it's too fast on my laptop.
Maybe just hold
Andres Freund and...@anarazel.de writes:
I think Peter (on IM) just found a more likely explanation than mine.
index_close(idxRel, NoLock);
heap_close(relation, NoLock);
candidates = lappend_oid(candidates,
On 2015-05-08 11:10:00 -0700, Peter Geoghegan wrote:
+1. I knew we should have done this before commit.
Hrmpf.
I couldn't hit the problem with CCA unfortunately, even after a bunch of
tries; quite possibly it's too fast on my laptop. So I'll just have
remove the check and we'll see whether it
On Fri, May 8, 2015 at 1:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
That's nice, but 9.5 feature freeze is only a week away. I don't have a
lot of confidence that this stuff is actually in a state where we won't
regret shipping it in 9.5.
Yeah. The POC you were asking for upthread certainly
On 2015-05-08 14:59:22 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
I think Peter (on IM) just found a more likely explanation than mine.
index_close(idxRel, NoLock);
heap_close(relation, NoLock);
candidates =
Alvaro Herrera wrote:
Here's a cleaned up version of this patch; I threw together a very quick
test module, and updated a conflicting OID. As far as I can tell, I'm
only missing the documentation updates before this is push-able.
Here is a complete version. Barring serious problems, I intend
On 2015-05-08 14:30:46 -0400, Tom Lane wrote:
Maybe just hold an open transaction in another session while you do what
the regression test does? I think this is probably not a matter of CCA
per se but just timing. It's unfortunate that the test in question is
run serially without other
On Fri, May 8, 2015 at 11:35 AM, Andres Freund and...@anarazel.de wrote:
I think Peter (on IM) just found a more likely explanation than mine.
index_close(idxRel, NoLock);
heap_close(relation, NoLock);
candidates =
On Fri, May 8, 2015 at 12:00 PM, Peter Geoghegan p...@heroku.com wrote:
On Fri, May 8, 2015 at 11:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Ooops. But shouldn't that have failed 100% of the time in a CCA build?
Or is the candidates list fairly noncritical?
The candidates list is absolutely
On 2015-05-08 14:32:14 -0400, Robert Haas wrote:
On Fri, May 8, 2015 at 2:27 PM, Andres Freund and...@anarazel.de wrote:
On 2015-05-08 14:15:44 -0400, Robert Haas wrote:
Apparently, we have been hanging our hat since the release of 9.3.0 on
the theory that the average multixact won't ever
On Fri, May 8, 2015 at 3:14 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Alvaro Herrera wrote:
Here's a cleaned up version of this patch; I threw together a very quick
test module, and updated a conflicting OID. As far as I can tell, I'm
only missing the documentation updates before
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I wrote:
Peter Geoghegan p...@heroku.com writes:
On Fri, May 8, 2015 at 11:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Ooops. But shouldn't that have failed 100% of the time in a CCA build?
Or is the candidates list fairly noncritical?
The
On Fri, May 8, 2015 at 4:23 PM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
On Thu, May 7, 2015 at 7:55 PM, Sawada Masahiko sawada.m...@gmail.com
wrote:
On 5/7/15, Sawada Masahiko sawada.m...@gmail.com wrote:
On Wed, May 6, 2015 at 5:42 AM, Robert Haas robertmh...@gmail.com
Alvaro Herrera wrote:
Alvaro Herrera wrote:
Here's a cleaned up version of this patch; I threw together a very quick
test module, and updated a conflicting OID. As far as I can tell, I'm
only missing the documentation updates before this is push-able.
Here is a complete version.
On Fri, May 8, 2015 at 11:06 AM, Andres Freund and...@anarazel.de wrote:
On 2015-05-08 20:37:15 +0300, Heikki Linnakangas wrote:
Why does INSERT ON CONFLICT pay attention to indcheckxmin? Uniqueness check
only cares about the most recent committed version of the tuple, and the
index good for
My colleague Thomas Munro and I have been working with Alvaro, and
also with Kevin and Amit, to fix bug #12990, a multixact-related data
corruption bug. I somehow did not realize until very recently that we
actually use two SLRUs to keep track of multixacts: one for the
multixacts themselves
On Fri, May 8, 2015 at 2:27 PM, Andres Freund and...@anarazel.de wrote:
On 2015-05-08 14:15:44 -0400, Robert Haas wrote:
Apparently, we have been hanging our hat since the release of 9.3.0 on
the theory that the average multixact won't ever have more than two
members, and therefore the members
Robert Haas robertmh...@gmail.com writes:
On Fri, May 8, 2015 at 1:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
That's nice, but 9.5 feature freeze is only a week away. I don't have a
lot of confidence that this stuff is actually in a state where we won't
regret shipping it in 9.5.
Yeah. The
On Fri, May 8, 2015 at 11:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Ooops. But shouldn't that have failed 100% of the time in a CCA build?
Or is the candidates list fairly noncritical?
The candidates list is absolutely critical.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list
Peter Geoghegan p...@heroku.com writes:
On Fri, May 8, 2015 at 11:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Ooops. But shouldn't that have failed 100% of the time in a CCA build?
Or is the candidates list fairly noncritical?
The candidates list is absolutely critical.
Oh, I was confusing
* Peter Geoghegan (p...@heroku.com) wrote:
On Fri, May 8, 2015 at 12:00 PM, Peter Geoghegan p...@heroku.com wrote:
On Fri, May 8, 2015 at 11:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Ooops. But shouldn't that have failed 100% of the time in a CCA build?
Or is the candidates list fairly
I wrote:
Peter Geoghegan p...@heroku.com writes:
On Fri, May 8, 2015 at 11:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Ooops. But shouldn't that have failed 100% of the time in a CCA build?
Or is the candidates list fairly noncritical?
The candidates list is absolutely critical.
Oh, I was
On Thu, May 7, 2015 at 7:55 PM, Sawada Masahiko sawada.m...@gmail.com
wrote:
On 5/7/15, Sawada Masahiko sawada.m...@gmail.com wrote:
On Wed, May 6, 2015 at 5:42 AM, Robert Haas robertmh...@gmail.com
javascript:; wrote:
On Tue, May 5, 2015 at 11:10 AM, Sawada Masahiko sawada.m...@gmail.com
On 2015-05-08 20:37:15 +0300, Heikki Linnakangas wrote:
Why does INSERT ON CONFLICT pay attention to indcheckxmin? Uniqueness check
only cares about the most recent committed version of the tuple, and the
index good for that use immediately. If there was a problem there, the
uniqueness check
Hi,
On 2015-05-08 14:15:44 -0400, Robert Haas wrote:
Apparently, we have been hanging our hat since the release of 9.3.0 on
the theory that the average multixact won't ever have more than two
members, and therefore the members SLRU won't overwrite itself and
corrupt data.
It's essentially a
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Peter Geoghegan p...@heroku.com writes:
On Fri, May 8, 2015 at 11:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Ooops. But shouldn't that have failed 100% of the time in a CCA build?
Or is the candidates list fairly noncritical?
The candidates list is
Hello!
Today, there exists GSSAPI authentication support in Postgres. I plan
to extend this work to include encryption as well, but wanted to get
your input on that first since you've probably thought about this
already.
From what I can tell, the auth/encryption layer is very nicely designed
Josh Berkus wrote:
I have a couple workloads in my pool which do consume mxids faster than
xids, due to (I think) execeptional numbers of FK conflicts. It's
definitely unusual, though, and I'm sure they'd rather have corruption
protection and endure some more vacuums. If we do this, though,
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Actually, looking closer, the quoted code is simply not broken without
RELCACHE_FORCE_RELEASE: without that, neither heap_close nor index_close
will do anything that could cause a cache flush. So while it's
Robert Haas wrote:
My colleague Thomas Munro and I have been working with Alvaro, and
also with Kevin and Amit, to fix bug #12990, a multixact-related data
corruption bug.
Thanks for this great summary of the situation.
1. I believe that there is still a narrow race condition that cause
On 05/08/2015 11:27 AM, Andres Freund wrote:
Hi,
On 2015-05-08 14:15:44 -0400, Robert Haas wrote:
3. It seems to me that there is a danger that some users could see
extremely frequent anti-mxid-member-wraparound vacuums as a result of
this work. Granted, that beats data corruption or
On 2015-05-08 12:57:17 -0700, Josh Berkus wrote:
I have a couple workloads in my pool which do consume mxids faster than
xids, due to (I think) execeptional numbers of FK conflicts. It's
definitely unusual, though, and I'm sure they'd rather have corruption
protection and endure some more
On 2015-05-08 15:22:09 -0400, Tom Lane wrote:
I'm back to suspecting that the indcheckxmin issue is the true cause of
the buildfarm failure
Me too.
though we lack an explanation why Andres failed to reproduce it ...
My laptop is probably a good bit faster than jaguarundi, particularly in
a
On 2015-05-08 22:29:47 +0200, Andres Freund wrote:
On 2015-05-08 15:22:09 -0400, Tom Lane wrote:
I'm back to suspecting that the indcheckxmin issue is the true cause of
the buildfarm failure
though we lack an explanation why Andres failed to reproduce it ...
My laptop is probably a good
... btw, I just noticed something that had escaped me because it seems so
obviously wrong that I had not even stopped to consider the possibility
that the code was doing what it's doing. To wit, that the planner
supposes that two foreign tables are potentially remote-joinable if they
share the
On 05/08/2015 03:39 PM, Michael Paquier wrote:
On Fri, May 8, 2015 at 9:34 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
On 05/08/2015 03:25 PM, Vladimir Borodin wrote:
Seems, that pg_rewind does not account --dry-run option properly. A simple
fix
for that is attached.
No, the --dry-run
2015-05-07 13:43 GMT+02:00 Alvaro Herrera alvhe...@2ndquadrant.com:
The problem is here:
[root@ps-test5:/etc/puppet/modules/postgresql/files] pg_controldata
/mnt/ebs/pgsql/data
pg_control version number:922
Catalog version number: 201302181
The catversion for
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
On 05/08/2015 03:39 PM, Michael Paquier wrote:
On Fri, May 8, 2015 at 9:34 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
On 05/08/2015 03:25 PM, Vladimir Borodin wrote:
Seems, that pg_rewind does not account --dry-run option properly. A simple
fix
On Fri, May 8, 2015 at 7:53 PM, Andres Freund and...@anarazel.de wrote:
On 2015-05-04 14:23:16 -0400, Robert Haas wrote:
On Fri, May 1, 2015 at 10:41 AM, Abhijit Menon-Sen a...@2ndquadrant.com
wrote:
As for the non-backpatchable 0002, I agree with Andres that it should be
included in 9.5;
On Fri, May 8, 2015 at 2:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, we have two alternatives. I can keep hacking on this and get it
to a state where it seems credible to me, but we won't have any proof
that it actually works (though perhaps we could treat any problems
as bugs that should
Sergey Konoplev wrote:
On Thu, Mar 27, 2014 at 3:26 PM, Sergey Konoplev gray...@gmail.com wrote:
On Sun, Sep 22, 2013 at 4:38 PM, Stas Kelvich stas.kelv...@gmail.com
wrote:
Here is the patch that introduces kNN search for cubes with euclidean,
taxicab and chebyshev distances.
What
On Fri, May 8, 2015 at 5:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
... btw, I just noticed something that had escaped me because it seems so
obviously wrong that I had not even stopped to consider the possibility
that the code was doing what it's doing. To wit, that the planner
supposes that
Andres Freund and...@anarazel.de writes:
prairiedog, without CCA, failed as well
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=prairiedogdt=2015-05-08%2019%3A55%3A11
different test, but again directly after index creation. So I hope it's
indeed the indcheckxmin thing.
Oh, interesting. That
2015-05-09 2:46 GMT+09:00 Tom Lane t...@sss.pgh.pa.us:
Kouhei Kaigai kai...@ak.jp.nec.com writes:
I've been trying to code-review this patch, because the documentation
seemed several bricks shy of a load, and I find myself entirely confused
by the fdw_ps_tlist and custom_ps_tlist fields.
Robbie,
* Robbie Harwood (rharw...@redhat.com) wrote:
Today, there exists GSSAPI authentication support in Postgres. I plan
to extend this work to include encryption as well, but wanted to get
your input on that first since you've probably thought about this
already.
Great!
From what I
2015-05-09 3:51 GMT+09:00 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Fri, May 8, 2015 at 1:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
That's nice, but 9.5 feature freeze is only a week away. I don't have a
lot of confidence that this stuff is actually in a state
2015-05-09 6:48 GMT+09:00 Tom Lane t...@sss.pgh.pa.us:
... btw, I just noticed something that had escaped me because it seems so
obviously wrong that I had not even stopped to consider the possibility
that the code was doing what it's doing. To wit, that the planner
supposes that two foreign
Sawada,
* Sawada Masahiko (sawada.m...@gmail.com) wrote:
Thank you for reviewing.
I agree with this.
Attached patch is updated version v10.
Committed with quite a few additional changes and improvements. Please
take a look, test, and let me know if you see any issues or have any
concerns.
Hi all.Seems, that pg_rewind does not account --dry-run option properly. A simple fix for that is attached.
pg_rewind_dry_run_fix.patch
Description: Binary data
--May the force be with you…https://simply.name
On 05/08/2015 03:25 PM, Vladimir Borodin wrote:
Hi all.
Seems, that pg_rewind does not account --dry-run option properly. A simple fix
for that is attached.
No, the --dry-run takes effect later. It performs all the actions it
normally would, including reading files from the source, except
On Fri, May 8, 2015 at 9:34 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
On 05/08/2015 03:25 PM, Vladimir Borodin wrote:
Seems, that pg_rewind does not account --dry-run option properly. A simple
fix
for that is attached.
No, the --dry-run takes effect later. It performs all the actions it
On Fri, May 8, 2015 at 3:55 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 7 May 2015 at 21:40, Michael Paquier michael.paqu...@gmail.com wrote:
Hi all,
Coverity is complaining about the following assertion introduced in
commit 924bcf4 (parallel stuff, SerializeSnapshot@snapmgr.c):
+
Stephen Frost sfr...@snowman.net writes:
I'm all for improving performance of postgres_fdw and would like to see
us support sending queries off to be worked asyncronously, but starting
execution on the remote server during ExecInitNode is against the
documentated FDW API spec. I discussed
On Friday, May 8, 2015, Amit Langote langote_amit...@lab.ntt.co.jp wrote:
Hi,
Commit 63f1ccd got rid of src/tool/backend and hence
src/tool/backend/index.html. But lmgr README still directs reader to the
aforementioned file. Attached removes this obsolete reference.
Please ignore this.
Hi!
Patch is pretty ready, last issue was about changed extension interface, so
there should be migration script and version bump.
Attaching a version with all migration stuff.
distances2r4.patch
Description: Binary data
Stas.
On 09 May 2015, at 05:20, Alvaro Herrera
Minor v2 update to change a not badly chosen variable name.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index a808546..2517a3a 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++ b/doc/src/sgml/ref/pgbench.sgml
@@ -326,8 +326,7 @@ pgbench optional
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
On Tue, Dec 9, 2014 at 05:38:25PM -0500, Stephen Frost wrote:
My comment that include_realm is supported back to 8.4 was because there
is an expectation that a pg_hba.conf file can be used unchanged across
several major releases. So
Hi,
On 2015-04-24 08:46:48 +0530, Abhijit Menon-Sen wrote:
diff --git a/contrib/pgstattuple/pgstatbloat.c
b/contrib/pgstattuple/pgstatbloat.c
new file mode 100644
index 000..612e22b
--- /dev/null
+++ b/contrib/pgstattuple/pgstatbloat.c
@@ -0,0 +1,389 @@
+/*
+ *
Kyotaro,
* Kyotaro HORIGUCHI (horiguchi.kyot...@lab.ntt.co.jp) wrote:
The attached is the fixed patch. It apparently improves the
performance for the test case shown in the previous mail, in
which the average tuple length is about 140 bytes.
I'm all for improving performance of postgres_fdw
On 2015-05-04 14:23:16 -0400, Robert Haas wrote:
On Fri, May 1, 2015 at 10:41 AM, Abhijit Menon-Sen a...@2ndquadrant.com
wrote:
As for the non-backpatchable 0002, I agree with Andres that it should be
included in 9.5; but I take it you're still not convinced?
No, I'm not convinced. That
92 matches
Mail list logo
