Tom Lane wrote:
> I can't see automating it though. We already have a perfectly
> good solution to the automated shutdown problem.
Oh, I totally agree with that. I somehow thought we'd gotten off
into how someone could recover after shooting their foot.
-Kevin
--
Sent via pgsql-hackers m
Robert Haas wrote:
> A database that can't accept new connections is a liability, not
> an asset.
+1
I have so far been unable to imagine a use case for the production
databases I use where I would prefer to see backends continue after
postmaster failure.
-Kevin
--
Sent via pgsql-hackers
Robert Haas wrote:
> Would anyone like to argue vigorously for or against the above
> proposal?
Greg's numbers look reasonable to me, and there's nobody I'd trust
more to come up with reasonable numbers for this. One less tunable
is a good thing, especially since this designed to scale from
s
Anssi Kääriäinen wrote:
> I think I found a problem. This is using SSI v8. The table
> definition:
>
> create table test_t (id integer, val1 text, val2 integer);
> create index test_idx on test_t(id) where val2 = 1;
> insert into test_t (select generate_series(0, 1), 'a', 2);
> insert in
Alvaro Herrera wrote:
> Excerpts from Robert Haas's message:
>
>> I'd rather remove the deprecating warning.
>
> +1
+1
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alvaro Herrera wrote:
> If postmaster dies, and then another backend crashes, then your
> backend running "your honking big query" could run across
> corrupted state and then you'd be in serious trouble.
Worst of all, it could give bogus results without error. I really
don't see a production
Tom Lane wrote:
> The reason for wanting to deprecate and ultimately remove that
> syntax is so we can get rid of FREEZE as a reserved word.
>
> We could probably still allow the new-style syntax VACUUM (FREEZE)
Oh, OK. I can go along with that. If we're going that route,
though, shouldn't
Robert Haas wrote:
> this seems to be speeding up the first run by 6x at the expense of
> slowing down many subsequent runs by 10-15%.
If the overall throughput when measured far enough out to have hit a
steady state again is anywhere in the neighborhood of the unpatched
throughput, the leveli
Tom Lane wrote:
> "Kevin Grittner" writes:
>> shouldn't we be getting support for the new syntax added, so
>> there can be a release or two supporting both?
>
> You mean like 9.0?
Yeah, just like that.
If we're going to be supporting that long
Robert Haas wrote:
> I'm hoping some will pick it up and play with it some more (hint,
> hint).
That was a bit of a pun, eh?
Anyway, there are so many ideas in this area, it's hard to keep them
all straight. Personally, if I was going to start with something,
it would probably be to better
Robert Haas wrote:
> Background freezing plays havoc with Hot Standby
I must have missed or forgotten the issue of background vacuums
and hot standby. Can you summarize why that's worse than hitting
thresholds where autovacuum is freezing things?
> this test is sufficient to show that elimi
Robert Haas wrote:
> Freezing sooner could be viewed as an alternative to hint bits.
Exactly. And as your test showed, things run faster frozen than
unfrozen with hint bits set.
> Trouble is, it breaks Hot Standby, badly.
You're really starting to worry me here. Both for performance and
Tom Lane wrote:
> Robert Haas writes:
>> Those things are related, though. Freezing sooner could be
>> viewed as an alternative to hint bits.
>
> Freezing sooner isn't likely to reduce I/O compared to hint bits.
> What that does is create I/O that you *have* to execute ... both
> in the page
Robert Haas wrote:
> The critical issue is whether the tuples get frozen while they're
> still invisible to some transactions on the standby server.
> That's when you get query cancellations.
Oh, OK; I get that. That seems easy enough to at least mitigate to
a large degree by some threshold
Tom Lane wrote:
> "Kevin Grittner" writes:
>> So, still +1 on removing the wording about FREEZE being
>> deprecated, but instead we should mention what actually *is*
>> deprecated (the omission of the parentheses).
>
> If we're going to do tha
Robert Haas wrote:
> I'm not wildly enthusiastic about breaking this with only one
> intervening release. We normally support deprecated syntax for
> quite a bit longer than that.
"one intervening release"? Where did you see that?
I thought we were just talking about deprecating the old sy
Tom Lane wrote:
> "Kevin Grittner" writes:
>> Robert Haas wrote:
>>> The critical issue is whether the tuples get frozen while
>>> they're still invisible to some transactions on the standby
>>> server. That's when you get query cancellat
diff --git a/src/backend/replication/.gitignore
b/src/backend/replication/.gitignore
new file mode 100644
index 000..a0332b2
--- /dev/null
+++ b/src/backend/replication/.gitignore
@@ -0,0 +1,3 @@
+/repl_gram.c
+/repl_gram.h
+/repl_scanner.c
--
Sent via pgsql-hackers mailing list (pgsql-hack
Robert Haas wrote:
> a quick-and-dirty attempt to limit the amount of I/O caused by hint
> bits. I'm still very interested in knowing what people think about
> that.
I found the elimination of the response-time spike promising. I
don't think I've seen enough data yet to feel comfortable endor
Robert Haas wrote:
> I think you may be confused about what the patch does - currently,
> pages with hint bit changes are considered dirty, period.
> Therefore, they are written whenever any other dirty page would be
> written: by the background writer cleaning scan, at checkpoints,
> and when a
Anssi Kääriäinen wrote:
> I tried to break the version 11 of the patch (some of the work was
> against earlier versions). In total I have used a full work day
> just trying to break things, but haven't been able to find anything
> after version 8. I can verify that the partial index issue is
> fi
Jeff Janes wrote:
> A review:
Thanks! Very thorough!
> None of the issues I raise above are severe. Does that mean I
> should change the status to "ready for committer"?
I see that notion was endorsed by Robert, so I'll leave it alone for
now. If a committer asks me to do something about
Itagaki Takahiro wrote:
> Shigeru HANADA wrote:
>> Attached patch would avoid this leak by adding per-copy context to
>> CopyState. This would be overkill, and ResetCopyFrom() might be
>> reasonable though.
>
> Good catch. I merged your fix into the attached patch.
Review for CF:
While ther
> Dan Ports wrote:
> Yes, that comment was supposed to be attached to
> possibleUnsafeConflicts.
> Actually, I think that "other" hash no longer exists
> The comment above SERIALIZABLEXACT also needs to be updated since
> it refers to said hash table. And if I'm not mistaken (Kevin?), we
> c
> Heikki Linnakangas wrote:
> Setting the high bit in OldSetXidAdd() seems a bit weird. How about
> just using UINT64_MAX instead of 0 to mean no conflicts? Or 1, and
> start the sequence counter from 2.
Sure. I think I like reserving 1 and starting at 2 better. Will do.
> ReleasePredicate
> Dan Ports wrote:
> On Mon, Jan 17, 2011 at 07:20:20PM -0600, Kevin Grittner wrote:
>> OK. I may need to bounce some questions off the list to resolve
>> some of them. The biggest, in my mind, is whether
>> MySerializableXact needs to be declared volatile. I don'
Heikki Linnakangas wrote:
> There's a few remaining TODO comments in the code, which obviously
> need to be resolved one way or another
Not all of these are "must haves" for 9.1. Here's how they break
down:
The two in predicate_internals.h mark places which would need to be
touched if we fu
"Kevin Grittner" wrote:
> If my back-of-the-envelope math is right, a carefully constructed
> pessimal load could need up to (max_connections / 2)^2 -- so 100
> connections could conceivably require 2500 structures, although
> such a scenario would be hard to create.
Thom Brown wrote:
> I've attached a couple minor fixes to the docs. One relating to
> SECURITY LABEL and the other for pg_class.relpersistence
relpersistence should be "char", not char.
Oddly enough, there is a difference.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
Thom Brown wrote:
> relkind in the same table is the same type, but isn't displayed as
> "char" in the docs, and the same applies to many other system
tables.
> They would need changing too then.
>
> Examples are:
>
> pg_type.typtype
> pg_proc.provolatile
> pg_attribute.attstorage
That's a g
Tom Lane wrote:
> If we could solve the refcounting problem I think this would be a
> very significant win.
Instead of trying to keep a refcount, how about just evicting from
the buffer as needed based on LRU?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Here's an issue for feedback from the community -- do we want to
support truly serializable transactions on hot standby machines?
The best way Dan and I have been able to think to do this is to
build on the SERIALIZABLE READ ONLY DEFERRABLE behavior. We are
able to obtain a snapshot and then che
Simon Riggs wrote:
> In this release? Maybe? In later releases? Yes.
>
> If it blocks your excellent contribution in this release, then
> from me, "no". If you can achieve this in this release, yes.
> However, if this is difficult or complex, then I would rather say
> "not yet" quickly now, tha
Robert Haas wrote:
> Kevin Grittner wrote:
>> I agree it's pretty late in the cycle, but I'm going through all
>> the loose ends and found this one -- which has been hanging out on
>> the Wiki page as an R&D item for over a full year without
>> disc
Simon Riggs wrote:
> I gave you a quick response to let you know that HS need not be a
> blocker, for this release. If you are saying you have knowingly
> ignored a requirement for a whole year, then I am shocked. How
> exactly did you think this would ever be committed?
I was asked not to dis
Robert Haas wrote:
> I think filtered is pretty clear and like it...
I find it ambiguous. [Takes sip of filtered water.] How about
excluded?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpr
Heikki Linnakangas wrote:
> On 20.01.2011 03:05, Kevin Grittner wrote:
>> If we don't do something like this, do we just provide REPEATABLE
>> READ on the standby as the strictest level of transaction
>> isolation? If so, do we generate an error on a request for
>>
Simon Riggs wrote:
> On Wed, 2011-01-19 at 19:05 -0600, Kevin Grittner wrote:
>
>> The idea is that whenever we see a valid snapshot which would
>> yield a truly serializable view of the data for a READ ONLY
>> transaction, we add a WAL record with that snapshot inform
I wrote:
> Why not? We already generate appropriate snapshots for this in
> SSI, so is the problem in getting the appropriate information into
> the WAL stream or in having a request for a snapshot within a
> serializable transaction while running in hot standby the problem?
I dropped few word
Tom Lane wrote:
> I'm pretty concerned about the performance implications, too. In
> particular that sounds like you could get an unbounded amount of
> WAL emitted from a *purely read only* transaction flow.
No. Read only transactions wouldn't create any flow at all. And I
suggested that we
Tom Lane wrote:
> Simon Riggs writes:
>> On Wed, 2011-01-19 at 19:05 -0600, Kevin Grittner wrote:
>>> The idea is that whenever we see a valid snapshot which would
>>> yield a truly serializable view of the data for a READ ONLY
>>> transaction, we add a WAL r
> Robert Haas wrote:
> On Thu, Jan 20, 2011 at 3:57 PM, Kevin Grittner
> wrote:
>> Robert Haas wrote:
>>
>>> I think filtered is pretty clear and like it...
>>
>> I find it ambiguous. [Takes sip of filtered water.]
>
> Oh, you mean water that h
Robert Haas wrote:
> Kevin Grittner wrote:
>> Attached is a rebased roll-up of the 3 and 3a patches from last
>> month.
> do you have a link to previous discussion?
http://archives.postgresql.org/pgsql-hackers/2010-12/msg00582.php
That thread seems to break, but
> Robert Haas wrote:
> Jeff Janes wrote:
>> I found the following message somewhat confusing:
>> ERROR: read-only property must be set before any query
>
> I think what we need here is two messages, this one and a similar one
> that starts with "read-write property...".
>
>> When a subtransacti
Robert Haas wrote:
> Kevin Grittner wrote:
>> As I mentioned in another email, we might want to throttle this.
>> My thinking was that we could start a timer on capturing a
>> snapshot, and continue to gather new ones as they become
>> available. When you hit the tim
Heikki Linnakangas wrote:
> It's not the order in which the xid was assigned that matters, but
> the order the transactions started and got their snapshots. The
> xids might be assigned a lot later, after the transactions have
> already read data.
>From the "Apparent Serial Order of Execution"
"Kevin Grittner" wrote:
> (1) A read write transaction might need to be canceled to
> prevent the view of the data a committed read only transaction has
> already seen from becoming inconsistent. (Dan's example)
And this one seems entirely a theoretical possibility
Robert Haas wrote:
> On Fri, Jan 21, 2011 at 8:05 AM, Nicolas Barbier
>> This has been discussed before; in [1] I summarized:
>>
>> "IOW, one could say that the backup is consistent only if it were
>> never compared against the system as it continued running after
>> the dump took place."
>
> B
Tom Lane wrote:
> Simon Riggs writes:
>> On Fri, 2011-01-21 at 11:19 +0200, Heikki Linnakangas wrote:
>>> It's not the order in which the xid was assigned that matters,
>>> but the order the transactions started and got their snapshots.
>>> The xids might be assigned a lot later, after the transa
Anssi Kääriäinen wrote:
> I am beginning to understand the problem. If you don't mind, here
> is a complete example if somebody else is having troubles
> understanding this.
>
> Let's say we have tables D1 and D2. Both contain a single column,
> id, and a single row. The data in the beginning is
"Kevin Grittner" wrote:
> When I test your example, though, I'm getting the serialization
> failure on T3 rather than T2, so I'd call that a bug. Will
> investigate. Thanks again for your tests!
Fixed with this:
http://git.postgresql.org/gitweb?p=users/kgritt
Anyone else seeing anything like this on `make world`?
make[3]: Entering directory
`/home/kgrittn/git/postgresql/kgrittn/doc/src/sgml'
{ \
echo ""; \
echo ""; \
} > version.sgml
"/usr/bin/perl" ./mk_feature_tables.pl YES
../../../src/backend/catalog/sql_feature_package
Robert Haas wrote:
> Jeff Janes wrote:
>> I found the following message somewhat confusing:
>> ERROR: read-only property must be set before any query
>
> I think what we need here is two messages, this one and a similar
> one that starts with "read-write property...".
Done. I started out by
I wrote:
> We're not talking about passing the backwards. I'm suggesting
> that we probably don't even need to pass them forward, but that
> suggestion has been pretty handwavy so far. I guess I should fill
> it out, because everyone's been ignoring it so far.
It's been too hectic today to fl
> Jeff Davis wrote:
> On Fri, 2011-01-21 at 18:52 -0600, Kevin Grittner wrote:
>> My assumption is that when we have a safe snapshot (which should
>> be pretty close to all the time), we immediately provide it to any
>> serializable transaction requesting a snapshot, ex
Robert Haas wrote:
> Upon further review, I am wondering if it wouldn't be simpler and
> more logical to allow idempotent changes of these settings at any
> time, and to restrict only changes that actually change something.
I don't care a lot about that either -- if I remember correctly, we
go
Tom Lane wrote:
> I seem to recall pointing out upthread that the FK check triggers
> are designed on the assumption that the constraint does hold
> currently. Has any analysis been done on exactly how badly they'll
> fail when it doesn't hold? I remain unconvinced that this behavior
> is desir
Dan is still beating up on the latest patch with DBT-2, but I expect
that I'll be posting a patch tomorrow with all known issues fixed, no
known bugs, and reasonable performance -- except for the issue of how
this work relates to hot standby in the 9.1 release. (We did find
and fix a few bugs afte
Robert Haas wrote:
> I am wondering if it wouldn't be simpler and more logical to allow
> idempotent changes of these settings at any time, and to restrict
> only changes that actually change something. It feels really
> weird to allow changing these properties to their own values at
> any time
Just to put this on the record for 9.2: I've just thought of a way
to further extend the READ ONLY optimizations to de facto READ ONLY
transactions. Right now, when a dangerous structure is formed with
three transactions (which consists of read-write dependencies from
T0 -> T1 -> T2) and T2 is com
Thanks for the review, Jeff!
Dan Ports wrote:
> On Tue, Jan 25, 2011 at 01:07:39AM -0800, Jeff Davis wrote:
>> At a high level, there is a nice conceptual simplicity. Let me
>> try to summarize it as I understand it:
>> * RW dependencies are detected using predicate locking.
>> * RW dependencies
Jeff Davis wrote:
> For starters, the above structures require unlimited memory, while
> we have fixed amounts of memory. The predicate locks are
> referenced by a global shared hash table as well as per-process
> SHMQueues. It can adapt memory usage downward in three ways:
> * increase lock g
Joshua Tolley wrote:
>> http://www.xtranormal.com/watch/8285377/?listid=20642536
> I foresee a whole new set of animated postgres tutorials...
Seriously, I was thinking the same thing. I threw this together
while waiting to see if DBT-2 could shake out any new problems after
some minor cha
Heikki Linnakangas wrote:
> Not sure if that LSB section is relevant anyway. It specifies the
> exit codes for init scripts, but pg_ctl is not an init script.
Except that when I went to the trouble of wrapping pg_ctl with an
init script which was thoroughly LSB compliant (according to my
reading
Andres Freund wrote:
> On 2013-01-29 00:11:12 +1100, Josh Berkus wrote:
>>
>>> So I think we need to sort by age(relfrozenxid) in tables that
>>> are over the anti-wraparound limit. Given your code that
>>> doesn't seem to be that hard?
>>
>> I might also suggest that we think about changing the d
Andres Freund wrote:
> On 2013-01-29 16:09:52 +1100, Josh Berkus wrote:
>>
>>> I have to admit, I fail to see why this is a good idea. There
>>> isn't much of an efficiency bonus in freezing early (due to
>>> hint bits) and vacuums over vacuum_freeze_table_age are
>>> considerably more expensive a
Andres Freund wrote:
> I can't imagine that anybody with a large database ran pg
> successfully with a small freeze_min_age due to this.
I can't speak to this from personal experience, because at
Wisconsin Courts we found ourselves best served by running a
database VACUUM FREEZE ANALYZE each nig
Kevin Grittner wrote:
> To: Andres Freund
>> Trivial patch attached.
>
> I didn't see a patch attached.
Never mind; I was looking in the wrong spot. (I just switched
email providers again because the last one couldn't seem to get the
email headers right for thr
Jeff Janes wrote:
> Kevin Grittner wrote:
>> So reducing vacuum_freeze_min_age not only helps minimize the
>> writes that are needed when autovacuum needs to scan the entire
>> heap,
>
> How does it do that? If the tuple doesn't need to frozen now
> becau
Jim Nasby wrote:
> the only reason to freeze is XID wrap
The conclusions you draw seem to be based on a slightly different
premise than stated here; the conclusions are only supported by the
assumption that "the only reason to freeze at any particular moment
is to assure that all tuples are froz
MauMau wrote:
> Just doing "pkill postgres" will unexpectedly terminate postgres
> of other instances.
Not if you run each instance under a different OS user, and execute
pkill with the right user. (Never use root for that!) This is
just one of the reasons that you should not run multiple clus
Andres Freund wrote:
> On 2013-02-01 15:09:34 -0800, Jeff Janes wrote:
>> Since freeze_min_age was mistakenly being used, the limit
>> would be 50 million in the past (rather than 150 million) under
>> defaults. But since the last full-table vacuum, whenever that was,
>> used freeze_min_age for
I'm hoping that someone familiar with sepgsql can review this
portion of the materialized view patch and comment on whether it is
the best approach for dealing with the integration of these two
features. Basically, the patch as it stands treats a materialized
view as a table for purposes of sepgsq
Kohei KaiGai wrote:
> 2013/2/3 Kevin Grittner :
>> I'm hoping that someone familiar with sepgsql can review this
>> portion of the materialized view patch and comment on whether it is
>> the best approach for dealing with the integration of these two
>> featu
Kohei KaiGai wrote:
> Let me confirm a significant point. Do you never plan a feature
> that allows to update/refresh materialized-views out of user
> session?
Currently only the owner of the MV or a database superuser can
refresh it, and the refresh is run with the permissions of the MV
owner.
Sean Chittenden wrote:
> Currently src/port/pgcheckdir.c will reject non-empty
> directories, which is an issue during initdb(1) when PGDATA is
> also the mount point for filesystems that support snapshots (e.g.
> ZFS or UFS2).
> Granted it's not hard to create a subdirectory, initdb there and
>
Heikki Linnakangas wrote:
> On 07.02.2013 10:41, Simon Riggs wrote:
>> Why would someone want to turn off safe-promote mode, assuming it was
>> fast enough?
> Because faster is nicer, even if the slow mode would be "fast enough".
http://www.youtube.com/watch?v=H3R-rtWPyJY
-Kevin
--
Sent
Kohei KaiGai wrote:
> So, I'd like to review two options.
> 1) we uses db_table object class for materialized-views for
> a while, until selinux-side become ready. Probably, v9.3 will
> use db_table class then switched at v9.4.
> 2) we uses db_materialized_view object class from the
> begining, b
Tom Lane wrote:
>> when attempting to use a prepared statement:
>
>> ps = con.prepareStatement("insert into enumcast values (?)");
>> ps.setString(1, "meh");
>> ps.executeUpdate();
>
>> we get a
>
>> org.postgresql.util.PSQLException: ERROR: column "current_mood"
>> is of type mood bu
Magnus Hagander wrote:
> if there is any other committer who [wants to receive emails from
> the packagers list], let me know and I will add you there as well.
Hi Magnus,
Please add me.
Thanks,
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Kohei KaiGai wrote:
> I'll adjust contrib/sepgsql portion to fit materialized-view with
> matter of existing view.
OK. In case it is of any use to you as a starting point, attached
is what I originally had, which seems to be similar to what you
describe as your preference. I'll revert everythi
Robert Haas wrote:
> I'm not sure what others think, but the proposed wording seems a
> bit hard on plain text dumps to me.
Agreed. I don't know how many times I've piped the output of
pg_dump to the input of psql. Certainly that was very common
before pg_upgrade was available. And for develo
I'm using valgrind to find a problem with materialized views, and
ran into this, which I have confirmed is present on the master
branch as of 7803e9327db3788f68d820c19f4081afb79edd12.
Memory freed here:
at 0x76E3AF: pfree (mcxt.c:677)
by 0x50861E: parse_analyze (analyze.c:105)
by 0x684FF
Tom Lane wrote:> Kevin Grittner writes:
>> I'm using valgrind to find a problem with materialized views, and
>> ran into this, which I have confirmed is present on the master
>> branch as of 7803e9327db3788f68d820c19f4081afb79edd12.
>
>> Memory freed here:
scapes and we can do what we like for the rest of
the escape sequence. A mnemonic, such as Lance suggests, does seem
like a good approach.
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas wrote:
> On Fri, Feb 15, 2013 at 8:01 PM, Kevin Grittner wrote:
>> There is one odd aspect to pg_dump, but I think the way it is
>> behaving is the best way to handle it, although I invite other
>> opinions. If you load from pg_dump output, it will try to
>
Bruce Momjian wrote:
> On Fri, Feb 15, 2013 at 08:24:16PM -0500, Robert Haas wrote:
>> On Fri, Feb 15, 2013 at 8:01 PM, Kevin Grittner wrote:
>>> There is one odd aspect to pg_dump, but I think the way it is
>>> behaving is the best way to handle it, although I invite
Noah Misch wrote:
> On Sat, Feb 16, 2013 at 09:53:14AM -0800, Kevin Grittner wrote:
> I agree that making the dump fail on this account is bad.
I would argue that this is an overstatement of the issue except for
restores that use the single-transaction switch and pg_upgrade
without th
Alvaro Herrera wrote:
> Kevin Grittner escribió:
>
>> I'm OK with that approach, and in the absence of anyone pushing
>> for another direction, will make that change to pg_dump. I'm
>> thinking I would only do this for materialized views which were
>>
Thom Brown wrote:
> On 16 February 2013 01:01, Kevin Grittner wrote:
>> Unless something else comes up in review or I get feedback to
>> the contrary I plan to deal with the above-mentioned issues and
>> commit this within a week or two.
>
> At the moment it's
Noah Misch wrote:
> On Mon, Feb 18, 2013 at 06:49:14AM -0800, Kevin Grittner wrote:
>> Alvaro Herrera wrote:
>>> Maybe it would be a good idea to try to put such commands at
>>> the very end of the dump, if possible.
>
>> 25, /
e attached.
Will apply. Thanks.
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
u think it would be
better to include them in with tables there?
> Also a \dM.
I already added it as \dm in the current patch. Does that conflict
with something else that's pending?
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via
Kevin Grittner
> There was one minor syntax issue not addressed by Noah, nor much
> discussed in general that I didn't want to just unilaterally
> choose; but given that nobody seems to care that much I will put
> forward a proposal and do it that way tomorrow if nobody objec
, is that I include the heap and indexes for MVs in the _user_
views. I'm attaching the patch for just the system_views.sql file
for discussion before I go write docs for this part.
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Companydiff --git a/src/b
Kevin Grittner wrote:
> I'm attaching the patch for just the system_views.sql file
> for discussion before I go write docs for this part.
Meh. If I'm gonna have pg_matviews I might as well include an
isscannable column. v2 attached.
--
Kevin Grittner
EnterpriseDB: http://www.
Tom Lane wrote:
> Kevin Grittner writes:
>> When I went to do this, I hit a shift/reduce conflict, because
>> with TABLE being optional it couldn't tell whether:
>
>> TRUNCATE MATERIALIZED VIEW x, y, z;
>
>> ... was looking for five relations or three
der views or tables is
> appropriate.
Right. I think adding pg_matviews covers the stated use-case
enough to answer Erik's concern. I'm not going to mess with adding
non-standard stuff to the standard views.
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Post
doesn't have to make any shift-reduce decision until
> after it can "see past" the first identifier. It's a bit tedious
> but beats making a word more reserved than it has to be.
Thanks! Will do.
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterpris
389:8: warning: variable 'found' set but not used
> [-Wunused-but-set-variable]
>
> I don't get that on Linux, but I bet that is just the gcc version
> (4.6.2 vs 4.4.6) rather than the OS.
I get it on Linux with gcc version 4.7.2.
> It looks like it
901 - 1000 of 4000 matches
Mail list logo
