On Tue, Sep 19, 2017 at 12:22:39PM -0400, Tom Lane wrote:
> "'Bruce Momjian'" writes:
> > I am sure Tom can explain his reasoning.
>
> We don't normally release-note documentation changes. If this
> wasn't purely a documentation change, then I was
On Tue, Sep 19, 2017 at 12:30:01PM -0400, Tom Lane wrote:
> "'Bruce Momjian'" writes:
> > On Tue, Sep 19, 2017 at 12:22:39PM -0400, Tom Lane wrote:
> >> We don't normally release-note documentation changes. If this
> >> wasn't purely a d
onsidering for core, especially now that we've got a
> reasonable password-based authentication method with SCRAM.
Does LDAP do this too?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I
", "peer", "pam", "ldap", "radius" or "cert".
>
> The "md5" option no longer works, as discussed in other threads.
Uh, I think that "md5" still works just fine.
--
Bruce Momjian http://momjian.us
Enterpris
roughly, and
> there's no longer time to catch any remaining oversights through testing.
>
> Any other votes out there?
Well, I was concerned yesterday that we had a broken build farm so close
to release. (I got consistent regression failures.) I think PG 11 would
be better fo
On Tue, Sep 26, 2017 at 05:32:15PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Tue, Sep 26, 2017 at 04:07:02PM -0400, Tom Lane wrote:
> >> Any other votes out there?
>
> > Well, I was concerned yesterday that we had a broken build farm so close
> &
hanged over time.
>
> Yes, I used the form that the person used in their emails.
How should this be handled for the Postgres 11 release notes?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am,
release notes are created, or some other method?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
--
Sent via pgsql-h
tgres://localhost/test,postgres://localhost/test2
I realize this is libpq-feature-creep, but considering the complexities
of a pooler and virtual IP address reassignment, I think adding this
makes sense. The fact that other DBs are doing it, including I think
VMWare's libpq, supports th
t we did previously for
diagnostic functions. Either their is logic to why this function is
different from the other diagnostic functions in contrib, or we need to
have a separate discussion of whether diagnostic functions belong in
contrib or core.
--
Bruce Momjian http://momjian.
very different from requiring the user to install a
> separate package.
I don't care what we do, but I do think we 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
then open a separate thread to discuss the future of
where we want diagnostic functions to be. It is too complicated to talk
about both issues in the same thread.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone
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 fun
ing late to this, but I think Robert is right. WAL 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 http://momjian.us
EnterpriseDB http://enterprisedb.com
On Sun, Jun 14, 2015 at 12:05:54PM +0100, Dean Rasheed wrote:
> On 11 June 2015 at 05: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
On Thu, Aug 6, 2015 at 01:48:26PM -0400, Robert Haas wrote:
> On Thu, Aug 6, 2015 at 10:33 AM, Bruce Momjian wrote:
> > On Sun, Jun 14, 2015 at 12:05:54PM +0100, Dean Rasheed wrote:
> >> On 11 June 2015 at 05:15, Bruce Momjian wrote:
> >> > I have committed the
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
uuming.
>
> Oh. That's what it was combined with. I don't think it makes sense to
> throw these three items together into one note. Their benefit/risk
> potential is pretty different.
I believe Andres has made all these adjustments suggested. If not,
please let me kno
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 6
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 commit
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/r
On Thu, Aug 6, 2015 at 03:32:43PM -0700, Peter Geoghegan wrote:
> On Thu, Aug 6, 2015 at 3:06 PM, Bruce Momjian wrote:
> >> Below performance improvement in the "General Performance" category is
> >> missing:
> >>
> >> Reduce btree scan
On Fri, Jun 26, 2015 at 03:39:19PM -0700, Peter Geoghegan wrote:
> On Wed, Jun 10, 2015 at 9:15 PM, Bruce Momjian 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. Thi
that exact format for major releases though; there's 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
; > places.
>
> Which isn't exactly 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
te release note entry. We've left of
> many more significant things.
It is a bug fix.
> * 2015-04-14 [9fa8b0e] Peter ..: Move pg_upgrade from contrib/ to src/bin/
> 2015-04-13 [81134af] Peter ..: Move pgbench from contrib/ to src/bin/
> Should imo merged with all the other
On Thu, Aug 6, 2015 at 10:21:29PM -0400, Tom Lane wrote:
> Bruce Momjian 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
On Thu, Aug 6, 2015 at 11:19:46AM -0700, Jeff Janes wrote:
> On Wed, Jun 10, 2015 at 9:15 PM, 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
On Thu, Aug 6, 2015 at 06:42:38PM -0700, Peter Geoghegan wrote:
> On Thu, Aug 6, 2015 at 6:08 PM, Bruce Momjian 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
On Fri, Aug 7, 2015 at 11:53:30AM -0400, Robert Haas wrote:
> On Thu, Aug 6, 2015 at 10:24 PM, Bruce Momjian wrote:
> >> * 2014-10-02 [3acc10c9] Robert..: Increase the number of buffer mapping
> >> partition..
> >> should we mention this? This has been patched by
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 wrote:
> > > I though tabout this, and it is really an issue for FDW authors, not for
> > &g
the magnitude of this issue. 9.5 release note item
attached and applied.
--
Bruce Momjian http://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 th
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 com
On Sun, Aug 9, 2015 at 01:24:33AM +1200, David Rowley wrote:
>
> On 7 August 2015 at 14:24, Bruce Momjian wrote:
>
> On Tue, Jun 30, 2015 at 09:00:44PM +0200, Andres Freund wrote:
> > * 2014-12-08 [519b075] Simon ..: Use GetSystemTimeAsFileTime directly in
> wi
but not attributes
> like TABLESPACE or CONNECTION LIMIT. Other attributes like LC_COLLATE and
> LC_CTYPE can't be changed without recreating the DB, but those don't matter
> for the pg_upgrade case anyway.
>
> It seems those would be good material for another patch?
rmance for that type as compared to
> text/varchar(n). This needs to be highlighted.
>
> [1]
> http://www.postgresql.org/message-id/flat/CAM3SWZRRCs6KAyN-bDsh0_pG=8xm3fvcf1x9dlsvd3wvbt1...@mail.gmail.com#CAM3SWZRRCs6KAyN-bDsh0_pG=8xm3fvcf1x9dlsvd3wvbt1...@mail.gmail.com
I ha
On Wed, Aug 26, 2015 at 10:10:01AM -0700, Peter Geoghegan wrote:
> On Wed, Aug 26, 2015 at 7:33 AM, Bruce Momjian 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
y. We should at minimum have a canonical
> example of how to do it, but something built in would be even
> better.
Coming in late here, but have you looked at my locking presentation; I
think there are examples in there:
http://momjian.us/main/writings/pgsql/locking.pdf
--
Bru
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 wrote:
> > > I have applied the attached patch to document this in the data type docs.
&g
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-col
be run when a change like this
happens. The command string would write a status on another server or
send an email.
Based on the new s_s_name API, this would mean whenever we switch to a
different priority level, like 1 to 2, 2 to 3, or 2 to 1.
--
Bruce Momjian http://momjian.us
ow focused we are in working on a
few big 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 http://momjian.us
EnterpriseDB
src/tools/git_changelog should be modified to
output 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 http://mo
On Fri, Aug 28, 2015 at 05:32:38PM -0400, Tom Lane wrote:
> Alvaro Herrera 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
> >
sion for fastgetattr() 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
maybe 2% on an in-memory
SELECT-only workload. Same with a few 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 http://momjian.us
EnterpriseDB http://e
s to max out the CPU sooner.
--
Bruce Momjian http://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.po
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
> >
old and new
servers, so doing something 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 http://momjian.us
EnterpriseDB
| {}
I can see them having problems with a user being able to see the SSL
remote user names of all connected users.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql
ling will be needed soon, 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 http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their o
On Sun, Aug 30, 2015 at 03:31:10PM +0100, Simon Riggs wrote:
> On 30 August 2015 at 03:17, Bruce Momjian 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
be a community requirement. It might not work, but
right now, it is the only possible approach I can see.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pg
n sharding
at all, but at least it is time 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 FW
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 t
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 writes:
> > > On Tue, Jul 7, 2015 at 11:48:13AM -0400, Tom Lane wrote:
> > >> It's a bug. Back-patch as needed.
> &
for users, and needs a simpler interface, and
one that can be better optimized internally. I assume FDW-based
sharding will benefit from that work as well.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has thei
gt; > +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 http://momjian.us
EnterpriseDB
solution 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 http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Eve
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 http://momjian.us
EnterpriseDB http://enterprisedb.com
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 wrote:
> >
> >>>I think it would help if its noted somewhere in the document as it would
> &
-sharding 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 h
its, like better FDWs and 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.
--
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
d partitioning, and I think we need to fix that.
Hopefully we don't do the same thing with sharding.)
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mail
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, 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 12:40:40PM -0400, Robert Haas wrote:
> On Tue, Sep 1, 2015 at 6:55 AM, Bruce Momjian wrote:
> > I assumed these queries were going to be solved by sending as digested
> > data as possible to the coordinator, and having the coordinator complete
> > any
t; 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 assume that the old
and
a 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
Date: Sat Feb 16 18:52:50 2013 -0500
Warn about i
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
use these will be upgraded from the old
cluster.
Also, any custom full text search files (dictionary, synonym,
thesaurus, stop words) must also be copied to the new cluster.
Is that sufficient? I think the thing that is missing is the need to
modify postgresql.conf, b
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
&
eplication 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
nchronous_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 http://momjian.us
EnterpriseDB
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
ing selected data around.
--
Bruce Momjian http://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
which I know 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
eplication has similar 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
d only on the slaves.
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 http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has th
ter
the switch.
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
al
hat the
> >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
e order of 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.
--
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 l
nd
change it there, and finally, remove the old password. Is that the
process? I am not realizing that without multiple plasswords, this is a
hard problem.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their o
one wants that complexity. 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 http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has th
, but
> 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 http://momjian.us
EnterpriseDB http://enterprisedb.com
+
gt;
> 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 http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyo
. 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 http://momjian.us
EnterpriseDB http:/
uld we do it?
I have shell scripts 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 http://momjian.us
EnterpriseDB
uld be worth 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 http://momjian.us
En
On Wed, Sep 9, 2015 at 06:14:28PM +0300, Ildus Kurbangaliev wrote:
> On Wed, 9 Sep 2015 10:52:02 -0400
> Bruce Momjian wrote:
>
> > On Wed, Jun 17, 2015 at 07:58:21AM +0200, CPT wrote:
> > > Hi all;
> > >
> > > We are running a multi-TB bioinform
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?
--
Bruce M
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.
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:
blems
> can be fixed or mitigated but it is a case where a test case demonstrates
> the problem even if that requires patching PostgreSQL.
We suspected trying to use mmap would have costs, but it is nice to hear
actual details about it.
--
Bruce Momjian http://momji
ne larger question is how many of these things that Postgres needs are
needed by other applications? I doubt Postgres is large enough to
warrant changes on its own.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+
mance.
>
> Does anyone know if this has been done before with Postgres? I would have
> assumed yes, but I'm not finding anything in Google about people having done
> this.
Not that I know of.
--
Bruce Momjian http://momjian.us
EnterpriseDB
to run as superuser in these cases, but it is hard to see
why would need to do that in the normal case.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pg
501 - 600 of 17339 matches
Mail list logo
