Joe Conway m...@joeconway.com writes:
The attached one-liner seems to do the trick. It should probably be
backpatched to 9.1. Remaining questions:
Thanks for the patch (and testing, etc, that it entails)!
1) Are there other database object types, likely to be included in
extension
Clark C. Evans wrote:
I'd really love the ability to grant a *user*
role-based privileges database by database.
For background, I have several databases running
in a single cluster, one database per business unit.
Each database has the same core schema with the same
basic role permissions,
I will implement it as an extension then.
My feeling is that PostgreSQL extensions tend to fall into obscurity.
As an ordinary user it took me really long time to find out that
interesting features are available in form of extensions; they are
certainly under-marketed. But this is a topic for
On 2013-05-29 09:30:43 +0200, Dimitri Fontaine wrote:
2) How should we handle already installed extensions, which will still
lack dependency records after this bugfix?
I don't really see any other way here than providing an upgrade script
that will somehow re-attach those objects,
On Wed, May 29, 2013 at 4:33 AM, Maciej Gajewski
maciej.gajews...@gmail.com wrote:
I propose to not integrate the unsigned types into existing promotion
hierarchy, and behave just like gcc would with -Werror: require
explicit cast. Between them, the unsigned types would be automatically
On Wed, May 29, 2013, at 04:26 AM, Albe Laurenz wrote:
Clark C. Evans wrote:
I'd really love the ability to grant a *user*
role-based privileges database by database.
The only cluster-wide role permissions are the options
SUPERUSER, CREATEDB, CREATEROLE, INHERIT,
LOGIN and REPLICATION.
On Tue, May 28, 2013 at 10:08 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-05-28 21:26:49 -0400, Robert Haas wrote:
On Tue, May 28, 2013 at 8:00 PM, Andres Freund and...@2ndquadrant.com
wrote:
I only suggested MOVED_IN/OFF because I didn't remember
On Tue, May 28, 2013 at 5:43 PM, Tomas Vondra t...@fuzzy.cz wrote:
Hi,
I've just noticed that this patch in 2012-01 commitfest
https://commitfest.postgresql.org/action/patch_view?id=729
added log_timing option to auto_explain, but it never actually made it
to the docs. Attached is a
Clark C. Evans wrote:
I'd really love the ability to grant a *user*
role-based privileges database by database.
The only cluster-wide role permissions are the options
SUPERUSER, CREATEDB, CREATEROLE, INHERIT,
LOGIN and REPLICATION.
Incorrect; role-to-role membership (different from
Andres Freund and...@2ndquadrant.com writes:
On 2013-05-29 09:30:43 +0200, Dimitri Fontaine wrote:
2) How should we handle already installed extensions, which will still
lack dependency records after this bugfix?
I don't really see any other way here than providing an upgrade script
On May 28, 2013, at 10:55 PM, Bruce Momjian wrote:
On Wed, May 22, 2013 at 03:05:57PM -0400, Ray Stell wrote:
However, if we pass these items into the scripts, we then force
these values to be used, even if the user wants to use a different
value. It is a balance between supplying defaults
On 5/28/13 10:55 PM, Bruce Momjian wrote:
Wow, I never realized other tools used -U for user, instead of -u.
Should I change pg_upgrade to use -U for 9.4? I can keep supporting -u
as an undocumented option.
It seems to me that that option shouldn't be necessary anyway.
pg_upgrade should
* Albe Laurenz (laurenz.a...@wien.gv.at) wrote:
Maybe the db_user_namespace parameter can help:
http://www.postgresql.org/docs/9.2/static/runtime-config-connection.html#GUC-DB-USER-NAMESPACE
I doubt it and I wouldn't encourage anyone to use it even if it happened
to help in this situation..
On 5/28/13 8:00 PM, Andres Freund wrote:
- Various procedural languages use the combination of TID and XMIN to
determine whether a function needs to be recompiled.
Hm. As previously said, I am less than convinced of those adhoc
mechanisms and I think this should get properly integrated into
On 5/28/13 11:36 AM, Greg Smith wrote:
Outside of the run for performance testing, I think it would be good at
this point to validate that there is really a 16MB file full of zeroes
resulting from these operations. I am not really concerned that
posix_fallocate might be slower in some cases;
Clark,
* Clark C. Evans (c...@clarkevans.com) wrote:
I apologize for posting to -hackers; it was probably the wrong list.
I don't know about that.. It's a new feature request, not sure where
else you'd email about it.
That said, it's also a non-trivial thing to change and it would have to
be
On 2013-05-29 03:56:38 +0200, Andres Freund wrote:
On 2013-05-28 21:36:17 -0400, Robert Haas wrote:
On Tue, May 28, 2013 at 1:58 PM, Andres Freund and...@2ndquadrant.com
wrote:
Guessing around I looked and noticed the following problematic pattern:
1) A: wants to do an update, doesn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/29/2013 05:52 AM, Dimitri Fontaine wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-05-29 09:30:43 +0200, Dimitri Fontaine wrote:
2) How should we handle already installed extensions, which
will still lack dependency records after
* Peter Eisentraut (pete...@gmx.net) wrote:
On 5/28/13 11:36 AM, Greg Smith wrote:
Outside of the run for performance testing, I think it would be good at
this point to validate that there is really a 16MB file full of zeroes
resulting from these operations. I am not really concerned that
Christopher Browne cbbro...@gmail.com writes:
You could hide your own favorite patterns by putting this into your
~/.gitignore that isn't part of the repo, configuring this globally, thus:
git config --global core.excludesfile '~/.gitignore'
You can also put per-project setup in
On 2013-05-29 10:36:07 -0400, Stephen Frost wrote:
* Peter Eisentraut (pete...@gmx.net) wrote:
On 5/28/13 11:36 AM, Greg Smith wrote:
Outside of the run for performance testing, I think it would be good at
this point to validate that there is really a 16MB file full of zeroes
resulting
On 2013-05-29 07:35:42 -0700, Joe Conway wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/29/2013 05:52 AM, Dimitri Fontaine wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-05-29 09:30:43 +0200, Dimitri Fontaine wrote:
2) How should we handle already installed
On Wed, May 29, 2013 at 08:59:42AM -0400, Ray Stell wrote:
[ moved to hacker ]
Wow, I never realized other tools used -U for user, instead of -u.
Should I change pg_upgrade to use -U for 9.4? I can keep supporting
-u as an undocumented option.
That would make for consistency, but not
On 5/29/13 10:42 AM, Andres Freund wrote:
On 2013-05-29 10:36:07 -0400, Stephen Frost wrote:
I *really* hope that the Linux kernel, and other, folks are smart enough
to realize that they can't just re-use random blocks from an I/O device
without cleaning it first.
FWIW, posix' description
Robert Haas escribió:
On Tue, May 28, 2013 at 10:08 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2013-05-28 21:26:49 -0400, Robert Haas wrote:
I am all for adding a comment why this is safe though. We thought about
it for some while before we were convinced...
I'm fine with
I just took time to inspect our contribs, USE_PGXS is not supported by all
of them atm because of SHLIB_PREREQS (it used submake) I have a patch
pending here to fix that. Once all our contribs can build with USE_PGXS I
fix the VPATH.
I've added 'most' of the patches to the commitfest... (I am
Abhishek Rai abhishek...@gmail.com writes:
SELECT * from pg_stat_replication();
I've noticed that when I terminate the standby (cleanly or through kill
-9), the result of above function goes from 1 row to zero rows. The result
comes back to 1 row when the standby restarts and reconnects.
On 5/28/13 9:42 PM, Abhishek Rai wrote:
Detecting primary health is easy. But what is the best way to know if
the standby is live? Since this is not a hot-standby, I cannot send
queries to it.
Then how do you define live for your use case?
Currently, I'm sending the following query to the
On Wed, May 29, 2013 at 9:16 AM, Peter Eisentraut pete...@gmx.net wrote:
On 5/28/13 9:42 PM, Abhishek Rai wrote:
Detecting primary health is easy. But what is the best way to know if
the standby is live? Since this is not a hot-standby, I cannot send
queries to it.
Then how do you
On Wed, May 29, 2013 at 9:14 AM, Dimitri Fontaine dimi...@2ndquadrant.frwrote:
Abhishek Rai abhishek...@gmail.com writes:
SELECT * from pg_stat_replication();
I've noticed that when I terminate the standby (cleanly or through kill
-9), the result of above function goes from 1 row to
On Fri, 2013-05-24 at 22:16 +0100, Simon Riggs wrote:
I think its perfectly understandable. Robert, Jeff and I discussed
that for a while before we passed it. I'm still not happy with it, and
think its a pretty confusing section of code with multiple paths
through it, but I just can't see a
On Tue, 2013-05-28 at 19:51 -0400, Robert Haas wrote:
If we just wanted to reduce read cost, why not just take a simpler
approach and give the visibility map a isfrozen bit? Then we'd know
which pages didn't need rescanning without nearly as much complexity.
That would break pg_upgrade,
On Tue, 2013-05-28 at 09:29 -0700, Josh Berkus wrote:
- it would prevent us from getting rid of allvisible, which has a
documented and known write overhead
It would? I don't think these proposals are necessarily in conflict.
It's not entirely clear to me how they fit together in detail, but it
On 05/29/2013 11:33 AM, Maciej Gajewski wrote:
I will implement it as an extension then.
My feeling is that PostgreSQL extensions tend to fall into obscurity.
As an ordinary user it took me really long time to find out that
interesting features are available in form of extensions; they are
I agree that extensions are undermarketed. Although pgxn is a good step,
I could not find it from postgresql.org:-(
I propose to not integrate the unsigned types into existing promotion
hierarchy, and behave just like gcc would with -Werror: require
explicit cast. Between them, the unsigned
I looked a bit more into the code and it appears to me that the following
are true:
- A separate wal sender process is created on the primary side for each
connected standby.
- The wal sender process terminates (walsender.c / WalSndLoop) when there
is an error to write to the standby's socket.
-
On Wed, May 29, 2013, at 09:45 AM, Stephen Frost wrote:
* Albe Laurenz (laurenz.a...@wien.gv.at) wrote:
Maybe the db_user_namespace parameter can help:
http://www.postgresql.org/docs/9.2/static/runtime-config-connection.html#GUC-DB-USER-NAMESPACE
I doubt it and I wouldn't encourage anyone
On Mon, May 27, 2013 at 9:41 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 27 May 2013 15:36, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
On Mon, May 27, 2013 at 08:26:48AM -0400, Stephen Frost wrote:
That said, many discussions and ideas do get shut down,
On Wed, May 29, 2013, at 10:08 AM, Stephen Frost wrote:
This capability might well come with a real way to have per-database
roles in general, which has been asked for quite often as well. You
would then be able to have an 'auditor' role in each database and have
them actually be different
On Tue, May 28, 2013 at 09:56:03AM -0400, Bruce Momjian wrote:
On Tue, May 28, 2013 at 09:49:32AM -0400, Magnus Hagander wrote:
On Tue, May 28, 2013 at 9:48 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, May 28, 2013 at 9:40 AM, Bruce Momjian br...@momjian.us wrote:
On Wed, May 22,
Bruce Momjian escribió:
Done. This was the first run of the Perl-based pgindent script. There
was a lot of code churn in this run as the paragraphs are slightly
wider. Also, I saw some outdenting of long lines, rather than allowing
them to go past 80 characters, but it seemed minimal. If
It's another possibility, but I think it's still somewhat remote given how
long we've been using this method with this code. It's sadly hard to test
because taking the full backup without the hard linking is fairly expensive
(the databases comprise multiple terabytes).
As a possibly unsatisfying
On Wed, May 29, 2013 at 05:56:32PM -0400, Alvaro Herrera wrote:
Bruce Momjian escribió:
Done. This was the first run of the Perl-based pgindent script. There
was a lot of code churn in this run as the paragraphs are slightly
wider. Also, I saw some outdenting of long lines, rather than
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/29/2013 07:43 AM, Andres Freund wrote:
On 2013-05-29 07:35:42 -0700, Joe Conway wrote:
On 05/29/2013 05:52 AM, Dimitri Fontaine wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-05-29 09:30:43 +0200, Dimitri Fontaine wrote:
2) How
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/29/2013 03:31 PM, Joe Conway wrote:
On 05/29/2013 07:43 AM, Andres Freund wrote:
Couldn't ALTER EXTENSION ... ADD ...; be brought up to
speed to support this?
Sounds better to me than manually fiddling with pg_depend... We
can't really
On Wed, May 29, 2013 at 8:40 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Thanks for asking :-). I've been fixing bitrot throughout the winter. I just
started cleaning it up again last week, and also continued with performance
testing.
Unfortunately I lost the 8-core box I used
I think these sort of entries don't make much sense:
#wal_sender_timeout = 60s # in milliseconds; 0 disables
I think we should remove units from the comments when it's clear from
the name or the default value that time units are accepted.
--
Sent via pgsql-hackers mailing list
* Bruce Momjian (br...@momjian.us) wrote:
Wow, uh, yeah, I guess we could do that. I will await more feedback.
Please don't. I'm already rather concerned by this one. It looks like
there's a rule to pull a line in to meet the max-column requirement even
when that makes things line up 'funny',
On Wed, May 29, 2013 at 1:11 PM, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2013-05-28 at 19:51 -0400, Robert Haas wrote:
If we just wanted to reduce read cost, why not just take a simpler
approach and give the visibility map a isfrozen bit? Then we'd know
which pages didn't need
Hello,
I have been trying to understand how pg_trgm works. As part of that, I
was looking at gin_extract_query_trgm(), which I think, extracts
trigrams from a search query string. So, I debugged for 3 cases:
1) column_name LIKE '%緊急%'
in this case, inside gin_extract_query_trgm(), after a call
On Wed, May 29, 2013 at 9:57 AM, Andres Freund and...@2ndquadrant.com wrote:
Thought about that, but given that 9.3's visibilitymap_set already will
already FPI heap pages I concluded it wouldn't really be an improvement
since it's only one ||log_heap_page or so there. Not sure what's
better.
On Wed, May 29, 2013 at 09:59:10PM -0400, Peter Eisentraut wrote:
I think these sort of entries don't make much sense:
#wal_sender_timeout = 60s # in milliseconds; 0 disables
I think we should remove units from the comments when it's clear from
the name or the default value that time
On Wed, May 29, 2013 at 10:08:10PM -0400, Stephen Frost wrote:
* Bruce Momjian (br...@momjian.us) wrote:
Wow, uh, yeah, I guess we could do that. I will await more feedback.
Please don't. I'm already rather concerned by this one. It looks like
there's a rule to pull a line in to meet the
On Wed, 2013-05-29 at 22:46 -0400, Robert Haas wrote:
Again independently of Josh's proposal, we could eliminate
PD_ALL_VISIBLE. This would require either surrendering the
optimization whereby sequential scans can skip visibility checks on
individual tuples within the page, or referring to
On Tue, May 28, 2013 at 10:39 PM, Robert Haas robertmh...@gmail.com wrote:
IMHO, we should press forward with this approach. Considering that
these are pretty extreme test cases, I'm inclined to view the
performance loss as acceptable. We've never really viewed DDL as
something that needs
55 matches
Mail list logo
