On 27 April 2013 20:23, Robert Haas robertmh...@gmail.com wrote:
On Sat, Apr 27, 2013 at 10:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
2. The checksum algorithm business. Again, we don't get to tinker with
that anymore once we're in beta.
I think it's pretty darn clear that we should change
On 27 April 2013 19:06, Tom Lane t...@sss.pgh.pa.us wrote:
Noah Misch n...@leadboat.com writes:
On Sat, Apr 27, 2013 at 10:59:32AM -0400, Tom Lane wrote:
As far as #1 goes, I think we have little choice at this point but to
remove the unlogged-matviews feature for 9.3.
This perspective is
On 04/24/2013 09:39 PM, Shaun Thomas wrote:
On 04/24/2013 08:24 AM, Robert Haas wrote:
Are you referring to the fact that vm.zone_reclaim_mode = 1 is an
idiotic default?
Servers are getting shafted in a lot of cases, and it's actually
starting to make me angry.
A significant part of that
On Sat, Apr 27, 2013 at 3:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Apr 27, 2013 at 3:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Um, wait, it's *not* in pg_class now, and what I was about to do was
go put it there. Is there a typo in the above
--
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
attachment: avalanche-fnv-slr3.pngattachment: avalanche-fnv-slr17.png
fnv-ants-20130428.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On 04/25/2013 10:55 PM, Andrew Dunstan wrote:
It's an Amazon product based on release 8.0, but with many many
features removed (e.g. Indexes!)
More specifically, it's a hacked-up column-store-ized Pg for OLAP and
analytics work. As I understand it Amazon didn't develop it themselves;
they
Robert Haas robertmh...@gmail.com writes:
On Sat, Apr 27, 2013 at 3:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I cannot say that I find that idea attractive; the biggest problem with
it being that updating such a state flag will be nontransactional,
unless we go to a lot of effort to support
Simon Riggs si...@2ndquadrant.com writes:
On other patches, one committer objecting to something is seen as
enough of a blocker to require change. That should work in every
direction.
The bottom line here is that we have substantial disagreement on how
unlogged matviews should be implemented,
After a bit of discussion, the core committee has decided that we're not
really ready to wrap a credible beta1 candidate tomorrow. There are
several unresolved issues such as what to do about checksums and
matviews; and there seems no good reason to force resolution of
these important issues on a
On 28 April 2013 16:55, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On other patches, one committer objecting to something is seen as
enough of a blocker to require change. That should work in every
direction.
The bottom line here is that we have substantial
Simon Riggs si...@2ndquadrant.com writes:
On 28 April 2013 16:55, Tom Lane t...@sss.pgh.pa.us wrote:
The bottom line here is that we have substantial disagreement on how
unlogged matviews should be implemented, and there's no longer enough
time for coming to a resolution that will satisfy
On Tue, Feb 26, 2013 at 01:09:30PM -0800, David Fetter wrote:
On Wed, Feb 13, 2013 at 06:45:31AM -0800, David Fetter wrote:
On Sat, Feb 09, 2013 at 11:59:22PM -0800, David Fetter wrote:
Folks,
Per suggestions and lots of help from Andrew Gierth, please find
attached a patch to
On 28 April 2013 21:06, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On 28 April 2013 16:55, Tom Lane t...@sss.pgh.pa.us wrote:
The bottom line here is that we have substantial disagreement on how
unlogged matviews should be implemented, and there's no longer
On Sun, Apr 28, 2013 at 11:41 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Apr 27, 2013 at 3:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I cannot say that I find that idea attractive; the biggest problem with
it being that updating such a state flag
Folks,
The FOR ROLE syntax is completely broken, as of 9.2.4. Not sure when
exactly this got broken; I remember it working sometime in the past:
[jberkus@pgx-test ~]$ psql -U postgres analytics2
psql (9.2.4)
Type help for help.
analytics2=# ALTER DEFAULT PRIVILEGES FOR ROLE webui IN SCHEMA web
I wrote:
The only alternative I can see is to make a back-patch that just teaches
get_eclass_for_sort_expr() to compute valid nullable_relids for the sort
expression. That's necessary code in any case, and it would fix the
immediately complained-of bug. The thing that scares me is that it is
... in fact, there is no combination of actions which will make FOR
ROLE work. Any invokation of FOR ROLE inevitably results in a
permission denied message:
analytics2= \c - webui
You are now connected to database analytics2 as user webui.
analytics2= ALTER DEFAULT PRIVILEGES FOR ROLE
Robert Haas robertmh...@gmail.com writes:
On Sun, Apr 28, 2013 at 11:41 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, it's fairly clear *how* to do it: add some more processing that
occurs after we've completed crash replay. We already have some of
that, eg completion of partial splits in
On Sun, Apr 28, 2013 at 1:06 AM, Atri Sharma atri.j...@gmail.com wrote:
Inspired by the awesome work done by Oleg sir in HStore, I have been thinking
about making a graph data type as an extension in postgres.
I have been reading about graph databases and how storing data in graphs can
lead
Josh Berkus j...@agliodbs.com writes:
Actually, the problem is worse than I thought. It looks like I can't
set default privs for any role which is not the owner of the schema:
analytics2= ALTER DEFAULT PRIVILEGES IN SCHEMA web GRANT SELECT ON
TABLES TO dbreader;
ERROR: permission denied
The fine manual notes that the target role has to already have CREATE
privileges on the target schema --- maybe that's what's biting you in
this case?
Nope. That was the first thing I thought of. It really is that the
target role must *own* the schema. So clearly a bug.
--
Josh Berkus
On 29 April 2013 01:40, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Apr 28, 2013 at 11:41 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, it's fairly clear *how* to do it: add some more processing that
occurs after we've completed crash replay. We already
It's probably pretty easy to add this, but I think the question is
what would make it better than storing the same representation in a
text field.
I completely agree. The main point in making a new datatype would be
to add support for operations that are normally done with graphs.
Obviously
Can you please elaborate, why would it be a disaster?
Consider that we've done
create table t1 (id int primary key, ... other stuff ...);
create view v1 as select * from t1;
create view v2 as select * from v1 group by id;
Currently, v2 would be rejected but you would like to make it
24 matches
Mail list logo
