| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
| |
|
| |
|
|\
| |
| |
| |
| |
| | |
Introduce new ActiveRecord transaction error classes
Closes #26018
|
| | |
|
| |
| |
| |
| |
| | |
Because `type_cast` against `binds` always requires
`attr.value_for_database` and this pattern appears frequently.
|
|/
|
|
| |
Address to https://github.com/rails/rails/commit/5a302bf553af0e6fedfc63299fc5cd6e79599ef3#commitcomment-18288388.
|
|
|
|
| |
or deadlocks
|
|
|
|
|
|
| |
Follow up of 1683410.
Signed-off-by: Jeremy Daer <jeremydaer@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Example:
create_table :users do |t|
t.string :name
t.index 'lower(name) varchar_pattern_ops'
end
Fixes #19090.
Fixes #21765.
Fixes #21819.
Fixes #24359.
Signed-off-by: Jeremy Daer <jeremydaer@gmail.com>
|
|
|
|
|
|
|
|
| |
- Rename max to statement_limit
- Remove magic number 1000 from everywhere
- Defined StatementPool::DEFAULT_STATEMENT_LIMIT and started using it everywhere
Signed-off-by: Jeremy Daer <jeremydaer@gmail.com>
|
|
|
|
|
| |
Adapters override `#supports_savepoints?` to return `true` if they
support transaction savepoints. Defaults to `false`.
|
|
|
|
| |
`IPAddr` is used in `OID::Cidr`.
|
|
|
|
| |
`Arel::Visitors::VISITORS` was removed at https://github.com/rails/arel/pull/412.
|
|\
| |
| |
| | |
Extract `arel_visitor` and move up to the abstract adapter
|
| | |
|
|\ \
| | |
| | |
| | | |
Add `ActiveRecord::ValueTooLong` exception class
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
* Switch to keyword args where we can without breaking compat.
* Use add_table_options! for :options, too.
* Some code polish.
|
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Comments are specified in migrations, stored in database itself (in its schema),
and dumped into db/schema.rb file.
This allows to generate good documentation and explain columns and tables' purpose
to everyone from new developers to database administrators.
For PostgreSQL and MySQL only. SQLite does not support comments at the moment.
See docs for PostgreSQL: http://www.postgresql.org/docs/current/static/sql-comment.html
See docs for MySQL: http://dev.mysql.com/doc/refman/5.7/en/create-table.html
|
| |
| |
| |
| | |
Follow up to #24079
|
|\ \
| |/
|/|
| |
| | |
samphilipd/sam/properly_deallocate_prepared_statements_outside_of_transaction
Correctly deallocate prepared statements if we fail inside a transaction
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Addresses issue #12330
Overview
========
Cached postgres prepared statements become invalidated if the schema
changes in a way that it affects the returned result.
Examples:
- adding or removing a column then doing a 'SELECT *'
- removing the foo column then doing a 'SELECT bar.foo'
In normal operation this isn't a problem, we can rescue the error,
deallocate the prepared statement and re-issue the command.
However in PostgreSQL transactions, once any command fails, the
transaction becomes 'poisoned' and any subsequent commands will raise
InFailedSQLTransaction.
This includes DEALLOCATE statements, so the default deallocation
strategy instead of removing the cached prepared statement instead
raises InFailedSQLTransaction.
Why this is bad
===============
1. InFailedSQLTransaction is a fairly cryptic error and doesn't
communicate any useful information about what has actually gone wrong.
2. In the naive implementation the prepared statement never gets
deallocated - it stays alive for the length of the session taking up
memory on the postgres server.
3. It is unsafe to retry the transaction because the bad prepared
statement is still in the cache and we would see the exact same failure
repeated.
Solution
========
If we are outside a transaction we can continue to handle these failures
gracefully in the usual way.
Inside a transaction instead of issuing a DEALLOCATE command that will
certainly fail, we now raise
ActiveRecord::PreparedStatementCacheExpired.
This can be handled further up the stack, notably inside
TransactionManager#within_new_transaction. Here we can make sure to
first rollback the transaction, then safely issue DEALLOCATE statements
to invalidate the rest of the cached prepared statements.
This also allows the user (or some gem) the opportunity to catch this error and
voluntarily retry the transaction if a schema change causes the prepared
statement cache to become invalidated.
Because the outdated statement has been deallocated, we can expect the
transaction to succeed on the second try.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
p PostgreSQLAdapter::OID::Money.precision
# => 19
p PostgreSQLAdapter::OID::Money.new.precision
# => nil
|
| |
| |
| |
| |
| |
| |
| | |
This reverts commit ff835f90800a3e4122d64606cb328908c2e0e071, reversing
changes made to c4d85dfbc71043e2a746acd310e32f4f04db801a.
Reason: This broke the tests. We will add back after investigated.
|
| | |
|
|\ \
| | |
| | | |
Add `:expression` option support on the schema default
|
| | |
| | |
| | |
| | | |
The default 'now'::date is CURRENT_DATE.
|
|/ /
| |
| |
| | |
These methods are private and unused from anywhere.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is useful to libraries that want to feature gate based on the
version of PostgreSQL the user is connected to. For instance, I want to
know if the user is connected to a version of Postgres that supports
concurrent materialized view refreshes. I could add that as a method on
the adapter as a PR, but rails has no need for this itself.
Rails is already using the postgresql_version for its own feature gating
and this makes that possible for other libraries.
|
| |
| |
| |
| |
| | |
Since the attributes API is new in Rails 5, we don't actually need to keep
the behavior of `attribute :point`, as it's not a breaking change.
|
| |
| |
| |
| | |
`pool` in args is unused anymore. And `config` is used in all adapters.
|
|\ \
| | |
| | |
| | |
| | | |
kamipo/schema_dumping_support_for_postgresql_geometric_types
Add schema dumping support for PostgreSQL geometric data types
|
| | | |
|
|\ \ \
| |/ /
|/| |
| | |
| | | |
kamipo/not_passing_native_database_types_to_table_definition
Not passing `native_database_types` to `TableDefinition`
|
| |/
| |
| |
| |
| |
| | |
The `native_database_types` only used in `TableDefinition` for look up
the default `:limit` option. But this is duplicated process with
`type_to_sql`. Passing `native_database_types` is not needed.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- key was a poor choice of name. A key implies something that will
unlock a lock. The concept is actually more like a 'lock identifier'
- mysql documentation calls this a 'lock name'
- postgres documentation calls it a 'lock_id'
- Updated variable names to reflect the preferred terminology for the database in
question
|
|/ |
|
| |
|
|\
| |
| |
| |
| | |
samphilipd/sam/manual_locking_on_schema_migrations
Make migrations concurrent safe (using advisory locks)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Addresses issue #22092
- Works on Postgres and MySQL
- Uses advisory locks because of two important properties:
1. The can be obtained outside of the context of a transaction
2. They are automatically released when the session ends, so if a
migration process crashed for whatever reason the lock is not left
open perpetually
- Adds get_advisory_lock and release_advisory_lock methods to database
adapters
- Attempting to run a migration while another one is in process will
raise a ConcurrentMigrationError instead of attempting to run in
parallel with undefined behavior. This could be rescued and
the migration could exit cleanly instead. Perhaps as a configuration
option?
Technical Notes
==============
The Migrator uses generate_migrator_advisory_lock_key to build the key
for the lock. In order to be compatible across multiple adapters there
are some constraints on this key.
- Postgres limits us to 64 bit signed integers
- MySQL advisory locks are server-wide so we have to scope to the
database
- To fulfil these requirements we use a Migrator salt (a randomly
chosen signed integer with max length of 31 bits) that identifies
the Rails migration process as the owner of the lock. We multiply
this salt with a CRC32 unsigned integer hash of the database name to
get a signed 64 bit integer that can also be converted to a string
to act as a lock key in MySQL databases.
- It is important for subsequent versions of the Migrator to use the
same salt, otherwise different versions of the Migrator will not see
each other's locks.
|
|\ \
| | |
| | | |
PostgreSQL, Replace static connection param list by libpq's dynamic list
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This makes the connection adapter future-proof regarding to new parameters.
To maintain backward compatibility, :requiressl is added by hand. It is
deprecated by PostgreSQL since 2003, but still accepted by libpq.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In Postgres 8.1 the standard_conforming_strings setting was read-only,
meaning you got an error if you tried to update it. By filtering on
`context = 'user'` we only try to update the setting if it's
user-writable[1].
[1]: http://www.postgresql.org/docs/9.4/static/view-pg-settings.html
|
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The standard_conforming_strings setting doesn't exist on all versions of
Postgres, but if it does exist, Rails turns it on. Previously this was done by
effectively disabling errors on the Postgres connection, issuing a SET to turn
the setting on, then re-enabling errors on the connection. However, if you're
running pgbouncer in transaction-pooling mode, you can't guarantee that
successive calls to `#execute` will be sent to the same pgbouncer-postgres
connection, so you can end up disabling errors on a different postgres
connection, and never re-enabling them. Future queries on that connection that
result in errors (e.g. violating unique constraints) will leave the connection
in a bad state where successive queries will fail.
This commit sets standard_conforming_strings by issuing an UPDATE to
pg_settings, which will update the setting if it exists, and do nothing if it
doesn't (rather than erroring out like SET would), which means we can remove
the error-disabling code.
It's also worth noting that Postgres has allowed standard_conforming_strings to
be updated since 8.2 (which is the oldest version Rails supports), so
technically we probably don't even need to be defensive here.
|