pg_dump: Properly handle public schema ACLs with --clean
pg_dump has always handled the public schema in a special way when it
comes to the "--clean" option. To wit, we do not drop or recreate the
public schema in "normal" mode, but when we are run in "--clean" mode
then we do drop and recreate t
pg_dump: Properly handle public schema ACLs with --clean
pg_dump has always handled the public schema in a special way when it
comes to the "--clean" option. To wit, we do not drop or recreate the
public schema in "normal" mode, but when we are run in "--clean" mode
then we do drop and recreate t
Repair incorrect pg_dump labeling for some comments and security labels.
We attached no schema label to comments for procedural languages, casts,
transforms, operator classes, operator families, or text search objects.
The first three categories of objects don't really have schemas, but
pg_dump tr
Repair incorrect pg_dump labeling for some comments and security labels.
We attached no schema label to comments for procedural languages, casts,
transforms, operator classes, operator families, or text search objects.
The first three categories of objects don't really have schemas, but
pg_dump tr
Repair incorrect pg_dump labeling for some comments and security labels.
We attached no schema label to comments for procedural languages, casts,
transforms, operator classes, operator families, or text search objects.
The first three categories of objects don't really have schemas, but
pg_dump tr
Repair incorrect pg_dump labeling for some comments and security labels.
We attached no schema label to comments for procedural languages, casts,
transforms, operator classes, operator families, or text search objects.
The first three categories of objects don't really have schemas, but
pg_dump tr
Repair incorrect pg_dump labeling for some comments and security labels.
We attached no schema label to comments for procedural languages, casts,
transforms, operator classes, operator families, or text search objects.
The first three categories of objects don't really have schemas, but
pg_dump tr
Repair incorrect pg_dump labeling for some comments and security labels.
We attached no schema label to comments for procedural languages, casts,
transforms, operator classes, operator families, or text search objects.
The first three categories of objects don't really have schemas, but
pg_dump tr
Make simplehash.h grow hashtable in additional cases.
Increase the size when either the distance between actual and optimal
slot grows too large, or when too many subsequent entries would have
to be moved.
This addresses reports that the simplehash performed, sometimes
considerably, worse than dy
pg_upgrade: Fix large object COMMENTS, SECURITY LABELS
When performing a pg_upgrade, we copy the files behind pg_largeobject
and pg_largeobject_metadata, allowing us to avoid having to dump out and
reload the actual data for large objects and their ACLs.
Unfortunately, that isn't all of the infor
pg_upgrade: Fix large object COMMENTS, SECURITY LABELS
When performing a pg_upgrade, we copy the files behind pg_largeobject
and pg_largeobject_metadata, allowing us to avoid having to dump out and
reload the actual data for large objects and their ACLs.
Unfortunately, that isn't all of the infor
pg_upgrade: Fix large object COMMENTS, SECURITY LABELS
When performing a pg_upgrade, we copy the files behind pg_largeobject
and pg_largeobject_metadata, allowing us to avoid having to dump out and
reload the actual data for large objects and their ACLs.
Unfortunately, that isn't all of the infor
pg_upgrade: Fix large object COMMENTS, SECURITY LABELS
When performing a pg_upgrade, we copy the files behind pg_largeobject
and pg_largeobject_metadata, allowing us to avoid having to dump out and
reload the actual data for large objects and their ACLs.
Unfortunately, that isn't all of the infor
pg_upgrade: Fix large object COMMENTS, SECURITY LABELS
When performing a pg_upgrade, we copy the files behind pg_largeobject
and pg_largeobject_metadata, allowing us to avoid having to dump out and
reload the actual data for large objects and their ACLs.
Unfortunately, that isn't all of the infor
pg_upgrade: Fix large object COMMENTS, SECURITY LABELS
When performing a pg_upgrade, we copy the files behind pg_largeobject
and pg_largeobject_metadata, allowing us to avoid having to dump out and
reload the actual data for large objects and their ACLs.
Unfortunately, that isn't all of the infor
On Mon, Mar 6, 2017 at 3:23 PM, Tom Lane wrote:
> Yes, I think it's rather silly not to do so. We have made comparable
> backpatched fixes multiple times in the past. What is worth discussing is
> whether there are *additional* things we ought to do in 9.6 to prevent
> misbehavior in installatio
Avoid dangling pointer to relation name in RLS code path in DoCopy().
With RLS active, "COPY tab TO ..." failed under -DRELCACHE_FORCE_RELEASE,
and would sometimes fail without that, because it used the relation name
directly from the relcache as part of the parsetree it's building. That
becomes
Avoid dangling pointer to relation name in RLS code path in DoCopy().
With RLS active, "COPY tab TO ..." failed under -DRELCACHE_FORCE_RELEASE,
and would sometimes fail without that, because it used the relation name
directly from the relcache as part of the parsetree it's building. That
becomes
Avoid dangling pointer to relation name in RLS code path in DoCopy().
With RLS active, "COPY tab TO ..." failed under -DRELCACHE_FORCE_RELEASE,
and would sometimes fail without that, because it used the relation name
directly from the relcache as part of the parsetree it's building. That
becomes
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> David Steele writes:
> > On 3/6/17 12:48 PM, Robert Haas wrote:
> >> This issue also exists in 9.6, but we obviously can't do anything
> >> about 9.6 clusters that already exist. Possibly this could be
> >> back-patched so that future 9.6 clusters wo
David Steele writes:
> On 3/6/17 12:48 PM, Robert Haas wrote:
>> This issue also exists in 9.6, but we obviously can't do anything
>> about 9.6 clusters that already exist. Possibly this could be
>> back-patched so that future 9.6 clusters would come out OK, or
>> possibly we should back-patch so
On 3/6/17 12:48 PM, Robert Haas wrote:
Mark pg_start_backup and pg_stop_backup as parallel-restricted.
They depend on backend-private state that will not be synchronized by
the parallel machinery, so they should not be marked parallel-safe.
This issue also exists in 9.6, but we obviously can't d
Robert Haas writes:
> On Mon, Mar 6, 2017 at 8:21 AM, Amit Kapila wrote:
>> On Fri, Mar 3, 2017 at 9:27 AM, Robert Haas wrote:
>>> Notify bgworker registrant after freeing worker slot.
>> After this commit, I am seeing parallel queires being stucked on my
>> windows machine. I think the notify
Allow dropping multiple functions at once
The generic drop support already supported dropping multiple objects of
the same kind at once. But the previous representation
of function signatures across two grammar symbols and structure members
made this cumbersome to do for functions, so it was not
Replace LookupFuncNameTypeNames() with LookupFuncWithArgs()
The old function took function name and function argument list as
separate arguments. Now that all function signatures are passed around
as ObjectWithArgs structs, this is no longer necessary and can be
replaced by a function that takes
Add operator_with_argtypes grammar rule
This makes the handling of operators similar to that of functions and
aggregates.
Rename node FuncWithArgs to ObjectWithArgs, to reflect the expanded use.
Reviewed-by: Jim Nasby
Reviewed-by: Michael Paquier
Branch
--
master
Details
---
http://g
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes
Combine several DROP variants into generic DropStmt
Combine DROP of FOREIGN DATA WRAPPER, SERVER, POLICY, RULE, and TRIGGER
into generic DropStmt grammar.
Reviewed-by: Jim Nasby
Reviewed-by: Michael Paquier
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/e6477a813
Use class_args field in opclass_drop
This makes it consistent with the usage in opclass_item.
Reviewed-by: Jim Nasby
Reviewed-by: Michael Paquier
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/63ebd377a6ecd3388596c3ea958e813f23b5f4ae
Modified Files
-
Fix incorrect comments.
Commit 19dc233c32f2900e57b8da4f41c0f662ab42e080 introduced these
comments. Michael Paquier noticed that one of them had a typo, but
a bigger problem is that they were not an accurate description of
what the code was doing.
Patch by me.
Branch
--
master
Details
-
Mark pg_start_backup and pg_stop_backup as parallel-restricted.
They depend on backend-private state that will not be synchronized by
the parallel machinery, so they should not be marked parallel-safe.
This issue also exists in 9.6, but we obviously can't do anything
about 9.6 clusters that alread
On Mon, Mar 6, 2017 at 8:21 AM, Amit Kapila wrote:
> On Fri, Mar 3, 2017 at 9:27 AM, Robert Haas wrote:
>> Notify bgworker registrant after freeing worker slot.
>
> After this commit, I am seeing parallel queires being stucked on my
> windows machine. I think the notify pid is stale in
> ReportB
Fix user-after-free bug.
Introduced by commit aea5d298362e881b13d95a48c5ae116879237389.
Patch from Amit Kapila. Issue discovered independently by Amit Kapila
and Ashutosh Sharma.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/7f6fa29f18aa84743185ee7ada97f277459228
Reorder the asynchronous libpq calls for replication connection
Per libpq documentation, the initial state must be
PGRES_POLLING_WRITING. Failing to do that appears to cause some issues
on some Windows systems.
From: Petr Jelinek
Branch
--
master
Details
---
http://git.postgresql.org/
On Fri, Mar 3, 2017 at 9:27 AM, Robert Haas wrote:
> Notify bgworker registrant after freeing worker slot.
>
After this commit, I am seeing parallel queires being stucked on my
windows machine. I think the notify pid is stale in
ReportBackgroundWorkerExit() as we are freeing the same in
ForgetBa
On Fri, Mar 3, 2017 at 10:50 PM, Simon Riggs wrote:
> Allow vacuums to report oldestxmin
>
> Allow VACUUM and Autovacuum to report the oldestxmin value they
> used while cleaning tables, helping to make better sense out of
> the other statistics we report in various cases.
>
> Branch
> --
> ma
Enhance docs for ALTER TABLE lock levels of storage parms
As requested by Robert Haas
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/6f3a13ff058f15d565a30c16c0c2cb14cc994e42
Modified Files
--
doc/src/sgml/ref/alter_table.sgml | 9 -
1 file change
Reduce lock levels for table storage params related to planning
The following parameters are now updateable with ShareUpdateExclusiveLock
effective_io_concurrency
parallel_workers
seq_page_cost
random_page_cost
n_distinct
n_distinct_inherited
Simon Riggs and FabrÃzio Mello
Branch
--
master
Allow partitioned tables to be dropped without CASCADE
Record partitioned table dependencies as DEPENDENCY_AUTO
rather than DEPENDENCY_NORMAL, so that DROP TABLE just works.
Remove all the tests for partitioned tables where earlier
work had deliberately avoided using CASCADE.
Amit Langote, revie
39 matches
Mail list logo