On Wed, Feb 24, 2016 at 09:34:37AM -0500, Bruce Momjian wrote:
> > I have nothing against particular FDW advances. However, it's unclear for me
> > that FDW should be the only sharding approach.
> > It's unproven that FDW can do work that Postgres XC/XL does. With FDW we can
ome
> product providing functionality similar to Oracle RAC or MySQL
> Gallera. It is yet another direction of cluster development for
> PostgreSQL. Let's be more open and flexible.
Yes, I listed only the workloads I could think of. It would be helpful
to list more workloads and start to decide what can
o be
maintained anymore, or used by existing solutions.
--
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
ime. But I haven't heard
> about it.
No, you didn't miss it. :-( We just haven't gotten to studying that
yet. One possible outcome is that built-in Postgres has non-cross-node
sharding, and forks of Postgres have cross-node sharding, again assuming
cross-node sharding requires an unacceptable am
On Wed, Feb 24, 2016 at 01:08:29AM +, Simon Riggs wrote:
> On 23 February 2016 at 16:43, Bruce Momjian <br...@momjian.us> wrote:
>
> There was discussion at the FOSDEM/PGDay Developer Meeting
> (https://wiki.postgresql.org/wiki/FOSDEM/PGDay_2016_Developer_Meeting)
&g
On Thu, Aug 7, 2014 at 01:26:24PM +0900, Fujii Masao wrote:
> On Thu, Aug 7, 2014 at 2:17 AM, Bruce Momjian <br...@momjian.us> wrote:
> >
> > Seems we still have not addressed this.
>
> Thanks for the reminder :) I'm not sure if I have time to work on this
> for a
On Tue, Feb 23, 2016 at 09:54:46AM -0700, David G. Johnston wrote:
> On Tue, Feb 23, 2016 at 9:43 AM, Bruce Momjian <br...@momjian.us> wrote:
>
> 4. Cross-node read-write queries:
>
> This will require a global snapshot manager and global snapshot manager.
>
>
approach.
--
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 mailin
>>back-patchable bug fixes in the same area.
> >
> > Agreed.
>
> +1. I think this is clearly a back-patchable fix.
Fix applied to head and 9.5.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
On Fri, Feb 19, 2016 at 08:20:31AM -0800, Andres Freund wrote:
> On 2016-02-19 10:14:47 -0500, Bruce Momjian wrote:
> > We have already hesitated to record DDL changes for
> > logical replication because of the code size, maintenance overhead, and
> > testing required.
&
On Fri, Feb 19, 2016 at 11:20:13AM -0500, David Steele wrote:
> On 2/19/16 10:54 AM, Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> >
> >> Understood. My point is that there is a short list of read events, and
> >> many DDL events. We have alread
On Fri, Feb 19, 2016 at 12:54:17PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Understood. My point is that there is a short list of read events, and
> > many DDL events. We have already hesitated to record DDL changes for
> > logical replication
the WAL to do the auditing, but the same
facility could be used for both, e.g. output some JSON standard format
that both logical replication and auditing could understand.
The bottom line is we need to crack the record-DDL nut somehow, and at
least in this case, we have two use-cases
On Mon, Feb 15, 2016 at 06:32:06PM +0100, Magnus Hagander wrote:
>
>
> On Mon, Feb 15, 2016 at 6:29 PM, Bruce Momjian <br...@momjian.us> wrote:
>
> Someone on IRC reported that if they had run the pg_upgrade-created
> delete_old_cluster.sh shell script it woul
hether to
> trust the specific group, but I don't think there's any practical
> way to do that. System conventions vary too much.
Should we have a GUC to control the group permissions restriction? I
can certainly see value in allowing for group access to the certificat
On Wed, Feb 17, 2016 at 01:59:09PM +0530, Robert Haas wrote:
> On Wed, Feb 17, 2016 at 5:20 AM, Bruce Momjian <br...@momjian.us> wrote:
> > On Fri, Feb 5, 2016 at 01:16:25PM -0500, Stephen Frost wrote:
> >> Looking at pgaudit and the other approaches to auditing which have
code seems very similar to how to handle the logical
replication of DDL commands. First, have we looked into hooking
auditing into scanning logical replication contents, and second, how are
we handling the logical replication of DDL and could we use the same
approach for auditing?
--
Bruce Momjian
On Tue, Feb 16, 2016 at 03:57:01PM -0300, Alvaro Herrera wrote:
> Masahiko Sawada wrote:
> > On Wed, Feb 17, 2016 at 12:02 AM, Bruce Momjian <br...@momjian.us> wrote:
> > > On Tue, Feb 16, 2016 at 11:56:25PM +0900, Masahiko Sawada wrote:
> > >> > I agr
3d458d10c4a8f47, which is
> > the commit that should have been listed here, likely.
>
> Are you willing to fix it?
Fixed and patched back to 9.5.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ A
for every upgrade from
> > pre-9.6 to 9.6+, so why not just hard-code in the functions we need. We
> > can remove it once 9.5 is end-of-life.
> >
>
> Hm, we should rather remove the source code around PAGE_CONVERSION and
> page.c at 9.6?
Yes. I can do it if you wi
So, the question is, do we feel that PgLogical is best and recommended
way to do logical replication. If it is, then having it in core makes
sense.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprised
o 9.6+, so why not just hard-code in the functions we need. We
can remove it once 9.5 is end-of-life.
--
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. +
+
directory inside the old data directory, only a check for tablespace
directories in the old cluster. (I never anticipated someone would do
this.)
The attached patch adds the proper check. This should be backpatched to
all supported Postgres versions.
--
Bruce Momjian <br...@momjian
On Thu, Feb 11, 2016 at 07:18:46PM -0500, Bruce Momjian wrote:
> No, that is not an improvement --- see my previous comment:
>
> > We could get more sophisticated by checking the catalog version number
> > where the format was changed, but that doesn't seem worth it, and is
ering of the
> pg_controldata entries.
By testing for '906', you prevent users from using pg_upgrade to go from
one catalog version of 9.6 to a later one. Few people may want to do
it, but it should work.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
is the limit on subject size. Sometimes it's very
> difficult to be sufficiently communicative in, say, 50 characters.
Agreed, but that is a gitweb limit we can't control, I think.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
d -e :a -e '/./,$!d;/^\n*$/{$d;N;};/\n$/ba'
and this removes adjacent blank lines:
cat --squeeze-blank
I can publish my script at the appropriate time.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprised
uld like whatever
> template is decided upon to be included in our git repo and then we
> should be able to make it the template that's opened up when people go
> to commit pretty easily.
OK, but keep in mind whatever script committers user should remove tags
that are empty after exiting th
--
Report by
Patch by
Reviewed by
Backpatch through
The dashed lines are used to specify a target length for the summary
line and are automatically removed before the commit message is posted.
--
Bruce Momjian <br...@momjian
Reviewed-by:
Backpatch through:
I had to make up "Patch-by:" as it wasn't listed.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you wi
On Thu, Jan 28, 2016 at 03:52:00AM -0500, Bruce Momjian wrote:
> There has been a request in the FOSDEM developers meeting that
> committers use a more consistent format for commit messages. This is
> the format I use:
Here is an updated version that includes a potential b
on those suggestions:
-- email subject limit -
-- gitweb summary limit --
Reported-by:
Bug:
Author:
Reviewed-by:
Tested-by:
Backpatch-through:
--
Bruc
mplicitly pejorative. Maybe we could find another
> way to phrase that, like "Design-suggestions-by" or maybe a more
> general "Suggestions-by".
I wasn't sure if "User-Interface-Bikeshedded-By" related to the patch,
or to the discussion of labels for the comm
k binary format from STS but not previous LTS.
> This allows two LTS versions per 5 year support cycle
I just don't buy the Ubuntu release model for our database. Ubuntu is
trying to balance hot features vs stability, while we are really focused
on stability, similar to Debian.
--
Bruce Momj
like the 8.X series of release
dates. Everyone might be fine with that, but we had better be prepared
for November-February major release dates going forward.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ A
tly unfair.
Unfair or not, that is probably the effect. I can also see people
publishing git trees to avoid this roadblock.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ A
is we can't sustain five commitfests and stay on time
--- we need to go back to four, which I think is what we used to do. We
twiddled our thumbs back in the September-release years too, but had
consistency because twiddling was built into the schedule.
--
Bruce Momjia
On Thu, Jan 21, 2016 at 12:05:19AM +0100, Andres Freund wrote:
> On 2016-01-20 18:02:20 -0500, Bruce Momjian wrote:
> > The two sobering blockers I can remember were multi-xact (9.3) and JSONB
> > compression (9.4).
>
> I don't see how those compare. The multixact stu
On Wed, Jan 20, 2016 at 05:56:27PM -0500, Tom Lane wrote:
> Bruce Momjian <br...@momjian.us> writes:
> > On Wed, Jan 20, 2016 at 01:59:59PM -0800, Peter Geoghegan wrote:
> >> I think that we've learned some lessons from the problems with 9.3. I
> >> don't think th
On Wed, Jan 20, 2016 at 04:48:16PM +0100, Andres Freund wrote:
> On 2016-01-20 10:40:14 -0500, Bruce Momjian wrote:
> > We have gotten off of that cycle in the last two major releases, and
> > this isn't going to improve as long as we have commitfests starting
> > after
> do.
So, if that is true, and people are not improving the TODO list
situation, how likely will a bug tracker be at improving or
deteriorating the situation?
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.c
. It might be a good idea to formally state what those lessons
> are.
I do think that is effectively a lesson we learned, wrong or not.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so
o integration and get to beta in May --- at least we
have never been able to do that.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, s
t. If we were to expand that to
cover reviewers, we would then be overburdinging that system and we
would probably end up removing all names from the release notes.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
in different schemas. So the only
> >solution seems to be explicit schema for statistics.
>
> That solution seems good to me.
>
> (with apologies for not having looked at the rest of this much at all)
Woh, this will be an optimizer game-changer, from the us
y but I think that as long as dynloader.h is
> copied in include/ we had better change that as well, and it makes the
> code cleaner.
I have applied this patch all the way back to 9.1. This means PL/Java
can be cleanly built via MSVC on Windows for all installs after the nex
On Mon, Jan 18, 2016 at 07:50:12PM -0500, Bruce Momjian wrote:
> > >>>> 1) Change NextXID output format from "%u/%u" to "%u:%u"
> > >>>>(see recent hackers thread)
> > >>>
e in the source installation into
> one session.
The fix for that would be for pg_upgrade to change
check_loadable_libraries() to start a new session for each LOAD command.
Would you like that done?
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
or all
plan reuses, rather than waiting for five and then perhaps getting this
bad behavior.
--
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 g
On Mon, Jan 18, 2016 at 01:10:05PM -0500, Tom Lane wrote:
> Bruce Momjian <br...@momjian.us> writes:
> > On Mon, Jan 11, 2016 at 10:44:42AM -0500, Tom Lane wrote:
> >> But it gets worse: a report today in pgsql-general points out that
> >> even if you have the t
fOn Mon, Jan 18, 2016 at 01:54:02PM -0800, Joe Conway wrote:
> On 01/18/2016 01:47 PM, Bruce Momjian wrote:
> > On Sun, Jan 17, 2016 at 02:24:46PM -0800, Joe Conway wrote:
> >> On 01/16/2016 06:02 AM, Michael Paquier wrote:
> >>> On Wed, Dec 30, 2015 at 9:08 AM,
On Mon, Jan 18, 2016 at 02:14:11PM -0500, Tom Lane wrote:
> Bruce Momjian <br...@momjian.us> writes:
> > I never understood why we don't just keep the selectivity estimates of
> > previous plans and just reuse the plan if the selectivity estimates are
> > similar.
ot;) :
> > _("off"));
> > ! printf(_("Latest checkpoint's NextXID: %u:%u\n"),
> > This should be definitely a separate patch.
>
> Ok. Notwithstanding Simon's reply, there seems to be consensus that this
> is the way to go. Will commit it this
can now see storage latency that is practically
> on-par with things like lock acquisition[1].
How is this different from Fusion I/O devices, which have been around
for years?
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB ht
ed new
ones.
That all seems very straight-forward to me.
--
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
? Well, moreso: it's a range of values
> for a range of heap pages.
FYI, that TODO entry was removed since July 9, probably as part of my
9.5 cleanup.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
^^^group
I assume we don't want to change that.
--
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 +
On Sun, Jan 17, 2016 at 01:49:19PM -0500, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > > pgbackrest:
> > >
> > > To run pgbackrest as a non-superuser and not the 'postgres' system
> > > user, grant the pg_backup role to the backre
at function to the backup role. This is another
example where different backup tools need different permissions.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so o
add additional functions in some cases. In particular, we
> will need alternate versions of pg_terminate_backend and
> pg_cancel_backend. One thought I had was to make that
Like these? Could we define own-user-type rights?
--
Bruce Momjian <br...@momjian.us>http://momjian
-bMU4WiS1pjtBwRvH4cE-nN9y5gj8ZLCO7KMrlvYg/view
>
> > Fuzzer:
> > https://docs.google.com/presentation/d/12Dd9Bhcugkdi2w0ye4T1fy9ccjconJEz9cNthdeyH7k/view
>
> Very cool, thanks!
No, you need to see the video! It was amazing. I couldn't believe what
I was hearing. I was like
t every backup soltuion to view that as a feature which they
> want to support, as there are environments which will find it desirable,
> at a minimum, and even some which will require it.
pg_dump doesn't need to read the PGDATA directory, and I thought this
permission was to be used by pg_d
but it seems others do...).
I think the source of that is that many people have asked for
backup-only uses, and I thought running pg_dump or pg_dumpall was one of
those cases.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
a.user_id,
mime m,
users uc,
users uo
WHERE (
s.mime_id = 904
OR s.mime_id = 908 )
AND m.mime_id = o.mime_id
AND o.owner = uo.user_id
AND o.creator = uc.user_id
ORDER BY
s.mtime
al, i.e. it would be nice of one of these was more active in the
second half of the checkpoint period. I assume that is what is being
discussed here.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
On Tue, Jan 5, 2016 at 04:53:26PM +0100, Andres Freund wrote:
> On 2016-01-05 10:48:43 -0500, Bruce Momjian wrote:
> > On Tue, Jan 5, 2016 at 04:42:24PM +0100, Andres Freund wrote:
> > > On 2016-01-05 10:40:13 -0500, Bruce Momjian wrote:
> > > > On Tue, Jan 5, 20
On Tue, Jan 5, 2016 at 04:31:15PM +0100, Andres Freund wrote:
> On 2016-01-05 10:28:25 -0500, Bruce Momjian wrote:
> > On Sun, Dec 13, 2015 at 12:35:34PM +0100, Andres Freund wrote:
> > > > > One thing to call out is that an "oversized" s_lock can now make
&g
On Tue, Jan 5, 2016 at 04:42:24PM +0100, Andres Freund wrote:
> On 2016-01-05 10:40:13 -0500, Bruce Momjian wrote:
> > On Tue, Jan 5, 2016 at 04:31:15PM +0100, Andres Freund wrote:
> > > On 2016-01-05 10:28:25 -0500, Bruce Momjian wrote:
> > > Yes? But it's ok sizew
an.
>
> Ok cool. I'm not particularly concerned either, just didn't want to slip
> that in without having it called out.
Uh, didn't you and I work in 9.5 to make sure the BufferDesc was 64-byte
aligned to avoid double-CPU cache invalidation that was causing
performance prob
On Sun, Jan 3, 2016 at 12:35:02PM -0500, Tom Lane wrote:
> Robert Haas <robertmh...@gmail.com> writes:
> > On Dec 31, 2015, at 1:04 PM, Bruce Momjian <br...@momjian.us> wrote:
> >> Let's hold this for 9.5.1 and all minor releases will get it at the same
> >&
On Mon, Jan 4, 2016 at 12:59:26PM -0500, Tom Lane wrote:
> Bruce Momjian <br...@momjian.us> writes:
> > On Sun, Jan 3, 2016 at 12:35:02PM -0500, Tom Lane wrote:
> >> If we're willing to allow 9.4.6 to install different files than 9.4.5
> >> does, I don't
te the copyright headers to 2016 :)
Yes, it is on my January 1 list of things to do. I will do it today.
--
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 b
On Sat, Jan 2, 2016 at 12:00:36PM -0500, Bruce Momjian wrote:
> On Fri, Jan 1, 2016 at 04:43:07PM +0900, Michael Paquier wrote:
> > Hi all,
> >
> > Happy new year to all and best wishes!
> >
> > I guess that the following command followed by a commit is th
than requiring the entire pg_stats version to be bumped. I am not sure
how we would consistently record the data type name. pg_upgrade
preserves pg_type.oid, so that would work for it, but pg_type.oid is not
preserved for non-pg_upgrade usage of non-builtin data types. For those
cases, I gue
On Thu, Dec 31, 2015 at 12:50:13AM -0500, Bruce Momjian wrote:
> On Wed, Dec 30, 2015 at 11:57:45PM -0500, Tom Lane wrote:
> > Bruce Momjian <br...@momjian.us> writes:
> > > Oops. Once this patch is applied, it is only going to take effect when
> > > someone _in
ut it seems risky:
> > conversion of NaN to an integer isn't well defined.
>
> Am I going to have to fire up the emulator again?
Greg's lightning talk in Vienna about how he got the emulator working
was priceless. I know he posted the VAX results, but how he got them
was amazing.
9.4 all vanish from the earth.
I think we decided that only older _minor_ versions would need your
workaround, so anyone doing a minor upgrade after 9.5.1 and friends
would be fine.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB ht
On Wed, Dec 30, 2015 at 11:57:45PM -0500, Tom Lane wrote:
> Bruce Momjian <br...@momjian.us> writes:
> > Oops. Once this patch is applied, it is only going to take effect when
> > someone _installs_ Postgres. Even an initdb will not add the file.
> > This means that
is a Windows build issue
which I cannot test. I would need someone else to apply it after
testing.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am
ry to marry pg_stat_statements and auto_explain for
> the next iteration of "online query plans" extension I was proposing a few
> months ago, and the first thing I was going to look into is rectifying this
> problem with IN() jumbling. So, have a +1 from me.
Is this a TODO?
--
Bru
On Wed, Dec 30, 2015 at 05:21:05PM -0800, Peter Geoghegan wrote:
> On Wed, Dec 30, 2015 at 5:20 PM, Bruce Momjian <br...@momjian.us> wrote:
> > Is this a TODO?
>
> It's on my (very long) personal TODO list. It would be great if
> someone else took it, though. So, yes.
On Tue, Dec 29, 2015 at 02:08:19PM -0500, Bruce Momjian wrote:
> In the Windows MSVC build, we handle pg_config_os.h in the Perl scripts,
> but not dynloader.h. The attached patch copies the process used for
> pg_config_os.h to handle dynloader.h. I believe this is the only *.h
> f
d be noted, recorded somewhere so this introduce possible
> >> > compatibility
> >> > issue - due default processing .psqlrc.
> >>
> >> That's written in the commit log, so I guess that's fine.
> >
> > ook
>
> Bruce uses the commit log to pre
appear in all the next minor version releases, including 9.5.1,
which should happen in the next 60 days.
Thanks.
--
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
On Tue, Dec 29, 2015 at 03:01:55PM -0500, Chapman Flack wrote:
> On 12/29/15 14:08, Bruce Momjian wrote:
>
> > This should fix the PL/Java Windows build problem. I don't think I will
> > get this patch into 9.5.0 but will put it in after 9.5.0 is released and
> > it wil
at can cause the data to be ignored.
--
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
tempt, somehow, ideally automatically by
> default
> * Ability to restart a failed upgrade attempt without doing a "double
> upgrade",
> i.e. ensure transformation is immutable
Have you forgotten how pg_upgrade works? This new vm file is only
created on the new cluster,
On Fri, Dec 4, 2015 at 07:09:03PM -0500, Chapman Flack wrote:
> On 12/04/15 12:56, Bruce Momjian wrote:
> >
> > OK, good logical reason to install dynloader.h on Windows.
>
> Ah! Thanks. I was starting to wonder whether I had said something wrong
> and been sent to
h? Mingw? MSVC? EDB's? OpenSCG?
Postgres Pro (Russian)?
Is this a change we need to make on the server end and then all the
installers will automatically install the file? It is present in all
Unix-like installs?
--
Bruce Momjian <br...@momjian.us>ht
On Wed, Dec 2, 2015 at 08:53:07AM +, Dave Page wrote:
> On Tue, Dec 1, 2015 at 9:55 PM, Bruce Momjian <br...@momjian.us> wrote:
> > On Tue, Dec 1, 2015 at 06:40:09PM -0300, Alvaro Herrera wrote:
> >> Bruce Momjian wrote:
> >>
> >> > Do we st
, e.g.
solid-state drives, might also be better modeled with a lower value for
random_page_cost.
What we don't have is way to know how much is in the cache, not only at
planning time, but at execution time. (Those times are often
different for prepared queries.) I think that is
Do we still have licensing issues if we ship Postgres and OpenSSL
together?
--
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 inscriptio
On Tue, Dec 1, 2015 at 06:40:09PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Do we still have licensing issues if we ship Postgres and OpenSSL
> > together?
>
> See
> https://www.postgresql.org/message-id/20150801151410.GA28344%40awork2.anarazel.de
Tr
t to avoid the overhead of multiple coordinators, while those
using multiple coordinators are going to have to live with that
overhead.
I think an open question is what workloads can use a single coordinator?
Read-only? Long queries? Are those cases also ones where the
snapshot/transaction overhead is negligibl
s detail in the pg_upgrade manual page:
+ Since the format of visibility map has been changed in version 9.6,
+ pg_upgrade creates and rewrite new '_vm'
+ file even if upgrading from 9.5 or before to 9.6 or later with link mode
(-k).
--
Bruce Momjian <br...@momjian.us>http://momjia
On Mon, Nov 30, 2015 at 07:05:21PM +0100, Andres Freund wrote:
> On 2015-11-30 12:58:43 -0500, Bruce Momjian wrote:
> > I would not bother mentioning this detail in the pg_upgrade manual page:
> >
> > + Since the format of visibility map has been changed in version 9.
onment. So unless the
> makefile goes out of its way to circumvent it, you can just do
>
> COPT=-Werror
> export COPT
>
> and then run your usual configure/compile cycle. There's no
> specific need to modify the makefiles or pass extra arguments
> into make.
F
, so "page
info map" isn't very descriptive. "page status" or "page state" might
make more sense, but even then, free space is a kind of page
status/state. What is happening is that broadening the name to cover
both visibility and freeze state also encompasses free
On Wed, Nov 4, 2015 at 07:58:52AM -0500, Bruce Momjian wrote:
> [BCC to pgsql-cluster-hack...@postgresql.org]
>
> I have summarized the Vienna cluster summit meeting from last week by
> adding italicized answers to the agenda questions, even though we didn't
> fo
This git cartoon was too funny not to share:
http://xkcd.com/1597/
Maybe we need it on our git wiki page. ;-)
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I
601 - 700 of 16619 matches
Mail list logo
