doc: Clarify CREATE TABLESPACE documentation
Be more specific about when and how to create the directory and what
permissions it should have.
Discussion:
https://www.postgresql.org/message-id/flat/5ca60e1a-26f9-89fd-e912-021dd2b8afe2%40gmail.com
Branch
--
master
Details
---
https://git
Fix ALTER COLUMN TYPE to not open a relation without any lock.
If the column being modified is referenced by a foreign key constraint
of another table, ALTER TABLE would open the other table (to re-parse
the constraint's definition) without having first obtained a lock on it.
This was evidently in
Fix ALTER COLUMN TYPE to not open a relation without any lock.
If the column being modified is referenced by a foreign key constraint
of another table, ALTER TABLE would open the other table (to re-parse
the constraint's definition) without having first obtained a lock on it.
This was evidently in
Fix ALTER COLUMN TYPE to not open a relation without any lock.
If the column being modified is referenced by a foreign key constraint
of another table, ALTER TABLE would open the other table (to re-parse
the constraint's definition) without having first obtained a lock on it.
This was evidently in
Fix ALTER COLUMN TYPE to not open a relation without any lock.
If the column being modified is referenced by a foreign key constraint
of another table, ALTER TABLE would open the other table (to re-parse
the constraint's definition) without having first obtained a lock on it.
This was evidently in
Fix tuple_data_split() to not open a relation without any lock.
contrib/pageinspect's tuple_data_split() function thought it could get
away with opening the referenced relation with NoLock. In practice
there's no guarantee that the current session holds any lock on that
rel (even if we just read
Fix tuple_data_split() to not open a relation without any lock.
contrib/pageinspect's tuple_data_split() function thought it could get
away with opening the referenced relation with NoLock. In practice
there's no guarantee that the current session holds any lock on that
rel (even if we just read
Fix tuple_data_split() to not open a relation without any lock.
contrib/pageinspect's tuple_data_split() function thought it could get
away with opening the referenced relation with NoLock. In practice
there's no guarantee that the current session holds any lock on that
rel (even if we just read
Fix ALTER COLUMN TYPE to not open a relation without any lock.
If the column being modified is referenced by a foreign key constraint
of another table, ALTER TABLE would open the other table (to re-parse
the constraint's definition) without having first obtained a lock on it.
This was evidently in
Fix ALTER COLUMN TYPE to not open a relation without any lock.
If the column being modified is referenced by a foreign key constraint
of another table, ALTER TABLE would open the other table (to re-parse
the constraint's definition) without having first obtained a lock on it.
This was evidently in
Fix tuple_data_split() to not open a relation without any lock.
contrib/pageinspect's tuple_data_split() function thought it could get
away with opening the referenced relation with NoLock. In practice
there's no guarantee that the current session holds any lock on that
rel (even if we just read
Fix ALTER COLUMN TYPE to not open a relation without any lock.
If the column being modified is referenced by a foreign key constraint
of another table, ALTER TABLE would open the other table (to re-parse
the constraint's definition) without having first obtained a lock on it.
This was evidently in
Lock relation used to generate fresh data for RMV.
Back-patch the 9.4-era commit 2636ecf78 into 9.3, as that fixes a case
where we open a relation while not holding any lock on it. It's
probably mostly safe anyway, since no other session could touch the
newly-created table; but I think CheckTable
Add assertions that we hold some relevant lock during relation open.
Opening a relation with no lock at all is unsafe; there's no guarantee
that we'll see a consistent state of the relevant catalog entries.
While use of MVCC scans to read the catalogs partially addresses that
complaint, it's still
Change PROCEDURE to FUNCTION in CREATE EVENT TRIGGER syntax
This was claimed to have been done in
0a63f996e018ac508c858e87fa39cc254a5db49f, but that actually only
changed the documentation and not the grammar. (That commit did fully
change it for CREATE TRIGGER.)
Branch
--
REL_11_STABLE
Det
Change PROCEDURE to FUNCTION in CREATE EVENT TRIGGER syntax
This was claimed to have been done in
0a63f996e018ac508c858e87fa39cc254a5db49f, but that actually only
changed the documentation and not the grammar. (That commit did fully
change it for CREATE TRIGGER.)
Branch
--
master
Details
--
On 2018-09-30 17:55:57 +, Tom Lane wrote:
> Create an RTE field to record the query's lock mode for each relation.
> Details
> ---
> https://git.postgresql.org/pg/commitdiff/fdba460a26af919c0b366755d119f384706e670a
This triggers a new warning for me, when building without asserts:
/home/
Andres Freund writes:
> On 2018-09-30 17:55:57 +, Tom Lane wrote:
>> Create an RTE field to record the query's lock mode for each relation.
> This triggers a new warning for me, when building without asserts:
> /home/andres/src/postgresql/src/backend/executor/execMain.c: In function
> ‘Init
Refactor relation opening for VACUUM and ANALYZE
VACUUM and ANALYZE share similar logic when it comes to opening a
relation to work on in terms of how the relation is opened, in which
order locks are tried and how logs should be generated when something
does not work as expected.
This commit refa
On 2018/10/02 1:43, Tom Lane wrote:
> Add assertions that we hold some relevant lock during relation open.
>
> Opening a relation with no lock at all is unsafe; there's no guarantee
> that we'll see a consistent state of the relevant catalog entries.
> While use of MVCC scans to read the catalogs
Amit Langote writes:
> On 2018/10/02 1:43, Tom Lane wrote:
>> Add assertions that we hold some relevant lock during relation open.
>> ...
>> Amit Langote and Tom Lane
> I'm sorry if it wasn't clear, but the lock manager code was added to the
> original 0001 patch by David Rowley; see this message
Test passing expanded-value representations to workers.
Currently, we don't have an explicit test to pass expanded-value
representations to workers, so we don't know whether it works on all kind
of platforms. We suspect that the current code won't work on
alignment-sensitive hardware. This commi
22 matches
Mail list logo
