I'm using PostgreSQL and all queries have been working fine for all our users. Except now. Some hours ago, some of the sentences are not working for some users. For instance:
select comments from appointments_appointmentlog where id=102501539;
If I run this sentence in the psql tool, it runs just fine. But, I use a different id (one of the problematic ones), then it gets stuck:
UPDATE appointments_appointmentlog SET comments='A' WHERE id=30042047;
The select command works fine though:
select comments from appointments_appointmentlog where id=30042047;
Any idea what may be happenning? Do you need any additional information? Also, as a side note, I can update, create and delete other rows in the same appointments_appointmentlog table.
Note: not sure if relevant, but we are using Django 1.1 (I know I know, too old). The problem can also be reproduced with raw sql though, without using django.
Edit
As #a_horse_with_no_name said in the comments, it is a lock:
LOG: process 3637036 still waiting for ShareLock on transaction 2604361155 after 4413702.724 ms
DETAIL: Process holding the lock: 3635781. Wait queue: 3637036.
CONTEXT: while deleting tuple (429566,2) in relation "appointments_appointmentlog"
STATEMENT: DELETE FROM "appointments_appointmentlog" WHERE "appointments_appointmentlog"."id" IN (30042047)
Not sure how to unlock it though.
Related
I am having no joy with the RavenDb profiler. There's output rendered in the browser, but the profiler always claims there are no requests and no sessions.
When the document store is created I make the following call:
RavenProfiler.InitializeFor(docStore);
And in my master layout I have this, just before the closing body tag:
#Raven.Client.MvcIntegration.RavenProfiler.CurrentRequestSessions()
As far as I can tell there's nothing more required in order for this to work (of course, I may be wrong) yet the output of the profiler is always as above.
I'm using version 3.0.0.0 of Raven.Client.MvcIntegration.
Any ideas?
I figured it out. It was an issue with how I resolved the DocumentStore via my Windsor Container. It turned out that I ended up with two instances of the DocumentStore, and the wrong one was registered with RavenProfiler. Once I ensured that only one DocumentStore was created, everything started working as expected.
In a database, i have a field called date. Is there a way to delete a row when the date passes, so that it doesnt show up anymore? Ive tried comparing it to todays date in the view, but this wouldnt happen everyday, and people would still see it on the first page load. Any ideas?
Removing something from your database is not safe for many reasons. Starting from permissions going to on_delete logic. If you are not sure about that it's totally required to delete something, just mark this row as active=false.
I would not recomend to use cron, since it hard to maintain: you have to set different tasks on different environments manually, copy these files somewhere on your VCS, work with bash instead of python.
Also, when talking about events, I would not recommend to store something like this in your database, since it is not controlled by VCS and hard to maintain.
If your app is pretty simple schedule is an option.
But if you are looking for some extra info like:
What rows were deleted?
Were there any exceptions?
You can move to more complex Celery with Beat turned on. Extra dependencies (like Redis, RabbitMQ) are the main disadvantage.
Docs:
celery beat
Related:
How do I get a Cron like scheduler in Python?
I believe the best way would be to use a Cron Job or to use a additional conditional in the view to show only rows after the said date.
I would recommend you use a mysql event, since this will run constantly, unlike triggers that are only fired on database operations. You want this to occur outside of anything happening in the application, just based on time, so mysql event will work for this scenario. See full tutorial here: http://www.sitepoint.com/working-with-mysql-events/
I had a easier approach, i guess you could call it "hard-coded". I made a function called deleteevent, which had the following code
def deleteevent():
yesterday = date.today() - timedelta(1)
if Events.objects.filter(event_date = yesterday).count():
Events.objects.filter(event_date = yesterday).delete()
Then, in every other function i had, i called this at the beginning, so the event would be deleted before the page loaded
I have a "DatabaseError: current transaction is aborted" that comes and goes (to be specific, 11 times out of 841) in a Django 1.3 project using Postgres. The project is a quiz site and the error occurs when a user submits the answer form in the view. From the database's perspective, the process involves a number of queries and looks like this:
Gather all of the correct answers for the question (they are multiple choice and may need more than one answer)*
Grab the user's profile
Save this answer
Query for the user's new point total
Save the total to their profile
Check to see if they qualify for a new reward
Award new reward if they do
Somewhere in that tortured process, this error crops up (I'm guessing because one query isn't waiting for the others). Is there a way for me, in production (i.e., DEBUG = False), to log the database errors just in this case? I'm on WebFaction and the Postgres error logs are not available to me. Could I steal something from this middleware example to fire in just this specific case?
Alternatively, is there a better way to find this error or should I be wrapping the individual queries in transactions (unfortunately they aren't all in the same place in the code, not sure if wrapping the view in a transaction decorator would help)?
*Just to confuse matters, the multiple right answers requirement was added in the middle of development and then dropped right before we went live, so I could simplify this process somewhat, basically skipping steps 1 and 4, but I'd like to know a general answer to this sort of mysterious issue.
You haven't said where in your 7 steps you have transactions that begin and end. That would be helpful to know.
One source of "transaction aborted" messages is due to deadlocks. More details would be in the PostgreSQL logs.
But the bottom line is that you will continue to have a painful and time-consuming experience debugging PostgreSQL if you can't get access to your PostgreSQL error messages. Take that up with WebFaction. If they can't helpful and your time is worth much, your bottom line costs will be lower by moving to an environment that provides this fundamental feature.
You have to enable autocommit for the transaction. In your DATABASES entry, include:
'OPTIONS': {'autocommit': True,},
By default, Django opens a transaction at the first query. By using this option, you manually have to start a transaction (e.g. using #commit_on_success). Since there is no transaction open anymore, you'll get the actual error that was previously masked by the transaction error.
The autocommit setting will be the new default for Django 1.6, see https://docs.djangoproject.com/en/dev/ref/databases/#postgresql-notes
Would it be ok to get a CF app to check for a valid database before proceeding to process that request?
This is because there may be instances where the database server may be down or being upgraded, hence an error comes when a db dependant request is made.
If there is no connection to the db server, the user can be safely redirected to a safe page.
Or can cfcatch work?
How can this check be done?
Thank you.
in your onRequestStart method of your Application.cfc file or in an Application.cfm file you can run a simple query to check that the database is available. Wrap the query in cftry/cfcatch. If the query fails, you can redirect the user in the cfcatch, if it succeeds, you can be reasonably sure that your database is "alive".
I've used such a check in one project. Code may looks as follows (not sure if it will work in versions of ColdFusion lower than 8), consider this sample as chunk of UDF written in CFScript:
// service factory object instance
factory = CreateObject("java","coldfusion.server.ServiceFactory");
// the datasource service
dsService = factory.DatasourceService;
// verify the dsn
return dsService.verifyDataSource(arguments.dsn);
Oh, I have even found small note in the code I wrote on my old laptop couple of years ago:
// [performance note] this server check takes 1-3ms at local PC (Kubuntu 7.10, CF8 + Apache2, Sempron 3500+, 1GB RAM)
While time looks like small I have found out that doing this check on each request is not really useful for my application. Any way I have a habit to use the try/catch extensively for errors handling. But if your datasources may cheange frequently it may have more sense.
Adding an extra query to every request to make sure that the database is up is a patently bad idea. A better approach would be to build a "maintenance mode" switch into your application, that you would manually enable when you are doing planned maintenance (upgrades, etc).
If you want to have a "friendly" page displayed when an error (like database issues) occur, then use the onError() method in Application.cfc and/or the <cferror .../> tag in Application.cfm, as a global error handler.
If you are worried the db could vanish, I would implement a "SELECT 1 AS A" query in your OnRequestStart handler that runs only every N minutes. This can be accomplished by using the query caching feature. I'd start with performing the query every 30 min.
I've been trying to run a dynamic query inside a cfquery tag. Previously it was running fine.
So now, I can see the debugger enter the cfquery tag, but it does not finish running. It didn't seem to have made an affect to the database, since nothing was added for that insert query. Putting try & catch blocks didn't catch anything.
When I looked at the Server Monitor, under Statistics ->Database -> Active Queries -> and sure enough it is listed as an active query.
My other cfqueries tags are running fine though.
There is no problem on the database side.
I've tried changing the content of the tag to run a non dynamic insert query, but it results in the same thing. When I've changed the content of the query to a badly formed sql, it does catch the error.
Would you suspect this to be a ColdFusion problem?
Post your query. There is going to be something horribly wrong with it. My gut instinct says deadlock or cross join.