;
> I don't think it matters, but we'll be going from 9.5.1 to 10.0.
pg_upgrade 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 Momjia
On Tue, Sep 19, 2017 at 12:42:40PM -0700, Jeff Janes wrote:
> On Tue, Sep 19, 2017 at 12:20 PM, Bruce Momjian wrote:
>
> On Wed, Sep 6, 2017 at 04:19:52PM -0400, Stephen Cook wrote:
> > Hello!
> >
> > Is there a way to decrypt data encrypted
;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.
--
B
, so using
those tools should work.
--
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-general maili
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
;t backpatch this change since the original docs were not
incorrect.
--
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 +
>
> The idea is to minimize downtime.
You can't use streaming replication between different major versions.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+
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
> table
ks used anywhere else but in pg_upgrade?
Nope, it is used only by transfer_relfile() calling linkFile().
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+
re 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 http://momjian.us
links 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 the
o start a
hackers thread about that.
Amen to the usability of the archives with no thread breaks --- I am
sure that was not easy.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once w
; elasticsearch 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/
--
Bru
with the rest of 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/
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 chain
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 http://momjian.us
EnterpriseDB http://enterprisedb.com
pecified) 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 http://momjian.us
EnterpriseDB
etermines its location?
I am guessing someone at your site created it --- Postgres does not
create such directories by default.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+
h this 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.
I
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
> >:
>
> On Thu, Oct 13, 2016 at 10:14:08AM +0200, Andreas Joseph Krogh wrote:
> > I would assume that having pg_largeobject in a s
L level. Of course, you can create a custom version of pg_upgrade to
do that.
--
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 inscr
he overhead of locking
on queries and stuff. I don't know any numbers myself.
--
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
t;
> 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 measured a production-quality
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 Mom
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.
--
, and 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 http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so
> downgrade.
Yes, you would need a mode that prevented new-format writes on the new
server.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient
it fails then 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 http://momjian.us
Enter
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 Momjian
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 mu
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 http://momj
hat 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 http://momjian.us
EnterpriseDB http://enterprisedb.com
+
out.
> 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 p
there is any possible fix.
>
> 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.
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 didn't.
--
Bruce Mo
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 supports th
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 wrote:
> > >
> &g
2299
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 they
understood of Postgres behavior. His talk near the end about the
replication infrastucture being exposed to them was also
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 wrote:
> >
> > > I agree, but I am not sure how to improve it. The big complaint I have
>
On Wed, Jul 27, 2016 at 12:51:40PM -0400, Rakesh Kumar wrote:
> On Wed, Jul 27, 2016 at 12:47 PM, Bruce Momjian 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/sqlserver. None of them
On Wed, Jul 27, 2016 at 12:33:27PM -0400, Rakesh Kumar wrote:
> On Wed, Jul 27, 2016 at 11:45 AM, Bruce Momjian 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 the upgraded
> &
the upgraded
server, you can't 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 http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you ar
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 http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ A
ate 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 http://momjian.us
EnterpriseDB
ains 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 http://momjian.us
EnterpriseDB
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
nt 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 http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was
On Tue, Mar 22, 2016 at 10:16:22AM -0600, Scott Marlowe wrote:
> On Tue, Mar 22, 2016 at 9:15 AM, Thomas Kellerer wrote:
> > Bruce Momjian schrieb am 22.03.2016 um 16:07:
> >>
> >> However, I do think database upgrades are easier with Oracle RAC
> >
> > I th
ing. 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 scal
On Fri, Feb 19, 2016 at 02:49:16PM +0100, s d wrote:
> On 19 February 2016 at 14:19, Bruce Momjian wrote:
> > Ah, no. That's not possible
> >
> >
> > ...not possible, Yet.
> >
> > PostgreSQL grows by adding the feature
tures 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 http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I.
uestion)
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 http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As y
e 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 http://momjian.us
Enter
T can be 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 http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscriptio
d behavior
can be abused, 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 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
-
e to this.
The simplest solution is to wait for 9.4.6 to be released and test that.
--
Bruce Momjian 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 Mon, Nov 30, 2015 at 08:08:50AM +, Benedikt Grundmann wrote:
>
>
> On Sat, Nov 28, 2015 at 2:39 AM, Adrian Klaver
> wrote:
>
> On 11/27/2015 06:07 PM, Tom Lane wrote:
> > Adrian Klaver writes:
> >> On 11/27/2015 08:15 AM, Bruce Momjian wro
; 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 are going
int
> "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,
are. The good 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 http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. A
erthing owned by my_new_install_user and postgres
are now swapped. This is basically 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 w
ion?
I think you want the HAVING clause, e.g. HAVING COUNT(*) > 8.
--
Bruce Momjian 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 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 writes:
> > > I load and dump text files with currency values in it. The decimal in
> > > these
> > > input and out
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
> > dig
s there a way to log all statements that update data?
Not really. Is this something we should document better?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-general mailing lis
re trying to run. 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 cop
pgrade, 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 http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
dif
hat it is most 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 a
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
> >>>report
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 http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent
tly part of community Postgres so you will need to
report it to them directly.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-general mailing list (pgsql-general@postgres
/core/
Hopefully this will be helpful to people.
--
Bruce Momjian http://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
ation too.
I have rarely seen this question asked. I think minor-release
downgrading is fine in this case.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-general mailing list
ear.
Many projects deal with this compound bug debt regularly, but we have
mostly avoided this fate.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-general mail
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:
> &g
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:
> > > >
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
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&#x
uld be listed and should correspond 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.
INFO messages are always displayed
on the client so internally INFO is marked as 'hidden' so it doesn't
display as an option.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
c for ECPGsetconn( ... ), 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 http://momjian.us
EnterpriseDB
y 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 http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has thei
convenient when writing pgplsql
> functions, to select into a record.
The pl/psql `SELECT INTO` is not related to the SQL SELECT INTO command
--- yeah, confusing, so no, the pl/psql ability is not deprecated.
--
Bruce Momjian http://momjian.us
EnterpriseDB
On Wed, May 13, 2015 at 06:23:58PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Wed, May 13, 2015 at 06:10:26PM -0400, Tom Lane wrote:
> >> Bruce Momjian writes:
> >>> Is there a reason the following patch wasn't applied?
>
> >> I don&#x
te the temp table using CREATE TABLE, then INSERT ... SELECT.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make chan
On Wed, May 13, 2015 at 06:10:26PM -0400, Tom Lane wrote:
> Bruce Momjian 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 s
pshot();
> CommitTransactionCommand();
> + pgstat_report_stat(false);
>
> /*
>* If the relation has a secondary toast rel, vacuum that too while we
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to
ut you found a need
for it.
I think the big question is whether (4) or HH24 (2) represents
characters. or digits for zero-padding. printf() assumes it is
characters, e.g. %02d outputs "-2" not "-02", but I think our API
suggests it is digits, meaning the minus sign is not p
rade manual page has instructions on upgrading
streaming standbys via rsync, and it will work for all versions 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 http://momjian.us
Enterpr
ssive
SELECT commands within a single transaction see the same data, i.e.,
they do not see changes made by other transactions that committed after
their own transaction started.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://ent
ries in tablespaces, but we added that for pg_upgrade, and I
am sure they would work fine for pg_dump too.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-general mailing l
o with the choices. Sort of like
> pgAdmin 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.
--
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_upgradecl
bumps.
> >
> > Karsten
> >
>
> Indeed I have that program installed in /usr/lib but the man pages state
> that it cannot handle tablespaces.
Wow, that is odd. I wonder why.
--
Bruce Momjian http://momjian.us
EnterpriseDB h
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&#x
gt; lead to data loss. It's not a high potential as, hopefully, people will
> check first, but I can imagine a hosting provider or environments where
> there are lots of independent clusters not catching this issue in their
> testing, only to discover someone set their database to 'd
privilege for the new tablespace. This command 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-defa
1 - 100 of 2119 matches
Mail list logo
