rade never runs the old and new servers at the same time. I am
not sure if that would be OK, but I have never heard of problems related
to this. I am afraid you will just need to test it.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
On Tue, Sep 19, 2017 at 12:42:40PM -0700, Jeff Janes wrote:
> On Tue, Sep 19, 2017 at 12:20 PM, Bruce Momjian <br...@momjian.us> wrote:
>
> On Wed, Sep 6, 2017 at 04:19:52PM -0400, Stephen Cook wrote:
> > Hello!
> >
> > Is there a way to decrypt
;deployed SAP on PostgreSQL community edition?
> >
> >Is PostgreSQL community involved in any future road-map of SAP application
> >deployment on PostgreSQL?
>
>
> Does SAP support PostgreSQL ?
You would have to ask SAP, but the agreed-upon answer is no.
--
Bruc
, so using
those tools should work.
--
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. +
+ Ancient Roman grave inscription +
--
Se
> we should be considering for core, especially now that we've got a
> reasonable password-based authentication method with SCRAM.
Does LDAP do this too?
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+
hundreds.
I didn't backpatch this change since the original docs were not
incorrect.
--
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. +
+
> The idea is to minimize downtime.
You can't use streaming replication between different major versions.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once wa
On Tue, Jun 13, 2017 at 04:07:48PM -0400, Bruce Momjian wrote:
> On Fri, Jun 9, 2017 at 07:55:55AM -0700, Adrian Klaver wrote:
> I apologize for not being smarter on this thread. When I helped with
> the Windows port, I was told Windows didn't have hard links for use by
> tablespace
e but in pg_upgrade?
Nope, it is used only by transfer_relfile() calling linkFile().
--
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. +
+
pg_upgrade was added to the tree, I
see that the code even at that time used hard links on Windows. I have
created the attached patch which I will apply to all current Postgres
versions to fix this error.
Thanks for the report and the research. :-)
--
Bruce Momjian <br...@momjian.us>http:
nks to directories),
> the old data dir cannot be removed.
> With hard-links to file, we can get rid of the old data dir once we are sure
> that the upgrade is fine.
I was told junction points on Windows were hard links and no one has
ever complained about not being able to remove them
rs thread about that.
Amen to the usability of the archives with no thread breaks --- I am
sure that was not easy.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once wa
earch in front of our datasource right now.
Full text search of JSON and JSONB data is coming in Postgres 10, which
is to to be released in September of this year:
https://www.depesz.com/2017/04/04/waiting-for-postgresql-10-full-text-search-support-for-json-and-jsonb/
--
Bruce Momjian &
f the world, and not have to deal
> with replies to topics that I don't care about anyway.
You might want to look at PgLife, which gives you a read-only view of
what's currently happening in the Postgres community:
http://pglife.momjian.us/
--
Bruce Momjian <br...@momjian.us&g
On Tue, Feb 28, 2017 at 10:50:02PM +0100, Frazer McLean wrote:
> On 28 Feb 2017, at 21:51, Bruce Momjian wrote:
> >I have researched this and will post a blog and and document the fix in
> >the next few months. The reason you have to supply the entire
> >certificate
k the certificates as CAs so they are passed
from the server to the client. You are looking for the CA certificates
to say:
X509v3 Basic Constraints:
CA:TRUE
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
time zone.
Right, TIMESTAMP WITH TIME ZONE converts the timestamp value to the
local time zone on output. Imagine a monetary type that converted the
money amount to local currency on output --- that would be cool.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
on?
I am guessing someone at your site created it --- Postgres does not
create such directories by default.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I.
is version 9.4.9.
>
> stopped waiting
>
> pg_ctl: could not start server
>
> Examine the log output.
>
>
>
> Is it possible to upgrade Postgres 9.4.9 to 9.6 with pg_upgrade option or I
> need to do it through pg_dump only? Any help would be appreciated.
It should work. I th
On Thu, Oct 13, 2016 at 04:35:35PM +0200, Andreas Joseph Krogh wrote:
> På torsdag 13. oktober 2016 kl. 16:09:34, skrev Bruce Momjian
> <br...@momjian.us
> >:
>
> On Thu, Oct 13, 2016 at 10:14:08AM +0200, Andreas Joseph Krogh wrote:
> > I would assume
Of course, you can create a custom version of pg_upgrade 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, so you will be. +
+ Ancient Rom
d of locking
on queries and stuff. I don't know any numbers myself.
--
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. +
+ Ancient Roman gra
n, and more PR than reality.
>
> But there certainly are some things that can be made more efficient if
> you don't care about durability and replication.
Agreed. Stonebraker measured Shore DBMS, which is an academic database:
http://research.cs.wisc.edu/shore/
If he had measure
OP you do not show overriding pg_upgrade defaults for ports, so
> assuming the scripts are looking for the live ports and not the upgrade
> ports that should not be an issue.
Agreed. I have no idea what would cause this, and have never heard a
report like this before.
--
Bruce Momjia
thousands of objects, you need to do a minor version
> upgrade to at least 9.1.19 before doing the major version upgrade. If
> you are on 9.0 or before with so many objects, you don't have a lot of
> good options.
Yeah, that's what I remember. Thanks for the details.
--
Bruce Momjian
Unix socket naming, it starts to get messy.
Well, pg_upgrade uses a socket created in the current run directory, so
that should be fine.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once
s, you would need a mode that prevented new-format writes on the new
server.
--
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. +
+ Ancie
hen uninstall PG, reinstall the older version
> and restart. Lather, rinse, repeat until it upgrades cleanly.
pg_upgrade needs to run the old and new server binaries as part of its
operation, so that would not work.
--
Bruce Momjian <br...@momjian.us>
On Fri, Jul 29, 2016 at 07:49:36PM +0200, Maeldron T. wrote:
> And yes, I hate upgrading PostgreSQL especially on FreeBSD where pg_upgrade
> isn’t really an option.
Is that because it is hard to install the old and new clusters on the
same server on FreeBSD?
--
Bruce Momjia
On Wed, Jul 27, 2016 at 01:02:40PM -0400, Bruce Momjian wrote:
> Watching the video was helpful:
>
> https://vimeo.com/145842299
>
> You can see the failover happened because of various user errors. That
> doesn't excuse our bug, but I am not sure exactly how much
I thought we were talking about pg_upgrade in -k link mode? or does that
> rely on a dump/restore --schema-only operation to create the metadata?
Yes, it does, with our without -k --- -k only controls file link vs file
copy.
--
Bruce Momjian <br...@momjian.us>http:
lem any more.
Uh, that is only true if the slowness was in _dumping_ many objects.
Most of the fixes have been for _restoring_ many objects, and that is
done in the new cluster, so they should be OK.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
En
No need to ever wait a "couple of days" as OP claims. :)
>
> What really bites is the analyze afterwards. That's the part
> that takes too long (yes, --in-stages helps some). Would love
> to see progress made there.
Agreed. I will try to prioritize it.
--
Bruce Momjia
>
> Then again, if you want to report a pg_upgrade failure, I suggest you
> open a thread of your own rather than hijack this one.
You need only minimal disk space when using pg_upgrade --link. I agree
we would like a full bug report so we can find a fix for you.
--
Bruce Momjian &
mysql provides same functionality for rollback like oracle/db2
> provides. That is,
> rollback on a minor version upgrade possible, but not on major version
> upgrade.
>
> I am surprised PG does not even allow minor version rollback.
Uh, I thought we did. Perhaps there a few that
g, whether on PostgreSQL or MySQL, if you want to
> go
> back a major release, you would need to dump./ reload that 1TB database …
What they wanted, and I think was mentioned in the document, was that
they wanted to upgrade the slaves independently, then the master. I
think MySQL s
On Wed, Jul 27, 2016 at 12:59:59PM -0400, Bruce Momjian wrote:
> On Wed, Jul 27, 2016 at 12:47:24PM -0400, Bruce Momjian wrote:
> > On Wed, Jul 27, 2016 at 12:33:27PM -0400, Rakesh Kumar wrote:
> > > On Wed, Jul 27, 2016 at 11:45 AM, Bruce Momjian <br...@momjian.us> wrote
can see the failover happened because of various user errors. That
doesn't excuse our bug, but I am not sure exactly how much they
understood of Postgres behavior. His talk near the end about the
replication infrastucture being exposed to them was also interesting.
--
Bruce Momjian
On Wed, Jul 27, 2016 at 12:47:24PM -0400, Bruce Momjian wrote:
> On Wed, Jul 27, 2016 at 12:33:27PM -0400, Rakesh Kumar wrote:
> > On Wed, Jul 27, 2016 at 11:45 AM, Bruce Momjian <br...@momjian.us> wrote:
> >
> > > I agree, but I am not sure how to improve
On Wed, Jul 27, 2016 at 12:51:40PM -0400, Rakesh Kumar wrote:
> On Wed, Jul 27, 2016 at 12:47 PM, Bruce Momjian <br...@momjian.us> wrote:
>
> > Yes. I was saying I don't know how to improve pg_upgrade to address it.
>
> This problem is there even in oracle/db2/sqlse
On Wed, Jul 27, 2016 at 12:33:27PM -0400, Rakesh Kumar wrote:
> On Wed, Jul 27, 2016 at 11:45 AM, Bruce Momjian <br...@momjian.us> wrote:
>
> > I agree, but I am not sure how to improve it. The big complaint I have
> > heard is that once you upgrade and open up writes on
re-apply those writes to the old server if you need to
fall back to the old server. I also don't see how to improve that either.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
On Fri, Jul 1, 2016 at 05:39:28PM -0400, Bruce Momjian wrote:
> > Replacing beta1 with beta2 leads to a 404 (for both direct download links)
>
> Yes, I confirmed in a later email that it is still broken.
>
> It was also reported by someone else today:
>
>
>
On Fri, Jul 1, 2016 at 10:12:46PM +0200, Thomas Kellerer wrote:
> Bruce Momjian schrieb am 28.06.2016 um 05:36:
> >On Fri, Jun 24, 2016 at 07:44:17AM +0200, Thomas Kellerer wrote:
> >>the Beta2 downloads on
> >>
> >> http://www.enterprisedb.com/products-serv
a1 for the Windows 64bit builds.
>
> All others properly link to beta1
This looks fixed now.
--
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. +
+
te to this thread, but one item not discussed about
columnar storage is the use of compression of identical column values
across rows. Existing Postgres storage only compresses single values,
not values across rows.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
Enterpri
that it can't
> find "orafunc" on 9.5, which is true. Is there a standard way of
> handling this situation?
Uh, I would uninstall the extension on the old cluster and reinstall it
on the new one.
--
Bruce Momjian <br...@momjian.us>http://momjian
On Wed, Apr 27, 2016 at 10:30:41AM -0400, Bruce Momjian wrote:
> On Wed, Apr 27, 2016 at 10:24:36AM -0400, Rakesh Kumar wrote:
> > [PUsaBSKn_n] Compose (@composeio)
> > 4/26/16, 1:24 PM
> > You can now upgrade your #PostgreSQL 9.4 to 9.5 easily at Compose. buff.l
oyment where we may, or may not, run the pg_upgrade tool.
The only _zero-downtime_ upgrade option is with logical-based
replication like Slony.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you ar
On Tue, Mar 22, 2016 at 10:16:22AM -0600, Scott Marlowe wrote:
> On Tue, Mar 22, 2016 at 9:15 AM, Thomas Kellerer <spam_ea...@gmx.net> wrote:
> > Bruce Momjian schrieb am 22.03.2016 um 16:07:
> >>
> >> However, I do think database upgrades are easier with Orac
g. For me,
this chart summarizes it:
HA Scaling Upgrade Add/Remove
Oracle RAC 50% 50%easyeasy
Streaming Rep. 100% 25%* hardeasy
Sharding 0%100%hardhard
* Allows read scaling
--
On Fri, Feb 19, 2016 at 02:49:16PM +0100, s d wrote:
> On 19 February 2016 at 14:19, Bruce Momjian <br...@momjian.us> wrote:
> > Ah, no. That's not possible
> >
> >
> > ...not possible, Yet.
> >
> > PostgreSQL grows by add
dding the features people need and its changing rapidly.
I wonder if PLPerl could be used to extract the words from a PDF
document and create a tsvector column from it.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.co
Just to clarify, pg_upgrade handles cases where the old/new clusters
either both have checksums, or neither you can't change the
checksum setting during pg_upgrade.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.
email readers make it difficult to inline quote stuff. Trimming
text is particularly hard on mobile devices. As more people use
web-based or mobile email clients, will the "nice" type of email
formatting become rarer and rarer?
--
Bruce Momjian <br...@momjian.us>http:/
e improved. I know of no such work for 9.6,
and it is unlikely it will be done in time for 9.6.
--
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
e.g. laws to compensate victims of carelessly unsafe
environments have yielded many unethical personal injury lawyers in the
USA. Therefore, we need to be careful of negative CoC effects.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
de Secondary database so that I
> don’t have to build standby again from the scratch after upgrading primary
> database?
Yes, read the 9.5 docs for upgrading the standby --- it also works for
9.4 and earlier:
http://momjian.us/main/blogs/pgblog/2015.html#June_10_2015
--
simplest solution is to wait for 9.4.6 to be released and test 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
tes:
> >> On 11/27/2015 08:15 AM, Bruce Momjian wrote:
> >>> My guess is you are sharing the constraint name "seqno_not_null" with
> >>> multiple tables. I think you are going to have to dig into the system
> >>> tables
; I have no idea, but this is a pg_dump bug or inconsistent system tables,
> rather than a pg_upgrade-specific bug.
>
>
> Any recommendation on how to proceed?
My guess is you are sharing the constraint name "seqno_not_null" with
multiple tables. I think you
gt; "seqno_not_null" for relation "js_activity_2011" already exists
> Command was: ALTER TABLE "js_activity_2011"
> ADD CONSTRAINT "seqno_not_null" CHECK (("seqno" IS NOT NULL)) NOT VALID;
I have no idea, but this is a pg_dump
od news is that the system generated an error
message that helped diagnose the problem, and the 9.5 error message is
much clearer.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I
asically what you need to do after changing
the ownership of the Postgres file system files.
You can see the 9.5 requirements in the pg_upgrade function
check_is_install_user(). You might as well just honor what that
requires as you will eventually be moving to 9.5.
--
Bruce Momjian &
ion?
I think you want the HAVING clause, e.g. HAVING COUNT(*) > 8.
--
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 Wed, May 13, 2015 at 01:40:41PM -0400, Bruce Momjian wrote:
> > I can't find any way to produce the output '-09:00' . There's no apparent
> > way
> > to add an additional width-specifier. HH24 is clearly not constrained to be
> > 2
> > digits wide, since &quo
On Thu, May 14, 2015 at 01:02:01PM -0400, Bruce Momjian wrote:
> On Sun, Feb 10, 2013 at 06:27:02PM -0500, Tom Lane wrote:
> > Jeremy Lowery <jslow...@gmail.com> writes:
> > > I load and dump text files with currency values in it. The decimal in
> > > the
all statements that update data?
Not really. Is this something we should document better?
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-general mailin
n. Unless you want to use --link-dest.
> In which case I think the cmd would be like:
>
> rsync --archive --delete --hard-links --size-only --link-dest=old_pgdata
> new_pgdata remote_dir
>
> I'm gonna try this now, will report back.
No, you are copying "old_pgdata and
e, will be run on the
standbys. You can see all the results of the patch here:
http://momjian.us/pgsql_docs/pgupgrade.html
Thanks.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has
rently part of community Postgres so you will need to
report it to them directly.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-general mailing lis
eport is in the right place.
Huh, why did we decide that when the community doesn't control any of
it? That doesn't make any sense.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own
On Mon, Aug 31, 2015 at 09:58:36AM -0700, Joshua Drake wrote:
> On 08/31/2015 09:37 AM, Bruce Momjian wrote:
> >On Mon, Aug 31, 2015 at 12:30:52PM -0300, Alvaro Herrera wrote:
> >>>BDR is not currently part of community Postgres so you will need to
> >&
useful to them, just like they shape Postgres
> itself. If other people want to join the team developing BDR, they are
> most welcome.
If you think things are moving a positive direction for inclusion,
that's fine with me. I had not seen much activity recently.
--
Bruce Momjian
/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-general mailing list (pgsql-general@postgresql.org)
To make
minor-release
downgrading is fine in this case.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
avoided this fate.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http
On Fri, May 15, 2015 at 01:10:27PM +0200, Michael Meskes wrote:
On 14.05.2015 19:35, Bruce Momjian wrote:
On Fri, May 31, 2013 at 02:26:08PM +0200, Leif Jensen wrote:
Hi guys.
In the ECPG manual (including latest 9.1.9) about ECPG SQL SET
CONNECTION connection name; it is stated
On Fri, May 15, 2015 at 10:49:43AM -0400, Stephen Frost wrote:
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
On Mon, Mar 9, 2015 at 12:43:05PM -0400, Bruce Momjian wrote:
On Fri, Mar 6, 2015 at 06:10:15PM -0500, Stephen Frost wrote:
The first is required or anyone who has done
On Fri, May 15, 2015 at 10:51:15AM -0400, Bruce Momjian wrote:
On Fri, May 15, 2015 at 10:49:43AM -0400, Stephen Frost wrote:
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
On Mon, Mar 9, 2015 at 12:43:05PM -0400, Bruce Momjian wrote:
On Fri, Mar 6, 2015 at 06:10:15PM -0500
are on our own in defining the API.
The patch doesn't handle non-whole-number strings very well as there is
no way for the user to specify decimal precision because we have
overridden the decimal digit meaning, but that seems fine to me as most
users will be using whole numbers.
--
Bruce Momjian
( ... ), it
looks very much like it is thread-aware if translated with the
--enable-thread-safety option.
What should I believe ?
Can someone comment on this report from 2013?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http
display as an option.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http
to an
int64 C type. Also I see there is an INT8OID, PG_GETARG_INT64,
DatumGetInt64, and Int64GetDatum---I think all for bigints. Does that
sound right? If so, would you like a documentation patch?
Applied doc patch attached. Thanks for the report.
--
Bruce Momjian br...@momjian.us
On Mon, Mar 9, 2015 at 12:43:05PM -0400, Bruce Momjian wrote:
On Fri, Mar 6, 2015 at 06:10:15PM -0500, Stephen Frost wrote:
Technically, there haven't been any complaints about either pg_dumpall's
behavior in this regard, or pg_upgrade's, but pg_upgrade's post-upgrade
scripts would
On Wed, May 13, 2015 at 06:23:58PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Wed, May 13, 2015 at 06:10:26PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Is there a reason the following patch wasn't applied?
I don't think anybody ever did
On Wed, May 13, 2015 at 06:10:26PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Is there a reason the following patch wasn't applied?
I don't think anybody ever did the legwork to verify it was a good idea.
In particular, it'd be good to check if sending a tabstat message
--- yeah, confusing, so no, the pl/psql ability is not deprecated.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org
subscription:
http://www.postgresql.org/mailpref/pgsql-general
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-general mailing list (pgsql-general
table using CREATE TABLE, then INSERT ... SELECT.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
the negative sign as a digit in all the places
I thought it was reasonable.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
diff --git a/src/backend/utils/adt/formatting.c b/src/backend/utils
of
pg_upgrade back to 9.0:
http://www.postgresql.org/docs/devel/static/pgupgrade.html
Let me know if you have any problems.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent
the same data, i.e.,
they do not see changes made by other transactions that committed after
their own transaction started.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god
not supporting all pg_backup/pg_restore combinations or for
that matter pg_restore not knowing what to do with a plain text
pg_dump file.
Understoo, but I was not aware there was anything special required for
pg_upgrade to support tablespaces.
--
Bruce Momjian br...@momjian.ushttp
that for pg_upgrade, and I
am sure they would work fine for pg_dump too.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org
On Mon, Apr 20, 2015 at 02:41:09PM -0700, Adrian Klaver wrote:
On 04/20/2015 12:49 PM, Bruce Momjian wrote:
On Sat, Apr 18, 2015 at 09:08:20AM +1000, rob stone wrote:
For what it's worth: Debian provides a
pg_upgradecluster
tailored to its specific setup of PostgreSQL clusters
installed in /usr/lib but the man pages state
that it cannot handle tablespaces.
Wow, that is odd. I wonder why.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via
or environments where
there are lots of independent clusters not catching this issue in their
testing, only to discover someone set their database to 'datallowconn =
false' for whatever reason and now that database is gone...
Agreed. I will work on a patch for this.
--
Bruce Momjian br
On Mon, Mar 9, 2015 at 12:43:05PM -0400, Bruce Momjian wrote:
On Fri, Mar 6, 2015 at 06:10:15PM -0500, Stephen Frost wrote:
Technically, there haven't been any complaints about either pg_dumpall's
behavior in this regard, or pg_upgrade's, but pg_upgrade's post-upgrade
scripts would
physically moves
any tables or indexes in the database's old default tablespace to the
new tablespace. The new default tablespace must be empty for this
database, and no one can be connected to the database. Tables and
indexes in non-default tablespaces are unaffected.
--
Bruce Momjian
1 - 100 of 1888 matches
Mail list logo
