Re: pg_upgrade from 9.4 to 10.4

[Tom Lane]

Bruce Momjian  writes:
> On Fri, Aug  3, 2018 at 04:56:32PM -0400, Bruce Momjian wrote:
>> On Fri, Aug  3, 2018 at 01:55:04PM -0400, Tom Lane wrote:
>>> Right now is probably not a good time to fix this, but it seems like
>>> something that could be improved.  I'd be kind of inclined to remove
>>> the pidfile checking business altogether in favor of inspecting the
>>> state in pg_control; or at least do them both in the same place with
>>> the same recovery attempt if we don't like what we see.

>> Yes, I realize this was inconsistent.  It was done this way purely based
>> on how easy it would be to check each item in each place.  I am fine
>> with removing the #3 cleanup so we are consistent.  We can also add docs
>> to say it should be a "clean" shutdown.

> How do you want me to handle this, considering it has to be backpatched?

Well, removing the check entirely is certainly not a good idea.

I looked at the code briefly and concur that making it work "nicely" isn't
as simple as one could wish; the code you added has some dependencies on
the context it's in, so that moving it elsewhere would require code
duplication or refactoring.  Maybe it's not something to try to shoehorn
into v11.  We can always improve it later.

(I'd also say that the weekend before a release wrap is no time
to be committing anything noncritical, so even if you're feeling
motivated to fix it in v11, best to hold off till after the wrap.)

regards, tom lane

Re: pg_upgrade from 9.4 to 10.4

[Bruce Momjian]

On Fri, Aug  3, 2018 at 04:56:32PM -0400, Bruce Momjian wrote:
> On Fri, Aug  3, 2018 at 01:55:04PM -0400, Tom Lane wrote:
> > Bruce Momjian  writes:
> > > The comment at the top of src/port/system.c explains why we need those
> > > quotes.  Spaces was not the issue.
> > 
> > So, while starting to prepare the release notes, I looked at this patch
> > again and I'm still wondering why it's designed this way.  AFAICS,
> > the current state of affairs is:
> > 
> > 1. previous server was shut down nicely: all good.
> > 2. previous server was shut down with "-m immediate": we complain and die.
> > 3. previous server was shut down with "kill -9": we clean up and press on.
> > 
> > I am not really sure why case 2 deserves a wrist slap and making the user
> > clean it up manually when we're willing to clean up automatically in
> > case 3.  If we're going to treat them differently, that's backwards.
> > 
> > Right now is probably not a good time to fix this, but it seems like
> > something that could be improved.  I'd be kind of inclined to remove
> > the pidfile checking business altogether in favor of inspecting the
> > state in pg_control; or at least do them both in the same place with
> > the same recovery attempt if we don't like what we see.
> 
> Yes, I realize this was inconsistent.  It was done this way purely based
> on how easy it would be to check each item in each place.  I am fine
> with removing the #3 cleanup so we are consistent.  We can also add docs
> to say it should be a "clean" shutdown.

How do you want me to handle this, considering it has to be backpatched?

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+  Ancient Roman grave inscription +

Re: Draft release notes are up

[Jonathan S. Katz]

On Aug 4, 2018, at 1:17 PM, Jonathan S. Katz  wrote:On Aug 4, 2018, at 12:17 PM, Jonathan S. Katz  wrote:On Aug 4, 2018, at 12:11 PM, Tom Lane  wrote:"Jonathan S. Katz"  writes:[ s/interruptable/interruptible/ ]Huh ... I hadn't actually known that the two forms weren't more or lessequally acceptable, but a bit of dictionary-perusing says you're right.Grep finds a couple of other "interruptable"s in our tree, both likelymy fault.The other two I found that I would recommend fixing:“mis-quoting” => “misquoting”"Manually-created” => “Manually created”LGTM otherwise. I will have a PR draft available soon.PR draft attached. This combines both the the cumulative updateas well as PG11B3.I kindly request checks for accuracy and or key omissions thatare worth highlighting.Added an EOL warning for 9.3.Jonathan2018-05-10 Cumulative Update and PostgreSQL 11 Beta 3 Released
==

The PostgreSQL Global Development Group has released an update to all supported
versions of our database system, including 10.5, 9.6.10, 9.5.14, 9.4.19, 9.3.24.
This release bugs reported over the last three months.  Users should plan to
update at the next convenient downtime.

Please note that PostgreSQL changed its versioning scheme with the release of
version 10.0, so updating to version 10.5 from any 10.x release is considered a
minor update.

The PostgreSQL Global Development Group also announces that the third beta
release of PostgreSQL 11 is now available for download. This release contains
previews of all features that will be available in the final release of
PostgreSQL 11 (though some details of the release could change before then) as
well as bug fixes that were reported during the second beta.

In the spirit of the open source PostgreSQL community, we strongly encourage you
to test the new features of PostgreSQL 11 in your database systems to help us
eliminate any bugs or other issues that may exist. While we do not advise for
you to run PostgreSQL 11 Beta 3 in your production environments, we encourage
you to find ways to run your typical application workloads against this beta
release.

Bug Fixes and Improvements
--

This update also fixes over 40 bugs reported in the last several months. Some of
these issues affect only version 10, but many affect all supported versions.

These fixes include:

* Several fixes related to VACUUM, including an issue that could lead to data
corruption in certain system catalog tables
* Several fixes for replaying write-ahead logs, including a case where a
just-promoted standby server would not restart if it crashed before its first
post-recovery checkpoint
* Several performance improvements for replaying write-ahead logs
* Several fixes for logical replication and logical decoding, including ensuring
logical WAL senders reporting the streaming state correctly
* Allow replication slots to be dropped in single-user mode
* Fix to have `variance` and similar aggregate functions return accurate results
when executed using parallel query
* Fix SQL-standard FETCH FIRST syntax to allow parameters ($n), as the standard
expects
* Fix to ensure that a process doing a parallel index scan will respond to
signals, such as one to abort a query
* Fix EXPLAIN's accounting for resource usage, particularly buffer accesses, in
parallel workers
* Several fixes for the query planner including improving the cost estimates for
hash-joins and choosing to use indexes for mergejoins on composite type columns
* Fix performance regression related to POSIX semaphores for multi-CPU systems
running Linux or FreeBSD
* Fix for GIN indexes that could lead to an assertion failure after a pg_upgrade
from a version before PostgreSQL 9.4
* Fix for `SHOW ALL` to display superuser configuration settings to roles that
are allowed to read all settings
* Fix issue where `COPY FROM .. WITH HEADER` would drop a line after every
4,294,967,296 lines processed
* Several fixes for XML support, including using the document node as the
context for XPath queries as defined in the SQL standard, which affects the
`xpath` and `xpath_exists` functions, as well as `XMLTABLE`
* Fix libpq for certain cases where `hostaddr` is used
* Several ecpg fixes for Windows
* Fix password prompting in Windows client programs so that echo is properly
disabled
* Several `pg_dump` fixes, including correctly outputting `REPLICA IDENTITY`
properties for constraint indexes
* Make `pg_upgrade` check that the old server was shut down cleanly

This update also contains tzdata release 2018e, with updates for North Korea.
The 2018e also reintroduces the negative-DST changes that were originally
introduced in 2018a, which affects historical and present timestamps for Ireland
(1971-), as well as historical timestamps for Namibia (1994-2017) and the former
Czechoslovakia (1946-1947). If your application is storing time

Re: Draft release notes are up

[Jonathan S. Katz]

> On Aug 4, 2018, at 12:17 PM, Jonathan S. Katz  wrote:
> 
> 
>> On Aug 4, 2018, at 12:11 PM, Tom Lane  wrote:
>> 
>> "Jonathan S. Katz"  writes:
>>> [ s/interruptable/interruptible/ ]
>> 
>> Huh ... I hadn't actually known that the two forms weren't more or less
>> equally acceptable, but a bit of dictionary-perusing says you're right.
>> Grep finds a couple of other "interruptable"s in our tree, both likely
>> my fault.
> 
> The other two I found that I would recommend fixing:
> 
> “mis-quoting” => “misquoting”
> "Manually-created” => “Manually created”
> 
> LGTM otherwise. I will have a PR draft available soon.

PR draft attached. This combines both the the cumulative update
as well as PG11B3.

I kindly request checks for accuracy and or key omissions that
are worth highlighting.

Thanks,

Jonathan

2018-05-10 Cumulative Update and PostgreSQL 11 Beta 3 Released
==

The PostgreSQL Global Development Group has released an update to all supported
versions of our database system, including 10.5, 9.6.10, 9.5.14, 9.4.19, 9.3.24.
This release fixes bugs reported over the last three months.  Users should plan
to update at the next convenient downtime.

Please note that PostgreSQL changed its versioning scheme with the release of
version 10.0, so updating to version 10.5 from any 10.x release is considered a
minor update.

The PostgreSQL Global Development Group also announces that the third beta
release of PostgreSQL 11 is now available for download. This release contains
previews of all features that will be available in the final release of
PostgreSQL 11 (though some details of the release could change before then) as
well as bug fixes that were reported during the second beta.

In the spirit of the open source PostgreSQL community, we strongly encourage you
to test the new features of PostgreSQL 11 in your database systems to help us
eliminate any bugs or other issues that may exist. While we do not advise for
you to run PostgreSQL 11 Beta 3 in your production environments, we encourage
you to find ways to run your typical application workloads against this beta
release.

Bug Fixes and Improvements
--

This update also fixes over 40 bugs reported in the last several months. Some of
these issues affect only version 10, but many affect all supported versions.

These fixes include:

* Several fixes related to VACUUM, including an issue that could lead to data
corruption in certain system catalog tables
* Several fixes for replaying write-ahead logs, including a case where a
just-promoted standby server would not restart if it crashed before its first
post-recovery checkpoint
* Several performance improvements for replaying write-ahead logs
* Several fixes for logical replication and logical decoding, including ensuring
logical WAL senders reporting the streaming state correctly
* Allow replication slots to be dropped in single-user mode
* Fix to have `variance` and similar aggregate functions return accurate results
when executed using parallel query
* Fix SQL-standard FETCH FIRST syntax to allow parameters ($n), as the standard
expects
* Fix to ensure that a process doing a parallel index scan will respond to
signals, such as one to abort a query
* Fix EXPLAIN's accounting for resource usage, particularly buffer accesses, in
parallel workers
* Several fixes for the query planner including improving the cost estimates for
hash-joins and choosing to use indexes for mergejoins on composite type columns
* Fix performance regression related to POSIX semaphores for multi-CPU systems
running Linux or FreeBSD
* Fix for GIN indexes that could lead to an assertion failure after a pg_upgrade
from a version before PostgreSQL 9.4
* Fix for `SHOW ALL` to display superuser configuration settings to roles that
are allowed to read all settings
* Fix issue where `COPY FROM .. WITH HEADER` would drop a line after every
4,294,967,296 lines processed
* Several fixes for XML support, including using the document node as the
context for XPath queries as defined in the SQL standard, which affects the
`xpath` and `xpath_exists` functions, as well as `XMLTABLE`
* Fix libpq for certain cases where `hostaddr` is used
* Several ecpg fixes for Windows
* Fix password prompting in Windows client programs so that echo is properly
disabled
* Several `pg_dump` fixes, including correctly outputting `REPLICA IDENTITY`
properties for constraint indexes
* Make `pg_upgrade` check that the old server was shut down cleanly

This update also contains tzdata release 2018e, with updates for North Korea.
The 2018e also reintroduces the negative-DST changes that were originally
introduced in 2018a, which affects historical and present timestamps for Ireland
(1971-), as well as historical timestamps for Namibia (1994-2017) and the former
Czechoslovakia (1946-1947). If your application is storing timestamps with those
timezones in the affected date ranges, we ask that you pl

Re: Stored procedures and out parameters

[David Fetter]

On Sat, Aug 04, 2018 at 07:03:47AM +0100, Shay Rojansky wrote:
> > Shay>Npgsql currently always sends a describe as part of statement
> > execution (for server-prepared messages the describe is done only once, at
> > preparation-time). Vladimir, are you doing things differently here?
> >
> > The same thing is for pgjdbc. It does use describe to identify result row
> > format.
> > However, "CALL my_proc()" works just fine with current git master for both
> > simple and extended protocol.
> >
> 
> In one way that's good, but I wonder how this squares with the following
> written by David above:
> 
> > 1. A stored procedure should be able to return multiple resultsets with
> different structures.
> > 2. A stored procedure can decide dynamically of the structure of the
> resultset(s) it returns, and the caller will discover it as they're
> returned, not before.
> 
> Both of the above seem to be simply incompatible with the current
> PostgreSQL protocol. Describe currently returns a single RowDescription,
> which describes a single resultset, not more.

Long ago, when I was trying to simulate this behavior, I created
functions which returned SETOF REFCURSOR. It worked at least up to the
extent of being able to use multiple result sets. I don't recall
whether I had a good way to describe the rowtypes, but I suspect one
could be hacked together by having one refcursor be of a specific
rowtype whose job is to describe all the rest.

Best,
David.
-- 
David Fetter  http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

Re: Draft release notes are up

[Jonathan S. Katz]

> On Aug 4, 2018, at 12:11 PM, Tom Lane  wrote:
> 
> "Jonathan S. Katz"  writes:
>> [ s/interruptable/interruptible/ ]
> 
> Huh ... I hadn't actually known that the two forms weren't more or less
> equally acceptable, but a bit of dictionary-perusing says you're right.
> Grep finds a couple of other "interruptable"s in our tree, both likely
> my fault.

The other two I found that I would recommend fixing:

“mis-quoting” => “misquoting”
"Manually-created” => “Manually created”

LGTM otherwise. I will have a PR draft available soon.

Jonathan


signature.asc
Description: Message signed with OpenPGP

Re: Draft release notes are up

[Tom Lane]

"Jonathan S. Katz"  writes:
> [ s/interruptable/interruptible/ ]

Huh ... I hadn't actually known that the two forms weren't more or less
equally acceptable, but a bit of dictionary-perusing says you're right.
Grep finds a couple of other "interruptable"s in our tree, both likely
my fault.

regards, tom lane

Re: Draft release notes are up

[Jonathan S. Katz]

> On Aug 3, 2018, at 6:15 PM, Tom Lane  wrote:
> 
> First cut at release notes for next week's minor releases is up at
> 
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=c1455de2af2eb06ee493f9982f060ac7e571f656
> 
> If you prefer not to read XML markup, they should appear in the devel docs
> on the website after guaibasaurus's next run, a couple hours from now.

Thank you for compiling the notes. I found a small misspelling in the notes, fix
attached.

Jonathan



release1005.diff
Description: Binary data


signature.asc
Description: Message signed with OpenPGP

Re: [report] memory leaks in COPY FROM on partitioned table

[Kohei KaiGai]

2018-08-03 12:38 GMT+09:00 Alvaro Herrera :
> On 2018-Aug-03, Kohei KaiGai wrote:
>
>> 2018-08-02 5:38 GMT+09:00 Alvaro Herrera :
>> > On 2018-Aug-01, Alvaro Herrera wrote:
>> >
>> >> Right, makes sense.  Pushed that way.
>> >
>> > KaiGai, if you can please confirm that the pushed change fixes your test
>> > case, I'd appreciate it.
>>
>> Can you wait for a few days? I can drop the test dataset and reuse the 
>> storage
>> once benchmark test is over
>
> Of course -- take your time.
>
I could load the same data (544GB csv, 789GB heap) using COPY FROM successfully.
When I reported the problem, rss usage of postgresql process increased
about 10MB/s ratio,
then OOM killer eliminated after a few hours.

Now, it consumed about 60MB rss at the beginning of COPY FROM, and it grows up
very slowly during the COPY FROM execution, then grew up to 250MB
before completion.
We may have another memory blocks which are not released during
execution, however,
I could not identify whether it is really memory leaking or not, and who's jobs.

It may be an idea to put a debug code that raises a notice when
MemoryContext allocates
more than the threshold.

Thanks,
-- 
HeteroDB, Inc / The PG-Strom Project
KaiGai Kohei 

Conflict handling for COPY FROM

[Surafel Temesgen]

Hellow hackers,

A few commitfest ago there was same effort to add errors handling to COPY
FROM[1] and i see there that we already have infrastructure for supporting
handling of unique violation or exclusion constraint violation error and I
think it is independently useful too. Attached is a patch to do that.

In order to prevent extreme condition the patch also add a new GUC variable
called copy_max_error_limit that control the amount of error to swallow
before start to error and new failed record file options for copy to write
a failed record so the user can examine it.

With the new option COPY FROM can be specified like:

COPY table_name [ ( column_name [, ...] ) ]

FROM { 'filename' | PROGRAM 'command' | STDIN }[ON CONFLICT IGNORE
failed_record_filename] [ [ WITH ] ( option [, ...] ) ]

[1].
https://www.postgresql.org/message-id/flat/7179f2fd-49ce-4093-ae14-1b26c5dfb...@gmail.com

Comment?

Regards

Surafel
diff --git a/contrib/file_fdw/file_fdw.c b/contrib/file_fdw/file_fdw.c
index 2cf09aecf6..ba63624eac 100644
--- a/contrib/file_fdw/file_fdw.c
+++ b/contrib/file_fdw/file_fdw.c
@@ -676,6 +676,8 @@ fileBeginForeignScan(ForeignScanState *node, int eflags)
 	cstate = BeginCopyFrom(NULL,
 		   node->ss.ss_currentRelation,
 		   filename,
+		   NULL,
+		   false,
 		   is_program,
 		   NULL,
 		   NIL,
@@ -752,6 +754,8 @@ fileReScanForeignScan(ForeignScanState *node)
 	festate->cstate = BeginCopyFrom(NULL,
 	node->ss.ss_currentRelation,
 	festate->filename,
+	NULL,
+	false,
 	festate->is_program,
 	NULL,
 	NIL,
@@ -1117,7 +1121,7 @@ file_acquire_sample_rows(Relation onerel, int elevel,
 	/*
 	 * Create CopyState from FDW options.
 	 */
-	cstate = BeginCopyFrom(NULL, onerel, filename, is_program, NULL, NIL,
+	cstate = BeginCopyFrom(NULL, onerel, filename, NULL, false, is_program, NULL, NIL,
 		   options);
 
 	/*
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index bee4afbe4e..edd96f4711 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -7129,6 +7129,19 @@ SET XML OPTION { DOCUMENT | CONTENT };
   
  
 
+ 
+  copy_maximum_error_limit (integer)
+  
+   copy_maximum_error_limit configuration parameter
+  
+  
+  
+   
+Specifies the maximum number of ignored unique or exclusion constraint violation error
+on COPY FROM before starting to error.The default is 100.
+   
+  
+ 
  
 
  
diff --git a/doc/src/sgml/ref/copy.sgml b/doc/src/sgml/ref/copy.sgml
index 13a8b68d95..f3639b3b48 100644
--- a/doc/src/sgml/ref/copy.sgml
+++ b/doc/src/sgml/ref/copy.sgml
@@ -24,6 +24,7 @@ PostgreSQL documentation
 
 COPY table_name [ ( column_name [, ...] ) ]
 FROM { 'filename' | PROGRAM 'command' | STDIN }
+[ON CONFLICT IGNORE 'failed_record_filename']
 [ [ WITH ] ( option [, ...] ) ]
 
 COPY { table_name [ ( column_name [, ...] ) ] | ( query ) }
@@ -167,6 +168,28 @@ COPY { table_name [ ( 

 
+   
+ON CONFLICT IGNORE
+
+ 
+  specifies ignore to error on a raising unique or exclusion constraint violation 
+  up to configured amount .Instead write the error record to failed record file and 
+  precede to the next record
+ 
+
+   
+
+   
+failed_record_filename
+
+ 
+  The path name of the failed record file. failed record file name can be an absolute or
+  relative path. Windows users might need to use an E'' string and double any backslashes
+  used in the path name.
+ 
+
+   
+

 STDOUT
 
diff --git a/src/backend/commands/copy.c b/src/backend/commands/copy.c
index 9bc67ce60f..b91335d783 100644
--- a/src/backend/commands/copy.c
+++ b/src/backend/commands/copy.c
@@ -43,6 +43,7 @@
 #include "port/pg_bswap.h"
 #include "rewrite/rewriteHandler.h"
 #include "storage/fd.h"
+#include "storage/lmgr.h"
 #include "tcop/tcopprot.h"
 #include "utils/builtins.h"
 #include "utils/lsyscache.h"
@@ -118,6 +119,7 @@ typedef struct CopyStateData
 	int			file_encoding;	/* file or remote side's character encoding */
 	bool		need_transcoding;	/* file encoding diff from server? */
 	bool		encoding_embeds_ascii;	/* ASCII can be non-first byte? */
+	FILE	   *failed_rec_file;
 
 	/* parameters from the COPY command */
 	Relation	rel;			/* relation to copy to or from */
@@ -147,6 +149,8 @@ typedef struct CopyStateData
 	bool		convert_selectively;	/* do selective binary conversion? */
 	List	   *convert_select; /* list of column names (can be NIL) */
 	bool	   *convert_select_flags;	/* per-column CSV/TEXT CS flags */
+	char	   *failed_rec_filename;
+	bool		ignore_conflict;
 
 	/* these are just for error messages, see CopyFromErrorCallback */
 	const char *cur_relname;	/* table name for error messages */
@@ -995,7 +999,8 @@ DoCopy(ParseState *pstate, const CopyStmt *stmt,
 			PreventCommandIfReadOnly("COPY FROM");
 		PreventCommandIfParallelMode("COPY FROM");
 

Re: Stored procedures and out parameters

[Daniel Verite]

Shay Rojansky wrote:

> In one way that's good, but I wonder how this squares with the following
> written by David above:
> > 1. A stored procedure should be able to return multiple resultsets with
> different structures.
> > 2. A stored procedure can decide dynamically of the structure of the
> resultset(s) it returns, and the caller will discover it as they're
> returned, not before.

> Both of the above seem to be simply incompatible with the current
> PostgreSQL protocol. Describe currently returns a single RowDescription,
> which describes a single resultset, not more. And as I wrote before, I
> don't see how it's possible with the current protocol for the caller to
> discover the structure of the resultset(s) "as they're returned"

It works at least with the simple query mode, where it's similar
to handling results from a query string containing multiple 
statements separated by semicolons.

But it's not clear whether this could work with the extended query
protocol. The doc says that the necessary RowDescription message(s)
would be missing:

  "The possible responses to Execute are the same as those described
   above for queries issued via simple query protocol, except that
   Execute doesn't cause ReadyForQuery or RowDescription to be issued",


Best regards,
-- 
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite

Re: doc - improve description of default privileges

[Fabien COELHO]

I have not found a convenient presentation of the default privileges for 
different objects, and how to display them (if possible, not always).


The information is partly provided within the GRANT description, and not very 
explicit: eg it is said that owners have all possible perms, but which they 
are is not said explicitely, although they are implied by the different GRANT 
sysnopsys. Then some objects are given perms for the PUBLIC.


The attached patch tries to improve the documentation, in particular with an 
added table to summarizes my findings, so that they are recorded somewhere.


The attached fixes the tablespace entry that I forgot to fill in full.

--
Fabien.diff --git a/doc/src/sgml/ref/grant.sgml b/doc/src/sgml/ref/grant.sgml
index ff64c7a3ba..650601965b 100644
--- a/doc/src/sgml/ref/grant.sgml
+++ b/doc/src/sgml/ref/grant.sgml
@@ -175,6 +175,8 @@ GRANT role_name [, ...] TO EXECUTE privilege for functions and procedures; and
USAGE privilege for languages and data types
(including domains).
+summarizes the hardcoded
+   default privileges granted to all object's types.
The object owner can, of course, REVOKE
both default and  expressly granted privileges. (For maximum
security, issue the REVOKE in the same transaction that
@@ -205,6 +207,9 @@ GRANT role_name [, ...] TO currval function.
For large objects, this privilege allows the object to be read.
   
+  
+   This privilege is abbreviated r when displayed.
+  
  
 
 
@@ -218,6 +223,9 @@ GRANT role_name [, ...] TO  FROM.
   
+  
+   This privilege is abbreviated a when displayed.
+  
  
 
 
@@ -240,6 +248,9 @@ GRANT role_name [, ...] TO 
+  
+   This privilege is abbreviated w when displayed.
+  
  
 
 
@@ -253,6 +264,9 @@ GRANT role_name [, ...] TO SELECT privilege as well, since it must reference 
table
columns to determine which rows to delete.)
   
+  
+   This privilege is abbreviated d when displayed.
+  
  
 
 
@@ -263,6 +277,9 @@ GRANT role_name [, ...] TO  on
the specified table.
   
+  
+   This privilege is abbreviated D when displayed.
+  
  
 
 
@@ -274,6 +291,9 @@ GRANT role_name [, ...] TO  statement.)
   
+  
+   This privilege is abbreviated x when displayed.
+  
  
 
 
@@ -284,6 +304,9 @@ GRANT role_name [, ...] TO  statement.)
   
+  
+   This privilege is abbreviated t when displayed.
+  
  
 
 
@@ -304,6 +327,9 @@ GRANT role_name [, ...] TO 
+  
+   This privilege is abbreviated C when displayed.
+  
  
 
 
@@ -315,6 +341,9 @@ GRANT role_name [, ...] TO pg_hba.conf).
   
+  
+   This privilege is abbreviated c when displayed.
+  
  
 
 
@@ -325,6 +354,9 @@ GRANT role_name [, ...] TO 
Allows temporary tables to be created while using the specified 
database.
   
+  
+   This privilege is abbreviated T when displayed.
+  
  
 
 
@@ -339,6 +371,9 @@ GRANT role_name [, ...] TO ROUTINE to refer to a 
function,
aggregate function, or procedure regardless of what it is.
   
+  
+   This privilege is abbreviated X when displayed.
+  
  
 
 
@@ -382,6 +417,9 @@ GRANT role_name [, ...] TO 
+  
+   This privilege is abbreviated U when displayed.
+  
  
 
 
@@ -627,6 +665,95 @@ GRANT ALL PRIVILEGES ON kinds TO manuel;
 
 GRANT admins TO joe;
 
+
+  
+   Default hardcoded access privileges per object's type
+   
+
+ 
+  Object's type
+  psql \-command
+  Owner
+  PUBLIC
+ 
+
+
+ 
+  DATABASE
+  \l
+  CTc
+  Tc
+ 
+ 
+  DOMAIN
+  \dD+
+  U
+  U
+ 
+ 
+  FUNCTION or 
PROCEDURE
+  \df+
+  X
+  X
+ 
+ 
+  FOREIGN DATA WRAPPER
+  \dew+
+  U
+  
+ 
+ 
+  FOREIGN SERVER
+  \des+
+  U
+  
+ 
+ 
+  LANGUAGE
+  \dL+
+  U
+  U
+ 
+ 
+  LARGE OBJECT
+  
+  rw
+  
+ 
+ 
+  SCHEMA
+  \dn+
+  UC
+  
+ 
+ 
+  SEQUENCE
+  \dp
+  rwU
+  
+ 
+ 
+  TABLE and relation-like objects
+  \dp
+  arwdDxt
+  
+ 
+ 
+  TABLESPACE
+  \db+
+  C
+  
+ 
+ 
+  TYPE
+  \dT+
+  U
+  U
+ 
+
+   
+  
+