facilities will be available to
external sharding solutions as well.
Is this acceptable?
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Roman
se risks. I doubt we can
really do anymore than warn folks as there is just no good boundary on
how to avoid problems, as Andres and Simon pointed out. Josh is right
that patent problems have been a rarity, and I have every hope that this
will continue.
--
Bruce Momjian <br...@
On Fri, Oct 30, 2015 at 04:47:35AM -0400, Bruce Momjian wrote:
> Therefore, I caution people from viewing the Greenplum source code as
> you might see patented ideas that could be later implemented in
> Postgres, opening Postgres up to increased patent violation problems. I
> am al
On Sun, Nov 1, 2015 at 01:27:13AM -0500, Bruce Momjian wrote:
> On Fri, Oct 30, 2015 at 04:47:35AM -0400, Bruce Momjian wrote:
> > Therefore, I caution people from viewing the Greenplum source code as
> > you might see patented ideas that could be later implemented in
> &
hese companies would sue the community for patent infringement,
they could sue users, and the company could be bought by a sinister
company that could enforce those patents. For example, few had problems
with Sun's control over Java, but when Oracle bought Sun, more people
were concerned. So
On Fri, Oct 30, 2015 at 09:56:48AM +0100, Andres Freund wrote:
> Hi,
>
> I don't really want to discuss patent issues publically.
While we don't want to discuss patented ideas, the patent terms are an
imporant topic here.
> On 2015-10-30 04:47:35 -0400, Bruce Momjian wrote:
> &
email list.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription +
--
Sent via pgsql-hackers mailing lis
e we have
any mechanism now to close those parallel processes.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription
nyway.
>
> This looks more like a bug to me than a To-do item.
Uh, many TODO items are bugs.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Roman
Unix we use fork() and on Windows we use thread. It
is not clear in the TODO list which platform this is for. I don't see
any signal control in the pg_upgrade source code.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
not
pg_upgrade-specific as there is no signal control in pg_upgrade --- you
are just getting the defaults.
(Updated TODO to mention Linux.)
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so o
On Fri, Oct 16, 2015 at 02:50:04PM +0530, Amit Kapila wrote:
> On Fri, Oct 16, 2015 at 8:34 AM, Bruce Momjian <br...@momjian.us> wrote:
>
> I have spend the past few days updating our TODO list, removing
> completed and now-unnecessary items:
>
> htt
On Fri, Oct 16, 2015 at 12:00:11PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > I have spend the past few days updating our TODO list, removing
> > completed and now-unnecessary items:
> >
> > https://wiki.postgresql.org/wiki/Todo
>
> Thanks. W
On Fri, Oct 16, 2015 at 12:02:03PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Are you suggesting I remove those links? It is kind of odd to have
> > links to patches for features we don't want, or just keep it?
>
> No, quite the contrary -- I think th
On Fri, Oct 16, 2015 at 11:43:10AM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Probably the most controvertial change was to move on-disk bitmap
> > indexes to the "not wanted" section, though I kept the links in case we
> > change our minds
I have spend the past few days updating our TODO list, removing
completed and now-unnecessary items:
https://wiki.postgresql.org/wiki/Todo
I encourage others to also update the list to make it more accurate.
Thanks.
--
Bruce Momjian <br...@momjian.us>http://momj
shows me the limits as I am typing the commit text to
remind me of the limits:
-- email subject limit ---------
-- gitweb summary limit --
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
Any news on this item from 2013, worked on again 2014?
---
On Wed, Aug 6, 2014 at 12:55:59PM -0400, Bruce Momjian wrote:
> On Fri, Nov 29, 2013 at 02:04:10AM +, Greg Stark wrote:
> > Attached is what I have
> Translations are sync'd to the main repository from the translations
> project - so I assume this needs to be submitted there, but I don't
> know how.
I think the details are here:
https://wiki.postgresql.org/wiki/NLS
--
Bruce Momjian <br...@momjian.us&g
don't code. Bug triage is exactly the
> kind of thing very part-time community supporters can do, if we make it
> easy for them to do.
Yes. Part of the problem is that tracker maintenance is almost done in
a closet, so there is little outward reinforcement to keep people
motivated.
--
Br
On Tue, Oct 6, 2015 at 03:33:20PM -0300, Alvaro Herrera wrote:
> Joshua D. Drake wrote:
> > On 10/06/2015 10:57 AM, Josh Berkus wrote:
> > >On 10/06/2015 10:17 AM, Bruce Momjian wrote:
>
> > >Speaking of which ... this project is rich in skilled users who are
ternal binaries like
> "pg_ctl status" or some parsing of postmaster.pid with kill(pid, 0)
> for example.
To disable the old cluster, pg_upgrade rename pg_control to
pg_control.old in disable_old_cluster(). You should do that, or
pg_upgrade should use whatever new method you c
ot sure if we
have succeeded because of our current non-retain mode, or in spite of
it. It might be time to switch to a default-retain mode, especially
since most other projects have that mode, but we should be clear what we
are getting into.
--
Bruce Momjian <br...@momjian.us>http://momj
On Wed, Apr 29, 2015 at 03:48:04PM -0400, Bruce Momjian wrote:
> On Tue, Apr 28, 2015 at 09:15:49AM -0400, Bruce Momjian wrote:
> > > It seems to me that waiting for 9.6 for what's arguably a bug fix is too
> > > much. It's not like this is a new feature. Why do
e
> new master.
Did you read this thread convering the same topic from a few weeks ago?
http://www.postgresql.org/message-id/flat/55fa2537.4070...@gmx.net#55fa2537.4070...@gmx.net
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
f this feature?
> >>
> > It says these enhancement on interface allows extensions to implement
> > join operation in their own way (including remote join in case of FDW),
> > however, enhancement of postgres_fdw is not yet upstreamed.
>
> Thank you for this clarification
the dramatic engineerings feats that have made us famous.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
On Thu, Sep 10, 2015 at 09:59:41PM -0400, Bruce Momjian wrote:
> On Fri, Sep 11, 2015 at 12:41:09AM +, Hyongtae Lim wrote:
> > The following review has been posted through the commitfest application:
> > make installcheck-world: tested, passed
> > Implements feature:
mply add a function like that:
> heap_page_item_parse(Oid relid, bytea data, t_infomask2 int,
> t_infomask int, t_bits int, bool force_detoast, warning_mode bool)
> returns bytea[]
Should pageinspect create a table that contains some of the constants
used to interpret infomask?
--
; Documentation:not tested
>
> This looks good to me.
> I've done some tests(pg_dumpall & restore with sql, upgrade test(8.4, 9.x,
> ...)) and there was no problems.
> so I'm marking this as ready for committer.
Thanks. I am going to commit it in the next 24 hours. Thanks.
--
th considering having a new bigtsvector type?
>
> Btw, we've been very impressed with the extent that PostgreSQL has
> tolerated all kinds of loads we have thrown at it.
Can anyone on hackers answer this question from June?
--
Bruce Momjian <br...@momjian.us>htt
On Wed, Sep 9, 2015 at 06:14:28PM +0300, Ildus Kurbangaliev wrote:
> On Wed, 9 Sep 2015 10:52:02 -0400
> Bruce Momjian <br...@momjian.us> wrote:
>
> > On Wed, Jun 17, 2015 at 07:58:21AM +0200, CPT wrote:
> > > Hi all;
> > >
> > > We are runnin
ripts that test pg_dump restore/upgrade of every
supported PG version. I also have expected pg_dump output files for
every major version. This is explained in src/bin/pg_upgrade/TESTING.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
habit I often forget.
>
>
> Noted. I usually don't do that.
I am thinking we should all agree if we should redirect commit comments
to hackers, or not, so we are consistent.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
. I think
> this doesn't conflict with his work except the grammar part.
I am very glad multi-variate statistics are being addressed. I think
this is our most common cause of optimizer failures.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
microseconds then you only
> need to have a small handful of I/O requests in flight to keep your
> processor busy.
Well, there is still the processing time of getting that data ready.
All I know is that people have reported that prefetching is even more
useful for SSDs.
--
Bruce Momjia
On Thu, Sep 3, 2015 at 11:56:52PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Thu, Sep 3, 2015 at 11:37:09PM +0200, Petr Jelinek wrote:
> > > >I don't understand. I'm just proposing that the source code for the
> > > >extension to live in src
inally, remove the old password. Is that the
process? I am not realizing that without multiple plasswords, this is a
hard problem.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their o
exity. For me, this libpq
change has a simple user API with a small amount of code change that
give us a simple solution to a common problem.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has t
that's certainly not simple either and can get quite painful.
OK, for me, if we can explain the benefit for users, it seems worth
doing just to allow that.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+
laves.
Yes, and imagine doing this with FDW's, updating the catalog table
location of the FDW as part of the failover process --- interesting.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has
milar syncrep properties as the
> binary one (feedback works same way).
Yes, I assumed that. Logical replication uses WAL, so if you are
synchronous with WAL, logical replication is synchronous too. However,
of course, it is synchronous in being durable, not synchronous in terms
of applying the WAL
The new output looks like this:
\connect postgres
ALTER DATABASE template1 SET TABLESPACE tt;
\connect template1
Based on our previous policy, these are both bugs and cause either
errors or inaccurate restores, so I plan to apply the attached patch to
all back branches.
--
t;extension is installed automatically. For that, you still need a
> >superuser to run CREATE EXTENSION.
> >
>
> +! for this
OK, what does "+!" mean? (I know it is probably a shift-key mistype,
but it looks interesting.)
--
Bruce Momjian <br
ing selected data around.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
is typical, allows the shards to back up each other.
You could say shard 2 is the backup for shard 1, but then if shard one
goes bad, the entire workload of shard 1 goes to shard 2. With the
above approach, the load of shard 1 is shared by all the shards.
--
Bruce Momjian <br...@momjia
plication to wait for multiple nodes. But in theory
> those seem like limitations that can be lifted. Also, the GTM needs
> to be aware that this stuff is happening, or it will DTWT. That too
> seems like a problem that can be solved.
Can you explain why logical replication is better than binar
On Wed, Sep 2, 2015 at 04:50:32PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Fri, Aug 28, 2015 at 10:34:38PM -0700, AI Rumman wrote:
>
> > > In pg_upgrade, how about adding a feature to copy data directory over
> > > network.
> > > That
standby_names. We can't just keep requiring external
tooling to identify things that the database knows easily and can send
an alert. Removing failed nodes is also something we should do and
notify users about.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
On Tue, Sep 1, 2015 at 06:11:45PM -0400, Bruce Momjian wrote:
> Let me clearer about what the Citus Data paper shows. I said originally
> that the data was sent to the coordinator, sorted, then resent to the
> shards, but the document:
>
> https://goo.gl/vJWF85
&
On Tue, Sep 1, 2015 at 08:20:47PM -0400, Bruce Momjian wrote:
> On Tue, Jul 28, 2015 at 02:19:00PM -0400, Andrew Dunstan wrote:
> >
> > On 07/28/2015 02:01 PM, Tom Lane wrote:
> > >I had a discussion with some folks at Red Hat about this:
> > >https://bugzilla.r
do that for the original setup
too. Odds are they get an error, look at the message, figure out they
need shared_preload_libraries, and re-test it.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has the
On Tue, Sep 1, 2015 at 12:40:40PM -0400, Robert Haas wrote:
> On Tue, Sep 1, 2015 at 6:55 AM, Bruce Momjian <br...@momjian.us> wrote:
> > I assumed these queries were going to be solved by sending as digested
> > data as possible to the coordinator, and having the coordin
unately it's no more than a vague
> feeling so I can't tell you where to look; but it'd be a good idea to look
> around and/or test, rather than just assume we can let users frob these
> knobs to whatever random settings they feel like.
You might be thinking of pg_upgrade, which _used_ to
client who should have known better doing
> this just a week or two ago.
Uh, we added an initdb warning about mount points:
commit 17f15239325a88581bb4f9cf91d38005f1f52d69
Author: Bruce Momjian <br...@momjian.us>
Date: Sat Feb 16 18:52:50 2013 -0500
On Tue, Sep 1, 2015 at 08:18:38AM -0700, Joshua Drake wrote:
> On 09/01/2015 02:48 AM, Bruce Momjian wrote:
> >On Tue, Sep 1, 2015 at 09:30:41AM +0530, Pavan Deolasee wrote:
>
> >There is no question that using XC/XL will get us to a usable solution
> >faster, but se
On Tue, Sep 1, 2015 at 10:15:27AM +0200, Andres Freund wrote:
> On 2015-08-31 20:54:51 -0400, Bruce Momjian wrote:
> > Uh, we already have a list of things we need to add to FDWs to make them
> > work, and Citus Data has provided a document of more things that are
> > n
cross-node ACID
control.
In summary, I don't think adding a ton of code just to do sharding will
be acceptable. A corollary of that, is that if FDWs are unable to
provide useful sharding, I don't see an acceptable way of adding
built-in sharding to Postgres.
--
Bruce Momjian <br...@momjian.u
ning, and I think we need to fix that.
Hopefully we don't do the same thing with sharding.)
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers maili
On Mon, Aug 31, 2015 at 11:23:58PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > My hope is that many FDW improvements will benefit sharding and
> > non-sharding workloads, but I bet some improvements are going to be
> > sharding-specific. I would say we are
On Tue, Jul 7, 2015 at 03:21:50PM -0400, Bruce Momjian wrote:
> 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
1
> >
> > Let's get rid of pg_dumpall -g.
>
> Quite the opposite, I think --- let's get rid of pg_dumpall EXCEPT when
> invoked as pg_dumpall -g.
Is this a TODO?
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
tion is to install json_build94 as you did,
run pg_upgrade, then just uninstall json_build94 as nothing depends on
it. Not sure if this should be in the pg_upgrade docs or not.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprise
e understanding why it was failing and why it was
> looking for json_build.
The problem is that this is a rare case where you had an extension that
was later included in Postgres.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
On Mon, Aug 31, 2015 at 07:28:00PM -0400, Andrew Dunstan wrote:
>
>
> On 08/31/2015 07:21 PM, David E. Wheeler wrote:
> >On Aug 31, 2015, at 4:20 PM, Bruce Momjian <br...@momjian.us> wrote:
> >
> >>>I think it would help if its noted somewhere in the docu
rding workloads, but I bet some improvements are going to be
sharding-specific. I would say we are still in the exploratory stage,
but based on the number of people who care about this feature and want
to be involved, I think we are off to a very good start. :-)
--
Bruce Momjian <
in September !
In summary, I think we need to start working on built-in sharding, and
FDWs are the only way I can see to do it with minimal code changes,
which I think might be a community requirement. It might not work, but
right now, it is the only possible approach I can see.
--
Bruce Momjian br
to research this.
OK, I will send you a separate email and you can then supply their email
addresses.
FWIW, I would be interested in that as well. I worked in this area of things
for a couple of years as well FWIW.
OK, I will send you an email.
--
Bruce Momjian br...@momjian.us
On Sun, Aug 30, 2015 at 03:31:10PM +0100, Simon Riggs wrote:
On 30 August 2015 at 03:17, Bruce Momjian br...@momjian.us wrote:
I have recently increased my public statements about the idea of adding
horizontal scaling/sharding to Postgres.
Glad to see it. Many people have been
On Sun, Aug 30, 2015 at 10:08:06PM -0400, Bruce Momjian wrote:
On Mon, Aug 31, 2015 at 09:53:57AM +0900, Michael Paquier wrote:
Well, I have had many such discussions with XC/XL folks, and that was my
opinion. I have seen almost no public discussion about this because the
idea
without NFS is going to be vary hard.
I think it is much simpler to just copy the old clsuter to the remote
server and run pg_upgrade in --link mode on the remote server.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
names of all connected users.
--
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
, that the XC approach is the only reasonable
way to do it, and that FDWs are the cleanest way to get it into community
Postgres.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent
() and heap_getattr(). Not only is
the resulting code significantly more readable, but the conversion also
shrinks the code size:
Hey, the fastgetattr() macro was a work of art! ;-) (And more of my
hacks disappear.)
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB
other macros I created in those
early years.
Frankly, my hacks last a lot longer than I expected. (Did someone say
pg_upgrade. :-) )
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god
.
--
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://www.postgresql.org/mailpref
On Sat, Aug 29, 2015 at 12:23:30AM +0200, Andres Freund wrote:
On 2015-08-28 17:49:35 -0400, Bruce Momjian wrote:
If we _don't_ do that, how do you easily get those lines into the
release notes? I can't imagine how hard it was for Andres to add that
text to the 9.5 release notes
On Fri, Aug 28, 2015 at 05:32:38PM -0400, Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Bruce Momjian wrote:
To simplify the creation of the release note with the commit tag as an
SGML comment, I think src/tools/git_changelog should be modified to
output this string
this string. The format trunc feature was added in git 1.8.3.
Is that old enough for everyone?
I am not going to need this until the 9.6 release notes. Should I add
it or someone else?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http
On Thu, Jun 25, 2015 at 10:42:54AM -0400, 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
priority level, like 1 to 2, 2 to 3, or 2 to 1.
--
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
things or many small things, e.g. when we don't have many big
features in a major release, the count tends to be high as we clean up
previously-released big features.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
On Wed, Aug 26, 2015 at 10:10:01AM -0700, Peter Geoghegan wrote:
On Wed, Aug 26, 2015 at 7:33 AM, Bruce Momjian br...@momjian.us wrote:
I have applied the attached patch to document this in the data type docs.
Thanks, but shouldn't varchar/text also be mentioned in the release
notes, rather
at my locking presentation; I
think there are examples in there:
http://momjian.us/main/writings/pgsql/locking.pdf
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent
On Wed, Aug 26, 2015 at 02:47:14PM -0400, Bruce Momjian wrote:
On Wed, Aug 26, 2015 at 10:10:01AM -0700, Peter Geoghegan wrote:
On Wed, Aug 26, 2015 at 7:33 AM, Bruce Momjian br...@momjian.us wrote:
I have applied the attached patch to document this in the data type docs.
Thanks
://www.postgresql.org/message-id/flat/CAM3SWZRRCs6KAyN-bDsh0_pG=8xm3fvcf1x9dlsvd3wvbt1...@mail.gmail.com#CAM3SWZRRCs6KAyN-bDsh0_pG=8xm3fvcf1x9dlsvd3wvbt1...@mail.gmail.com
I have applied the attached patch to document this in the data type docs.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
few
complaints about this problem.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
diff --git a/src/bin/pg_upgrade/info.c b/src/bin/pg_upgrade/info.c
new file mode 100644
index
On Thu, Aug 6, 2015 at 10:35:50PM -0400, Bruce Momjian wrote:
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
of this issue. 9.5 release note item
attached and applied.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
diff --git a/doc/src/sgml/release-9.5.sgml b/doc/src/sgml/release-9.5.sgml
On Fri, Aug 7, 2015 at 09:02:09PM +0200, Andres Freund wrote:
On 2015-08-07 14:43:11 -0400, Bruce Momjian wrote:
Well, we could just throw a Postgres 9.5 is faster release note item
in there and call it a day. ;-)
Based on my experience one of the prime reason people move to a new
On Sat, Aug 8, 2015 at 02:49:21PM -0400, Bruce Momjian wrote:
What I _am_ saying is that you should use the same criteria I am using,
and just disagree on the place for the line, rather than use a different
criteria, which will lead to perpetual complaints. We can change the
criteria
On Sun, Aug 9, 2015 at 01:24:33AM +1200, David Rowley wrote:
On 7 August 2015 at 14:24, Bruce Momjian br...@momjian.us wrote:
On Tue, Jun 30, 2015 at 09:00:44PM +0200, Andres Freund wrote:
* 2014-12-08 [519b075] Simon ..: Use GetSystemTimeAsFileTime directly in
win32
On Fri, Aug 7, 2015 at 11:53:30AM -0400, Robert Haas wrote:
On Thu, Aug 6, 2015 at 10:24 PM, Bruce Momjian br...@momjian.us wrote:
* 2014-10-02 [3acc10c9] Robert..: Increase the number of buffer mapping
partition..
should we mention this? This has been patched by a number
On Thu, Aug 6, 2015 at 06:44:40PM -0300, Alvaro Herrera wrote:
Bruce Momjian wrote:
On Fri, Jun 19, 2015 at 08:21:19PM +0200, Andres Freund wrote:
I think 647248e3708, 4fe384bd85, 4f85fde8, 59f71a0d0 should also be
I couldn't look up 647248e3708, I got unknown revision or path
On Thu, Aug 6, 2015 at 01:48:26PM -0400, Robert Haas wrote:
On Thu, Aug 6, 2015 at 10:33 AM, Bruce Momjian br...@momjian.us wrote:
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
On Fri, Jun 19, 2015 at 08:21:19PM +0200, Andres Freund wrote:
Hi,
On 2015-06-11 00:15:21 -0400, Bruce Momjian wrote:
I have committed the first draft of the 9.5 release notes. You can view
the output here:
So, I did a pass through master's state:
listitem
para
On Fri, Jun 19, 2015 at 09:44:04PM +0200, Andres Freund wrote:
Hi,
On 2015-06-11 00:15:21 -0400, Bruce Momjian wrote:
I have committed the first draft of the 9.5 release notes. You can view
the output here:
I'm looking through all the commits, checking which I think should
possibly
.
I think maybe we should separate that back out. The list needs to be
user-accessible, but if it's hard to understand what it's referring
to, that's not good either.
Yea. And if then Bruce goes and compares feature counts... :)
:-)
--
Bruce Momjian br...@momjian.ushttp
On Mon, Jun 22, 2015 at 09:14:01PM +, Rajeev rastogi wrote:
On 11 June 2015 09:45, 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, Aug 6, 2015 at 11:19:46AM -0700, Jeff Janes wrote:
On Wed, Jun 10, 2015 at 9: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
701 - 800 of 16619 matches
Mail list logo
