text:
Fox Imagines Much-Discussed Universal Maternity Coverage Was Kept Secret
Blog ››› ››› EMILY ARROWOOD
Fox host Neil Cavuto pretended that the Affordable Care Act's (ACA) ban on gender discrimination, which requires all policies to include maternity care coverage, was never "telegraphed" to the American people when the law was first discussed -- Cavuto is right, if you ignore repeated remarks made by President Obama, Health and Human Services Secretary Kathleen Sebelius, and multiple media outlets prior to the bill's passage.
Under the ACA, all insurance plans are now required to cover maternity and newborn care, one of the law's 10 categories of 'essential health benefits' that every policy must include. The maternity care requirement puts an end to the systemic discrimination against women that pervaded the insurance industry. Previously, many companies charged women higher rates than men for the same plans and denied coverage or increased premiums for women who become pregnant, actions which the law prohibits.
Fox host Neil Cavuto referenced this requirement on the November 15 edition of Your World while discussing the ACA with MIT economist Jonathan Gruber. After Gruber explained the impetus behind the rule, Cavuto claimed that it "was never, ever" explained to the country until now:
GRUBER: The key thing is, if you want to end discrimination, for example by gender, if you want to say that women should not have to pay more than men for health insurance, then that means that everyone has to share the cost of maternity coverage. Now if you don't think that's right, that's a totally legitimate position to take --
CAVUTO: But that was never telegraphed. When all of this started, Jonathan -- that's fine, if you want to say that now though -- none of that was telegraphed, as was the fact that many people would lose their plans and many more would pay a lot more for plans. None of that was this Utopian view that you would do better by doing some good, maybe paying more, but in the net positive the country would benefit. That was never -- that was never ever said.
What Cavuto claims was "never, ever said" was said, repeatedly -- by the media, the president, and the Health and Human Services (HHS) cabinet secretary, all before Congress passed the ACA on March 23, 2010.
FactCheck.org laid out in August 2009 how the proposed ACA "bill itself specifies the 'minimum services to be covered' in a basic plan, including prescription drugs, mental health services, maternity and well-baby care." That same year, McClatchy reported how the ACA would end insurance companies' practice of treating gender and pregnancy as a preexisting condition, and would "require maternity coverage to be offered at reasonable rates." One month before the bill became law, ABC highlighted the fact that the bill "requires that all policies cover maternity care," a point The New York Times has also noted.
In a September 2009 speech before Congress on the need to pass health care reform, President Obama specifically cited his plan to end discrimination based on pre-existing conditions and to require insurance companies to cover preventive care services for everyone. He even detailed the impetus behind these mandates -- what Cavuto deemed a "Utopian view":
PRESIDENT OBAMA: [U]nless everybody does their part, many of the insurance reforms we seek -- especially requiring insurance companies to cover pre-existing conditions - just can't be achieved.
That large-heartedness - that concern and regard for the plight of others -- is not a partisan feeling. It is not a Republican or a Democratic feeling. It, too, is part of the American character. Our ability to stand in other people's shoes. A recognition that we are all in this together; that when fortune turns against one of us, others are there to lend a helping hand. A belief that in this country, hard work and responsibility should be rewarded by some measure of security and fair play; and an acknowledgement that sometimes government has to step in to help deliver on that promise.
Prior to the ACA's passage, HHS released reports citing the fact that "the vast majority of individual market health insurance policies did not cover maternity care" as a reason health care reform was desperately needed. HHS Secretary Sebelius spoke repeatedly about the ACA's requirement that health plans "cover preventive services for everyone" and no longer discriminate against women.
Public knowledge of the ACA when it passed appears to have little consequence on Fox -- this not the first time the network has conveniently disappeared previous statements about the ACA in order to attack the president.
- Posted In
- Gender, The Presidency & White House, Health Care, Health Care Reform
- Network/Outlet
- Fox News Channel
- Person
- Neil Cavuto
- Show/Publication
- Your World w/ Neil Cavuto
Instructions for signing up and claiming your comment history are located here.
Updated rules for commenting are here.


text:
Customer Care Content
Please, read the Privacy Policy statements outlined below. Your using the website and placing orders with us automatically means your full agreement to all of the statements of the current Privacy Policy. If you do not agree to the terms of this policy, please, do not access or use this website.
We ship every cell phone repeater from Hong Kong. Due to its location, Hong Kong permits sending goods on favorable terms and you get lower price in the end.
There is no law that says all sellers must take back an item. But our company guarantees that you can return your order and get a refund. We really care about our customer's satisfaction. If there is something you don`t like about the purchased items, just let us know to arrange the return or exchange.

subset: commoncrawl


text:
Join as a member. There's a certificate with your name on it.
Updated: Comment #118
There are a number of significant issues with installing and running Drupal 8 on PostgreSQL.
Proposed resolution
Identify the major issues and implement workarounds or fixes. This should now be done in each individual related issue rather than tacking onto a huge patch.
These issues are listed in the Related Issues block to the right.
Comments #1 - #117 are related to this issue pre-meta status. The latest "full patch" is from Comment #109. This should be used as a started point for the sub-tasks to split off code into new patches.
- In transaction context, the first failure makes the transaction abort, and subsequent operations, even if they would normally succeed, also fail with the error "current transaction is aborted, commands ignored until end of transaction block". This differs from the behavior of MySQL. The workaround is to wrap all queries that occur inside a transaction with SAVEPOINT.
- Cache tables are missing at the end of the installation. Ensure cache tables exist when deleteAll/DeleteMultiple is called.
- Some things such as node/add/page fail because queries such as "select * from users where (uid IN ('autocomplete'))" which succeeds in MySQL, causes an exception in PostgreSQL because 'autocomplete' is not an integer. menu_get_item() needs to be fixed to get the correct route for user/autocomplete.
- Toolbar menu links do not appear because of the way a orderBy() override for pgsql adds fields in front of fields expected by Entity\Query. The workaround is to add a tag to the query to disable the special features of the override in specific cases.
- Prevent pgsql driver from trying to implode primary key fields that are defined by an array (column, key_length) as that syntax is not supported.
(Update Feb. 2014. There is work in progress to completely remove menu_get_item() from core, so this issue might get fixed by #2177031: Remove menu_get_item() and every use of it. )
Remaining tasks
- Create patches for known issues in their respective issue.
- Create issues and relate those issues to this task as new bugs are discovered.
Related Issues
#2010368: Installer can't create new database on PostgreSQL
#2056627: Form API autocomplete is broken for routes
#1003788: PostgreSQL: PDOException:Invalid text representation when attempting to load an entity with a string or non-scalar ID
#2111979: PostgreSQL is unable to create a new database
Original report by hosef
When one installs Drupal 8 on a PostgreSQL database, the installation will hang while installing the Image module. You can get around the install hang by using the minimal profile, however, when you go view a page on the site(after trying either profile) you will get:
Page not found
The requested page "/" could not be found.
There don't appear to be any relevent entries in the Apache log, however the following shows up in the PostgeSQL log for each page load:
2013-05-22 22:05:01 PDT STATEMENT: DELETE FROM cache_menu
2013-05-22 22:05:01 PDT ERROR: current transaction is aborted, commands ignored until end of transaction block
2013-05-22 22:05:01 PDT STATEMENT: SELECT 1 FROM information_schema.tables WHERE (table_catalog = 'drupalcore') AND (table_schema = 'public') AND (table_name = 'cache_menu')
|1007 bytes
PASSED: [[SimpleTest]]: [MySQL] 60,043 pass(es). View
|Screen Shot 2013-10-14 at 4.18.41.png
PASSED: [[SimpleTest]]: [MySQL] 59,031 pass(es). View
Comment #1JoshuaRogers CreditAttribution: JoshuaRogers commented
Managed to reproduce the issue. And found the source of the issue. Working on a patch.
Comment #2dcrocks CreditAttribution: dcrocks commented
Could you give a general indication of what the source is? I am having a similar problem with SQLite.
Comment #3JoshuaRogers CreditAttribution: JoshuaRogers commented
Doh! Sorry about that. The culprit seems to be in \Drupal\Core\Database\Connection.php:533-541.
if ($query instanceof StatementInterface) {
$stmt = $query;
$stmt->execute(NULL, $options);
else {
$this->expandArguments($query, $args);
$stmt = $this->prepareQuery($query);
$stmt->execute($args, $options);
While installing filters, one of the arguments being substituted into the SQL is an array. Since MySQL doesn't pass the query in as a StatementInterface, this isn't a problem because the connection calls
$this->expandArguments(...) and is able to explode the array into the appropriate placeholders and replacement values.
PgSQL and SQLite, on the other hand, appear to pass statements as instances of StatementInterface. This route, the arguments never get expanded, so eventually (on \Drupal\Core\Database\Driver\pgsql\Insert.php:48) this results in a situation where
$stmt->bindParam(...) is receiving an Array even though the default third argument tells it it should expect a string.
I think that both of these issues will probably be resolved in much the same way.
Comment #4JoshuaRogers CreditAttribution: JoshuaRogers commented
Won't be able to work on this issue for a few days and haven't made significant progress past the previous post. Anyone else is free to grab this.
Comment #5mradcliffe CreditAttribution: mradcliffe commented
I'm getting more failures like this, but earlier in the installation process in Pg 9.2.4. Looking into it a bit tonight.
Comment #6mradcliffe CreditAttribution: mradcliffe commented
FilterPluginManager calls CacheDecorator inappropriately, which causes a query to fail in the same way.
I split that into #2008644: FilterPluginManager::__construct calls CacheDecorator with incorrect parameters (expires).
I also am having issues with several cache tables not installing, specifically cache_menu, cache_page, and cache_views_results.
Comment #7Pancho CreditAttribution: Pancho commented
Confirm that there is a number of bugs. Issue is critical per Priority levels of issues.
If the database doesn't preexist and is to be created, I also get a
Fatal error: Call to undefined method Drupal\Core\Database\Driver\pgsql\Connection::exec() in /var/www/d8-test/core/lib/Drupal/Core/Database/Driver/pgsql/Connection.php on line 220
Might have something to do with each other. I'll be digging into this right now.
[edit:] no that's not connected but a separate issue, see #2010368: Installer can't create new database on PostgreSQL
Comment #8steinmb CreditAttribution: steinmb commented
PHP 5.4.13 (cli) (built: Apr 16 2013 11:46:33)
PostgreSQL 9.2.4
Confirm this bug. Installation will complete If you, like mention above, use the minimal profile but you end up with a broken site. Got this warning after the installation, though I do not think this is the issue.
Notice: A non well formed numeric value encountered in Drupal\menu_link\MenuLinkStorageController->save() (line 192 of core/modules/menu_link/lib/Drupal/menu_link/MenuLinkStorageController.php).
None of the registered routes works and cache_menu table is missing.
ERROR: current transaction is aborted, commands ignored until end of transaction block
STATEMENT: SELECT 1 FROM information_schema.tables WHERE (table_catalog = 'd8') AND (table_schema = 'public') AND (table_name = 'cache_menu')
ERROR: relation "cache_menu" does not exist at character 13
Manually creating the table allow me to navigate the site though some errors is still found i postgres. At least I'm able to navigate.
ERROR: relation "cache_page" does not exist at character 13
STATEMENT: DELETE FROM cache_page
WHERE (expire <> '0') AND (expire < '1370598489')
ERROR: relation "cache_path" does not exist at character 13
STATEMENT: DELETE FROM cache_path
WHERE (expire <> '0') AND (expire < '1370598489')
ERROR: relation "cache_filter" does not exist at character 13
STATEMENT: DELETE FROM cache_filter
WHERE (expire <> '0') AND (expire < '1370598489')
Create missing cache_menu
CREATE TABLE cache_menu
cid character varying(255) NOT NULL DEFAULT ''::character varying, -- Primary Key: Unique cache ID.
data bytea, -- A collection of data to cache.
expire integer NOT NULL DEFAULT 0, -- A Unix timestamp indicating when the cache entry should expire, or 0 for never.
created integer NOT NULL DEFAULT 0, -- A Unix timestamp indicating when the cache entry was created.
serialized smallint NOT NULL DEFAULT 0, -- A flag to indicate whether content is serialized (1) or not (0).
tags text, -- Space-separated list of cache tags for this entry.
checksum_invalidations integer NOT NULL DEFAULT 0, -- The tag invalidation sum when this entry was saved.
checksum_deletions integer NOT NULL DEFAULT 0, -- The tag deletion sum when this entry was saved.
CONSTRAINT cache_menu_pkey PRIMARY KEY (cid)
ALTER TABLE cache_menu
OWNER TO postgres;
COMMENT ON TABLE cache_menu
IS 'Storage for the cache API.';
COMMENT ON COLUMN cache_menu.cid IS 'Primary Key: Unique cache ID.';
COMMENT ON COLUMN cache_menu.data IS 'A collection of data to cache.';
COMMENT ON COLUMN cache_menu.expire IS 'A Unix timestamp indicating when the cache entry should expire, or 0 for never.';
COMMENT ON COLUMN cache_menu.created IS 'A Unix timestamp indicating when the cache entry was created.';
COMMENT ON COLUMN cache_menu.serialized IS 'A flag to indicate whether content is serialized (1) or not (0).';
COMMENT ON COLUMN cache_menu.tags IS 'Space-separated list of cache tags for this entry.';
COMMENT ON COLUMN cache_menu.checksum_invalidations IS 'The tag invalidation sum when this entry was saved.';
COMMENT ON COLUMN cache_menu.checksum_deletions IS 'The tag deletion sum when this entry was saved.';
-- Index: cache_menu_expire_idx
-- DROP INDEX cache_menu_expire_idx;
CREATE INDEX cache_menu_expire_idx
ON cache_field
USING btree
Attaching the complete log from postgreSQL during a minimal installation.
EDIT: Added info about what happen if you manually create cache_menu.
Comment #9Pancho CreditAttribution: Pancho commented
Thanks, @steinmb, for the log!
Unassigning though because I don't have time for it this weekend.
Comment #10fvideon CreditAttribution: fvideon commented
Comment #11fvideon CreditAttribution: fvideon commented
|» Unassigned
|» Needs review
PASSED: [[SimpleTest]]: [MySQL] 56,007 pass(es). View
I don't feel this patch is ready for prime time, but it at least shows the issue and one possible fix. The reason some of the cache_* tables are not being created during setup is tied to having the database transaction support enabled. By design, cache operations are allowed on cache bins that don't yet have the backing cache_* table and exceptions are caught as needed. The set() method is the one that creates the table. This happens inside a catch clause after the first attempt to write to the table fails. (See core/lib/Drupal/Core/Cache/DatabaseBackend.php around line 147).
The problem is that in the transaction context, the first failure makes the transaction abort, and subsequent operations, even if they would normally succeed, also fail with the error "current transaction is aborted, commands ignored until end of transaction block". Most of the cache_* tables are created not in transaction context, but a few such as cache_menu are, and these fail to be created.
The fix I drew up just checks if it's in a transaction, and if so takes an appropriate action to find out if the table exists, and thus avoids aborting the transaction.
One drawback is that there are more queries needed to do this checking compared to just using the try/catch. A possible mitigation would be to use a static array of bool to keep track of which bins have been created, so it would only need to check once for each.
I'm setting this back to unassigned now since I won't be working on it over the weekend. I can probably work on it more next week unless someone else has a better fix, or gets to it first.
Comment #12Damien Tournoud CreditAttribution: Damien Tournoud commented
This is so interesting. I wonder how we could have missed that before.
- On MySQL: an error raised by a statement of a transaction rolls back the statement (I suspect that it happens only if the statement hit the storage, no idea what happens if it doesn't);
- On PostgreSQL: an error raised by a statement rolls back the transaction (regardless of the error, it seems).
MySQL (or more precisely, InnoDB) basically does an implicit SAVEPOINT before each transaction. From browsing around, it doesn't seem that any of the behavior is configurable, so we will have to either perform an explicit rollback on error (on MySQL) or add a SAVEPOINT before every statement on PostgreSQL.
Comment #13Pancho CreditAttribution: Pancho commented
|Needs review
|» Needs work
Indeed fascinating that we didn't hit this before!
In SQLite this is nicely configurable, defaulting to "ON CONFLICT ABORT" and says this was "the behavior specified by the SQL standard." So even though it seems complicated to handle, by default it seems to match InnoDB's behaviour, and that's why this code works fine on SQLite and only fails on PostgreSQL.
Oracle IMHO also implicitely sets savepoints.Don't know about SQL Server.
So while PostgreSQL's, also non-configurable, "all or nothing" rollback decision is definitely more predictable, it seems to be quite an exception. This might be an argument for adding explicit savepoints for PostgreSQL
On the other side, as long as we don't have PostgreSQL testbots, it might be better to simulate PostgreSQL's behaviour on MySQL (inserting explicit rollbacks) and SQLite (using "ON CONFLICT ROLLBACK").
I guess, we should probably figure out both ways and see how they turn out to work, before making the final decision.
In any case, this should be generally solved, so I'm setting this back to needs work.
Comment #14Damien Tournoud CreditAttribution: Damien Tournoud commented
I suspect that we are hitting this now because PostgreSQL recently (in version 9, if I remember correctly) got support for transactional DDL. As a consequence the DDL statements that previously caused the previous (aborted) transaction to be cleared out do not anymore.
We should turn to PostgreSQL users. Given that PDO supports multi-statement queries, inserting a SAVEPOINT before every query will not have an impact on latency, which is a good thing, but might have an impact on the performance of execution of queries in general.
Note that adding a SAVEPOINT is what the psql command line tool does when ON_ERROR_ROLLBACK is enabled:
The on_error_rollback-on mode works by issuing an implicit SAVEPOINT for you, just before each command that is in a transaction block, and rolls back to the savepoint on error.
Comment #15steinmb CreditAttribution: steinmb commented
A shot in the dark, but is this related to #1907230: PostgreSQL - duplicate key value violates unique constraint "drupal_cache_block_pkey" ? Damien should remember those..
Comment #16Damien Tournoud CreditAttribution: Damien Tournoud commented
@steinmb: without looking at this in detail, I would say those are probably not related.
Comment #17fvideon CreditAttribution: fvideon commented
Working on the approach of putting a savepoint before every query..
Comment #18fvideon CreditAttribution: fvideon commented
|Needs work
|» Needs review
PASSED: [[SimpleTest]]: [MySQL] 55,984 pass(es). View
This uses the strategy of wrapping most everything with a savepoint (save for other savepoint operations).
I didn't see a way to do the savepoint release or rollback and return the correct results while putting everything in one PDO query. If someone knows a way to do that, we should use it. For now the release or rollback operation is handled as a separate query.
Cheers, Fred
Comment #19Damien Tournoud CreditAttribution: Damien Tournoud commented
Shooting in the dark, but I assume that:
SAVEPOINT <name> ; <the query> ; RELEASE <name>
... would work as it should? If the query fails, the rest of the batch will be ignored and an exception will get thrown, and in the exception handle we do the
ROLLBACK TO SAVEPOINT stuff.
Comment #20fvideon CreditAttribution: fvideon commented
AFAIK the results of the compound query are the results of the last statement. If it ends with SAVEPOINT RELEASE, fetchAll always returns an empty array. Do you know a way around that?
Comment #21Damien Tournoud CreditAttribution: Damien Tournoud commented
I assume that something like this should work, but I don't know the performance implications:
SAVEPOINT <name> ; DECLARE <cursor name> CURSOR FOR <the query> ; RELEASE <name> ; SELECT <cursor name>
... and we most likely have to CLOSE the cursor at one point.
I guess this is where it would start to make sense to subclass PDOStatement for PostgreSQL.
Comment #22fvideon CreditAttribution: fvideon commented
Good idea to try a cursor. I just did a quick test using this form:
"SAVEPOINT sp; DECLARE acursor CURSOR FOR " .$sql . "; RELEASE SAVEPOINT sp; FETCH ALL acursor"
It works with a valid SELECT query and returns the correct results. With a bogus query it appears to do the right thing and throws a PDO Exception. The problem was that if I call it with the bogus query followed by the valid query, the valid query throws the dreaded
"ERROR: current transaction is aborted, commands ignored until end of transaction block".
So it appears that the exception on the bogus query happens on the FETCH which is already outside of the SAVEPOINT, so it still aborts the outer transaction.
Comment #23fvideon CreditAttribution: fvideon commented
An update on #22: I was mistaken -- the CURSOR actually does appear to work as we'd want for SELECT. My initial test did not handle the ROLLBACK correctly, but once that was done, the valid query following the bogus query did succeed.
I will take another look at this.
Comment #24fvideon CreditAttribution: fvideon commented
And on to the next quandary: We can handle DELETE, UPDATE and INSERT using this compound query form, but then the PDOStatement rowCount() method always returns zero.
'SAVEPOINT sp; ' . $sql . '; RELEASE SAVEPOINT sp;'
Any thoughts about how to handle that better?
Comment #25fvideon CreditAttribution: fvideon commented
For this iteration the strategy using CURSOR is employed for SELECT queries to allow RELEASE to occur in the same operation. Queries other than SELECT still RELEASE as a separate operation since they can't use CURSOR, and we assume we may sometimes need a valid rowCount, etc.
The strategy employed for closing cursors is to let COMMIT or ROLLBACK do the implicit CLOSE, and just issue a unique name for each cursor.
Comment #26fvideon CreditAttribution: fvideon commented
Comment #27Pancho CreditAttribution: Pancho commented
Nice work. Certainly needs testing, and probably also profiling on PostgreSQL.
Also, I hope this doesn't cover failing transactions on PostgreSQL, which are not even tested by our bots. What was the failing query again in this case?
Need to check if this potentially works out for other dbas just as well, such as Oracle, SQL Server etc.
In the end I'm still not sure we shouldn't mimic PostgreSQL's behaviour on MySQL instead, but @Damien, I trust in your experience.
Comment #28Damien Tournoud CreditAttribution: Damien Tournoud commented
It seems like the ODBC driver for PostgreSQL does exactly the same thing. We could look into how they implemented it.
Comment #29Pancho CreditAttribution: Pancho commented
Oh, that would certainly be an argument for this approach...
Where did you find this documented, so you don't necessarily have to investigate this yourself?
Comment #30Damien Tournoud CreditAttribution: Damien Tournoud commented
Not sure where it is documented, but I have seen several log extracts that show that it does. For example, this confused user.
Comment #31Pancho CreditAttribution: Pancho commented
This is where it seemed to be introduced to ODBC, and it seems this problem is why psqlodbc introduced savepoint support at all.
Didn't really find much in the Changelog, so we need to dig into the sourcecode.
Comment #32Pancho CreditAttribution: Pancho commented
Here's the initial commit for savepoint support in psqlodbc.
Don't know if it is already actually implemented here. No time for looking into it more closely now, but possibly later tonight.
Comment #33steinmb CreditAttribution: steinmb commented
Took #25 for a spin, my test environment is identical to what I used in #8. No comments to the approach taken to solve the issue then I'm out of my depth and you need a deep postgres knowledge say anything useful, but I can help out test the issue. Attaching log from Postgres during installation.
#25 improve stuff. We are able finish a standard install but Drupal is still not working properly after the installation is done.
ERROR: relation "cache_menu" does not exist at character 102
STATEMENT: SELECT cid, data, created, expire, serialized, tags, checksum_invalidations, checksum_deletions FROM cache_menu WHERE cid IN ('links:tools:page:node:en:1:0')
ERROR: relation "cache_menu" does not exist at character 30
STATEMENT: SELECT 1 AS expression
cache_menu cache_menu
WHERE ( (cid = 'links:tools:page:node:en:1:0') )
ERROR: relation "cache_toolbar" does not exist at character 102
STATEMENT: SELECT cid, data, created, expire, serialized, tags, checksum_invalidations, checksum_deletions FROM cache_toolbar WHERE cid IN ('1:en')
ERROR: relation "cache_toolbar" does not exist at character 30
STATEMENT: SELECT 1 AS expression
cache_toolbar cache_toolbar
WHERE ( (cid = '1:en') )
ERROR: relation "cache_page" does not exist at character 102
STATEMENT: SELECT cid, data, created, expire, serialized, tags, checksum_invalidations, checksum_deletions FROM cache_page WHERE cid IN ('http://d8.dev/toolbar/subtrees/37kLT6Fe-nUOe4nTNwnGmcxfMq5B3qDO7POgtelSako')
Keep up the good work.
Comment #34steinmb CreditAttribution: steinmb commented
The issue also need a proper summary.
Comment #35fvideon CreditAttribution: fvideon commented
It appears to me (as described in #11) that the errors like 'relation "cache_*" does not exist' are normal, 'by design' behavior, since the cache tables are not created until the first set() method call, but may be queried before that.
Comment #36steinmb CreditAttribution: steinmb commented
That might be so, but then perhaps set() never gets called or it fails in creating the missing tables. The error in #33 (except the log file) is from trying to use Drupal after the installation is finished. Menu and the toolbar both where missing menu links.
Putting the summary tag back, we should follow https://drupal.org/issue-summaries
Comment #37fvideon CreditAttribution: fvideon commented
|Needs work
|» Needs review
PASSED: [[SimpleTest]]: [MySQL] 58,100 pass(es). View
Sorry about deleting the summary update tag -- that was unintentional.
A couple of new things:
I was looking at why node/add/page was throwing a PDO Exception on the freshly installed postgresql site, and it came down to a call to drupal_valid_path with argument 'user/autocomplete' which resulted in a query of the form:
select * from users where (uid IN ('autocomplete'))
Oddly (or so it seems to me) this works fine on Mysql, and it returns the row with uid = 0. On Postgresql it throws a PDO exception because 'autocomplete' is not of type integer.
The workaround implemented does a check in user_load() to make sure UID looks like a uint.
Secondly there was a problem with fetching the menu entries for the admin toolbar. This issue ended up being caused by the way the orderBy override in Driver/pgsql/Select.php is adding all the orderBy attributes to the query ahead of those added by Entity\Query. When processing results, Entity\Query expects specific attributes at indices 0 and 1 which are not there. The workaround was to add a tag to the query that causes the orderBy override to skip the step of adding fields. This works as long as Entity\Query does add all the fields it is using for sorting, and as far as I've seen it seems to.
Comment #38fvideon CreditAttribution: fvideon commented
Updated summary
Comment #38.0fvideon CreditAttribution: fvideon commented
Updates to reflect current status
Comment #39steinmb CreditAttribution: steinmb commented
|Needs review
|» Needs work
PHP 5.4.13 (cli) (built: Apr 16 2013 11:46:33)
PostgreSQL 9.2.4
Attached PostgreSQL log from the installation.
Sorry for the delay...
Hmmm, toolbar is still not working properly. Getting simular error like this after the installation:
ERROR: relation "cache_page" does not exist at character 102
STATEMENT: SELECT cid, data, created, expire, serialized, tags, checksum_invalidations, checksum_deletions FROM cache_page WHERE cid IN ('http://d8.dev/toolbar/subtrees/37kLT6Fe-nUOe4nTNwnGmcxfMq5B3qDO7POgtelSako')
ERROR: relation "cache_page" does not exist at character 102
STATEMENT: SELECT cid, data, created, expire, serialized, tags, checksum_invalidations, checksum_deletions FROM cache_page WHERE cid IN ('http://d8.dev/toolbar/subtrees/37kLT6Fe-nUOe4nTNwnGmcxfMq5B3qDO7POgtelSako')
ERROR: relation "cache_page" does not exist at character 102
Toolbar broken
Another thing I notice is that breadcrumb is not working. Not sure if it is related or not.
Breadcrumb not working
Comment #40fvideon CreditAttribution: fvideon commented
Very interesting. I am getting different results. The standard install succeeds for me, and the toolbar and breadcrumbs seem to be working correctly.
Here is more detail about my environment and test procedure. Maybe you can spot the significant difference.
PHP 5.4.15 (cli) (built: May 8 2013 21:26:53)
PostgreSQL 9.2.4, compiled by Visual C++ build 1600, 32-bit
I started with freshly pulled code from 8.x master from about an hour ago with the patch from #37 applied and a one line fix to allow the database creation to work as discussed here: https://drupal.org/node/2010368
I started with no settings.php and no database. I chose a standard install, chose to use PostgreSQL and otherwise used defaults.
When setup completed, the site appears to be working as far as I can tell. I can see the database has 60 tables including cache_menu and cache_toolbar, but not cache_page.
When I use the site, I see these in the PostgreSQL log:
2013-06-24 14:03:23 PDT ERROR: relation "cache_page" does not exist at character 102
2013-06-24 14:03:23 PDT STATEMENT: SELECT cid, data, created, expire, serialized, tags, checksum_invalidations, checksum_deletions FROM cache_page WHERE cid IN ('http://localhost/toolbar/subtrees/W4On4fG0UMbbtKNYPmIWxZbYylAipJ-RIketj0ObDUo')
PHP.ini settings that I changed from default settings include:
- Increase max_execution_time;
- Added some xdebug config;
- Enabled the following extensions: php_curl, php_gd2, php_mbstring, php_mysql, php_mysqli, php_pdo_mysql, php_pdo_pgsql, php_pgsql.
My PostgreSQL log from setup is attached.
Comment #41mradcliffe CreditAttribution: mradcliffe commented
I had the same experience as fvideon in #40. Although same version of postgresql 9.2.4, Mac OSX 10.7, Running MAMP PHP 5.4.4, Apache 2.2.2.
I think the toolbar issue is an unfixed bug. Is that global still used..? I cannot find a follow-up issue for that @todo, but it's from #1137920: Fix toolbar on small screen sizes and redesign toolbar for desktop, which is a 300+ comment mega-issue that I don't really want to read through at the moment.
* @todo Replace this hack with something better integrated with DrupalKernel
* once Drupal's page caching itself is properly integrated.
function _toolbar_initialize_page_cache() {
$GLOBALS['conf']['system.performance']['cache']['page']['enabled'] = TRUE;
Comment #42steinmb CreditAttribution: steinmb commented
Really strange.... Our setups and way to test is more and less identical. I'll fire up my vagrant machine and test on Linux and PostgreSQL 9.1.8.
Comment #43steinmb CreditAttribution: steinmb commented
Ubuntu 12.04 LTS
Apache 2.2.22
PostgreSQL 9.1.8
Looking good! Standard installation, breadcrumb and toolbar all works as expected. Created a node and got these that prob. are unrelated to this issue.
2013-06-26 11:10:48 UTC ERROR: invalid input syntax for integer: "" at character 192
2013-06-26 11:10:48 UTC STATEMENT: SELECT base.nid AS nid, base.uuid AS uuid, base.vid AS vid, base.type AS type, base.langcode AS langcode, base.tnid AS tnid, base.translate AS translate
node base
WHERE (base.nid IN (''))
2013-06-26 11:10:59 UTC ERROR: relation "cache_page" does not exist at character 102
2013-06-26 11:10:59 UTC STATEMENT: SELECT cid, data, created, expire, serialized, tags, checksum_invalidations, checksum_deletions FROM cache_page WHERE cid IN ('http://d8.dev/toolbar/subtrees/W4On4fG0UMbbtKNYPmIWxZbYylAipJ-RIketj0ObDUo')
2013-06-26 11:11:23 UTC ERROR: relation "cache_page" does not exist at character 102
2013-06-26 11:11:23 UTC STATEMENT: SELECT cid, data, created, expire, serialized, tags, checksum_invalidations, checksum_deletions FROM cache_page WHERE cid IN ('http://d8.dev/toolbar/subtrees/W4On4fG0UMbbtKNYPmIWxZbYylAipJ-RIketj0ObDUo')
I'll re-test with postgres 9.2.4. Perhaps there was something with head or my db. I'll drop it and recreate it and not only drop the tables.
Comment #44steinmb CreditAttribution: steinmb commented
OS X 10.8.x
Apache 2.2.22
PostgreSQL 9.2.4
Re-tested on PostgreSQL 9.2.4 and this time did it work just fine, so go figure. So where do we move from here? Not sure how to profile this issue.
Comment #45mradcliffe CreditAttribution: mradcliffe commented
I think the node translation query should be spun off into a new issue, and I think it's fairly major.
I think this issue should try to get installation issues solved for the most part. I don't think a consensus was reached about the performance implications of the approach in #25.
Comment #46fvideon CreditAttribution: fvideon commented
Here is a straw man approach to profiling that I think would give fairly realistic metrics:
- Capture SQL operations for a set of common tasks such as: install Drupal, create node, display node, etc. This can be done by configuring PostgreSQL to do verbose logging. Do this both with the SAVEPOINT strategy enabled, and without.
- Make a PHP test script to read a set of SQL operations and run them one at a time through PDO.
- Profile the test script with each set of SQL ops using a PHP profiler. I have no experience with it, but it looks like some people are using xhprof.
Comment #47JimmyAx CreditAttribution: JimmyAx commented
Failed to install for me.
Debian 7
PostgreSQL 9.1
Drupal 8 from Git
An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: http://localhost:8000/core/install.php?langcode=sv&profile=standard&id=1&op=do_nojs&op=do
StatusText: OK
( ! ) Fatal error: Call to a member function id() on a non-object in .../core/modules/menu/menu.module on line 221
Call Stack
10.0001235288{main}( )../install.php:0
20.0003252680install_drupal( )../install.php:39
30.85485292536install_run_tasks( )../install.core.inc:93
41.92647894520install_run_task( )../install.core.inc:536
51.92667895344_batch_page( )../install.core.inc:653
61.93037916864_batch_do( )../batch.inc:65
71.93037916896_batch_process( )../batch.inc:89
( )../batch.inc:226
91.93307943776_install_module_batch( )../batch.inc:226
101.93307944160module_enable( )../install.core.inc:2032
111.93307944208Drupal\Core\Extension\ModuleHandler->enable( )../module.inc:212
123.19498850944Drupal\Core\Extension\ModuleHandler->invoke( )../ModuleHandler.php:698
( )../ModuleHandler.php:300
143.19498851376menu_enable( )../ModuleHandler.php:300
On line 221 in menu.module we got
$link->plid = $system_link->id();. A
var_dump on
$system_link right after
entity_load_multiple_by_properties gives an empty array.
Comment #48mradcliffe CreditAttribution: mradcliffe commented
Re: #46 @fvideon: Yes, that makes sense to me, but I'm not an expert at profiling either. :|
Comment #49JimmyAx CreditAttribution: JimmyAx commented
This might be related to this issue: #1060476: Multiple issues when PostgreSQL is used with non-public schema
And for #43 (the invalid integer syntax): #1003788: PostgreSQL: PDOException:Invalid text representation when attempting to load an entity with a string or non-scalar ID
Comment #50steinmb CreditAttribution: steinmb commented
@JimmyAx: did you try the patch?
Comment #51JimmyAx CreditAttribution: JimmyAx commented
PASSED: [[SimpleTest]]: [MySQL] 58,094 pass(es). View
The one in #37? That one did not apply so I had to reroll it. This one is without the
user_load() fix as that belongs to #1003788: PostgreSQL: PDOException:Invalid text representation when attempting to load an entity with a string or non-scalar ID
The patch is not an acceptable solution. While it appears to be working (I got through the entire installation) it generates a lot of errors in the PostgreSQL log due to a lot of tables missing (mostly cache_*). I'm attaching the log from the start of the installation until the first page of the site.
Comment #52fvideon CreditAttribution: fvideon commented
Note that if you run through the D8 install with MySQL and look at PDOExceptions, you will see a lot of them in the form of
SQLSTATE[42S02]: Base table or view not found: 1146 Table '<tablename>' doesn't exist
I didn't see a way to make MySQL log these. One difference with PostgreSQL is that they do get logged with the default logging configuration.
Comment #53Josh Waihi CreditAttribution: Josh Waihi commented
Re @JimmyAx last comment (#51)
ERROR: relation "variable" does not exist at character 19
STATEMENT: SELECT value FROM variable WHERE name = 'install_task'
I found this issue came from Drupal attempting to find the install task. It doesn't even check to see if the table exists before querying it, it assumes the failure means that Drupal is not installed yet. Which is true. But its still a dirty hack. See install_verify_completed_task
I also get the same sort of issues, primarily with cache table. If I change the default cache handler to memory instead, I can install Drupal, but I still get a partially installed interface (missing menu items etc).
Comment #54steinmb CreditAttribution: steinmb commented
@Josh sounds correct. #51 contain some code that allow (at least it did) you to install Drupal. You even end up with a working installation. It's not perfect and needs work. I'm not even sure if it's the right solution....
Comment #55Josh Waihi CreditAttribution: Josh Waihi commented
AFAIK, PostgreSQL has always had transactional DDL statements so I don't think that is the underlying cause.
IMO, transactional statements isn't preferable either. Why should a statement fail and still allow the transaction to commit?
Comment #56Josh Waihi CreditAttribution: Josh Waihi commented
I recorded all the postgres statements from an attempted install of Drupal 8. I parsed out all CREATE, ERROR, BEGIN & ROLLBACK statements and have attached them.
There are 10 tables that generate query failures: key_value, cache_config, cache, cache_bootstrap, cache_views_info, cache_field, cache_entity, cache_block, cache_views_results and cache_menu.
In most cases, it appears that Drupal attempts to query these tables before they've been actually created in the database. However, the cache_block table simply does not get created. Nor is there an error from PostgreSQL explaining why. This would suggest that Drupal opted not to install the table for some other reason.
Comment #57xjm CreditAttribution: xjm commented
Comment #58xjm CreditAttribution: xjm commented
Comment #59xjm CreditAttribution: xjm commented
Comment #60mradcliffe CreditAttribution: mradcliffe commented
ah ha!
Drupal\Core\Database\Driver\pgsql\Schema.php is missing. pgsql driver does not implement Schema.php. I am confused about how tables are being created without it, but that's the problem with cache and probably other issues as well.
I'll work on this today.
Comment #61mradcliffe CreditAttribution: mradcliffe commented
Wait, my git directory was all messed up. Welp.
Comment #62mradcliffe CreditAttribution: mradcliffe commented
|Needs work
|» Needs review
PASSED: [[SimpleTest]]: [MySQL] 58,166 pass(es). View
I added a band-aid fix in DatabaseBackend.php which ensures that the cache tables exist if the method fails. This gets me through the install again.
Sorry for the false alarm re: Schema.php.
Comment #63mradcliffe CreditAttribution: mradcliffe commented
|Needs review
|» Needs work
#autocomplete_path is calling the following query and is uncaught PDOException in Database\Statement.php:
I'm not familiar enough to trace through to where this is. I know it's an access check, maybe called somewhere in url() and the access check behind UrlGenerator.
SELECT base.uid AS uid, base.uuid AS uuid, base.name AS name, base.langcode AS langcode, base.pass AS pass, base.mail AS mail, base.theme AS theme, base.signature AS signature, base.signature_format AS signature_format, base.created AS created, base.access AS access, base.login AS login, base.status AS status, base.timezone AS timezone, base.preferred_langcode AS preferred_langcode, base.preferred_admin_langcode AS preferred_admin_langcode, base.init AS init
users base
WHERE (base.uid IN ('autocomplete'))
Comment #64mradcliffe CreditAttribution: mradcliffe commented
Comment #64.0mradcliffe CreditAttribution: mradcliffe commented
summary-related-issues issue link changed
Comment #64.1mradcliffe CreditAttribution: mradcliffe commented
Add related blocker (?)
Comment #64.2mradcliffe CreditAttribution: mradcliffe commented
Add to resolution section
Comment #65mradcliffe CreditAttribution: mradcliffe commented
The cache issues are related to #2067429: Fix installer to not use Drupal\Core\Cache\DatabaseBackend, which probably points out an incompatibility with invoking cache backends.
Comment #66mradcliffe CreditAttribution: mradcliffe commented
|Needs work
|» Needs review
PASSED: [[SimpleTest]]: [MySQL] 57,841 pass(es). View
This patch adds comments to the quick fix in \Drupal\Core\Cache\DatabaseBackend.php.
Discussed with @effulgentsia, @alexpott, @msonnabaum, @xjm, and myself, and got buy-in for the quicker fix as long as this is passes testing (manual too) even if we don't know the exact root cause yet.
@msonnabaum mentioned that it would be interesting to create a separate cache backend that uses hstore in the future.
Comment #67burningdog CreditAttribution: burningdog commented
I can't comment on the patch, because I don't understand the code, but after applying it installation works for me.
Postgres: 9.2.4
Mac OS 10.6.8
Thank you! The only error I have in the drupal error log is generated by cron at http://drupal8.local/core/install.php?langcode=en&profile=standard and reads:
PDOException: SQLSTATE[42P10]: Invalid column reference: 7 ERROR: for SELECT DISTINCT, ORDER BY expressions must appear in select list LINE 1: ...id WHERE d.sid IS NULL OR d.reindex <> 0 ORDER BY d.reindex ... ^: SELECT DISTINCT n.nid FROM {node} n LEFT JOIN {search_dataset} d ON d.type = :type AND d.sid = n.nid WHERE d.sid IS NULL OR d.reindex <> 0 ORDER BY d.reindex ASC, n.nid ASC LIMIT 100 OFFSET 0; Array ( [:type] => node_search ) in Drupal\node\Plugin\Search\NodeSearch->updateIndex() (line 293 of core/modules/node/lib/Drupal/node/Plugin/Search/NodeSearch.php).
Comment #68mradcliffe CreditAttribution: mradcliffe commented
@burningdog, this issue looks like it was introduced by #2003482: Convert hook_search_info to plugin system, which was a commit from last week, but in fact it is also a bug in Drupal 7 node_update_index(). The code was taken pretty much straight into the new NodeSearch class.
I did not find any current issue when I searched for node_update_index or search. Created #2087169: NodeSearch::updateIndex does not include order by column in select.
Comment #69terikon CreditAttribution: terikon commented
I confirm that #62 solved for me following installation error, on Windows and MySQL (not PostgreSQL):
SQLSTATE[42S02]: Base table or view not found: 1146 Table '***.cache_field' doesn't exist.
Comment #70thekevinday CreditAttribution: thekevinday commented
I can confirm that the problem happens with 8.0-alpha3, but ...
As of the October 7, 2013, this issue does not appear in postgresql. I have not applied the patch here and the sight is now functional.
I do not know when the problem went away, but the last commit I pulled was:
- http://drupalcode.org/project/drupal.git/commit/04f662ff72c3030615e7e454...
Comment #71webchick CreditAttribution: webchick commented
|Needs review
|» Postponed (maintainer needs more info)
Interesting! Can anyone else confirm?
Comment #72mradcliffe CreditAttribution: mradcliffe commented
|Postponed (maintainer needs more info)
|» Active
Unfortunately I cannot confirm this with my current HEAD (commit ae7c20c7b5f1d65e66592328946a27eed808c434)
I haven't reached any transaction stoppage due to cache table creation, but comment_entity_statistic table creation borked and failed the install.
Postgres 9.2.4
ERROR: syntax error at or near "Array" at character 494
STATEMENT: CREATE TABLE comment_entity_statistics (
entity_id bigint CHECK (entity_id >= 0) NOT NULL default 0,
entity_type varchar(255) NOT NULL default 'node',
field_id varchar(255) NOT NULL default 'node__comment',
cid int NOT NULL default 0,
last_comment_timestamp int NOT NULL default 0,
last_comment_name varchar(60) NULL,
last_comment_uid bigint CHECK (last_comment_uid >= 0) NOT NULL default 0,
comment_count bigint CHECK (comment_count >= 0) NOT NULL default 0,
PRIMARY KEY (entity_id, Array, Array)
Comment #73mradcliffe CreditAttribution: mradcliffe commented
I did a bisect and stepped back to 5089f20fc96295330aefb8587ca06c300b070de6, but that also failed. That commit didn't do anything. I checked out the commit above @thekevinday mentioned
commit 04f662ff72c3030615e7e454eeada7277a72e360 (HEAD)
I ran into the same exact issue in the previous comment under the standard install.
I tried a minimal install with the same commit, and this installed
correctly. @thekevinday, did you try the standard install or just the minimal install?
Edit: Notice: A non well formed numeric value encountered in Drupal\menu_link\MenuLinkStorageController->save() (line 219 of core/modules/menu_link/lib/Drupal/menu_link/MenuLinkStorageController.php).
Edit 2: I enable menu, path, and toolbar. No menus appear in toolbar similar to previous comments in this issue
Comment #74mradcliffe CreditAttribution: mradcliffe commented
|» Needs work
PASSED: [[SimpleTest]]: [MySQL] 58,992 pass(es). View
Setting back status.
I re-rolled #66 and ran into the same issue. It looks like some other commit from the last month killed support for comment_entity_statistics.
I've uploaded the re-rolled patch after fixing a conflict that occurred when rebasing to origin/8.x on my local branch. Doesn't need to be tested.
Comment #75mradcliffe CreditAttribution: mradcliffe commented
It looks like postgres database driver in Drupal doesn't support this, which was introduced in 539 comment MONSTER MONSTER MONSTER Issue #731724
'primary key' => array('entity_id', array('entity_type', 32), array('field_id', 32)),
Edit: mysql and sqlite drivers have a createKeySql() implementation, but pgsql driver does not. Introduced in commit f4a58c3f3af1b5cb475ad427ab1dd69df926515f, which even has a title of "Postgres" :(
Comment #76mradcliffe CreditAttribution: mradcliffe commented
PASSED: [[SimpleTest]]: [MySQL] 59,031 pass(es). View
Okay, fixed the issue with comment_entity_statistics by writing another helper function to basically ignore the schema syntax. I guess fillfactor could be used, but that's up to debate.
I ran into this posting a comment, which seems to me that core still has weird menu / routing issues.
PDOException: SQLSTATE[22P02]: Invalid text representation: 7 ERROR: invalid input syntax for integer: "reply" LINE 5: WHERE (base.cid IN ('reply')) ^ in PDOStatement->execute() (line 54 of /Applications/MAMP/vhosts/drupal-git/core/lib/Drupal/Core/Database/Statement.php).
So pretty much the state of postgres just got worse in the last couple of weeks :*(
Comment #77mradcliffe CreditAttribution: mradcliffe commented
I think menu_get_item() needs to be solved completely before any more work can be done i.e. kill it with fire. I can't find all of the tasks that nuke it, but the one we're interested in now is the call in menu_get_custom_theme().
Is there a meta task for menu_get_item or an issue for menu_get_custom_theme yet?
Comment #78mradcliffe CreditAttribution: mradcliffe commented
|Needs work
|» Needs review
Comment issue is not related to this issue because it does not prevent Drupal 8 from being installed. Needs follow-up created.
I'm setting this to needs review as #76 is back to installable state.
Comment #79thekevinday CreditAttribution: thekevinday commented
Sorry, its clear that I miscommunicated with my last post.
What I meant was up to the said commit in the repository and now things work.
Not that specific commit.
As for the install I used, I am using minimal install.
Okay, so I managed to identify where things started to work in the 8.x branch:
- http://drupalcode.org/project/drupal.git/commit/ef2e45b0e86fc6863b8ee6d3...
- With this exact commit, things started to work in drupal 8 on postgresql.
- All commits prior to this commit on the 8.x branch are applied in my testing.
I tested by doing the following:
git reset ef2e45b --hard from the 8.x branch and then installing drupal 8 in minimal install mode.
git reset 61fcb6f --hard from the 8.x branch and then installing drupal 8 in minimal install mode.
(61fcb6f is the commit immediately before the working commit of ef2e45b in the 8.x branch).
I have not done any testing in standard install mode.
Comment #80mradcliffe CreditAttribution: mradcliffe commented
|Drupal 8 cannot be installed on PostgreSQL
|» Drupal 8 cannot be installed on PostgreSQL with standard install profile
Updated title.
Comment #81mradcliffe CreditAttribution: mradcliffe commented
|Drupal 8 cannot be installed on PostgreSQL with standard install profile
|» Drupal 8 cannot be installed on PostgreSQL
Actually, sorry for the spam, but I'm going to remove that title change. My testing with the minimal install profile revealed that no menus were available after installing the toolbar module.
Comment #82thekevinday CreditAttribution: thekevinday commented
I just tested #76 and it seems to fix the remaining issues/warnings/errors.
- Prior to the patch in #76, menus do not appear.
- After applying the patch in #76, menus do appear.
Comment #82.0thekevinday CreditAttribution: thekevinday commented
Added related issue #1003788
Comment #83dlu CreditAttribution: dlu commented
Attempted to install D8 this morning (fresh pull of HEAD, not patches) and got the attached error. Not sure if this is the right place to post it. I'll look into it more this afternoon.
Comment #84mradcliffe CreditAttribution: mradcliffe commented
The patch in #76 addresses that issue, dlu. Can you test?
Comment #85dlu CreditAttribution: dlu commented
I'll test it this afternoon. I'm working on https://drupal.org/node/1013034, thanks for this insight.
Comment #86fvideon CreditAttribution: fvideon commented
I saw the error in #83 last week even with the patch from #76. I noticed that it happened consistently when installing the taxonomy module. This was the configuration:
Windows 8
PHP 5.5 x64 TS (Binary marked "experimental" on php.net)
Apache 2.4 x64
The problem went away when I switched to:
PHP 5.4.20 x86
Apache 2.4 x86
PostgreSQL 9.2 was the same in both cases.
I attributed it to running the experimental PHP build.
Comment #86.0dlu CreditAttribution: dlu commented
Updated resolution with comment_entity_statistics primary key issue, and removed general testing. At this point I think general testing is done.
Comment #87dlu CreditAttribution: dlu commented
I've successfully installed today's version of D8 (as of 0f8b4e794e1e4c453185f2856b768aaeaa86f83b) with the patch from #76 using PostgreSQL (9.3.1) and PHP 5.5.4 (Homebrew) on OS X 10.9. I'm working on https://drupal.org/node/1013034 and would be happy to do anything that would help with testing along the way. I didn't see any problems as the Taxonomy module installed.
Not sure if this means it can go to RTBC or not. [edit: nope, should have read the issue summary more closely.]
Comment #88dlu CreditAttribution: dlu commented
One more problem. Currently can't create a database, these patches only work if you're using an existing database. See #2111979: PostgreSQL is unable to create a new database.
Comment #89JimmyAx CreditAttribution: JimmyAx commented
|Drupal 8 cannot be installed on PostgreSQL
|» Drupal cannot be installed on PostgreSQL
|Needs review
|» Needs work
|Issue tags:
|+needs backport to D7
This also affects 7.x as I was unable to install the latest dev snapshot to debug an issue.
Without the patch I get
SQLSTATE[42P07]: Duplicate table: 7 ERROR: relation "cache_tags" already exists. With the patch I get the exact same error message so it looks like things have changed.
Comment #89.0JimmyAx CreditAttribution: JimmyAx commented
Comment #90mradcliffe CreditAttribution: mradcliffe commented
I fetched and rebased my local branch to 8.x, but was not able to reproduce any oddities. I still have a working installation. Adding a re-roll shortly.
Comment #91mradcliffe CreditAttribution: mradcliffe commented
|Issue summary:
|View changes
|Needs work
|» Needs review
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 2001350-pgsql-fixes-91.patch. Unable to apply patch. See the log in the details link for more information. View
Comment #92mgifford CreditAttribution: mgifford commented
Comment #94mradcliffe CreditAttribution: mradcliffe commented
|Needs work
|» Needs review
I ran this test locally after fetching and rebasing to origin/8.x on my postgres branch, and it passed with flying colors. I did a git diff origin/8.x and the resulting patch was the same as patch in #91.
Let's try the test again.
Comment #95mradcliffe CreditAttribution: mradcliffe commented
Comment #97mradcliffe CreditAttribution: mradcliffe commented
I also confirmed that the test passes locally in MySQL via MAMP.
Not sure why the heck this is happening. Currrently HEAD is failing tests anyway, but not this test.
Comment #98mgifford CreditAttribution: mgifford commented
I'm not sure.. I should be able to find this here, right:
$ locate ValidationTest.php | grep form
I can't write unit tests, but maybe someone else can translate this error:
The test did not complete due to a fatal error.
Completion check
Comment #99dcrocks CreditAttribution: dcrocks commented
The testing log showed
Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 268435456 bytes) in /var/lib/drupaltestbot/sites/default/files/checkout/core/lib/Drupal/Core/Database/Connection.php on line 336
FATAL Drupal\system\Tests\Form\ValidationTest: test runner returned a non-zero error code (255).
Is this from the testing environment?
Comment #100mradcliffe CreditAttribution: mradcliffe commented
|Needs work
|» Needs review
Comment #101mradcliffe CreditAttribution: mradcliffe commented
Yes, that's from the test environment. The test fail in HEAD (not ValidationTest) is passing now so let's try again.
Comment #103bzrudi71 CreditAttribution: bzrudi71 commented
To hopefully get any progress on PostgreSQL fixing I created a new META issue queue for PostgreSQL, please see #2157455: [Meta] Make Drupal 8 work with PostgreSQL or remove support from core before release for details.
Regarding patch in #76 - It currently still applies to HEAD and PostgreSQL can be installed using standard profile. (And works afterwards :-))
However, PostgreSQL log still shows some errors with current patch and PostgreSQL Version 9.3 which should be fixed...
Comment #104bzrudi71 CreditAttribution: bzrudi71 commented
Comment #105DeimoS CreditAttribution: DeimoS commented
Comment #107InternetDevels CreditAttribution: InternetDevels commented
|Needs work
|» Needs review
PASSED: [[SimpleTest]]: [MySQL] 60,043 pass(es). View
|1007 bytes
Re-roll with little fixes according to latest changes in core.
Comment #108mradcliffe CreditAttribution: mradcliffe commented
I probably shouldn't be assigned, forgot to do this since September.
Comment #109DeimoS CreditAttribution: DeimoS commented
|Needs review
|» Reviewed & tested by the community
|0 bytes
Hi there guys,
previously I was working on Drupal 8 database driver for Oracle DB (#2037119: Roadmap for Drupal 8 oracle driver) and got a lot "funny" situation with Drupal database layer.
As result, I spent few hours to analyse this issue, all it's comments and pending patches.
Main idea of the issue (Drupal 8 installation on PostgeSQL) is fixed and installation on existing database works fine after applying the patch.
If apply #76 patch from #203955: Create database at installation time then installation works without existing database.
According to issue summary for me:
1. Transaction issue is solved.
2. All needed cache tables are creating.
3. Problem with autocomplete doesn't appears.
4. Toolbar links are present and breadcrumbs works are working corretly.
5. Problem with primary key fields that are defined by an array isn't appeared. comment_entity_statistics table was created with all defined indexes during installation.
I attached default postgresql log.
About errors in log-file: I am agree with #52. All errors is related to queries to missing tables and it isn't problem of PostgreSQL database driver because MySQL driver causes the same errors but just doesn't write them to log.
And we realy need this changes (patch from comment #107) to be committed to core because currently installation on PostgreSQL doesn't work at all. So, I set RTBC.
Comment #110DeimoS CreditAttribution: DeimoS commented
Oops, log-file is empty, attach correct one.
Comment #111webchick CreditAttribution: webchick commented
Great work on this, folks!!! So happy to see this green. :)
I was going to commit this today, but there's quite a bit of DB internals here that I don't quite understand, so assigning it to Crell for a lookover.
Comment #112webchick CreditAttribution: webchick commented
Two small things to factor into the next re-roll:
+++ b/core/lib/Drupal/Core/Database/Driver/pgsql/Connection.php @@ -31,6 +31,13 @@ class Connection extends DatabaseConnection { + private $_cursor_ctr; @@ -52,6 +59,8 @@ public function __construct(\PDO $connection, array $connection_options) { + $this->_cursor_ctr = 0;
We don't abbreviate variable names; should be spelled out "_cursor_counter".
+++ b/core/lib/Drupal/Core/Database/Driver/pgsql/Schema.php @@ -318,6 +318,21 @@ protected function _createKeySql($fields) { + protected function _createPrimaryKeySql($fields) {
This function needs docs.
Comment #113Crell CreditAttribution: Crell commented
|Reviewed & tested by the community
|» Needs work
+++ b/core/lib/Drupal/Core/Database/Driver/pgsql/Connection.php @@ -31,6 +31,13 @@ class Connection extends DatabaseConnection { /** + * Last used cursor number. + * + * @var type int + */ + private $_cursor_ctr;
What Angie said. Also, default to using protected, not private.
+++ b/core/lib/Drupal/Core/Database/Driver/pgsql/Connection.php @@ -128,11 +137,16 @@ public function query($query, array $args = array(), $options = array()) { + if (strpos($stmt->queryString,'SAVEPOINT mimic_innodb_not_released;') !== FALSE) { + $this->connection->prepare("RELEASE SAVEPOINT mimic_innodb_not_released")->execute(); + } +
I don't know PostgreSQL at all, so I'm not entirely sure what's going on here. However, string parsing SQL is what we try extremely hard to avoid. In what case is this even necessary, and why not do it in a more structured fashion?
+++ b/core/lib/Drupal/Core/Database/Driver/pgsql/Connection.php @@ -143,6 +157,10 @@ public function query($query, array $args = array(), $options = array()) { catch (\PDOException $e) { + if (preg_match("/SAVEPOINT (mimic_innodb_(released|not_released))/",$stmt->queryString,$matches)) { + $this->connection->prepare("ROLLBACK TO SAVEPOINT " . $matches[1])->execute(); + }
As above.
+++ b/core/lib/Drupal/Core/Database/Driver/pgsql/Connection.php @@ -170,7 +188,27 @@ public function prepareQuery($query) { - return parent::prepareQuery(preg_replace('/ ([^ ]+) +(I*LIKE|NOT +I*LIKE) /i', ' ${1}::text ${2} ', $query)); + $query = preg_replace('/ ([^ ]+) +(I*LIKE|NOT +I*LIKE) /i', ' ${1}::text ${2} ', $query);
Ugh, I didn't even realize we had this in here.
+++ b/core/lib/Drupal/Core/Database/Driver/pgsql/Connection.php @@ -170,7 +188,27 @@ public function prepareQuery($query) { + // While in transaction context, put a SAVEPOINT around every query that isn't + // itself a SAVEPOINT operation. This means that a failed query can't cause + // the transaction to abort, which mimics the behavior of innodb. + if ($this->inTransaction() && + (stripos($query,'SAVEPOINT ') === FALSE) && + (stripos($query,'RELEASE ') === FALSE)) { + if (preg_match('/^[\s]*SELECT /i', $query)) { + // In the case of SELECT the SAVEPOINT can also be released in the same + // query. Otherwise the RELEASE is a separate query. + $csr = 'csr' . $this->_cursor_ctr++; + $query = 'SAVEPOINT mimic_innodb_released; DECLARE '. $csr .' CURSOR FOR ' . + $query . '; RELEASE SAVEPOINT mimic_innodb_released; FETCH ALL ' . $csr; + } + else { + $query = 'SAVEPOINT mimic_innodb_not_released; ' . $query; + } + } + + return parent::prepareQuery($query);
It looks like a lot of this code here and above is tucking multiple query statement into a single query string. I don't know PostgreSQL enough to know if that's the "right" way to do things, but I do know that all this string parsing is not the "right" way in Drupal.
If there's a need to flag and track before/after concatenated queries, then we need an object that will do so. That is, we probably need to add a Postgres-specific set of methods (with their own interface and possibly trait or composable class) to the various query objects, and possibly even wrap the query string into an object to track internally. That way at least we can just deal with a few booleans that get compiled down rather than all this string parsing.
As an aside, can someone explain to me why this is necessary? I mean I see the comment, but I don't know what triggered this to be necessary in the first place. (Again, Postgres illiterate here.)
+++ b/core/lib/Drupal/Core/Database/Driver/pgsql/Schema.php @@ -318,6 +318,21 @@ protected function _createKeySql($fields) { + protected function _createPrimaryKeySql($fields) {
Methods should never have a leading underscore. That's PHP 4 legacy that we have long since left behind. (If this is extending another method somewhere, that's a bug that should be fixed.)
+++ b/core/lib/Drupal/Core/Entity/Query/Sql/Query.php @@ -206,6 +206,7 @@ protected function addSort() { + $this->sqlQuery->addTag('pgsql_no_addfield_on_orderby');
There should be no DB-specific code outside of the drivers themselves. Client code should never have to care what DB its on.
Comment #114andypost CreditAttribution: andypost commented
Comment #115andypost CreditAttribution: andypost commented
+++ b/core/lib/Drupal/Core/Database/Driver/pgsql/Update.php
@@ -65,8 +65,7 @@ public function execute() {
- $this->connection->query($stmt, $options);
- return $stmt->rowCount();
+ return $this->connection->query($stmt, array(), $options);
+++ b/core/lib/Drupal/Core/Database/Driver/pgsql/Connection.php
@@ -128,11 +137,16 @@ public function query($query, array $args = array(), $options = array()) {
+ $stmt->allowRowCount = TRUE;
rowCount() change caused by #2146733: Select queries should not use rowCount() to calculate number of rows should be fixed in #2167507-16: Fix rowCount query usage in pgsql and sqlite drivers
Comment #116webchick CreditAttribution: webchick commented
Hey there folks, I just committed #2167507: Fix rowCount query usage in pgsql and sqlite drivers so we can factor that code out of the next re-roll.
Comment #117Crell CreditAttribution: Crell commented
Comment #118mradcliffe CreditAttribution: mradcliffe commented
|Drupal cannot be installed on PostgreSQL
|» [meta] Drupal cannot be installed on PostgreSQL
|Bug report
|» Task
|Issue summary:
|View changes
I've changed this into a meta issue to address the four (or more) unfixed issues referenced in the issue summary separately.
I think some of those issues can be fixed and committed knowing that install state is still "broken". It's broken now so it won't be any worse off.
Comment #119mradcliffe CreditAttribution: mradcliffe commented
Progress so far on sub-tasks:
- Created separate patches for #2181283: Prevent pgsql driver from trying to implode primary key fields that are defined by an array and #2181289: Prevent exceptions on missing cache table during cache clear for pgsql, which are currently needs review waiting on the mysql test bot. They are also needs review for any one doing patch review. Once both of those are done, then both can be marked RTBC respectively.
- Tried to implement the savepoint/release thing in #2181291: Prevent a query from aborting the entire transaction in pgsql, but had limited success. It needs a lot of work, rework, and/or scrapping and redoing.
Comment #120mradcliffe CreditAttribution: mradcliffe commented
All sub issues are currently "Needs Review" and waiting on code review + manual testing. The manual testing part requires integrating ALL patches because they're all necessary to get through the installation.
My process for manual testing is as follows:
- Create branch for each issue based on 8.x and commit patch respectively:
git checkout 8.x; git checkout -b postgres-ISSUENUM; curl -L PATCHURL | git apply; git commit -a
- Create merge branch based on 8.x:
git checkout 8.x; git checkout -b postgres-merge-test
- Merge in each branch:
git merge postgres-ISSUENUM
- Drop public schema, create new public schema
- Delete settings.php and config directory
- Install Drupal with standard install profile.
Comment #121bzrudi71 CreditAttribution: bzrudi71 commented
Thanks mradcliffe for splitting the patch for better overview! I will do manual testing and review in the next days to see where we are. The 'old' patch worked for months, so I think the new issues will do also, but let's see...
Comment #122bzrudi71 CreditAttribution: bzrudi71 commented
Comment #123bzrudi71 CreditAttribution: bzrudi71 commented
|Needs work
|» Closed (fixed)
|Issue tags:
|-needs backport to D7
|Parent issue:
|» #2157455: [Meta] Make Drupal 8 work with PostgreSQL or remove support from core before release
As all required patches to make D8 install on PG again are in, I'm going to close this one as fixed :-)
All other remaining issues we have to take care of are now in #2157455: [Meta] Make Drupal 8 work with PostgreSQL or remove support from core before release. If one disagrees with that, please change status accordingly...
Comment #124mradcliffe CreditAttribution: mradcliffe commented
The testing bot uses testing profile, not standard profile.
#2181291: Prevent a query from aborting the entire transaction in pgsql still blocks installing on the standard profile. It's critical in and of itself. Do you want to keep this issue closed?
Comment #125bzrudi71 CreditAttribution: bzrudi71 commented
@mradcliffe Hmmh, D8 installs fine locally even in standard profile without #2181291: Prevent a query from aborting the entire transaction in pgsql on PG 9.3 for me. To make sure I'm not working with any testing code I did a git reset --hard origin/8.x first and it still works. All I can see from the PG logs is that the related error about the aborted transactions exists, but does no longer prevent from installing.
ERROR: relation "cache_menu" does not exist at character 13
STATEMENT: DELETE FROM cache_menu
ERROR: current transaction is aborted, commands ignored until end of transaction block
STATEMENT: SELECT 1 FROM information_schema.tables WHERE (table_catalog = 'd8') AND (table_schema = 'public') AND (table_name = 'cache_menu')
ERROR: relation "cache_menu" does not exist at character 13
STATEMENT: DELETE FROM cache_menu
ERROR: current transaction is aborted, commands ignored until end of transaction block
Can you crosscheck please. If it fails for you we need for sure leave this open ;-)
Comment #126mradcliffe CreditAttribution: mradcliffe commented
Do you have a working site afterward with menus?
Comment #127mradcliffe CreditAttribution: mradcliffe commented
I successfully installed Drupal without it, and I do have menus. :-)
Adjusted issue summary.
Comment #128bzrudi71 CreditAttribution: bzrudi71 commented
In short, yes! Site is working fine (screenshot attached)... BTW The broken menu was fixed in #2181285: Fix orderBy override in pgsql driver for toolbar menu links
Comment #129ILMostro CreditAttribution: ILMostro commented
I'm struggling to get drupal7 installed with postgresql9.3 on Fedora20. Searching for ERROR: relation "variable" does not exist at character 19 led me to this discussion; I don't see if this is resolved or whether it was even pin-pointed to a particular file, code base, function. Again, during install pg_log shows:
ERROR: relation "variable" does not exist at character 19
STATEMENT: SELECT value FROM variable WHERE name = 'install_task'
Installation fails, and "The requested page could not be found" with the Drupal Header showing on page.


text:
Marco Borriello has agreed to join West Ham on loan until the end of the season, reports from Italy this afternoon are suggesting.
There has been extensive speculation linking the Roma striker will a move to Upton Park in the past 24 hours and it is being claimed the 31-year-old will have a medical tomorrow before the move is confirmed, with the Hammers potentially having an option to make the move permanent.
Reports also suggest fellow Italian Antonio Nocerino, the AC Milan midfielder, is also in London to finalise a short-term move to the Hammers to aid their battle against relegation from the Premier League.


text: William Eidson, PA-C Specialties Physician Assistant, Radiology - Interventional Gender Male Overview Education / Training Overview Interests & Activities I enjoy travel, sports (as a competitor, observer and coach) as well as hiking, camping and other outdoor activities. Regardless of what I am doing, my favorite thing to is to spend time with my family and friends. Hospital Affiliations Banner MD Anderson Cancer Center (480) 256-6444Maps & Directions Education / Training Medical school Medical Univ of South Carolina, Charleston, SC My approach to care I am committed to a team-based approach to delivering excellent patient-centered care with integrity, compassion and respect.


text:
Under Cover of Midnight Hooded Cowl by Julie Turjoman
Welcome! You are browsing as a guestWould you like to see 268 projects made from this pattern and much more? create a free account What am I missing?
This book contains 28 patterns$13.54 on Amazon look inside this book!
Under Cover of Midnight Hooded Cowl
This pattern is available for free.
There is no better protection from bloodthirsty vampires than this plush hooded cowl, which encircles your delicate and appetizing human neck with warm woolen cables. Worn as a hood, it will help you blend into the shadows!
For more information, see: http://www.womansday.com/home/craft-ideas/diy-style-...


text:
A society for blind people will continue to be able to publish its newsletter for visually-impaired Three Rivers residents.
Hertfordshire Society for the Blind has been given a £600 cash boost, which means that large print, Braille and audio versions of Sight News will continue to be distributed.
The newsletter raises awareness of local and national issues, and promotes independence and gives advice on how to tackle loneliness and isolation.
The money came from Hertfordshire County Council's locality grant scheme.


text:
Decision makers
Tell Congress: Don't Cut Funding for Children in the Justice System
An estimated 250,000 youth are tried, sentenced, or incarcerated as adults every year across the United States. African-American youth are nine times more likely to receive an adult prison sentence than white youth.
Congress is currently considering what type of funding state juvenile justice programs will receive--and many vital programs are on the chopping block.
Insufficient funding will severely jeopardize, and in some states completely devastate, highly effective and proven delinquency prevention and community safety programs. A lack of funding will also cripple efforts to implement cost-effective alternatives to detention and incarceration, to reduce racial and ethnic disparities, and to keep children out of adult jails.
These programs need funding now more than ever to end the over-incarceration of young people of color in the justice system.
Urge Congress to maintain funding for juvenile justice programs to keep children out of adult jails.
Even in tough economic times, it is critical to provide states with the support necessary to protect youth and community safety. Proposed funding levels for juvenile justice programs are insufficient and will severely jeopardize, and in some states completely devastate, highly effective and proven delinquency prevention and community safety programs. The lack of funding will also cripple efforts to implement cost-effective alternatives to detention and incarceration, to reduce racial and ethnic disparities, and to keep children out of adult jails.
Deep cuts in federal juvenile justice programs undermine the implementation of federal juvenile justice laws and will:
• result in more youth incarcerated in adult jails -- costly and dangerous facilities where youth are placed at severe risk of suicide, physical and sexual abuse, recidivism, and a lifetime of disconnection from education and work;
• erode and jeopardize nationwide progress on juvenile justice improvements that have led to historic low rates in youth-offending across all U.S. states and territories; and
• eliminate support for cost-effective delinquency prevention programs and alternatives to incarceration shown to increase public safety and decrease recidivism, while producing cost savings to the public. For every $1 spent on prevention and community-based alternatives, taxpayers save up to $8 in lifetime criminal justice costs.
The proposed House cuts come on top of drastic reductions taken over the last decade. Since FY02, federal juvenile justice funds to states have been slashed by 90%. The Senate's proposed funding levels do much better to ensure that all states, territories and DC will continue to receive necessary resources to adhere to federal standards, to prevent and reduce delinquency, and to continue to protect youth who come into contact with the system. I urge you to adopt the Senate proposal for juvenile justice programs, specifically Title II and Title V of the Juvenile Justice and Delinquency Prevention Act (JJDPA), and the Juvenile Accountability Block Grant (JABG).
Campaign for Youth Justice started this petition with a single signature, and now has 1,442 supporters. Start a petition today to change something you care about.
Report abuse
Please report any content that may violate Change.org's Terms of Service or Community Guidelines.
Thank you for taking the time to report content. Our team will review your claim and contact you if we need more information.


text:
Courtney Stodden's Easter Bikini
Sorry, C-Stod, carrots don't prevent genital warts.
not a case of sexy all the way down to the toes when they are curled up and hanging over and out your shoes, eeeewwww
Wish I was that carrot! Nice photo bunny Courtney!
It's obvious this child has been molested by an old man. Why else do children like her try so hard to solicit such gross type of attention? They are obviously victims of child molestation. Maybe her dad fucked her as a baby……just sayin.


text:
2018 Young Leather Scientist Grant -Leather Research Grant Announced by IULTCS -
The Executive Committee of the IULTCS is pleased to launch the 2018 Young Leather Scientist Grant. This prestigious grant is to be awarded to a young ...
Read More
June 2017 Newsletter -
Click here to download the June 2017 Newsletter from UK leather.>...
Read More
Pittars to open first shop -
Visitors to Clarks Village will see something new this morning as the hoardings go up announcing Pittards first standalone and outlet store. Scheduled...
Read More
Find and contact companies that manufacture leather in the UK and access a wealth of information about where they are located, how to contact them and full details about the types of leather they supply.
The UK leather industry's long-standing reputation for quality, consistency and reliability is underpinned by a comprehensive system of regulation and industry agreements.
International trade is an important aspect of the leather industry, with hides, skins, leather and leather products all extensively traded.
An Aston Martin combines three important elements: power, beauty and soul. Aston Martins are truly special - they always have been and always will be.
More about Aston Martin Lagonda
The source for all information regarding UK leather, UK leather producers and the UK leather industry.
UK LEATHER aims to facilitate the process of identifying and contacting UK based manufacturing facilities that employ people in the manufacture of leather in the UK.
You can access a wealth of information about UK leather manufacturers as well as gaining direct access to the individual companies and their products.
"It's reassuring to know that the UK's world famous leather industry is represented with such passion and promoted so uniquely to brands like ours, who know quality when we see it."


text:
Would you like to save as your currency permanently or for this visit only?
Room size was the only positive thing from this stay Air condition keeps blowing cold air all night long. Location was far through if you don't mind taking buses it's ok. Room cleaning service needs to be improved.
Good minibus and public bus connections to Causway Bay and Central. Nice swimming pool. Only hk$20 cab ride to Ocean Park. Far away from the city.
NIce design,free shuttles,spacey rooms,good bus connection,nice wiew to Victoria... Freezing rooms 18-19°C, hotel has no central or local heating!Swimmingpool 15°C with virgin water
Nothing When I book the room. I have specific ask for non smoking room but when we get their the room is not available because they said I have not requested!! And the room is smell so bad! The shower is not clean!
location is good because its near Ocean Park. although no nearby good restaurant. and no good establishment except for that park. the hotel location is isolated. the cleanliness of the hotel is excellent. People must improve their english, very bad, especially taxi drivers - too bad. receptionist also must improve on their PR. (public relation) skills. not too nice. check in time must also be available in the morning and not just 2pm. this is too bad. travelers normally arrived in the morning so hotel check in at this time must also be available. no need to wait for the 2pm check in time.
New numbers Room with a View "on the mountain" was the number of views "on the wall"
The environment is quiet, good that they have shuttle bus. Clean and stylish design. Restaurant good.
Hotel is best with very well staff and very comfertable
Loved the happy hour. Loved the 23rd floor bar. Loved the breakfast. Very stylish room.
Actually I had stayed in many hotels during my business trips through the past 5 years but the friendly attitude of staff in this hotel is the most impressive which I really liked.
I have stayed here twice in 06. Both stays were excellent. Rooms are fantastic with HS internet, plasma T.V. Great views. Bar and food are very good. Great fitness center. Warning. It is not near the main part of the island. There is a shuttle to Central Station every hour. Taxi is not that expensive. Hotel is less expensive than other luxury hotels on the island. Very pleasant experience. Will stay again.
Large room, very comfortable. Staff was extremely friendly, Ms. Kennis helped us with everything we wanted.
cleanliness the wifi is so slow it is almost non existent. the exaust fan was not working so with limited space, it will definitely cause some smell in whole room
the inclusiveness; free softdrinks, newspapers and internet; even a good quality umbrella and an invitation to keep it! The double bed was not kingsize and I had expected pushed-together twins which would have been more suitable for my daughter and I.
View to the fishery & sea Two busy roads embrace the hotel, making it a very noisy spot round a clock. Closed windows do not resolve the problem, one can still hear traffic very well. If you want to get away from "hassle and bustle of Hong Kong" this is not the place to enjoy tranquility, it is a very busy area, only on the other side of Hong Kong island. Sea view" is supposed to tempt visitors to choose this hotel, but do not expect to see beautiful deserted sea shores, you will have very busy Aberdeen fishery right next to you + busy maritime traffic + some of you view will be blocked by buildings. I enjoyed watching fishery operations anyway, but that's not for everyone.
Homely feel and staff (Kennis Hou & Hazel) went extra mile to ensure we have a comfortable stay and always on hand to handle our needs.Location is within reach to most parts of Hong Kong and we can take ferry trip to nearby islands too. Will return again! The location facing the Chinese cemetery.
Everything, especially free use of washing machines and dryer. Nothing to dislike.
The facility and value
The staff incredibly helpful and pleasant. Hotel provided great info to assist guests in navigating around Hong Kong. Enjoyed the fact the hotel was located in local neighborhood which enabled us to enjoy everyday life in the neighborhood. Enjoyed the Evening Happy Hour - Great Experiences, we would definitely stay there again!
The room was clean (except the carpet) and convenient. Since I like the wood floor, I asked the staff to remove the carpet in the second day. The staff was pretty kind. The free breakfast was reasonably good. My favorite was the free entrance to the swimming pool and gym of Le Meridien Cyberport Hotel. You need to take a taxi or a bus to go from Abeo to Le Meridien, but it is worth trying. First, I had to pay 2% of extra charges for credit card payment (3% for Amex). When I made a reservation at booking.com, there was no information about the extra charges for credit card payment. Second, the staff asked me to keep a window open while cooking something. The smoke detector was very sensitive even though the hood on the stove is turn on.
Fantastic views. Interesting watching the fishing boats. Easy to bus it everywhere. Fabulous staff. We loved everything about it.
good price, clean, neat, not overly fussy or luxury, value for money, efficent breakfast plain, but also, that is good, I do not need a banquet...
helpful staff. there is a kind of ventilation in the room that provokes noise from outside like an open window.
Good location with friendly staff. When taking a shower, the bathroom floods the flooring with no proper drainage.
The room is nice, beds are comfortable. There are rooms for smokers. The conditioner can heat effectively. Good ventilation in a bathroom. Slippers and tooth-brushes are provided. There is a safe in the room. A newspaper is being delivered. Quite successfully hotel location: there are Aberdeen centre (the bus terminal, shops, snackbars). A beautiful view from the window, a wonderful promenade ashore. Very unsuccessful design of a toilet bowl - it is not broken, but not always works. Unfortunately there is no exit on a balcony and it is forbidden to open a window. Cleaning begins early - becomes noisy in a hall.
Internet and breakfast included in the price Breakfast is ok but not fantastic at all
It's good, my family felt much convenient and comfort during our staying there. Not applicable
Comes with Breakfast.good pricing.nice staffs Some rooms overlooking cemetery
Pretty big room. Good value for money Shower basin drain was too slow, so that water sometimes sloped over
The room is large compared to other hotels in Hong Kong I stayed before


text: 2. As of noon trading, NextEra Energy ( NEE) is up $1.01 (1.27) to $80.74 on average volume Thus far, 930,138 shares of NextEra Energy exchanged hands as compared to its average daily volume of 1.8 million shares. The stock has ranged in price between $80.32-$80.95 after having opened the day at $80.39 as compared to the previous trading day's close of $79.73. NextEra Energy, Inc., through its subsidiaries, engages in the generation, transmission, distribution, and sale of electric energy in the United States and Canada. The company is involved in the generation of renewable energy from wind and solar projects. NextEra Energy has a market cap of $33.6 billion and is part of the utilities industry. The company has a P/E ratio of 17.0, below the S&P 500 P/E ratio of 17.7. Shares are up 15.2% year to date as of the close of trading on Friday. Currently there are 9 analysts that rate NextEra Energy a buy, no analysts rate it a sell, and 7 rate it a hold. TheStreet Ratings rates NextEra Energy as a buy. The company's strengths can be seen in multiple areas, such as its expanding profit margins, good cash flow from operations and increase in stock price during the past year. We feel these strengths outweigh the fact that the company has had sub par growth in net income. Get the full NextEra Energy Ratings Report now. 3x UPSIDE POTENTIAL: TheStreet Quant Ratings has identified a handful of stocks that can potentially TRIPLE in the next 12-months. Learn more.


text:
A new book tells how Einstein and others made brilliant blunders
Player utilities
This story is based on a radio interview. Listen to the full interview.
Skip to content
This story is based on a radio interview. Listen to the full interview.
Kurt Andersen: As I mentioned to Andrea, I recently read an excellent new non-fiction book about mistakes made by scientific superstars, like Darwin, and Einstein, and Lord Kelvin, all regarded as unimpeachable geniuses now, of course, but over the course of their careers, all of them got something big wrong. The book is called "Brilliant Blunders" and it's by the NASA astrophysicist Mario Livio. He thinks it's important to remember the big missteps as well as the moments of genius, because science requires both.
Mario Livio: It has occurred to me that science is presented as this direct march to the truth, and being a scientist myself, I know that's very far from the truth. So, I really wanted to give this picture of this zig-zag path with lots of false starts, and so on.
Andersen: Which is why this book is so valuable. So, at the risk of giving aid and comfort to anti-scientific creationists, let's take the theory of evolution. What was flawed about it?
Livio: So, you know, Darwin didn't know any genetics, and we cannot blame him for that, I mean, nobody knew genetics at the time. But he adopted the theory of blending heredity, namely the characteristics of the two parents get mixed like gin and tonic or like paints and what he didn't realize, and that was his blunder, that with such a theory, actually natural selection could never have really worked.
Andersen: Because you'd know exactly what was going to happen forever. There's no mutations possible.
Livio: There's no mutations and plus you know the characteristic that you wanted to preserve gets diluted very, very fast and in fact disappears from the population instead of shifting the entire population into that direction.
Andersen: Right.
Livio: One thing that he understood, which was really fantastic, and you wonder why anybody else did not immediately understand, was that you say "If I take a distinct male and a distinct female, they also produce a distinct male or female and not some intermediate hermaphrodite."
Andersen: Yeah. Good point.
Livio: So, he noticed that there was a problem there, he just didn't know how to correct it.
Andersen: There are some scientists that you write about who are so intent on rejecting things that they don't understand, or in the particular case of Albert Einstein aren't mathematically consistent. Explain his idea of the cosmological constant and the trouble that caused him.
Livio: Einstein thought that they universe was static, that nothing was moving, because at the time when he tried to apply his theory of general relativity to the universe, 1917, we didn't know that the universe was not static. But he knew that there is gravity everywhere. Everything attracts everything else, so how can it be static - these things should just be collapsing. So, he added this term into his equations, which was not easy by the way, to add a term that would still leave all the principles intact, which added the repulsive gravity which exactly balanced the attractive gravity that existed there to keep everything in place.
Andersen: So, the math required him to create this X factor even though we had no idea what it is?
Livio: Right. Now, in the late 1920's, astronomers discovered that the universe is in fact expanding. Once Einstein heard that, he said, "But wait a second, if it's all expanding, I don't need this accurate balance, because all that gravity would do is it would slow down expansion." So he regretted having put that term in and pulled it out of his equation, even though it was allowed by the principles of the theory.
Andersen: And what did subsequent science do to that?
Livio: Well, 15 years ago - actually precisely 1998, two groups of astronomers discovered that our universe is not only expanding, the expansion is speeding up. It's accelerating, and as far as we can tell, at least to this point, the thing that's driving this speeding up is precisely that extra repulsive term that Einstein put originally into his equation.
Andersen: So, he was more or less right the first time?
Livio: Yes. He was more right the first time than by taking it out.
Andersen: So, are there ways for scientists to sort of keep shaking up their assumptions about, "Oh, this is right, this is wrong." Musicians can improvise, writers can switch back and forth between the third person and first person to give themselves a new sense of narrative reality, are there any equivalents in science?
Livio: I think that the 20th century perhaps has seen some of this happening in almost every area of creative processes. This is where you get the most discomfort from some people with music, with visual art, and you also get the big revolutions in physics - quantum mechanics, general relativity, which go against our everyday intuition of things as basic as space and time, and so on. So, I think yes, and it is perhaps interesting that these types of revolution appear to have been somewhat coincidental. You start to think, okay, maybe the connections are not direct, but still, people think in certain ways.
Andersen: Right. But can individual scientists stay on their game and keep their minds open? Is that possible once you've gone so far down in your particular specialty and your sense of what's true?
Livio: Yeah, it is still the case if you're stuck in some sort of minimum and you want to get out of that, you need some sort of larger perturbation. You cannot rely on some infinitesimal that will get you to a big discovery.
Andersen: String Theory in particular physics is the big, cool new theory that all the cool kids believe. It's this dramatic, ambitious big leap but unproven and may be unprovable. As you think about blunders and have spent so much time looking at this, do you have a hunch that 50 or 100 years from now, we'll see that we'll have had a brilliant blunder at its core, maybe toward the truth but in some fundamental way not the truth?
Livio: We might. One of the problems with blunders is that you can only tell that they're blunders after the fact. String theory or end theory is our current best attempt at unifying all the forces of nature, but as you point out there is no real experimental evidence for it. So, it could turn out to be a wrong direction and maybe we will need to go in another direction. But, it is still the case that a lot of very interesting mathematics and many, many interesting ideas have been developed, so I think if it will turn out to be a blunder, it will most probably be a brilliant blunder.
Andersen: Mario Livio, thank you very much.
Livio: Thank you for having me.
Andersen: Mario Livio's new book is called "Brilliant Blunders: From Darwin to Einstein".


text:
I am facing a very strange problem in my websevice which is working on
socket communication.
While i am publishing my webservice to the IIS and invoking a method,
a data loss problem in occuring. I seems strange because when i am
using the .net framework's inbuild application development server that
comes along with 2.0 framework,I am not facing this problem.
I dont know why it is not working with IIS while it is working with
other server?
Is there is any drawback of IIS in socket communication ?
I am using TCPClient to establish the connection.


text:
Lien (TJ) Tran worked for two years as a flight surgeon for the U.S. Air Force before starting his Occupational and Environmental medicine residency at UCSF in June 2013. Stationed at Fairchild Air Force base in Spokane, Washington, TJ was the Squadron Medical Element (SME) for the 92d Air Refueling Squadron. His responsibilities included providing medical support service to all flyers and their families.
"A flyer is anyone who has wings," says TJ. Flyers include fixed and rotary wing pilots, "boomers" or boom operators, "jumpers" or troops who are parachutists, and other personnel with aeronautical rating. "The planes we flew refuel other planes in the air and our motto is 'Dantibus Damus-We Give So That You May Give,'" adds TJ. As part of a team of four flight surgeons he was deployed every two to three months. He earned his air and achievement medals on his second deployment.
As a flight surgeon, TJ recognized that occupational and environmental factors weighed into many of the health issues he saw in clinical practice. When the troops who refueled the jets complained of back pain, for example, TJ and his team came up with ergonomic solutions to resolve the problem. While deployed to remote military locations, he worked closely with public health officials and bioenvironmental engineers to ensure the safety of food and water for service members.
Conducting hearing conservation programs for aviation and machine shop workers, toxicology investigations related to environmental and occupational exposures like jet fuel, and conducting Initial Flying Class exams for those who enlist to become flyers, helped prepare TJ for his chosen career.
"When I decided to look around for an occupational medicine residency, my preference was the West Coast, somewhere with nice weather, and I was fortunate to learn UCSF offers this specialty," says TJ. A California native, he chose UCSF because it was close to family and is a renowned institution, and it gave him the chance to learn from experts like Dr. Paul Blanc and Dr. Robert Harrison, whom he calls "grand masters" of the field. "Eventually I will head back to the military," notes TJ, "but if any issues arise I know I have friends at UCSF like Paul and Bob to refer back to for help."
When TJ completes his residency in June 2015 and returns to the US Air Force, he plans to obtain his pilot's license. He admits willingly, "I'm interested in being a flight surgeon because I get to fly."
Find this article and others online at http://coeh.berkeley.edu/bridges