an anyone point me in the right direction, or
tell me that this avenue is a dead end?
Thanks,
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
gs with the down side being a very hypothetical
*possible* cost to longer chains in the HTAB. But that's a separate
issue, best settled on the basis of benchmarks rather than
theoretical discussions.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
his is a symptom of a more general issue, so
I'd like to find a good solution.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Heikki Linnakangas wrote:
> That sounds simple enough. Add a boolean field to HeapScanDesc,
> "rs_relpredicatelocked", and set it when you acquire the relation
> lock.
I'll take a look at doing that. Thanks!
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-ha
Heikki Linnakangas wrote:
> On 13.01.2011 16:51, Kevin Grittner wrote:
>> But we acquired a relation lock up front, when we determined that
>> this would be a heap scan, so we could short-circuit this whole
>> thing if within the heapgettup_pagemode function we could
>&
a reason
to allow such an orphan to run?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 v
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
--
Sen
esigned to scale from
someone slapping it on his laptop for a first quick try, all the way
up to industrial strength production environments. I guess a manual
override doesn't bother me too much, but I am a bit dubious of its
value, and there is value in keeping the GUC count down
de you wrote included
in the test suite which is part of the patch. Well, if you do, I'll
pull it back out and invent something similar... ;-)
http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=2502cccbdd5e5d44be469549b91fe49c0554ec3e
-Kevin
--
Sent v
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
y
don't see a production use case for letting backends continue after
postmaster failure -- unless you only kinda, sorta care whether
committed data is actually retrievable or reported data is actually
accurate.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
though, shouldn't we be getting support for the new syntax added, so
there can be a release or two supporting both?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t, the leveling of the response times has enough value to
merit the change. At least in my world.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
ng able to get better forensics from WAL files if
certain barriers could be overcome -- having hard numbers on the
performance benefits which might also accrue might put that work in
a different perspective.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
ed
pages out. Maybe I'm missing something or you didn't post
everything you observed in this regard
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ormance and
to reduce the WAN bandwidth demands of our backup strategy we are
very aggressive with our freezing. Do off-hours VACUUM (FREEZE)
runs break hot standby? Autovacuum freezing? What are the
symptoms?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
ons
which would clobber performance. I suspect that you can envision a
hueristic which would be no more bothersome than autovacuum.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> was probably due to needing to reset hint bits on pages that we
> threw away without pushing them out.
It would be good to confirm and quantify.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
bout deprecating the old syntax, not
breaking it. If history is any guide, getting the deprecation
mentioned in the docs now would lead to actual removal somewhere
around 10.0.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
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
hink there would need to be some way to limit how many times that
happened before the hint bits were saved.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
clog often
enough to kill performance.
In other words, I'm asking that you show that the other two methods
aren't really needed for decent overall performance.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
ific mention in the docs; but I'm open to arguments to
the contrary -- particularly if they suggest what language to put
where.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
asks me to do something about any of those
issues (or others, of course), I'll happily do so.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
he
status on the CF page.
I'm wondering if it would make more sense to do the benchmarking with
just this patch or the full fdw patch set? Both?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> 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
. The biggest, in my mind, is whether MySerializableXact
needs to be declared volatile. I don't have my head around the
issues on that as well as I might. Any thoughts on it?
Thanks for the multiple reviews and all the suggestions. The code is
clearly better for your attention.
-Kevin
> 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'
around it better, but failing that, I'm disinclined to either
add locking I'm not sure we need or to remove the comment that says
we *might* need it there.
That's all of them.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
"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 mailin
rc/sgml/xfunc.sgml:1794:
"char"
./doc/src/sgml/release-8.0.sgml:3389: "char" data type
have been removed.
./doc/src/sgml/release-8.0.sgml:4460:"char" data
type have been removed.
./doc/src/sgml/release-8.0.sgml:4466:to do arithmetic on a
&qu
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.o
ctest level of transaction isolation?
If so, do we generate an error on a request for SERIALIZABLE, warn
and provide degraded behavior, or just quietly give them REPEATABLE
READ behavior?
Thoughts?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
ly way it can still happen for 9.1.
If not, I agree this can be 9.2 material. We just have to decide
how to document it and answer the questions near the bottom of my
initial post of the thread.
-Kevin
--
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:
> 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
oblems which needed response, and I got
into the mode of reacting to that rather than ticking through my
issues list.
-Kevin
--
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:
> 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.
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
dropped few words.
That was supposed to ask whether the problem was in getting hot
standby to *use such a snapshot*.
I'm open to other suggestions on how else we might do this. I don't
see any alternatives, but maybe you're seeing some possibility that
eludes me.
-Kevin
--
Sen
I
suggested that we might want some kind of throttle on how often we
generate snapshots even from the read write transactions. I'm not
at all clear on how you got to the concerns you have. Is there
something in particular I could clear up for you that isn't already
mentioned in
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
egression tests
>> do not exercise that case by testing the case where a SAVEPOINT is
>> either rolled back or released. Should those tests be included?
>
> +1.
OK, will put something together.
-Kevin
--
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:
> 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
ether we just dont, I guess; but that doesn't seem very
satisfactory as a long term solution.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
"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
tandby -- how far along you are for
purposes of recovery, and how far along you are for purposes of
seeing a view of the data sure to be consistent the later state of
the master. With SSI they can't be the same. If someone wants them
to be, they could implement a traditional S2PL serializable
ea is DOA from a performance standpoint. We sweated
> blood to avoid having to assign XIDs to read-only transactions,
> and we're not going back. If SSI requires that, SSI is not
> getting committed.
SSI doesn't require that. The suggestion that it would in *any* way
he
rather than T2, so I'd call that a bug. Will
investigate. Thanks again for your tests! You seem to be able to
shake out issues better than anyone else! Once found, fixing them
is not usually very hard, it's coming up with that creative usage
pattern to *find* the problem which is the h
"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
estfsync.sgml:20:1: start tag was here
make[3]: *** [HTML.index] Error 1
make[3]: *** Deleting file `HTML.index'
make[3]: Leaving directory
`/home/kgrittn/git/postgresql/kgrittn/doc/src/sgml'
Docs have been building fine until today. I can't rule out it being my
problem somehow, t
btransaction ends (whether by success or by rollback), which
>> was discussed as the desired behavior. But the included
>> regression tests do not exercise that case by testing the case
>> where a SAVEPOINT is either rolled back or released. Should
>> those test
andby-related cancellations would be in play. I
don't know whether the older snapshots would tend to increase the
standby-related cancellations, but it wouldn't surprise me.
Hopefully this is enough for people to make something of it.
-Kevin
--
Sent via pgsql-hackers mailing li
> 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
ny
sleep over that.
I'll do whatever people want in this regard with no reservations.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ague hint of what sort of thing you think might go wrong
might help people find problem code, if it actually exists.
Now, I understand that a broken index, like one based on a function
declared immutable which really isn't, could cause problems, but that
seems orthogonal.
-Kevin
--
Sent via p
e. :-)
http://www.xtranormal.com/watch/8285377/?listid=20642536
I could have just kept on going, but I decided at the start that it
had to be less than three minutes. Also, please make allowances for
the fact that while I went over 15 minutes putting that "movie"
together, it wasn&#
nge to what this patch was doing, because I don't
think the discussion made that entirely clear.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Definitely too late in the release cycle to be trying to add a new
optimization, though.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
aiting
>> for a snapshot, right?
>
> Correct. It probably wouldn't hurt to clear that field when
> releasing the transaction, but we don't use it after.
I thought they might show up in the pid column of pg_locks, but I
see they don't. Should they? If so, should we still see the pid
after a commit, for as long as the lock survives?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
because I'm looking forward to this
> feature. And I certainly think that you and Dan have applied the
> amount of planning, documentation, and careful implementation
> necessary for a feature like this.
Thanks much! This effort was driven, for my part, by the needs of
my employer; bu
I would think.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to my
reading) and offered it to the community, everyone said that rather
than have such a complicated script it would be better to change
pg_ctl to include that logic and exit with an LSB compliant exit
code.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
WAL-logging is an improvement. Anyone who has
run an OLTP load on a database which was loaded from pg_dump output
or other bulk load processes, has probably experienced the pain
related to the WAL-logged rewrite of massive quantities of data.
Of course, since it triggers based on transaction count, th
_min_age
| transactions.
So reducing vacuum_freeze_min_age not only helps minimize the
writes that are needed when autovacuum needs to scan the entire
heap, but also decreases the frequency of those full-table scans.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
EZE ANALYZE each night during off-peak hours.
> It seems to be broken since the initial introduction of
> freeze_table_age in 6587818542e79012276dcfedb2f97e3522ee5e9b.
> Trivial patch attached.
I didn't see a patch attached.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-h
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
he *next best* time to freeze is when the hint
bits are set, to avoid a separate page write. If you are doing
differential backups, the *third best* time to freeze is before the
first differential backup of the tuple, to avoid a separate backup
after the freeze. And so on.
-Kevin
--
Sent via p
not run multiple clusters
on the same machine with the same OS user.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
lems are serious enough to merit cautious back-patching,
in my view; the current state of affairs really is causing serious
disruption of production environments.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
lated differently -- from a view-like rule.
The portion of the patch which affects the contrib/sepgsql/ tree is
attached.
Thoughts?
-Kevin*** a/contrib/sepgsql/dml.c
--- b/contrib/sepgsql/dml.c
***
*** 191,196 check_relation_privileges(Oid relOid,
--- 191,197
switch (re
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
terialized-view without appropriate
> privilege control, or not.
I guess the question is whether it makes sense to support these
under sepgsql using table access labels, or whether we need new
labels and the feature is not usable in environments without those
labels. That's what I"m
ght want to take.
It's hard to get enthusiastic about a patch to make bad practice
more convenient. I would rather add a sentence or two to the
initdb documentation recommending that a cluster not be created at
a mount point; it should be created in a directory underneath the
mount point.
-Ke
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
it
would take that much to implement.
Thanks for looking at this!
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
he problem with this debate has always been that both sides are
completely right. Those are always the toughest to resolve. It
comes down to which evils we tolerate to garner which benefits. It
seems that in such cases inertia tends to win. I'm not so sure
that it should. An ideal soluti
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 c
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
s available. And for development purposes a
text script file is often exactly what is needed -- to store it in
custom format first would just be an extra step which would waste
time. Since I got my head around PITR dumps, I've rarely had a
reason to use the pg_dump custom format, myself.
-K
to get too sidetracked by what I went in to look for,
but I didn't want to lose track of this either. If nobody sorts it
out before I finish what I'm looking at this issue I'm currently
on, I will come back to this.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hacker
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
901 - 1000 of 4331 matches
Mail list logo
