I use this in my code -- I run my apps at foo.heroku.com with whatever
the ghetto SSL option is, so YMMV.
def remote_ip
if forwarded = request.env[HTTP_X_FORWARDED_FOR]
forwarded.split(,).first
elsif addr = request.env[REMOTE_ADDR]
addr
end
end
-pvh
On Oct 1,
No, Heroku always runs your master branch. You have to push to it. It's
noteworthy that you cannot push a tag directly. To push a tag, do this:
git push heroku my_tagged_version^{}:master
-p
On Fri, Oct 15, 2010 at 12:01 PM, Wes Gamble we...@att.net wrote:
Jimmy,
So what I should have done
On Tue, Nov 16, 2010 at 2:29 AM, Trevor Turk trevort...@gmail.com wrote:
Are there plans to offer an automated solution?
Definitely.
Is there a way to do this now? I've tried to put the Heroku gem into
my Gemfile and then execute the command from the console, but that
doesn't seem to
freaking cheap.
On Nov 16, 10:24 am, Peter van Hardenberg p...@heroku.com wrote:
On Tue, Nov 16, 2010 at 2:29 AM, Trevor Turk trevort...@gmail.com
wrote:
Are there plans to offer an automated solution?
Definitely.
Is there a way to do this now? I've tried to put the Heroku gem into
my
It works, but is not supported.
You can set the DATABASE_URL to the other app's DATABASE_URL and that will
behave under most circumstances, but we reserve the right to update your
DATABASE_URL if we need to, and if we do so the copied one would fall out of
sync and require a manual change.
-pvh
cron job. The EC2 instance captures
and downloads the backup to S3, then shuts itself down. Works well so
far. Obviously, it's not free, but it's freaking cheap.
On Nov 16, 10:24 am, Peter van Hardenberg p...@heroku.com wrote:
On Tue, Nov 16, 2010 at 2:29 AM, Trevor Turk trevort
Manually establishing a connection should work just fine. Just do something
like this in the class you want to use the alternate database:
url = URI.parse(ENV[HEROKU_POSTGRESQL_RONIN_URL])
ActiveRecord::Base.establish_connection( {
:adapter = url.protocol,
:host = url.host,
ENV[DATABASE_URL] will be the URL that the database written to
database.yml lives on.
On Mon, Nov 29, 2010 at 3:05 AM, Neil neil.middle...@gmail.com wrote:
We've many apps on Heroku (read about 30) of which roughly ten are
production apps.
Therefore I've been looking at creating a little
Hi Carson,
that's an interesting scaling model, but it doesn't map well onto the way
Heroku is architected. The Heroku model runs many distributed processes
throughout our single shared cloud. You don't have any nodes in a
traditional sense, but each web server dyno and background worker is
Listing existing backups is done via `heroku pgbackup` (no S). To see all
the commands, `heroku help | grep pgbackup`.
-p
On Sun, Dec 5, 2010 at 6:58 PM, Justin Houk jsh...@gmail.com wrote:
Hey folks!
We're working on adapting our system to use the new Heroku PGbackups addon
for our
That was specifically my mistake. We'll be fixing it soon, but in the mean
time, don't worry, we won't do anything to hurt your app if you stray
unknowingly over your size limit.
The information will probably land at pg:info some time soon, and hopefully
some extra visibility and numbers too.
If you're using a dedicated database (and if your queries are non-trivial
you probably want to move off the shared ones) then you can just use heroku
pg:ingress + psql.
-p
On Wed, Dec 8, 2010 at 10:51 AM, Zach Bailey znbai...@gmail.com wrote:
I'm wondering if anyone has had experience
Yeah, we're not too likely to build in some elaborate support for such a
niche use-case when there are tons of really universally useful things to
work on. Let us know how it goes and if you run into any big problems.
Regards,
Peter
On Fri, Dec 10, 2010 at 12:35 PM, Zach Bailey
heroku invokes rake jobs:work -- just make your thor tasks run when
invoked like that.
-p
On Mon, Dec 13, 2010 at 8:17 AM, Jimmy Thrasher ji...@jimmythrasher.comwrote:
You could:
- create a Rake task to wrap them
- write a wrapper script to call 'heroku console command which is like
As I remember, effective_cache_size is a query planner hint. It helps the QP
decide whether or not to use an index in place of a sequential scan for queries
of middling selectivity (say, 1-3%.) It doesn't actually affect the cache size,
and it's nontrivial to imagine a query which would
Both are hosted on EC2 and have similar latency characteristics as a result.
P
On Jan 15, 2011 6:58 AM, John Maxwell jgwmaxw...@gmail.com wrote:
Hi,
I was wondering how the network response differs between using Memcached
or
Redis on Heroku. I'm happy using either for caching my app, but I
Hi Wes,
maybe this is somehow related to the credentials roll. Can you open a
support ticket? I'd like to investigate further.
Peter
Dep't of Data
On Wed, Jan 26, 2011 at 10:14 AM, Wes Gamble we...@att.net wrote:
Happened again on the other app. This has happened to me on two apps.,
twice
We're working on that bug right now. Hope to have it released shortly. If
the matter is urgent, please open a support ticket and we'll run it
manually.
Peter
On Wed, Jan 26, 2011 at 12:57 PM, Brian bburr...@gmail.com wrote:
I just had the exact same problem. Would really like to clear my
This approach seems reasonably portable to me. It's worth mentioning that if
you're at the point where you're wondering whether there are subtle
differences between PostgreSQL, MySQL and sqlite, you're at the point where
you should just install PostgreSQL on your dev machine. It's really not hard
I would strongly suggest you move to a pgbackups workflow instead. That
should give you a much higher fidelity pipeline for moving data back and
forth. You can also (if you are on a dedicated database) use the direct
pg:psql access to pipe data in and out of your database.
Peter
On Fri, Feb 25,
Sorry, we don't have any plans in the next few months to update the existing
shared DBs to PG9. What PG9 features are you looking for?
-pvh
On Thu, Mar 10, 2011 at 8:31 AM, paulcc paulcc@gmail.com wrote:
Hi
Are there plans to shift the shared databases to Postgres 9 any time?
Also, the
It's very easy to run postgresql on your system. I highly advise you switch
to that model if you've got a production environment and this isn't a
just-for-fun project.
-p
On Sat, Mar 19, 2011 at 8:07 AM, Tom O'Neill vay...@gmail.com wrote:
Ideally your dev environment is as close to production
It's running whatever you include in your Gemfile.
-p
On Sat, Apr 9, 2011 at 8:09 PM, Todd A. Jacobs nos...@codegnome.org wrote:
How can I find out what version of Rails is running on the Bamboo
stack? If it's not 3.0.6, is it possible to specify a point release of
Rails in the Gemfile and use
No difference between the two shared options for performance. The only
way to get more performance and features is currently to move to a
dedicated database.
Peter
On Wed, Apr 20, 2011 at 4:23 AM, Clément clmntlx...@gmail.com wrote:
Hello
Would I see any performance increase if I switch to 20G
You could probably wrap the GSL into a Rubygem. Heroku compiles C extensions
during slug release. It's not exactly an elegant solution, but it might be
less work and better performance than porting the algorithms yourself.
-p
On Fri, May 6, 2011 at 1:05 AM, Albert Chou hotfusion...@gmail.com
We normally send a SIGTERM, then wait five (ish?) seconds to let the last
request serve and then, then send SIGKILL if the process still hasn't gone
away.
You can confirm this behaviour here by catching and logging the SIGTERM in
your app and then reproducing the situation you describe. If you
it's a queue thing? I'll be happy to
share the code I'm using to make the tests if you'd like. (I'm using
the default Sinatra gem (not specifying a version) on the bamboo-
ree-1.8.7 stack).
- How do I catch a SIGTERM during a Sinatra app request?
On May 12, 10:15 am, Peter van Hardenberg p
Ah, I see Oren has a more useful response! Thanks, Oren!
On Thu, May 12, 2011 at 3:08 PM, Peter van Hardenberg p...@heroku.comwrote:
Sorry -- you're going to have to figure out the Sinatra stuff yourself.
Based on my here let me google that for you investigation, it sounds like
Sinatra only
If your process is terminating too often, Heroku will start leaving
longer gaps between attempts to start it. You might try collecting the
logs for your worker processes and seeing if there's anything
interesting to be gleaned from that.
heroku logs --ps worker
-p
On Tue, May 24, 2011 at 5:05
Hmmm. Could it be that you're running out of memory and crashing
without writing to the logs?
-p
On Wed, May 25, 2011 at 3:10 PM, Brandon Casci bran...@loudcaster.com wrote:
well...I meant to add more to my response.
Regardless of the problem Heroku resolved, the workers crash an awful lot. I
Benjamin,
I don't have any help for the internal server error, but you can definitely
set up the environment variables from your manually crafted Sendgrid account
on your app directly via heroku config:add. This will mask the old
credentials and get you back on your feet until you can track down
Unfortunately contrib modules are difficult to support on our databases
today due to their namespace polluting nature and the requirement for
installing them as superuser. I'm afraid there isn't really a good
work-around, but we're optimistic that the new extension support in PG 9.1
will help us
A support ticket is the fastest path to resolution for this kind of problem;
this thread isn't closely monitored for operational issues. That said, if
you email me off-list with your app name and a link to the ticket, I'll get
someone to take a look ASAP.
-pvh
On Mon, Jun 20, 2011 at 10:08 AM,
of press lately. At railsconf, some heroku people
told me about it, and Aaron Patterson mentioned it in his key note.
--Keenan
On Monday, June 20, 2011 at 4:08 PM, Peter van Hardenberg wrote:
Unfortunately contrib modules are difficult to support on our databases
today due to their namespace
This totally sucks. I see no reason we can't write software which can help
take care of this and provide superior versioning in the system. Ultimately
the lesson here is that all cloud services need to be capable of being in
intermediate states (or reverting part way through!) during all deploys.
This doesn't work on Cedar, where psql is not available. You can always
SELECT version(); using your SQL interface of choice.
Speaking generally, the sandbox databases are 8.3, and the production
databases are 9.0. We hope to unify this soon, but the differences are
primarily that the older 8.3
Hi David,
it's not possible to modify collation on a database cluster except in
PostgreSQL 9.1. We're hoping to make it available to our users as soon as
possible.
Regards,
Peter van Hardenberg
On Wed, Oct 5, 2011 at 5:46 AM, David Hall petters...@gmail.com wrote:
I am trying to find a way
We generally maintain up-to-the-minute continuous archives replicated to
multiple data centers to protect against hardware failure. We recommend
using PGBackups to maintain daily logical SQL backups for use in the event
of an accident on the part of a developer, or just for import/export of
data
Hi Anil,
you can set up your own MySQL server outside Heroku on EC2 and attach it to
your app.
That said, we don't believe RDS is a sufficiently high quality service to
offer our customers, which is why we built Heroku Postgres.
Peter
On Thu, Dec 8, 2011 at 12:41 PM, Anil Punjabi
I'm afraid Heroku relocates processes regularly throughout its cloud
in order to maintain a reliable service.
That means there isn't really a good off-the-shelf solution for this.
You could consider building something like a port knocking system
where each dyno could request access to the
Application Error
:)
-p
On Thu, Jan 12, 2012 at 12:49 AM, Jörg Viola joerg.vi...@googlemail.comwrote:
Hi all,
having deployed my first production app to heroku (which was fun, really:
www.waduno.de - sorry, german;-),
I wanted to know how it performs. The logplex seems to deliver this
Ah yes -- take a look at Octopus as a starting point. Sequel has similar
functionality built in at the library level.
https://github.com/tchandy/octopus
-p
On Tue, Jan 17, 2012 at 11:34 AM, Tom tom.s.leh...@gmail.com wrote:
Does anyone know the best way to do this? I posted on Stackoverflow
Awesome! Please share!
On Wed, Feb 8, 2012 at 11:57 AM, Tom O'Neill vay...@gmail.com wrote:
Hey guys!
** **
How do you look at your production databases? Do you write debug/report
pages, use db:pull, something else? What about for live site debugging?***
*
** **
While working on
Also, please use consider using pg_dump / pg_restore instead of db:pull
for grabbing from your production database. It is much, much, much faster
and more reliable.
On Wed, Feb 8, 2012 at 12:08 PM, Peter van Hardenberg p...@heroku.comwrote:
Awesome! Please share!
On Wed, Feb 8, 2012 at 11
As a database guy at Heroku, I'm not one to speak authoritatively on
this, so please take this as the personal thoughts of someone and not
an official statement.
We idle apps in order to avoid having to charge for them. The more
people who prevent this behaviour, the more expensive our free apps
On Thu, Mar 8, 2012 at 11:21 AM, Karl threadh...@gmail.com wrote:
So, I need to connect to a SOAP API that *requires* the caller have a
fixed IP address. We all know that heroku has two options: $100 a month for
fixed ip ssl, or no-can-do. And I'm not convinced that the instance doing
the
Hi Carson,
Unfortunately, followers are exact replicas of the master database and do
not support having changes made to them, so unfortunately your proposed
plan won't work.
That said, if the on-disk storage type is compatible, it should be
basically instantaneous. Try it on a follower and see
Hi Josh,
you should never run SQLite locally and Postgres in production. That'd
be like running Ruby 1.8.6 in development and 1.9.3 in production...
only worse.
Postgres has historically kind of been a pain to install if you're on
Mac, but we just released a beta version of
at the analogy for running ruby 1.8.6 / 1.9.3, and its a fair
point. I've installed and removed postgres locally a couple times using
homebrew. I guess I should do it again, but I'll check out your app too.
Thanks.
-j
Sent with Sparrow
On Wednesday, April 25, 2012 at 4:19 PM, Peter van
-josh
On Wednesday, April 25, 2012 at 4:59 PM, Peter van Hardenberg wrote:
The app really makes life simple. You download the app. When you want
to run Postgres, you open the app. It puts an icon in the menubar
showing the database is running. When you quit, it goes away.
-p
On Wed, Apr
We do kinda-sorta support it, but it currently has a limitation in the form
that if we ever need to update your DATABASE_URL, we can't tell that you're
connecting from two apps and one of them (the non-owning app) will go
unupdated. We've got a feature in alpha right now which will resolve this,
, 2012 4:55:09 PM UTC-7, Peter van Hardenberg wrote:
We do kinda-sorta support it, but it currently has a limitation in the
form that if we ever need to update your DATABASE_URL, we can't tell that
you're connecting from two apps and one of them (the non-owning app) will
go unupdated. We've got
Hi Josh,
Based on the description of your issue it sounds like you've gone
over-limit on your `dev` database and kept it there for more than a week.
We send out warning emails at 7,000 rows and again when you go over limit
at 10,000 but it's possible that you didn't receive them. You can check
the row limit, and got the
notice last week. I removed a lot of rows so I assumed it would be back
under. I'm trying to migrate to Crane. It's slow, and I could use some help.
joshc at epicthink . com
On Mon, Nov 12, 2012 at 1:03 PM, Peter van Hardenberg p...@heroku.comwrote:
Hi Josh
Josh, starter tier plans don't support fork/follow. You'll have to use a
pgbackups dump/restore cycle to get on to a new plan. In fact, the whole
reason we put a row limit on `basic` plans was to help protect people from
getting to a database too big to be able to migrate without major
down-time,
Hi Jack,
we don't support setting the time in the pgbackups system. It's a feature
we have requested from time-to-time, and it's not out of the question that
we'll provide it eventually, but we're currently working on other
functionality, so I wouldn't expect to see it any time soon. As a
,
but as a note, if you're running a production app, we definitely recommend
a production tier database (crane or above). That said, we do think fixing
this is important, and we're on the case.
Best,
Peter van Hardenberg
Heroku Postgres
On Mon, Nov 26, 2012 at 6:54 PM, Wendy Friedlander
we
I've heard of people doing this:
https://github.com/ddollar/heroku-buildpack-multi
-p
On Sat, Dec 15, 2012 at 3:43 PM, Neil Middleton n...@neilmiddleton.comwrote:
You probably could create an application running Ruby and JRuby, but you'd
be looking at making a custom buildpack in order to do
by
heroku to view it.
Thanks
- Luke
On Tuesday, November 27, 2012 12:24:14 AM UTC-5, Peter van Hardenberg
wrote:
Hi all,
we're tracking some issues with the new `heroku-postgres` plans that
are
affecting a couple of the database clusters. One immediate step you
can
Hm - that's an interesting one. I've never seen Rails pick up a schema
change without a restart before. I suspect the complexity cost and overhead
of monitoring the schema would outweigh the benefits of saving a process
restart. That said, it's weird that even if you recreate tables with the
same
.
Thanks a lot for the hint, Peter!
On Monday, January 21, 2013 10:08:25 PM UTC+1, Peter van Hardenberg wrote:
crazy idea: try disabling prepared statements.
rationale: you might have prepared statements enabled, which is the
default, which would mean that instead of targeting the table by name
is worth a thousand words:
http://grozdova.com/psql-missing-relation-after-dump-restore.png
I am not sure if this is intended behaviour or not, but it should become
clear at the thread there.
On Tuesday, January 22, 2013 12:30:44 AM UTC+1, Peter van Hardenberg wrote:
So here's the deal
Okay! Tom Lane has now fixed this and future Postgres releases will not
exhibit this behaviour. The commit should land shortly. Thanks for the
report!
On Mon, Jan 21, 2013 at 11:04 PM, Peter van Hardenberg p...@heroku.comwrote:
Thanks for the extra reply Nickolay. I think I came up
When you clone from git you get not just the most recent version but all
the history of the master branch. If you look in heroku releases you should
see which of those commits correspond to which release. To check out that
particular commit just use:
$ git checkout ad3242 or whatever
You'll
You can't FTP - that's not a feature Heroku supports. It sounds like you
might want to spend a little bit of time familiarizing yourself better with
Git. Once you get the hang of it, it's a much more powerful tool than FTP
but it takes a little getting used to. Don't worry, though, your code
hey michael,
yes it's 9AM on a saturday morning after waza but dang it, i hate to see a
user suffer. i think what happened is you didn't migrate your data and
eventually our system archived the old database. i think we can set you
straight - give me a few.
On Sat, Mar 2, 2013 at 8:30 AM,
Hi Nickolay,
we haven't figured this out yet. Assuming you're on a production plan, you
could email me the requisite dictionary and I can try dropping it in place
for you on an experimental basis. Coming up with a better mechanism for
this is an interesting project. Ideally, it should be
in a table.
Best,
Nickolay
On Sunday, March 3, 2013 12:16:31 AM UTC+1, Peter van Hardenberg wrote:
Hi Nickolay,
we haven't figured this out yet. Assuming you're on a production plan,
you could email me the requisite dictionary and I can try dropping it in
place for you on an experimental
Hi Tam,
each dyno type needs to have its own name, and only one dyno type (web) can
receive HTTP traffic. Also, by default only a single `web` dyno gets run,
since you only get 750 dyno-hours free per month. To run more processes,
you'll need to do something like:
$ heroku scale worker=1
; only one of our apps, appSocket.js,
gets run.
Any more information you need to help me fix this?
Thanks!
On Monday, May 6, 2013 6:50:03 PM UTC-4, Peter van Hardenberg wrote:
Hi Tam,
each dyno type needs to have its own name, and only one dyno type (web)
can receive HTTP traffic. Also
Hi Manikanta,
by default, the Heroku Cedar environment is very minimalist. It includes
almost no packages, including, I think(?), no Python. You can probably
solve this problem by using multiple buildpacks. You'll want to combine the
PHP and Python build packs. It's unsupported, but it should
Curses! Foiled again!
On Mon, Jul 15, 2013 at 3:04 PM, Daniel Farina dan...@fdr.io wrote:
On Mon, Jul 15, 2013 at 3:01 PM, Peter van Hardenberg p...@heroku.com
wrote:
Hi Manikanta,
by default, the Heroku Cedar environment is very minimalist. It includes
almost no packages, including
Hi JP,
we're working on a Python support forum specifically for these kinds of
questions. Check it out: https://discussion.heroku.com/
I know there are a bunch of people keeping an eye on that group :)
-p
On Mon, Jul 15, 2013 at 12:09 PM, J.P. Fortier jpfortier1...@gmail.comwrote:
I've been
postgress
(3) The custom dictionary is maintained outside postgress and is up
loaded using a heroku CLI extension (or via the website)
On Sunday, March 3, 2013 10:16:31 AM UTC+11, Peter van Hardenberg wrote:
Hi Nickolay,
we haven't figured this out yet. Assuming you're on a production plan
74 matches
Mail list logo
