Fresh instance of Drupal 6.x dev, from CVS head
I expected confirmation of the page being created but was presented with the following error:
"currval of sequence "node_nid_seq" is not yet defined in this session"
Also, I repeated these steps and from the second time onwards I get the following error:
duplicate key violates unique constraint "node_pkey"
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | drupal-6.x-dev-psql_common_inc-0.1.patch | 703 bytes | hswong3i |
| #5 | common.inc__7.patch | 279 bytes | jpulles |
Comments
Comment #1
Shiny commentedreplicated, and looking at it.
Comment #2
Shiny commentedfirst attempt results in :
subsequent attempts results in:
Comment #3
shunting commentedI experienced the same behavior with the development version of d6 (// $Id: CHANGELOG.txt,v 1.226 2007/10/10 10:40:13 goba Exp $), running PHP Version 5.2.1, PostGres 8.2.3, Apache 2.2.4). I don't know common.inc well enough to patch it yet, but this is what I did to get posting, at least. So maybe what I did will help others. Forgive the verbosity, I just want to make sure I understand.
The bottom line seems to be that when you do an INSERT in PostGres, and one of the fields is a SERIAL field, you shouldn't pass a value into the SERIAL field at all, because that will override the autogenerated value.
So, in common inc, when collecting the values thus:
we end up with a NULL value in the "nid" field and a 0 in the "vid" field because that is what the {node} schema drives:
We then pass INSERT INTO {node) (nid,vid) VALUES (NULL,0) ... to db_query, which converts the NULL into a zero, so we get INSERT INTO {node) (nid,vid) VALUES (0,0). Then we come, in common.inc, to this line, which fires if we have serials (nid):
In database.pgsql.inc that translates to:
But currval can only return a value if nextval() has previously been called, which is not the case because we overrode the default value supplied by SERIAL sequence generator by passing in a value. And so we get the "currval of sequence 'node_nid_seq' is not yet defined in this session" error instead of the page confirmation.
By this time, Drupal has ended up populating the nid and vid values (even though the post hasn't been saved), but not auto-incrementing them (we over-rode the serial genator), so on subsequent attempts, which again pass in ..VALUES (0,0)..., we get the uniqueness constraint violations.
So, just to start inserting nodes again, I changed the default values of nid and vid in {node} to look like:
In database.pgsql.inc I changed currval to a SELECT so there would be no dependency on nextval:
And then I made use of the helpfully collected serial fields in common.inc:
Now fill in the serial fields in PostGres:
This now words because the serials are collected on INSERT as well as UPDATE, and by the time db_last_insert is called, the {node} table has been populated by the SERIAL generators to db_last_insert_id has a nid to retrieve.
I hope this is helpful to people who know both common.inc and PostGres better than I do, and can move this issue forward.
Comment #4
jpulles commentedRaised priority to critical.
Comment #5
jpulles commentedThe attached patch file changes the line "$object->$field = 'NULL';" in the drupal_write_record function in common.inc to "unset($object->field);". The effect is that the insert query doesn't want to set the serial field to a NULL value but instead auto-increments. It seems to solve the insert, but i don't know what else is affected, not to mention when using MySQL.
Comment #6
jpulles commentedBug is also present in the beta2 version.
Comment #7
hswong3i commentedPatch tested for both MySQL 5.0.32 and PostgreSQL 8.1.9 on Debian etch 4.0r1 with PHP 5.2.0-8+etch7, all passed for node creation, update with revision, and comment add/drop.
The change sounds logical, as we need not to include those auto incremental field within SQL, even though it is set as NULL, and works with lossy MySQL handling.
Patch reroll with latest CVS HEAD, and keep the patch syntax as clean. It should be RTBC.
Comment #8
hswong3i commentedComment #9
gábor hojtsyThanks, committed.
Comment #10
shunting commentedThe patch works for me on beta2 (to which, apparently, it has not yet been rolled in?)
Comment #11
hswong3i commentedI guess it is committed? CVS msg: http://drupal.org/cvs?commit=85124
Comment #12
gábor hojtsyYes, beta2 was released before this patch was committed.
Comment #13
(not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.