* Robert Haas (robertmh...@gmail.com) wrote:
> On Sun, Aug 4, 2013 at 4:26 PM, Dimitri Fontaine
> wrote:
> > What I'm yet unsure about is that there's a consensus that the use cases
> > are worthy of a new shared catalog in the system. Also I didn't look how
> > hard it is to actually provide for
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> This is all sufficiently bizarre that I don't know if there's an
> easy explanation.
It occurs to me that users, when faced with complex error messages, are
very likely to go to their favorite search engine with it and rarely
does that lead them to any docu
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Thoughts? In particular, anyone want to bikeshed on the message wording?
Looks like a good idea to me and the wording looks fine to me.
> Does this rise to the level of a usability bug that ought to be
> back-patched? As I said, we've seen this type of t
* Craig Ringer (cr...@2ndquadrant.com) wrote:
> More seriously, with interpolated strings for relation names etc it can
> be hard to know which chunks to search for, and search engines aren't
> always good at having the whole message thrown at them.
It's not perfect, but if the searches are gettin
Josh, Tom,
* Josh Berkus (j...@agliodbs.com) wrote:
> > Does this rise to the level of a usability bug that ought to be
> > back-patched? As I said, we've seen this type of thinko multiple
> > times before.
>
> Hmmm. On the one hand, I can't see the harm in it. On the other hand,
> I'm relucta
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 8/1/13 1:42 PM, Stephen Frost wrote:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> >> pgsecure_open_client() returns -1 if it can't lock the mutex. This is a
> >> problem because the callers are not pr
* Hannu Krosing (ha...@2ndquadrant.com) wrote:
> If you earlier used views for granting limited read access to some views
> you definitely did not want view users suddenly gain also write access to
> underlying table.
>
> You also probably did not GRANT only SELECT to your views as this was
> the
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Magnus Hagander writes:
> > psql is missing tab completion for \dx (or more usfully, for \dx+).
> > Attached patch fixes this.
>
> > Do we consider this a bugfix and backpatch (at least to 9.3? even
> > though the problem goes back further), or head only?
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Robert Haas escribió:
> > On Fri, Aug 9, 2013 at 8:44 AM, Stephen Frost wrote:
> > > A shared catalog which defined which *database* to run the trigger in,
> > > with a way to fire off a new backend worker in that da
* Amit Kapila (amit.kapil...@gmail.com) wrote:
> I think disabling ALTER SYSTEM can be more easily supported if we
> choose one of below options:
> a. UI into contrib module, people who don't want doesn't include it
> b. Have an include file mechanism, so that user can comment the
> include in post
* Andres Freund (and...@2ndquadrant.com) wrote:
> I vote for adapting the patch to additionally zero out the file via
> write(). In your tests that seemed to perform at least as good as the
> old method... It also has the advantage that we can use it a littlebit
> more as a testbed for possibly usi
* Josh Berkus (j...@agliodbs.com) wrote:
> Well, if that's the alternative, I'd vote for taking it. For me,
> personally, I think the usefulness of it would outstrip the number of
> functions I'd have to debug.
Agreed. Having it take an interval makes a whole lot more sense than
backing a decisi
* Amit Kapila (amit.kapil...@gmail.com) wrote:
> If both are okay, then I would like to go with second option (include
> file mechanism).
> I think by default, we should allow auto file to be included and if
> user faces any problem or otherwise,
> then he can decide to disable it.
If it's enabled
* Amit Kapila (amit.kapil...@gmail.com) wrote:
> initdb will create the empty auto file. If we don't enable by default,
> then if user uses
> ALTER SYSTEM and do sighup/restart, changed config parameter values
> will not come into affect
> until he manually enables it by removing '#' from '#include
* Amit Kapila (amit.kapil...@gmail.com) wrote:
>Do you mean to say, that when user uses ALTER SYSTEM and include is
> disabled, then we can give ERROR in
>ALTER SYSTEM, that to reflect the values, he need to enable it?
>Actually in previous version of patch, there was WARNING on such a
* Amit Kapila (amit.kapil...@gmail.com) wrote:
> Okay, let us decide how things will be if we disable by default:
>1. initdb won't create any empty auto file, rather the file will be
> created first time user uses ALTER SYSTEM.
I'm not particularly set on this.. Why not create the file initia
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Amit Kapila escribió:
> >3. postgresql.conf will contain include directive in below form:
> >#include = 'postgresql.auto.conf'
> >Whenever user wants to use Alter System, he needs to enable it
> > after first time using ALTER
* Amit Kapila (amit.kapil...@gmail.com) wrote:
> On Tue, Aug 20, 2013 at 6:21 PM, Stephen Frost wrote:
> > I'm not particularly set on this.. Why not create the file initially?
>If by default this feature needs to be disabled, then it is not
> must to have at initdb ti
* Amit Kapila (amit.kapil...@gmail.com) wrote:
> Wouldn't it be complicated to handle this way rather then by having
> include directive.
You misunderstood. I was suggesting a setup along these lines:
postgresql.conf:
# include = 'auto.conf' # Disabled by default
auto.conf:
###
* Amit Kapila (amit.kapil...@gmail.com) wrote:
> So let me try to explain what I understood from above:
>
> 1. enable_alter_system a new GUC whose default value =off.
> 2. Alter System will check this variable and return error (not
> allowed), if this parameter is off.
> 3. Now if user enables inc
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost escribió:
> > With includedir and include directives, and postgresql.conf setting a
> > defined ordering, with last-wins, you could simply have the 'includedir'
> > for conf.d come before the 'in
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> With this design, if you put enable_alter_system=off in auto.conf, there
> is no way for the user to enable alter system again short of editing a
> file in the data directory. I think this is one of the things that was
> "forbidden" by policy; o
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost escribió:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > > Stephen Frost escribió:
> > > > With includedir and include directives, and postgresql.conf setting a
> > > > defined
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> >> The conf.d/ path would be relative to postgresql.conf, so there's no
> >> need for Debian to patch anything.
>
> > Uhhh, I really d
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost escribió:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > > Stephen Frost escribió:
>
> > > > I'd much rather have an includedir directive than some hard-coded or
> > > >
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Well, all the relative paths in include/includedir directives would be
> relative to the directory specified by the -c config_file param, which
> makes perfect sense. So the conf.d would work fine in your example.
Why would include/includedir d
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost escribió:
> > Of course, the current situation is quite terrible anyway, imv. Having
> > the GUCs be relative to whereever the user happens to run pg_ctl from is
> > pretty ugly- not to mention that the co
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost escribió:
> > http://www.postgresql.org/docs/9.3/static/runtime-config-file-locations.html
>
> That's talking about the data_directory and the various foo_file
> settings, though; it doesn't apply to th
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2013-08-20 17:24:18 -0400, Tom Lane wrote:
> > In a thread over in pgsql-performance, Tomas Vondra pointed out that
> > choose_hashed_distinct was sometimes making different choices than
> > choose_hashed_grouping, so that queries like these:
> >
Martijn,
* Martijn van Oosterhout (klep...@svana.org) wrote:
> ISTM you want some kind of hybrid setting like:
>
> #include_system auto.conf
>
> which simultaneously does three things:
>
> 1. Sets the enable_alter_system flag
> 2. Indicates the file to use
> 3. Indicates the priority of the set
* Amit Kapila (amit.kapil...@gmail.com) wrote:
>This can resolve the problem of whether to read auto file rather
> cleanly, so the idea is:
>
> Enable/Disable reading of auto file
> -
> a. Have a new include in postresql.conf
> #include_a
* Amit Kapila (amit.kapil...@gmail.com) wrote:
> On Thu, Aug 22, 2013 at 6:06 PM, Stephen Frost wrote:
> > * Amit Kapila (amit.kapil...@gmail.com) wrote:
> >> Enable/Disable reading of auto file
> >> -
&g
Martijn,
* Martijn van Oosterhout (klep...@svana.org) wrote:
> Note, my whole purpose for suggesting something like:
>
> include_auto_conf_filepostgresql.auto.conf
>
> is because I want the file location to be configurable. If I put in my
> configuration:
>
> include_auto_conf_file/etc/
* Bruce Momjian (br...@momjian.us) wrote:
> On Tue, Aug 27, 2013 at 09:04:00AM +0530, Amit Kapila wrote:
> > > I really hate the idea that someone could configure 'X' in
> > > postgresql.conf and because the auto.conf line is later in the file,
> > > it's able to override the original setting. Doe
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > While I appreciate that there are bootstrap-type issues with this, I
> > really don't like this idea of "later stuff can just override earlier
> > stuff".
>
> > include files and con
* Bruce Momjian (br...@momjian.us) wrote:
> Agreed, but I think this is a much larger issue than ALTER SYSTEM SET.
Yeah, true.
> I think changing behavior to first-seen would only add to confusion.
> What we really need is a WARNING when a later postgresql.conf setting
> overrides an earlier one
* Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
> Although I didn't touch this task by myself, my senior colleague said that we
> calculated some possible bandwidth of leakage as an evident when we ship
> supercomputer system with MAC feature for customer who worry about security.
> I'm not sure how to
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> The sorts of watered-down half-features being proposed here are not
> going to do anything to address that situation. If there are
> restrictions on what GUCs can be changed with this feature, or if the
> feature is disabled by default, or if
On Thursday, August 29, 2013, Andres Freund wrote:
> On 2013-08-29 15:07:35 -0400, Robert Haas wrote:
> > I don't really see a compelling reason why it can't or shouldn't be in
> > core. But having something better in contrib would still be an
> > improvement on the status quo.
>
> I don't see mu
On Thursday, August 29, 2013, Andres Freund wrote:
>
> To quote Robert two mails up:
>
> > Huh? The problem with adminpack is that it doesn't let you modify
> > individual configuration settings. All you can do is rewrite an
> > entire file.
That's clearly fixable.
> I guess somebody could wri
Robert,
Was working on replying to this, but got distracted..
* Robert Haas (robertmh...@gmail.com) wrote:
> To be honest, I think the argument that this is dangerous is pretty
> ridiculous. AFAICS, the only argument anyone's advanced for this
> being dangerous is the theory that you might accid
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Aug 29, 2013 at 8:07 PM, Stephen Frost wrote:
> > I'm not talking about malicious DBAs but rather a generally
> > knowledgable DBA who changed shared_buffers up too high and then leaves on
> > vacation, while
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Stephen Frost writes:
> > The OPs people are the ones that will be upset with this because the DBAs
> > will be modifying configs which OPs rightfully claim as theirs.
>
> If that's the problem you want to solve, the
* Cédric Villemain (ced...@2ndquadrant.com) wrote:
> ALTER ROLE ALL may be good enougth to handle every GUC that we can also
> remove
> from postgresql.conf (I suppose all GUC needing only a reload, not a
> restart).
> It may needs some improvement to handle changing default for ALL and adding
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2013-08-30 10:20:48 +0200, Cédric Villemain wrote:
> > Grammar can be added later when the feature is stable.
>
> Could you explain the advantages of this? It will require users to get
> used to different interfaces and we will end up maintainin
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2013-08-30 08:48:21 -0400, Stephen Frost wrote:
> > I really just don't buy that- I've already put forward suggestions for
> > how to deal with it, but no one here seems to understand the
> > distinction. Mod
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2013-08-29 21:26:48 -0400, Stephen Frost wrote:
> > It's not the OPs guy that I'm worried about using ALTER SYSTEM- I don't
> > expect them to have any clue about it or care about it, except where it
> > can
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2013-08-30 09:19:42 -0400, Stephen Frost wrote:
> > wal_level and shared_buffers I can buy, but listen_addresses? The most
> > typical change there is going from localhost -> '*', but you've got to
> > b
* Robert Haas (robertmh...@gmail.com) wrote:
> there's a fairly generous but fixed-at-startup-time limit on how many
> segments you can have. In practice I don't think this matters much,
> but it was a sobering reminder that the main shared memory segment,
> with all of its inflexibility, has impo
* Andres Freund (and...@2ndquadrant.com) wrote:
> Technically trivial in the sense that it should be queryable from SQL
> without having to write code in an untrusted PL ;).
hah.
> I guess storing the file modification date along the file/location a GUC
> is originating from would be good enough.
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Aug 30, 2013 at 8:53 AM, Stephen Frost wrote:
> > Yes, one of the issues with the existing system is that you can't
> > specify a default to be applied to new roles. Also, there are
> > parameters which are not per-
happy users of this will
outweigh the complaints. I suppose there's only one way to find out.
Thanks!
Stephen
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> I think you
* Robert Haas (robertmh...@gmail.com) wrote:
> I think you're getting way too hung up on the fact that the proposed
> auto.conf will be stored as a flat file. From your comments upthread,
> I gather that you'd be rejoicing if it were a table.
I'd be happy if it was a table which managed an *ind
Josh,
* Josh Berkus (j...@agliodbs.com) wrote:
> On 08/30/2013 03:05 AM, Kohei KaiGai wrote:
> > Security community considers covert channel is a hard to solve problem;
> > nearly impossible to eliminate.
While impossible to eliminate, we should certainly consider cases like
this where we can do
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > We have issues with covert channels even without RLS though and holding
> > up RLS because it doesn't fix all the covert channels isn't sensible.
>
> I think it's entirely sensible to qu
KaiGai,
* Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
> The point we shouldn't forget is information leakage via covert-channel
> has less grade of threat than leakage via main-channel, because of
> much less bandwidth.
While true, this argument can't be used to simply ignore any and all
covert cha
* Stefan Kaltenbrunner (ste...@kaltenbrunner.cc) wrote:
> On 08/18/2013 05:40 PM, Tom Lane wrote:
> > Stefan Kaltenbrunner writes:
> >> While working on upgrading the database of the search system on
> >> postgresql.org to 9.2 I noticed that the dumps that pg_dump generates on
> >> that system are
Josh,
* Josh Berkus (j...@agliodbs.com) wrote:
> That's an astonishingly weak argument, because the bandwidth you're
> talking about is still very high, as in *hundreds* or *thousands* of
> values per minute.
I agree that, in this specific case, we should do something about it.
> It's one thin
* Peter Geoghegan (p...@heroku.com) wrote:
> I wonder, is anyone really running in production with full_page_writes
> off?
The simple answer to this is "yes, definitely."
I don't know if they change it on-the-fly, but I doubt it.
Thanks,
Stephen
signature.asc
Descript
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> So I think a more reasonable fix is just to skip the ProcessGUCArray
> call altogether when check_function_bodies = false, and to document
> that validators mustn't assume anything about the GUC environment
> when check_function_bodies = false.
>
> If no ob
Satoshi,
* Satoshi Nagayasu (sn...@uptime.jp) wrote:
> (2013/09/04 13:07), Alvaro Herrera wrote:
> >We already changed it:
> >
> > commit 187492b6c2e8cafc5b39063ca3b67846e8155d24
> > Author: Alvaro Herrera
> > Date: Mon Feb 18 17:56:08 2013 -0300
> >
> > Split pgstat file in smaller pieces
* Andres Freund (and...@2ndquadrant.com) wrote:
> I'd vote for adding zeroing *after* the fallocate() first. That's what's
> suggested by kernel hackers and what several other large applications
> do. As it looks like it's what we would have to do if we ever get to use
> fallocate for relation exte
* Robert Haas (robertmh...@gmail.com) wrote:
> On Sun, Sep 1, 2013 at 11:47 PM, Greg Smith wrote:
> > And if someone can INSERT values that they can't actually see once they're
> > committed, that's a similarly bad we should describe.
>
> This is desirable in some cases but not others. If the go
Vesa-Matti, Heikki,
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
> On 09.09.2013 15:36, Vesa-Matti J Kari wrote:
> >If I interpret this correctly, threads #2 and #3 are waiting for the same
> >lock but they make no progress.
>
> A-ha, the deadlock happens while doing SSL stuff. I didn't
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Heikki Linnakangas wrote:
> > I'll dig into that, but right now it seems like an OpenSSL or
> > libcrypto bug to me. Or something in the way we use them, although I
> > can't see anything obviously wrong in the libpq code at a quick
> >
* Robert Haas (robertmh...@gmail.com) wrote:
> But, I guess I'm not yet convinced that one-for-one substitution of
> nodes is impossible even with something about this simple.
Couldn't that be done with hooks in those specific plan nodes, or
similar..? Of course, as Tom points out, that wouldn'
Heikki,
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
> Thanks! I tested with git master.
I've run your test program against both git master and 9.2.4 on a couple
of Ubuntu 13.04 boxes and all I see are tons of these:
1: DEBUG: database connection established
1: DEBUG: about to call PQfi
Heikki,
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
> Hmm. Are you sure you're getting an SSL connection? Run it with
> something like this to make sure:
sslmode=require doesn't help on Unix domain connections. :)
Was able to get it to lock with both 9.2.4 and master, and with both
ver
* Noah Misch (n...@leadboat.com) wrote:
> On Tue, Sep 10, 2013 at 07:13:16PM -0700, David Johnston wrote:
> > Your feelings on how far to back-patch?
>
> All supported versions. The current behavior is a bug every way I look at it.
Agreed. I noticed a stale backend hanging around after a
cancel
* Noah Misch (n...@leadboat.com) wrote:
> Shouldn't it instead check the same things as PGSharedMemoryIsInUse()?
Offhand, I tend to agree that we should really be doing a very careful
job of looking at if an existing segment is still in use.
> The concrete situation in which I encountered this in
* Andrew Dunstan (and...@dunslane.net) wrote:
> You forgot to mention that we'd actually like to get away from being
> tied closely to OpenSSL because it has caused license grief in the
> past (not to mention that it's fairly dirty to manage).
While I agree with this sentiment (and have complained
Heikki, all,
* Stephen Frost (sfr...@snowman.net) wrote:
> Very curious. Out of time right now to look into it, but will probably
> be back at it later tonight.
Alright, I was back at this a bit today and decided to go with a hunch-
and it looks like I might have been right to try.
Leavi
Andres,
On Friday, September 13, 2013, Andres Freund wrote:
>
> It'd be interesting to replace the origin callbacks with one immediately
> doing an abort() or similar to see whether they maybe are called after
> they shouldn't be and from where.
>
Good thought. Got sucked into a meeting but once
* Stephen Frost (sfr...@snowman.net) wrote:
> * Andres Freund (and...@2ndquadrant.com) wrote:
> > Hm. close_SSL() first does pqsecure_destroy() which will unset the
> > callbacks, and the count and then goes on to do X509_free() and
> > ENGINE_finish(), ENGINE_fre
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2013-09-13 13:15:34 -0400, Stephen Frost wrote:
> > Good thought. Got sucked into a meeting but once I'm out I'll try having
> > the lock/unlock routines abort if they're called while ssl_open_connections
&g
* Peter Geoghegan (p...@heroku.com) wrote:
> I would suggest letting those other individuals speak for themselves
> too. Particularly if you're going to name someone who is on vacation
> like that.
It was my first concern regarding this patch.
Thanks,
Stephen
signature.
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
> Umm, with that patch, pqsecure_destroy() is never called. The "if
> (conn->ssl)" test that's now at the end of the close_SSL function is
> never true, because conn->ssl is set to NULL earlier.
Yeah, got ahead of myself, as Andres pointed out.
* Andres Freund (and...@2ndquadrant.com) wrote:
> It seems slightly cleaner to just move the pqsecure_destroy(); to the
> end of that function, based on a boolean. But if you think otherwise, I
> won't protest...
Hmm, agreed; I had originally been concerned that the SIGPIPE madness
needed to be ar
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
> Actually, I think there's a pre-existing bug there in git master. If
> the SSL_set_app_data or SSL_set_fd call in pqsecure_open_client
> fails for some reason, it will call close_SSL() with conn->ssl
> already set, and the mutex held. close_SS
* Andres Freund (and...@2ndquadrant.com) wrote:
> That patch looks wrong to me. Note that the if (conn->ssl) branch resets
> conn->ssl to NULL.
huh, it figures one would overlook the simplest things. Of course it's
not locking up now- we never remove the hooks (as my original patch was
doing :).
* Robert Haas (robertmh...@gmail.com) wrote:
> Therefore, I see no harm in
> having an operator that tests for
> are-these-values-identical-for-all-purposes. If that's useful for
> RMVC, then there may be other legitimate uses for it as well.
>
> And once we decide that's OK, I think we ought to
* Kevin Grittner (kgri...@ymail.com) wrote:
> Right. Not only would the per-type solution make materialized views
> maintenance broken by default, requiring per-type work to make it
> work reasonably, with silent failures for any type you didn't know
> about, but "no user-visible differences" is a
* Andres Freund (and...@2ndquadrant.com) wrote:
> I think this really needs to have an obscure name. Like ==!!== or
> somesuch (is equal very much, but doesn't actually test for equality ;))
hah.
> > What the heck is the use case for this being a user-oriented, SQL
> > operator..?
>
> The matera
* Merlin Moncure (mmonc...@gmail.com) wrote:
> Having matviews using SQL expressible features is a *good* thing.
Fine, then it should be implemented *using SQL*, which is based on
*values*, not on how the value is represented in bits and bytes.
> Having a user accessible operator is nice to have
* Kevin Grittner (kgri...@ymail.com) wrote:
> = and <> aren't listed above even though they do a byte-for-byte
> comparison because, well, I guess because we have chosen to treat
> two UTF8 strings which produce the same set of glyphs using
> different bytes as unequal. :-/
I tend to side with An
* Steve Singer (st...@ssinger.info) wrote:
> The problem is that there are datatypes (citext, postgis,...) that
> have defined = to return true when comparing two values that are
> different not just stored differently.
If the definition of the type is that they're equal, then they're equal.
Certa
Kevin,
On Wednesday, September 18, 2013, Kevin Grittner wrote:
> Stephen Frost > wrote:
>
> > If it's not actually *changing* (wrt its value), then I'm not at
> > all impressed with the notion that it's going to get updated
> > anyway.
>
> But P
* Kevin Grittner (kgri...@ymail.com) wrote:
> ... like
> just refreshing a view so that the new contents are the same as
> what you would see if you re-ran the query defining the matview.
I've heard this notion a few times of wanting to make sure that what you
get from running the query matches th
Steve,
Thanks for providing a summary.
* Steve Singer (st...@ssinger.info) wrote:
> The arguments for this patch are
> * We want the materialized view to return the same value as would be
> returned if the query were executed directly. This not only means
> that the values should be the same a
On Friday, September 20, 2013, Kevin Grittner wrote:
> Stephen Frost > wrote:
>
> > The issue here is that we're trying to make the mat view look
> > like what the query would do when run at the same time, which is
> > a bit of a losing battle, imv.
>
> If
* Kevin Grittner (kgri...@ymail.com) wrote:
> The result of this is that with the patch, an incremental refresh
> of a matview will always match what the query returned at the time
> it was run (there is no *correctness* problem) but if someone uses
> a query with non-deterministic results they may
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2013-09-20 10:51:46 -0400, Stephen Frost wrote:
> > I'm trying to figure out why that's a perfectly acceptable solution for
> > users running views with GROUP BYs, but apparently it isn't sufficient
> > fo
* Kevin Grittner (kgri...@ymail.com) wrote:
> Stephen Frost wrote:
> > You mean 'at the time of the incremental refresh', right? Yet that may
> > or may not match running that query directly by an end-user as the plan
> > that a user might get for the entire que
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2013-09-20 11:05:06 -0400, Stephen Frost wrote:
> > Sure; my thinking was going back to what Hannu had suggested where we
> > have a mechanism to see if the value was updated (using xmin or similar)
> > and then update it in
Josh,
* Josh Berkus (j...@agliodbs.com) wrote:
> I've been tinkering with a number of table bloat checks, and it occurred
> to me that the problm is that these are all approximations based on
> overall gross statistics, and as such highly inaccurate.
Greg Smith and I discussed some improvements a
* Josh Berkus (j...@agliodbs.com) wrote:
> Also, live vs. dead tuples doesn't tell me how much free *space* is
> available on pages.
I'm not really sure that you'd get much better from ANALYZE than you get
from tracking the inserted/updated/deleted tuples. Collecting that
information when VACUUM
Peter,
* Peter Geoghegan (p...@heroku.com) wrote:
> Forgive me if I'm making a leap here, but it seems like what you're
> saying is that the semantics of upsert that one might naturally expect
> are *arguably* fundamentally impossible, because they entail
> potentially locking a row that isn't cur
Vesa-Matti J Kari,
I've now committed a fix for this issue. If you have opportunity to,
it'd be great to pull down the latest git (for whichever supported
branch you'd like) and give it a try. Otherwise, the fix should be
out with our next round of point releases (which I expect will be
* Robert Haas (robertmh...@gmail.com) wrote:
> It seems odd to me that you have such strong opinions about what is
> and is not acceptable here given that you don't seem to familiar with
> the current state of this work.
That'd be because the arguments that I've been trying to make around
this h
* Kevin Grittner (kgri...@ymail.com) wrote:
> Unless we can tell whether there are any differences between two
> versions of a row, we can't accurately generate the delta to drive
> the incremental maintenance.
This is predicated on the assumption that you simply generate the new
view and then try
901 - 1000 of 4446 matches
Mail list logo
