Re: [HACKERS] psql: bogus descriptions displayed by \d+

2011-08-04 Thread Jeff Davis
really relations or relation variables (for instance, they can contain duplicates). Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Reduce WAL logging of INSERT SELECT

2011-08-04 Thread Jeff Davis
during the load. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] lazy vxid locks, v3

2011-08-01 Thread Jeff Davis
. Is it just a guard against calling VirtualXactLockTableCleanup twice? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] lazy vxid locks, v3

2011-07-31 Thread Jeff Davis
)) Is the LocalTransactionIdIsValid(lxid) a guard against calling VirtualXactLockTableCleanup twice? Can that happen? Or is it just defensive coding to avoid making an additional assumption? Regards, Jeff Davis PS: In the recent sinval synch patch, you had a typo: If we haven't catch up completely

Re: [HACKERS] SSI heap_insert and page-level predicate locks

2011-07-31 Thread Jeff Davis
. The index insert will check for any other predicate locks. would be a little more clear? (the last sentence is optional, and I only included it because the original comment mentioned indexes). Same for heap_update(). Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] cheaper snapshots

2011-07-28 Thread Jeff Davis
exist if one transaction is waiting for sync rep (synchronous_commit=on), and another is waiting for just a WAL flush (synchronous_commit=local)? I don't think that a synchronous_commit=off is required. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Deferred partial/expression unique constraints

2011-07-25 Thread Jeff Davis
, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] range types and ip4r

2011-07-19 Thread Jeff Davis
? If it's just a flat range it would be similar to int4range, I would think. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Commitfest Status: Sudden Death Overtime

2011-07-18 Thread Jeff Davis
: in which case I'd like to fix it up and get it in. Agreed. I certainly like the concept of the lazy vxid patch. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] lazy vxid locks, v2

2011-07-14 Thread Jeff Davis
that they lead somewhere. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [RRR] [HACKERS] Three patches which desperately need reviewers

2011-07-13 Thread Jeff Davis
will be tomorrow. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] reducing the overhead of frequent table locks, v4

2011-07-12 Thread Jeff Davis
. I was slightly bothered because it seemed a little unpredictable. But it seems very minor, and if we wanted to fix it later I think we could. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] reducing the overhead of frequent table locks, v4

2011-07-12 Thread Jeff Davis
On Tue, 2011-07-12 at 13:32 -0500, Robert Haas wrote: On Jul 12, 2011, at 12:02 PM, Jeff Davis pg...@j-davis.com wrote: Yeah, I think you're right here. It's probably not much of a practical concern. I was slightly bothered because it seemed a little unpredictable. But it seems very

Re: [HACKERS] reducing the overhead of frequent table locks, v4

2011-07-11 Thread Jeff Davis
? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Extra check in 9.0 exclusion constraint unintended consequences

2011-07-10 Thread Jeff Davis
enough that we don't want it to be another thing to keep track of. I don't really have a strong opinion here. People might hit in in 9.0, but there's a workaround. And they won't hit it in 9.1+. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

Re: [HACKERS] reducing the overhead of frequent table locks, v4

2011-07-10 Thread Jeff Davis
completely? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] reducing the overhead of frequent table locks, v4

2011-07-10 Thread Jeff Davis
the every should be acquire every. 3. Typo in comment in lock.c: last because most should be last because it's the most. (I just realized that's actually not your typo, so fixing it is optional). Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] [GENERAL] Creating temp tables inside read only transactions

2011-07-09 Thread Jeff Davis
out which ones should be local and which ones should be fully-qualified. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [GENERAL] Creating temp tables inside read only transactions

2011-07-09 Thread Jeff Davis
of different projects*. Regards, Jeff Davis * That being said, PostgreSQL's type system is actually very good. Consider the sophisticated type infrastructure (or at least plumbing around the type system) required to make KNN-GiST work, for instance. -- Sent via pgsql-hackers mailing

Re: [HACKERS] [GENERAL] Creating temp tables inside read only transactions

2011-07-09 Thread Jeff Davis
likely. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Extra check in 9.0 exclusion constraint unintended consequences

2011-07-09 Thread Jeff Davis
On Fri, 2011-07-08 at 22:51 -0400, Robert Haas wrote: I'm wondering if we might want to call this out with a note or similar... especially if we're only going to put it into the 9.0 docs. Sure, sounds good. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] [GENERAL] Creating temp tables inside read only transactions

2011-07-08 Thread Jeff Davis
to their attach. I'm not sure SQLite is the best example. It has a radically different architecture. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Extra check in 9.0 exclusion constraint unintended consequences

2011-07-07 Thread Jeff Davis
have suspected at the outset. Doc patch attached, but I'm not attached to the wording. Remember that we only need to update the 9.0 docs, I don't think you want to apply this to master (though I'm not sure how this kind of thing is normally handled). Regards, Jeff Davis excl-oper

Re: [HACKERS] [GENERAL] Creating temp tables inside read only transactions

2011-07-07 Thread Jeff Davis
bootstrapping challenges. Are there any plans in the works to do this? I don't think so. It sounds like some fairly major work for a comparatively minor benefit. Suggestions welcome, of course, to either make the work look more minor or the benefits look more major ;) Regards, Jeff Davis

Re: [HACKERS] Range Types, constructors, and the type system

2011-07-06 Thread Jeff Davis
option, but what if someone actually specified that 4th argument? We couldn't allow that. Also, are default arguments always applied in all the contexts where this function might be called? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Range Types, constructors, and the type system

2011-07-06 Thread Jeff Davis
On Wed, 2011-07-06 at 12:51 -0400, Robert Haas wrote: On Wed, Jul 6, 2011 at 12:22 PM, Jeff Davis pg...@j-davis.com wrote: To get into some more details: how exactly would this constructor be generated on the fly? Clearly we want only one underlying C function that accepts something like

Re: [HACKERS] reducing the overhead of frequent table locks, v4

2011-07-06 Thread Jeff Davis
rather than a centralized lock, thus still avoiding lock contention in the common (weak locks only) case. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Old postgresql repository

2011-07-06 Thread Jeff Davis
by now, I think. That's OK with me. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Range Types, constructors, and the type system

2011-07-06 Thread Jeff Davis
, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Range Types, constructors, and the type system

2011-07-05 Thread Jeff Davis
, so that has more of a precedent. I'm not really sure how much that matters. I'm OK with the intermediate type, but Florian seems skeptical of that idea. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

[HACKERS] Extra check in 9.0 exclusion constraint unintended consequences

2011-07-05 Thread Jeff Davis
in the documentation. Thoughts? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Range Types, constructors, and the type system

2011-07-05 Thread Jeff Davis
, but we'll need to come up with a pretty exhaustive list of possibly-useful constructors. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Range Types, constructors, and the type system

2011-07-05 Thread Jeff Davis
On Tue, 2011-07-05 at 13:06 -0400, Robert Haas wrote: On Tue, Jul 5, 2011 at 12:54 PM, Jeff Davis pg...@j-davis.com wrote: It would be something like: range_co(1,8)::int8range (just so we're comparing apples to apples) The intermediate type proposal doesn't require that we move the c

Re: [HACKERS] Range Types, constructors, and the type system

2011-07-01 Thread Jeff Davis
On Thu, 2011-06-30 at 09:59 -0700, David E. Wheeler wrote: On Jun 30, 2011, at 9:34 AM, Jeff Davis wrote: Then how do you get a text range that doesn't correspond to the LC_COLLATE setting? You cast it. My original solution was something like this, except involving domains

Re: [HACKERS] Range Types, constructors, and the type system

2011-07-01 Thread Jeff Davis
this is reasonable. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Range Types, constructors, and the type system

2011-06-30 Thread Jeff Davis
to document. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Range Types, constructors, and the type system

2011-06-30 Thread Jeff Davis
with a different collation? That would be very strange. Or, what about other types that just happen to have multiple useful total orders? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Range Types, constructors, and the type system

2011-06-30 Thread Jeff Davis
to be a little more sure that such values can't persist anywhere. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [COMMITTERS] pgsql: Make the visibility map crash-safe.

2011-06-30 Thread Jeff Davis
On Thu, 2011-06-30 at 07:50 -0400, Robert Haas wrote: I compare the performance of commit 431ab0e82819b31fcd1e33ecb52c2cd3b4b41da7 (post-patch) with commit 431ab0e82819b31fcd1e33ecb52c2cd3b4b41da7 (pre-patch). I believe that is a copy/paste error. Regards, Jeff Davis -- Sent via

Re: [HACKERS] Range Types, constructors, and the type system

2011-06-30 Thread Jeff Davis
On Thu, 2011-06-30 at 09:58 -0700, David E. Wheeler wrote: On Jun 30, 2011, at 9:29 AM, Jeff Davis wrote: Right. In that respect, it's more like a record type: many possible record types exist, but you only define the ones you want. Well, okay. How is this same problem handled for RECORD

Re: [HACKERS] Range Types, constructors, and the type system

2011-06-29 Thread Jeff Davis
throw exceptions handle them? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Range Types, constructors, and the type system

2011-06-29 Thread Jeff Davis
On Wed, 2011-06-29 at 08:52 -0400, Robert Haas wrote: On Tue, Jun 28, 2011 at 11:02 PM, Jeff Davis pg...@j-davis.com wrote: It's still not out of the question, but I thought that the intermediate type would be a less-intrusive alternative (and Robert seemed concerned about how intrusive

Re: [HACKERS] Range Types, constructors, and the type system

2011-06-28 Thread Jeff Davis
On Tue, 2011-06-28 at 10:58 -0400, Robert Haas wrote: On Mon, Jun 27, 2011 at 11:42 PM, Jeff Davis pg...@j-davis.com wrote: So, in effect, RANGEINPUT is a special type used only for range constructors. If someone tried to output it, it would throw an exception, and we'd even have enough

Re: [HACKERS] Range Types, constructors, and the type system

2011-06-28 Thread Jeff Davis
On Tue, 2011-06-28 at 09:30 -0700, David E. Wheeler wrote: On Jun 27, 2011, at 8:42 PM, Jeff Davis wrote: Do we think that this is a good way forward? The only thing I can think of that's undesirable is that it's not normal to be required to cast the result of a function, and might

Re: [HACKERS] Range Types, constructors, and the type system

2011-06-28 Thread Jeff Davis
to get it to pick the right function. If it were a new syntax like RANGE[]::int8range, then I think it would be easier to understand. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [HACKERS] Range Types and length function

2011-06-27 Thread Jeff Davis
for that. If users write upper(r)-lower(r), then they know what the semantics will be; or they can easily write their own length() function (perhaps specific to a range type). Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Range Types, constructors, and the type system

2011-06-27 Thread Jeff Davis
should be written anyway. OK, I'll have to think about this a little more, but it seems like a reasonable approach. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql

Re: [HACKERS] Range Types, constructors, and the type system

2011-06-27 Thread Jeff Davis
you are suggesting and a default ordering for the type (which we already support)? I suppose it's hard to tell what you mean by native. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Range Types, constructors, and the type system

2011-06-27 Thread Jeff Davis
way forward? The only thing I can think of that's undesirable is that it's not normal to be required to cast the result of a function, and might be slightly difficult to explain in the documentation in a straightforward way. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list

[HACKERS] Range Types and length function

2011-06-26 Thread Jeff Davis
idea. The length() function is obviously an important function to provide. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Range Types, constructors, and the type system

2011-06-26 Thread Jeff Davis
annotations are un-SQL-like. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Range Types and length function

2011-06-26 Thread Jeff Davis
On Sun, 2011-06-26 at 13:45 +0100, Greg Stark wrote: On Sun, Jun 26, 2011 at 8:18 AM, Jeff Davis pg...@j-davis.com wrote: * it needs to know the result type of that function, which might not be the subtype (for instance, for timestamp the difference type would be interval) What's

Re: [HACKERS] Range Types, constructors, and the type system

2011-06-26 Thread Jeff Davis
: range(lower(range(1,2)),upper(range(1,2)))::int8range but maybe that can be done more easily than I think? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Range Types and length function

2011-06-26 Thread Jeff Davis
leave length() as some inlinable SQL functions like I mentioned, or perhaps I should remove them completely. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] heap_hot_search_buffer refactoring

2011-06-25 Thread Jeff Davis
be visible according to the (non-MVCC) snapshot, correct? It might help if that was apparent from the code/comments. Other than that, it looks good. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

[HACKERS] Range Types, constructors, and the type system

2011-06-25 Thread Jeff Davis
range values? That was kicked around briefly, but perhaps we should revisit the possibilities there. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] crash-safe visibility map, take five

2011-06-24 Thread Jeff Davis
flushed and we don't. Just having this discussion has been good enough for me to get a better idea what's going on, so if you think the comments are sufficient that's OK with me. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] crash-safe visibility map, take five

2011-06-23 Thread Jeff Davis
is on, then LSN Z would be flushed before step 3; but that's another set of assumptions. That's why I left it simple and said that the assumption was snapshots are released if there's a crash. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] crash-safe visibility map, take five

2011-06-22 Thread Jeff Davis
explaining why that is safe with respect to the WAL-before-data rule. Obviously torn pages aren't much of a problem, because it's a single bit and completely idempotent. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] crash-safe visibility map, take five

2011-06-22 Thread Jeff Davis
On Wed, 2011-06-22 at 21:53 -0400, Robert Haas wrote: On Wed, Jun 22, 2011 at 8:53 PM, Jeff Davis pg...@j-davis.com wrote: On Thu, 2011-06-16 at 23:17 -0400, Noah Misch wrote: 2. In the words of a comment added by the patch: * The critical integrity requirement here is that we must never

Re: [HACKERS] Range Types and extensions

2011-06-21 Thread Jeff Davis
, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Range Types and extensions

2011-06-21 Thread Jeff Davis
, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Range Types and extensions

2011-06-20 Thread Jeff Davis
type annotations. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Range Types and extensions

2011-06-20 Thread Jeff Davis
interesting idea. A little awkward though, and doesn't offer much opportunity to specify inclusivity/exclusivity of the bounds. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

Re: [HACKERS] heap_hot_search_buffer refactoring

2011-06-19 Thread Jeff Davis
On Mon, 2011-06-06 at 14:03 -0400, Robert Haas wrote: The attached patch refactors heap_hot_search_buffer() so that index_getnext() can use it, and modifies index_getnext() to do so. Attached is a version of the patch that applies cleanly to master. Regards, Jeff Davis heap-hot

Re: [HACKERS] heap_hot_search_buffer refactoring

2011-06-19 Thread Jeff Davis
On Sun, 2011-06-19 at 10:50 -0700, Jeff Davis wrote: On Mon, 2011-06-06 at 14:03 -0400, Robert Haas wrote: The attached patch refactors heap_hot_search_buffer() so that index_getnext() can use it, and modifies index_getnext() to do so. Attached is a version of the patch that applies

Re: [HACKERS] Range Types and extensions

2011-06-19 Thread Jeff Davis
which total order the range type adheres to. If you meant that the collation shouldn't be stored along with the value itself, then I agree. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Range Types and extensions

2011-06-18 Thread Jeff Davis
a typecast) should offer the opportunity to handle cases like this with a function call, but changing collation does not. This leaves making the collation a part of the range type itself (as Robert suggested). Comments? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] Range Types and extensions

2011-06-18 Thread Jeff Davis
the COLLATE clause I think. I think rejecting it makes more sense, so a range would not be a collatable type; it just happens to use collations of the subtype internally. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Range Types and extensions

2011-06-08 Thread Jeff Davis
On Tue, 2011-06-07 at 10:20 -0700, Jeff Davis wrote: BTW, Jeff, have you worked out the implications of collations for textual range types? Well, it seems to work is about as far as I've gotten. As far as the implications, I'll need to do a little more research and thinking. But I don't

Re: [HACKERS] Range Types and extensions

2011-06-07 Thread Jeff Davis
need to do a little more research and thinking. But I don't immediately see anything too worrisome. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Range Types and extensions

2011-06-07 Thread Jeff Davis
. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Range Types and extensions

2011-06-06 Thread Jeff Davis
On Mon, 2011-06-06 at 06:56 +0200, Pavel Stehule wrote: 2011/6/6 Darren Duncan dar...@darrenduncan.net: Jeff Davis wrote: I'd like to take another look at Range Types and whether part of it should be an extension. Some of these issues relate to extensions in general, not just range

Re: [HACKERS] Range Types and extensions

2011-06-06 Thread Jeff Davis
On Sun, 2011-06-05 at 21:51 -0700, Darren Duncan wrote: Jeff Davis wrote: I'd like to take another look at Range Types and whether part of it should be an extension. Some of these issues relate to extensions in general, not just range types. First of all, what are the advantages

Re: [HACKERS] Range Types and extensions

2011-06-06 Thread Jeff Davis
documentation and tests. Both of those things can take a significant amount of time to rework, so I think I'll leave it alone until we have more of a consensus. We still have time before 9.2 to break some of the code out into an extension when we do have the doc/test issues resolved. Regards, Jeff

Re: [HACKERS] Range Types and extensions

2011-06-06 Thread Jeff Davis
On Mon, 2011-06-06 at 18:28 +0200, Pavel Stehule wrote: we can define a step FOREACH x IN RANGE . BY That wouldn't need any of the range infrastructure at all -- it would be purely syntactic, right? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Range Types and extensions

2011-06-06 Thread Jeff Davis
, but overall it should be a small amount of code per range. However, I'd say just bundle a bunch of rangetypes together in one extension. There's not really much cost -- if you are using one range type, you'll use a few more. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] Assert failure when rechecking an exclusion constraint

2011-06-05 Thread Jeff Davis
: if it's not in the pending list, what prevents systable_beginscan() from using it? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Range Types and extensions

2011-06-05 Thread Jeff Davis
constructors and accessors. That would at least make it easier to test, but then to be actually useful (with index support, operators, fancy functions, etc.) you'd need the extension. Thoughts? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Assert failure when rechecking an exclusion constraint

2011-06-05 Thread Jeff Davis
On Sun, 2011-06-05 at 15:09 -0400, Tom Lane wrote: so once we've set the index as the currentlyReindexedIndex, there's no need for it still to be in pendingReindexedIndexes. OK. The second version of the patch looks good to me. Regards, Jeff Davis -- Sent via pgsql-hackers mailing

Re: [HACKERS] storing TZ along timestamps

2011-06-02 Thread Jeff Davis
or GMT out of it. So you can answer queries such as which of these activities occurred outside of normal business hours as well as which of these events happened first. It would take a little care to use properly, however. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] storing TZ along timestamps

2011-06-02 Thread Jeff Davis
= mean equivalent after timezone adjustment. If we're making a distinction between 2000-01-01 10:00:00 +03 and 2000-01-01 9:00:00 +02, then = should not obscure that distinction. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] storing TZ along timestamps

2011-06-02 Thread Jeff Davis
the timezone definition as of the real time the value was entered? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] storing TZ along timestamps

2011-06-01 Thread Jeff Davis
On Fri, 2011-05-27 at 16:43 -0400, Alvaro Herrera wrote: Hi, One of our customers is interested in being able to store original timezone along with a certain timestamp. I assume that you're talking about a new data type, not augmenting the current types, correct? Regards, Jeff Davis

Re: [HACKERS] tackling full page writes

2011-05-24 Thread Jeff Davis
, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] What was the exact version of PostgreSQL where the column name length changed from 31 to 63 characters?

2011-04-26 Thread Jeff Davis
name, function name, etc.) are similarly affected. Is that correct? It was changed in this commit: http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=46bb23ac016714065711cf2a780e080c7310d66e which was first released in 7.3.0, as far as I can tell. Regards, Jeff Davis

Re: [HACKERS] Patch for pg_upgrade to turn off autovacuum

2011-04-22 Thread Jeff Davis
, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Patch for pg_upgrade to turn off autovacuum

2011-04-21 Thread Jeff Davis
. However, can you get the information directly from the bianry, rather than trying to infer it from the catalog version? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql

Re: [HACKERS] pg_upgrade bug found!

2011-04-08 Thread Jeff Davis
, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_upgrade bug found!

2011-04-08 Thread Jeff Davis
VACUUM FREEZE doing extra work. I suppose you could set the vacuum_freeze_min_age to be exactly the right value such that it freezes everything before the existing (and wrong) relfrozenxid, but in practice I think it would be the same amount of work. Regards, Jeff Davis -- Sent via pgsql

Re: [HACKERS] pg_upgrade bug found!

2011-04-08 Thread Jeff Davis
since the upgrade happened. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_upgrade bug found!

2011-04-08 Thread Jeff Davis
be required if you ever used pg_upgrade before. Using the new version of pg_upgrade/dump when you still have a bad relfrozenxid doesn't help. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] pg_upgrade bug found!

2011-04-07 Thread Jeff Davis
database. Well, that won't work, because VACUUM can't be executed in a transaction block or function. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_upgrade bug found!

2011-04-07 Thread Jeff Davis
that it will be too complicated (make sure to read every tuple though, not just the ones currently visible). Stepping back a second to make sure I understand the problem: the only problem is that relfrozenxid on the toast table after an upgrade is wrong. Correct? Regards, Jeff Davis -- Sent

Re: [HACKERS] pg_upgrade bug found!

2011-04-07 Thread Jeff Davis
. It's guaranteed to be the same value you see from the heap or newer; because if it's not visible in the heap, it's not going to be visible in the toast table. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] pg_upgrade bug found!

2011-04-07 Thread Jeff Davis
On Thu, 2011-04-07 at 12:38 -0700, Jeff Davis wrote: Any idea how to correct existing systems? Would VACUUM FREEZE of just the toast tables work? VACUUM FREEZE will never set the relfrozenxid backward. If it was never preserved to begin with, I assume that the existing value could

Re: [HACKERS] pg_upgrade bug found!

2011-04-07 Thread Jeff Davis
VACUUM) would get rid of that xid, or might something still try to look it up in the clog later? Not only that, but hint-bit-setting is not WAL-logged, so you'd really have to do a checkpoint afterward. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

Re: [HACKERS] lowering privs in SECURITY DEFINER function

2011-04-06 Thread Jeff Davis
, with triggers disabled, it's not safe to allow the user to execute arbitrary operations. In other words, if you wrap an unprivileged operation inside of privileged operations, it seems like the unprivileged operation then becomes privileged. Right? Regards, Jeff Davis -- Sent via pgsql-hackers

Re: [HACKERS] trivial patch: show SIREAD pids in pg_locks

2011-04-01 Thread Jeff Davis
or is idle? That might be confusing. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Problem with pg_upgrade?

2011-03-30 Thread Jeff Davis
of hidden GUC might be the best option. I tend to agree that a third option to the autovacuum setting would be confusing. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

<    2   3   4   5   6   7   8   9   10   11   >