On Thu, Aug 6, 2015 at 06:42:38PM -0700, Peter Geoghegan wrote:
On Thu, Aug 6, 2015 at 6:08 PM, Bruce Momjian br...@momjian.us wrote:
I though tabout this, and it is really an issue for FDW authors, not for
end users, so I put this text in the Source Code changes section:
I carefully
no need to
identify branches in major release notes.
Gee, if I had known we wanted to do this for major releases I could have
done it at the time I created the 9.5 release notes. It has to be
harder to do it after the fact. Should I do it for 9.6?
--
Bruce Momjian br...@momjian.ushttp
On Thu, Aug 6, 2015 at 03:32:43PM -0700, Peter Geoghegan wrote:
On Thu, Aug 6, 2015 at 3:06 PM, Bruce Momjian br...@momjian.us wrote:
Below performance improvement in the General Performance category is
missing:
Reduce btree scan overhead for and strategies
infrequent...
Anyway, how about:
format:%cd [%h] %(8,trunc)%cN: %(49,trunc)%s
(which you can configure as pretty.pgmajor or so in .gitconfig btw.)
Should we add this to src/tools/git_changelog? It currently uses git
log --format=fuller --date=iso.
--
Bruce Momjian br...@momjian.us
On Fri, Jun 26, 2015 at 03:39:19PM -0700, Peter Geoghegan wrote:
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
.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On Thu, Aug 6, 2015 at 10:21:29PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Tue, Jun 30, 2015 at 12:12:16AM +0200, Andres Freund wrote:
Anyway, how about:
format:%cd [%h] %(8,trunc)%cN: %(49,trunc)%s
(which you can configure as pretty.pgmajor or so in .gitconfig
On Sun, Jun 14, 2015 at 12:05:54PM +0100, Dean Rasheed wrote:
On 11 June 2015 at 05:15, Bruce Momjian br...@momjian.us 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
I think it's
this
makes sense. The fact that other DBs are doing it, including I think
VMWare's libpq, supports the idea of adding this simple specification.
Can someone work on a patch to implement this?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB
, or we need to
have a separate discussion of whether diagnostic functions belong in
contrib or core.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing
should be consistent.
Frankly I am unclear why I am even having to make this point, as cases
where we have chosen expediency over consistency have served us badly in
the past.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http
is used for crash
recovery, PITR, and streaming replication, and I am not sure we want to
specify all of those in the warning message.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god
On Wed, Aug 5, 2015 at 11:57:48PM -0300, Alvaro Herrera wrote:
Bruce Momjian wrote:
This is why I suggested putting the new SQL function where it belongs
for consistency and then open a separate thread to discuss the future of
where we want diagnostic functions to be. It is too
to be. It is too complicated to talk
about both issues in the same thread.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On Tue, Jul 7, 2015 at 11:48:13AM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I have discovered that psql \pset format does not display
latex-longtable as a valid value, e.g.:
test= \pset format kjasdf
\pset: allowed formats are unaligned, aligned, wrapped
On Tue, Jul 7, 2015 at 01:05:09PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Tue, Jul 7, 2015 at 11:48:13AM -0400, Tom Lane wrote:
It's a bug. Back-patch as needed.
Doesn't that cause translation string differences that are worse than
the original bug, e.g
displayed:
test= \pset format kjasdf
\pset: allowed formats are unaligned, aligned, wrapped, html, asciidoc,
latex, latex-longtable, troff-ms
Should this be fixed in 9.6 only or 9.5 too?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB
On Sun, Jun 14, 2015 at 11:21:35AM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
OK, new idea. What about, instead of having the last name be all-caps,
we have the last name start with an uppercase letter, then use smallcaps
for the rest of the last name:
https
On Sun, Jun 14, 2015 at 02:12:16PM -0400, 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
On Sat, Jun 13, 2015 at 11:30:30PM -0400, Bruce Momjian wrote:
Note that I guess MauMau is a nickname.
I think we are fine consistenly putting Japanese last names first _if_
we always capitalize the last name, e.g. FUJITA Etsuro --- is that a
good idea? Does everyone like that? Does any
On Sun, Jun 14, 2015 at 01:57:08PM -0300, Alvaro Herrera wrote:
Bruce Momjian wrote:
On Sat, Jun 13, 2015 at 05:47:59AM -0300, Alvaro Herrera wrote:
Also, it looks like we could spell your last name with an accent,
assuming the i-acute character in Latin1 is fine.
Ah, you
If you ever had trouble understanding a git manual page, this humorous
random git man page generator is full of fun:
http://git-man-page-generator.lokaltog.net/
Try a few generate runs to find one that seems logical. :-)
--
Bruce Momjian br...@momjian.ushttp://momjian.us
250
9.3187
9.4217
9.5176
The 9.5 number will only change a little by 9.5 final.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via
that accent.
All _seven_ of Petr's 9.5 commit mentions updated to add the accent.
:-) Thanks.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list
On Sat, Jun 13, 2015 at 08:18:26PM -0300, Alvaro Herrera wrote:
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
I noticed something while reading this and would like
. I'm not sure if
developers want to have official document in other than ASCII though.
Ah, yes, you could do them special for that translation.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has
On Thu, Jun 11, 2015 at 01:31:01PM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jun 11, 2015 at 11:32 AM, Bruce Momjian br...@momjian.us wrote:
Improve hash creation and lookup performance (Tomas Vondra,
Teodor Sigaev, Tom Lane, Robert Haas)
I suggest haveing
, but
pg_basebackup itself has. Though not always, and I'm not sure we've ever
claimed it was supported, but it has worked.
So we should still mention it in the release notes?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
On Thu, Jun 11, 2015 at 01:27:23PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Thu, Jun 11, 2015 at 05:16:07PM +1200, David Rowley wrote:
Would you also be able to mention something about�f15821e and�d222585 ?
I am going to defer to Tom on that. I have added
of the infrastructure too, after Robert.
I'd probably say Peter, Andrew, me.
Order changed, thanks. This entry was a consolidation of several
commits so the proper order wasn't clear to me.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http
for this one as I rewrote large
parts of this functionality as part of the review.
Added. Thanks.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing
On Fri, Jun 12, 2015 at 12:49:11PM +0900, Fujii Masao wrote:
On Thu, Jun 11, 2015 at 1:15 PM, Bruce Momjian br...@momjian.us 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
On Thu, Jun 11, 2015 at 10:20:13AM +0530, Amit Kapila wrote:
On Thu, Jun 11, 2015 at 9:45 AM, Bruce Momjian br...@momjian.us 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
Thanks
On Thu, Jun 11, 2015 at 02:00:08PM +0900, Amit Langote 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 eventually appear
On Thu, Jun 11, 2015 at 12:13:26PM -0400, Robert Haas wrote:
On Thu, Jun 11, 2015 at 11:32 AM, Bruce Momjian br...@momjian.us wrote:
Improve hash creation and lookup performance (Tomas Vondra,
Teodor Sigaev, Tom Lane, Robert Haas)
I suggest haveing two separate items. One
On Thu, Jun 11, 2015 at 05:16:07PM +1200, David Rowley wrote:
On 11 June 2015 at 16:15, Bruce Momjian br...@momjian.us 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
On Thu, Jun 11, 2015 at 02:16:59PM +0200, Tomas Vondra wrote:
Hi,
On 06/11/15 06: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 eventually appear here
are in that code! We kind of guessed on some of those
constants many years ago, and never revisited it. It would be nice to
get a better heuristic for those, but I am concerned it would require
the user to specify the number of CPU cores.
--
Bruce Momjian br...@momjian.ushttp
, though I am traveling for
conferences for the next ten days so there might a delay in my replies.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers
/core/
Hopefully this will be helpful to people.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
don't have to write WAL, they are fsyncing
shared buffers. Where is the restart point recorded, in pg_controldata?
c
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via
that it messed a bunch of stuff up is actually
pretty high, and I find doing that to the back-branches particularly
unexciting.
It is doing +1M lines of C code --- I assume it always will mess
something up.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB
On Mon, Jun 8, 2015 at 12:39:24PM -0400, Robert Haas wrote:
On Mon, Jun 8, 2015 at 12:36 PM, Bruce Momjian br...@momjian.us wrote:
Yeah, I think if we needed this out in an emergency, we would do it, but
based on the volume of recent releases, it would be hard. Are we seeing
user reports
they would still have problems
with 9.4.3.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
the number of
development tools required:
http://www.postgresql.org/ftp/snapshot/dev/
These would be easier to use than pulling from git.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has
On Mon, Jun 8, 2015 at 02:01:52PM -0300, Alvaro Herrera wrote:
Bruce Momjian wrote:
On Mon, Jun 8, 2015 at 12:39:24PM -0400, Robert Haas wrote:
On Mon, Jun 8, 2015 at 12:36 PM, Bruce Momjian br...@momjian.us wrote:
Yeah, I think if we needed this out in an emergency, we would do
feedback session. :-)
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
asking that such decisions be made independent of external time
pressures.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On Fri, Jun 5, 2015 at 04:54:56PM +0100, Simon Riggs wrote:
On 5 June 2015 at 16:05, Bruce Momjian br...@momjian.us wrote:
Please address some of the specific issues I mentioned.
I can discuss them but not because I am involved directly. I take
responsibility as a committer
, a database is useless.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
and sort those out.
+1 for Extensions directory for 9.6
This doesn't seem worth delaying the release for.
I didn't think any of this was for 9.5 consideration.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
are considered carefully. You can say decisions should
always be considered carefully, but I am not sure how realistic that is.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent
On Mon, Jun 1, 2015 at 05:57:27PM -0400, David Steele wrote:
On 6/1/15 4:42 PM, Joel Jacobson wrote:
Also ... if we were to rename it, it should be pg_wal or pg_xact.
Please let's not add yet another term for the WAL.
I like pg_wal. It's correct and suitably mysterious.
+1
--
Bruce
On Sun, May 31, 2015 at 11:55:44AM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
FYI, I realize that one additional thing that has discouraged code
reorganization is the additional backpatch overhead. I think we now
need to accept that our reorganization-adverse approach
On Sun, May 31, 2015 at 08:15:38PM +0900, Michael Paquier wrote:
On Sun, May 31, 2015 at 11:48 AM, Bruce Momjian wrote:
On Sat, May 30, 2015 at 10:47:27PM +0200, Andres Freund wrote:
So, I think we have built up a lot of technical debt. And very little
effort has been made to fix
On Sun, May 31, 2015 at 09:50:25AM -0400, Bruce Momjian wrote:
+1. Complexity has increased, and we are actually never at 100% sure
that a given bug fix does not have side effects on other things, hence
I think that a portion of this technical debt is the lack of
regression test coverage
. We could say we have
gotten too far out ahead of ourselves and we need to regroup and
restructure the code.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql
On Sat, May 30, 2015 at 08:56:53AM -0400, Bruce Momjian wrote:
On Sat, May 30, 2015 at 12:08:07AM -0400, Tom Lane wrote:
desperately in need of testing. The custom-plan code is desperately
in need of fixing and testing. The multixact code is desperately
in need of testing. The open-items
, and are pushing out an alpha of 9.5
because we know we aren't ready for a beta, just confirms my analysis.
I hate to be the bearer of bad news, but I think bad news is what we
must face.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http
another multi-xact-only fix release the week
after as being a bigger negative.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers
where we have to push it further due
to everyone being at the conference.
This brings up the issue of when we want to do 9.5 beta. Ideas?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own
On Fri, May 29, 2015 at 05:37:13PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Do we need release notes for an alpha? Once I do the release notes, it
is possible to miss subtle changes in the code that aren't mentioned in
commit messages.
If the commit message isn't
On Fri, May 29, 2015 at 04:01:00PM -0400, Tom Lane wrote:
Stephen Frost sfr...@snowman.net writes:
* Bruce Momjian (br...@momjian.us) wrote:
I am unclear if we are anywhere near ready for beta1 even in June. Are
we?
I'm all about having that discussion... but can we do it on another
for an alpha? Once I do the release notes, it
is possible to miss subtle changes in the code that aren't mentioned in
commit messages.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god
have now, but this
had to be backpatched, so reverting to the 9.3 and earlier behavior
seemed logical.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers
On Thu, May 28, 2015 at 10:13:14AM +0200, Christoph Berg wrote:
Re: Bruce Momjian 2015-05-28 20150527221607.ga7...@momjian.us
Well, if you used pg_dump/pg_restore, you would have had even larger
problems as the file names would have matched.
True, but even here it's possible that files get
. Both of
them set TLI=1. I would be inclined to restore compatibility if this were a
9.4.2 regression, but upgrades from 9.2 to 9.4 have always done that.
Right, it was only 9.3 to 9.4.0 (and 9.4.1) that restored the timeline.
Restores to 9.4.2 do not.
--
Bruce Momjian br...@momjian.us
seems pretty minor.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On Wed, May 27, 2015 at 05:40:09PM +0200, Christoph Berg wrote:
commit 4c5e060049a3714dd27b7f4732fe922090edea69
Author: Bruce Momjian br...@momjian.us
Date: Sat May 16 00:40:18 2015 -0400
pg_upgrade: force timeline 1 in the new cluster
Previously, this prevented promoted
On Wed, May 27, 2015 at 10:06:03PM +0200, Christoph Berg wrote:
Re: Bruce Momjian 2015-05-27 20150527174244.gb31...@momjian.us
In fact, I'm wondering if pg_upgrade shouldn't rather *increase* the
timeline to make sure the archive_command doesn't clobber any files
from the old cluster
to free
rider-resisting employees.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Sat, May 23, 2015 at 12:32:34PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Are we ready for a pgindent run? Back branches?
I think we could do it in HEAD, but it doesn't seem like we have consensus
about whether to touch the back branches. Suggest just HEAD for now
could skip fsync -1 failures only for symbolic
links.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On Mon, May 25, 2015 at 04:52:38PM -0300, Alvaro Herrera wrote:
Bruce Momjian wrote:
OK, makes sense. You can see the old and 'all' diffs here:
http://momjian.us/expire/
Something is wrong. See aclchk.c changes.
Yes, this is what I was concerned about. aclitem was a typedef
On Mon, May 25, 2015 at 12:49:41PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
If we wanted to do this on backbranches, I think we would create a diff
file of the minor release just before running pgindent and stamping so
users could see the non-pgindent content
On Mon, May 25, 2015 at 03:03:00PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Mon, May 25, 2015 at 01:10:04PM -0400, Tom Lane wrote:
Some of those diffs would disappear if you'd used an up-to-date typedefs
list ... not a lot, but some.
Uh, you mean a current 9.4.X
On Mon, May 25, 2015 at 03:12:24PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Mon, May 25, 2015 at 03:03:00PM -0400, Tom Lane wrote:
As we discussed upthread, if we're trying to minimize cross-branch
pgindent differences then we probably need to use the same typedefs
On Mon, May 25, 2015 at 03:20:47PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Mon, May 25, 2015 at 03:12:24PM -0400, Tom Lane wrote:
The point is for the back branches to absorb pgindent-induced changes that
have already happened in HEAD, so I'm not sure what you're
On Mon, May 25, 2015 at 09:00:25PM +0200, Andres Freund wrote:
On 2015-05-25 14:55:54 -0400, Bruce Momjian wrote:
One issue I discussed is doing a pgindent-only release so users doing a
diff would not have pgindent diffs mixed with fixes.
I find a pgindent only release a pretty pointless
On Mon, May 25, 2015 at 01:10:04PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Here is a re-run of pgindent on 9.4:
http://momjian.us/expire/pgindent-9.4.diff
Some of those diffs would disappear if you'd used an up-to-date typedefs
list ... not a lot, but some.
Uh
an fsync-fix-only release soon, adding pgindent diffs to that would
be as minimal a mixing as we could hope for.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql
On Mon, May 25, 2015 at 05:34:12PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Mon, May 25, 2015 at 04:52:38PM -0300, Alvaro Herrera wrote:
Something is wrong. See aclchk.c changes.
Yes, this is what I was concerned about. aclitem was a typedef in 9.0
and 9.1
On Mon, May 25, 2015 at 06:48:47PM -0300, Alvaro Herrera wrote:
Bruce Momjian wrote:
On Mon, May 25, 2015 at 04:52:38PM -0300, Alvaro Herrera wrote:
Bruce Momjian wrote:
OK, makes sense. You can see the old and 'all' diffs here:
http://momjian.us/expire
On Tue, May 26, 2015 at 01:15:17AM +0200, Andres Freund wrote:
On 2015-05-25 19:01:28 -0400, Bruce Momjian wrote:
A longer-term fix would be to make pgindent less stupid about this sort
of usage, but nobody's yet volunteered to dig into the guts of that code.
I assume a typedefs list
On Sat, May 23, 2015 at 11:37:30PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Sun, May 24, 2015 at 04:16:07AM +0200, Andres Freund wrote:
- if (IsA(node, Aggref) || IsA(node, GroupingFunc))
+ if (IsA(node, Aggref) ||IsA(node, GroupingFunc))
There's a bunch
On Sat, May 23, 2015 at 12:32:34PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Are we ready for a pgindent run? Back branches?
I think we could do it in HEAD, but it doesn't seem like we have consensus
about whether to touch the back branches. Suggest just HEAD for now
On Sun, May 24, 2015 at 04:16:07AM +0200, Andres Freund wrote:
On 2015-05-23 21:36:50 -0400, Bruce Momjian wrote:
pgindent run on HEAD and committed.
- if (IsA(node, Aggref) || IsA(node, GroupingFunc))
+ if (IsA(node, Aggref) ||IsA(node, GroupingFunc))
There's a bunch of changes like
always added the typedef list I used as part of pgindent commit
runs.
Are we ready for a pgindent run? Back branches?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via
On Sat, May 23, 2015 at 03:46:33PM +0200, Nils Goroll wrote:
Hi,
as many before, I ran into the issue of a postgresql database (8.4.1)
Uh, did you mean 9.4.1 as 8.4.1 is end-of-lifed.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB
to the missing history file error.
This confirms that setting the timeline to 1 unconditionally, as I did
on Friday, is the right fix, and I have added a C comment so we will
remember _why_ this has to be the case.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB
then call the function? I don't
see how the pooler could block this.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On Sun, May 17, 2015 at 08:35:49PM -0700, Josh Berkus wrote:
On 05/15/2015 05:58 AM, Bruce Momjian wrote:
I have processed all the open email items I can through mid-March,
though I do have two pg_upgrade fixes pending application today. I will
continue processing doc fixes and major bug
branches was historically only
pgindented in head, meaning that any future patches in that area could
not be easily backpatched.
Do we want to do this?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has
for password recovery is available. For Unix systems
peer authentication seems to be a good candidate.
Likely to be rejected.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent
On Mon, May 18, 2015 at 05:00:41PM -0300, Alvaro Herrera wrote:
Bruce Momjian wrote:
On Mon, May 18, 2015 at 09:32:23PM +0200, Volker Aßmann wrote:
But I like the more general approach proposed by Alvaro, so in case this
patch
would have a chance to not be immediately rejected, I
On Mon, May 18, 2015 at 07:10:00PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Mon, May 18, 2015 at 06:53:00PM -0400, Tom Lane wrote:
(BTW, one practical issue is where would we get typedef lists relevant
to the back branches. I'm not sure if the buildfarm
On Mon, May 18, 2015 at 06:53:00PM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, May 18, 2015 at 12:10 PM, Bruce Momjian br...@momjian.us wrote:
There was talk last time of pgindent-ing head and all back branches,
because a patch applied to head and back branches
On Sat, May 16, 2015 at 12:21:12PM -0400, Noah Misch wrote:
On Thu, May 14, 2015 at 10:06:11PM -0400, Bruce Momjian wrote:
On Thu, May 14, 2015 at 09:56:53PM -0400, Bruce Momjian wrote:
This patch makes pg_upgrade controldata checks more consistent, and adds
a missing check
On Sat, May 16, 2015 at 02:49:08PM -0400, Bruce Momjian wrote:
On Sat, May 16, 2015 at 12:21:12PM -0400, Noah Misch wrote:
On Thu, May 14, 2015 at 10:06:11PM -0400, Bruce Momjian wrote:
On Thu, May 14, 2015 at 09:56:53PM -0400, Bruce Momjian wrote:
This patch makes pg_upgrade controldata
I have processed all the open email items I can through mid-March,
though I do have two pg_upgrade fixes pending application today. I will
continue processing doc fixes and major bug fixes for 9.5, but
everything else I do will be for 9.6.
--
Bruce Momjian br...@momjian.ushttp
801 - 900 of 16619 matches
Mail list logo
