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
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
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
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, 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
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.
--
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
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
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
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
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
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
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: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
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
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
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
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. +
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.
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
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 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 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
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
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
/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
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
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
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
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
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
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
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
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
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
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 +
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
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
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:
>
>
>
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 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
> &
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: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
>
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: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
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
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
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.
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
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
+
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
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
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
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
> 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
, 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
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.
--
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
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
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
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
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
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
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. +
+
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
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
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
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,
; 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
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
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
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
-
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
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
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
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
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.
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
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 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
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 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
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
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
.
>
> Will the synchronized seq scan patch be able to do this by issuing all
> the CREATE INDEX commands at the same time from several different database
> connections ?
No, but it could someday.
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
Enterpr
t be non-standard from a clean SQL point of view.
> Nonetheless, is there any way to use those "long doubles" in SQL?
No. Frankly I didn't know 12-byte floats were supported in CPUs until
you posted this. You could write your own data type to use it, of
course.
--
Bruce
[EMAIL PROTECTED] wrote:
> On Fri, Jun 08, 2007 at 03:00:35PM -0400, Bruce Momjian wrote:
> > No. Frankly I didn't know 12-byte floats were supported in CPUs until
> > you posted this. You could write your own data type to use it, of
> > course.
>
> I didn&#x
mall white circle with a red
> square or a green triangle in the same fashion.
> Just a thought.
And what does the icon show or do?
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your
ds it'd contradict Oracle seem about nil.
>
> Fwiw even in the min/max/sum case the spec is moving away from having
> aggregates ignore NULL values. You now get a warning in Oracle if your
> aggregate includes any NULL inputs.
How does Oracle's new behavior relate t
t a note in the manual pointing out the difference from
> Oracle seems in order.
Agreed that we are good by following min/max. Not sure about a mention
in the docs that we are different from Oracle helps. Do we mention
other differences? I see us doing that only for PL/Psq
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Anyway, there's no doubt that we can point to the behavior of MAX/MIN
> >> as defense for what we made GREATEST/LEAST do, so I'm inclined to leave
> >> their
' commands, if there are any, and things like that.
Ditto. Also consider that the grammer changes in every major PostgreSQL
release.
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your
---
Ron Johnson wrote:
> On 06/01/07 11:22, Bruce Momjian wrote:
> > PFC wrote:
> >> On Thu, 31 May 2007 22:20:09 +0200, Vivek Khera <[EMAIL PROTECTED]> wrote:
> >>
> >>> On May 25, 2007, at 5:28 PM, Tom Lane wrote:
> >>>
> >>
Matthew T. O'Connor wrote:
> Bruce Momjian wrote:
> > Added to TODO:
> >
> > * Allow multiple indexes to be created concurrently, ideally via a
> > single heap scan, and have a restore of a pg_dump somehow use it
> >
> > http://archives.postg
Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > Matthew T. O'Connor wrote:
> >> Bruce Momjian wrote:
> >> >
> >> > * Allow multiple indexes to be created concurrently, ideally via a
> >> >
Gregory Stark wrote:
>
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > They could roll their own a lot easier if you had finished the psql
> > concurrent patch.
>
> I did. But you decided you didn't want it.
As far as I know, we asked
Bruce Momjian wrote:
> Gregory Stark wrote:
> >
> > "Bruce Momjian" <[EMAIL PROTECTED]> writes:
> >
> > > They could roll their own a lot easier if you had finished the psql
> > > concurrent patch.
> >
> > I did. But you deci
(end of broadcast)---
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>choose an index scan if your joining column's datatypes do not
>match
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
o
> PostgreSQL:
>
> Do NOT continue to run 7.4.2. Upgrade to 7.4.17. Not doing so is just
> a waste of your time and ours.
Agreed. Not upgrading is more risky than upgrading. This is in the
FAQ.
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
En
elp out. :)
Here is a vim version:
http://www.gunduz.org/postgresql/pgsql.vim
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
-
1 - 100 of 2011 matches
Mail list logo
