On Mon, Aug 31, 2015 at 05:46:08PM -0400, Bruce Momjian wrote:
> On Tue, Jul 28, 2015 at 04:23:36PM -0300, Alvaro Herrera wrote:
> > Josh Berkus wrote:
> > > On 07/28/2015 11:58 AM, Robert Haas wrote:
> > > > I'd be strongly in favour of teaching GRANT, SECURITY LABEL, COMMENT
> > > >> ON
On Tue, Jul 28, 2015 at 04:23:36PM -0300, Alvaro Herrera wrote:
> Josh Berkus wrote:
> > On 07/28/2015 11:58 AM, Robert Haas wrote:
> > > I'd be strongly in favour of teaching GRANT, SECURITY LABEL, COMMENT
> > >> ON DATABASE, etc to recognise CURRENT_DATABASE as a keyword. Then
> > >> dumping
On Thu, Jul 30, 2015 at 10:37:33PM -0400, Adam Brightwell wrote:
On Thu, Jul 30, 2015 at 02:26:34PM -0400, Robert Haas wrote:
1. pg_dumpall -g
2. pg_dump --create per database
Gah, OK, I see your point. But we better document this, because if
you need a PhD in PostgreSQL-ology to take
1. pg_dumpall -g
2. pg_dump --create per database
Gah, OK, I see your point. But we better document this, because if
you need a PhD in PostgreSQL-ology to take a backup, we're not in a
good place.
Agreed. Though, honestly, I find this to be a cumbersome approach. I
think it just makes
On Wed, Jul 29, 2015 at 10:50:53AM -0400, Robert Haas wrote:
On Wed, Jul 29, 2015 at 12:39 AM, Noah Misch n...@leadboat.com wrote:
On Tue, Jul 28, 2015 at 03:36:13PM -0400, Robert Haas wrote:
On Tue, Jul 28, 2015 at 3:33 PM, Andres Freund and...@anarazel.de wrote:
Hm? Let me try again: If
On Thu, Jul 30, 2015 at 2:49 AM, Noah Misch n...@leadboat.com wrote:
What exact formula did you have in mind? It must not be merely
1. pg_dumpall -g
2. pg_dump (without --create) per database
which _never_ works: it emits no CREATE DATABASE statements. Perhaps this?
1. pg_dumpall -g
2.
Noah Misch wrote:
What exact formula did you have in mind? It must not be merely
1. pg_dumpall -g
2. pg_dump (without --create) per database
which _never_ works: it emits no CREATE DATABASE statements. Perhaps this?
1. pg_dumpall -g
2. Issue a handwritten CREATE DATABASE statement
On Wed, Jul 29, 2015 at 12:39 AM, Noah Misch n...@leadboat.com wrote:
On Tue, Jul 28, 2015 at 03:36:13PM -0400, Robert Haas wrote:
On Tue, Jul 28, 2015 at 3:33 PM, Andres Freund and...@anarazel.de wrote:
Hm? Let me try again: If the admin does a ALTER DATABASE ... SET guc =
... *before*
On Tue, Jul 28, 2015 at 03:36:13PM -0400, Robert Haas wrote:
On Tue, Jul 28, 2015 at 3:33 PM, Andres Freund and...@anarazel.de wrote:
Hm? Let me try again: If the admin does a ALTER DATABASE ... SET guc =
... *before* restoring a backup and the backup does contain a setting
for the same
* Robert Haas (robertmh...@gmail.com) wrote:
On Sun, Jul 26, 2015 at 11:43 PM, Craig Ringer cr...@2ndquadrant.com wrote:
On 20 July 2015 at 01:18, Noah Misch n...@leadboat.com wrote:
On Wed, Jul 15, 2015 at 11:08:53AM +0200, Andres Freund wrote:
On 2015-07-15 12:04:40 +0300, Alvaro Herrera
On Sun, Jul 26, 2015 at 11:43 PM, Craig Ringer cr...@2ndquadrant.com wrote:
On 20 July 2015 at 01:18, Noah Misch n...@leadboat.com wrote:
On Wed, Jul 15, 2015 at 11:08:53AM +0200, Andres Freund wrote:
On 2015-07-15 12:04:40 +0300, Alvaro Herrera wrote:
Andres Freund wrote:
One thing worth
On 2015-07-28 14:58:26 -0400, Robert Haas wrote:
Yes, I think we should make restoring the database's properties the
job of pg_dump and remove it completely from pg_dumpall, unless we can
find a case where that's really going to break things.
CREATE DATABASE blarg;
SECURITY LABEL ON blarg IS
On Tue, Jul 28, 2015 at 3:03 PM, Andres Freund and...@anarazel.de wrote:
On 2015-07-28 14:58:26 -0400, Robert Haas wrote:
Yes, I think we should make restoring the database's properties the
job of pg_dump and remove it completely from pg_dumpall, unless we can
find a case where that's really
On 2015-07-28 15:05:01 -0400, Robert Haas wrote:
On Tue, Jul 28, 2015 at 3:03 PM, Andres Freund and...@anarazel.de wrote:
On 2015-07-28 14:58:26 -0400, Robert Haas wrote:
Yes, I think we should make restoring the database's properties the
job of pg_dump and remove it completely from
On Tue, Jul 28, 2015 at 3:10 PM, Andres Freund and...@anarazel.de wrote:
On 2015-07-28 15:05:01 -0400, Robert Haas wrote:
On Tue, Jul 28, 2015 at 3:03 PM, Andres Freund and...@anarazel.de wrote:
On 2015-07-28 14:58:26 -0400, Robert Haas wrote:
Yes, I think we should make restoring the
Josh Berkus wrote:
On 07/28/2015 11:58 AM, Robert Haas wrote:
I'd be strongly in favour of teaching GRANT, SECURITY LABEL, COMMENT
ON DATABASE, etc to recognise CURRENT_DATABASE as a keyword. Then
dumping them in pg_dump --create, and in pg_dump -Fc .
In practice I see zero real use of
On 2015-07-28 15:14:11 -0400, Robert Haas wrote:
On Tue, Jul 28, 2015 at 3:10 PM, Andres Freund and...@anarazel.de wrote:
DBA creates a database and sets some properties (security labels, gucs,
acls) on it. Then goes on to restore a backup. Unfortunately that backup
might, or might not,
* Andres Freund (and...@anarazel.de) wrote:
On 2015-07-28 15:14:11 -0400, Robert Haas wrote:
On Tue, Jul 28, 2015 at 3:10 PM, Andres Freund and...@anarazel.de wrote:
DBA creates a database and sets some properties (security labels, gucs,
acls) on it. Then goes on to restore a backup.
On Tue, Jul 28, 2015 at 3:33 PM, Andres Freund and...@anarazel.de wrote:
On 2015-07-28 15:27:51 -0400, Robert Haas wrote:
On Tue, Jul 28, 2015 at 3:16 PM, Andres Freund and...@anarazel.de wrote:
On 2015-07-28 15:14:11 -0400, Robert Haas wrote:
On Tue, Jul 28, 2015 at 3:10 PM, Andres Freund
On 07/28/2015 11:58 AM, Robert Haas wrote:
I'd be strongly in favour of teaching GRANT, SECURITY LABEL, COMMENT
ON DATABASE, etc to recognise CURRENT_DATABASE as a keyword. Then
dumping them in pg_dump --create, and in pg_dump -Fc .
In practice I see zero real use of pg_dumpall without
On Tue, Jul 28, 2015 at 3:16 PM, Andres Freund and...@anarazel.de wrote:
On 2015-07-28 15:14:11 -0400, Robert Haas wrote:
On Tue, Jul 28, 2015 at 3:10 PM, Andres Freund and...@anarazel.de wrote:
DBA creates a database and sets some properties (security labels, gucs,
acls) on it. Then goes on
On 2015-07-28 15:27:51 -0400, Robert Haas wrote:
On Tue, Jul 28, 2015 at 3:16 PM, Andres Freund and...@anarazel.de wrote:
On 2015-07-28 15:14:11 -0400, Robert Haas wrote:
On Tue, Jul 28, 2015 at 3:10 PM, Andres Freund and...@anarazel.de wrote:
DBA creates a database and sets some
On Thu, Jul 23, 2015 at 12:14:14PM -0400, Robert Haas wrote:
On Wed, Jul 22, 2015 at 3:42 PM, Adam Brightwell
adam.brightw...@crunchydatasolutions.com wrote:
I like Noah's proposal of having pg_dump --create reproduce all
database-level state.
Should it be enabled by default? If so,
On 20 July 2015 at 01:18, Noah Misch n...@leadboat.com wrote:
On Wed, Jul 15, 2015 at 11:08:53AM +0200, Andres Freund wrote:
On 2015-07-15 12:04:40 +0300, Alvaro Herrera wrote:
Andres Freund wrote:
One thing worth mentioning is that arguably the problem is caused by the
fact that we're
On Wed, Jul 22, 2015 at 03:42:58PM -0400, Adam Brightwell wrote:
I like Noah's proposal of having pg_dump --create reproduce all
database-level state.
Should it be enabled by default? If so, then wouldn't it make more
sense to call it --no-create and do the opposite? So, --no-create
While I'd favor optional --no-create if we were designing fresh, it's not
worth breaking user scripts by changing that now.
Agreed. So, --create would not be enabled by default.
How would this handle related global objects? It seems like this part
could get a little tricky.
Like roles and
I don't think there's any line near pg_dumpall. That tool seems to
have grown out of desperation without much actual design. I think it
makes more sense to plan around that's the best pg_dump behavior for the
various use cases.
Ok.
I like Noah's proposal of having pg_dump --create
On Wed, Jul 22, 2015 at 4:42 PM, Adam Brightwell
adam.brightw...@crunchydatasolutions.com wrote:
[...]
Also, I think this would potentially conflict with what FabrÃzio is
doing with CURRENT_DATABASE on COMMENT, though, I think it might be a
preferable solution.
Noah Misch wrote:
On Mon, Jul 20, 2015 at 07:01:14PM -0400, Adam Brightwell wrote:
I think that makes sense, but what about other DATABASE level info
such as COMMENT? Should that also be ignored by pg_dump as well? I'm
specifically thinking of the discussion from the following thread:
On Mon, Jul 20, 2015 at 07:01:14PM -0400, Adam Brightwell wrote:
Consistency with existing practice would indeed have pg_dump ignore
pg_shseclabel and have pg_dumpall reproduce its entries.
I think that makes sense, but what about other DATABASE level info
such as COMMENT? Should that
Consistency with existing practice would indeed have pg_dump ignore
pg_shseclabel and have pg_dumpall reproduce its entries.
I think that makes sense, but what about other DATABASE level info
such as COMMENT? Should that also be ignored by pg_dump as well? I'm
specifically thinking of the
On Wed, Jul 15, 2015 at 11:08:53AM +0200, Andres Freund wrote:
On 2015-07-15 12:04:40 +0300, Alvaro Herrera wrote:
Andres Freund wrote:
One thing worth mentioning is that arguably the problem is caused by the
fact that we're here emitting database level information in pg_dump,
normally
On 2015-07-14 13:09:26 -0400, Adam Brightwell wrote:
All,
I won't have time to do anything about this anytime soon, but I think we
should fix that at some point. Shall I put this on the todo? Or do we
want to create an 'open items' page that's not major version specific?
I think
Andres Freund wrote:
One thing worth mentioning is that arguably the problem is caused by the
fact that we're here emitting database level information in pg_dump,
normally only done for dumpall.
... the reason for which is probably the lack of CURRENT_DATABASE as a
database specifier. It
On 2015-07-15 12:04:40 +0300, Alvaro Herrera wrote:
Andres Freund wrote:
One thing worth mentioning is that arguably the problem is caused by the
fact that we're here emitting database level information in pg_dump,
normally only done for dumpall.
... the reason for which is probably the
On Fri, Jul 10, 2015 at 7:57 AM, Andres Freund and...@anarazel.de wrote:
pg_dump dumps security labels on databases. Which makes sense. The
problem is that they're dumped including the database name.
Which means that if you dump a database and restore it into a
differently named one you'll
All,
I won't have time to do anything about this anytime soon, but I think we
should fix that at some point. Shall I put this on the todo? Or do we
want to create an 'open items' page that's not major version specific?
I think adding it to the TODO would be great.
I'd be willing to
That doesn't answer my question. I'm talking about a client and server
running on the same system with SELinux MLS policy so that getpeercon
will return the context of the client process unless it has explicitly
sets the socket create context . So again will postgresql if the
sepgsql module
That doesn't answer my question. I'm talking about a client and server
running on the same system with SELinux MLS policy so that getpeercon
will return the context of the client process unless it has explicitly
sets the socket create context . So again will postgresql if the
sepgsql module is
So if I label a table with an SELinux context and the type of my
client connection does not have policy to be able to access the table
type will an AVC be generated and the access denied?
Of course, it depends on the policy of the system.
If client connection come from none-SELinux system,
On Tue, Jul 14, 2015 at 1:22 PM, Ted Toth txt...@gmail.com wrote:
I'm sort of new to this so maybe I'm missing something but since the
sepgsql SELinux userspace object manager was never integrated into
postgresql (AFAIK KaiGais branch was never merged into the mainline)
who uses these labels?
I'm sort of new to this so maybe I'm missing something but since the
sepgsql SELinux userspace object manager was never integrated into
postgresql (AFAIK KaiGais branch was never merged into the mainline)
who uses these labels? What use are they?
Ted
On Tue, Jul 14, 2015 at 12:09 PM, Adam
2015-07-15 2:39 GMT+09:00 Ted Toth txt...@gmail.com:
That's exactly what I'm talking about like I said KaiGais branch was
never merged into the mainline so I do not believe that it is used at
all.
It depends on the definition of integrated.
The PostgreSQL core offers an infrastructure for
So if I label a table with an SELinux context and the type of my
client connection does not have policy to be able to access the table
type will an AVC be generated and the access denied?
Ted
On Tue, Jul 14, 2015 at 12:53 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2015-07-15 2:39 GMT+09:00 Ted
Hi,
pg_dump dumps security labels on databases. Which makes sense. The
problem is that they're dumped including the database name.
Which means that if you dump a database and restore it into a
differently named one you'll either get a failure because the database
does not exist, or worse you'll
45 matches
Mail list logo
