Fix typo
Branch
--
REL9_1_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/280daac70790cd5fc0129ac620935e4fc4ca7a90
Modified Files
--
doc/src/sgml/ecpg.sgml |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--
Sent via pgsql-committers mailing list (pgsq
Fix typo
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/7431cb251a6c36ea520f955dd03d4b35b0f0f3e4
Modified Files
--
doc/src/sgml/ecpg.sgml |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--
Sent via pgsql-committers mailing list (pgsql-commi
Message style improvements
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/85612039b9eab75c2a29399f3a394acd4ca4cc3f
Modified Files
--
contrib/pg_archivecleanup/pg_archivecleanup.c |4 ++--
contrib/pg_standby/pg_standby.c | 13 +++---
Message style improvements
Branch
--
REL9_1_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/00fc5d22634df1a59c8a265dba3f12814dc343c3
Modified Files
--
contrib/pg_archivecleanup/pg_archivecleanup.c |4 ++--
contrib/pg_standby/pg_standby.c | 13 +++
Fix unsafe order of operations in foreign-table DDL commands.
When updating or deleting a system catalog tuple, it's necessary to acquire
RowExclusiveLock on the catalog before looking up the tuple; otherwise a
concurrent VACUUM FULL on the catalog might move the tuple to a different
TID before we
Fix unsafe order of operations in foreign-table DDL commands.
When updating or deleting a system catalog tuple, it's necessary to acquire
RowExclusiveLock on the catalog before looking up the tuple; otherwise a
concurrent VACUUM FULL on the catalog might move the tuple to a different
TID before we
Fix unsafe order of operations in foreign-table DDL commands.
When updating or deleting a system catalog tuple, it's necessary to acquire
RowExclusiveLock on the catalog before looking up the tuple; otherwise a
concurrent VACUUM FULL on the catalog might move the tuple to a different
TID before we
Fix unsafe order of operations in foreign-table DDL commands.
When updating or deleting a system catalog tuple, it's necessary to acquire
RowExclusiveLock on the catalog before looking up the tuple; otherwise a
concurrent VACUUM FULL on the catalog might move the tuple to a different
TID before we