Problem/Motivation

For performance reasons we currently force PostgreSQL to use emulated prepares:

// Prepared statements are most effective for performance when queries
// are recycled (used several times). However, if they are not re-used,
// prepared statements become inefficient. Since most of Drupal's
// prepared queries are not re-used, it should be faster to emulate
// the preparation than to actually ready statements for re-use. If in
// doubt, reset to FALSE and measure performance.
\PDO::ATTR_EMULATE_PREPARES => TRUE,

But that's a bad idea, because of:

Postgres PDO Driver uses native statement preparation by default. PDO MySQL uses emulated prepares by default. Native prepares are much more robust against SQL injection, so should be used if at all possible.

Proposed resolution

Re-think the current default to emulate prepares. Check if this is still a performance issue in Drupal 8, and if not, revert back to default to make PostgreSQL more robust against SQL injections.

Remaining tasks

?

User interface changes

none

API changes

none

Comments

pwolanin’s picture

There is an issue about using native prepares for MySQL also - seems the issues should be coupled?

bzrudi71’s picture

Status: Active » Needs review
StatusFileSize
new788 bytes

Well, let's actually test this now that we have a green PG bot...

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

bzrudi71’s picture

Version: 8.2.x-dev » 8.3.x-dev
StatusFileSize
new788 bytes

well, let's see :)

bzrudi71’s picture

Status: Needs review » Active
bzrudi71’s picture

Status: Active » Needs review
bzrudi71’s picture

bzrudi71’s picture

Status: Needs review » Closed (won't fix)

I'm going to close this one. Test time increased just a bit but what makes me more worry is that we have lot's of memory exceptions. And as #2489672: Limit all DB drivers to executing single statements by checking for delimiter is in now I don't think it's worth the effort ;-)
Feel free to open this issue again if any ideas or concerns...