application to use it at all, rather than the other
version formats we already provide.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
kip the final increment do it with
"continue", and I think this should do likewise.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Dave Cramer writes:
> Did you ever find a solution to this without updating ?
No. I filed a bug report which Apple seems uninterested in, perhaps
not too surprisingly.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
o
> be available to a non-superuser. We wouldn't be able to change these
> functions to start checking the 'directory' rights or we would break
> existing non-superuser usage of them.
This is a straw man argument --- if we tighten up the function to check
this as-yet-nonexis
Robert Haas writes:
> On Fri, Nov 10, 2017 at 2:24 PM, Tom Lane wrote:
>> Also, I wonder whether the InvalidOid hack in SS_assign_special_param
>> requires commentary. It might be safer to use a valid type OID there,
>> perhaps VOIDOID or INTERNALOID.
> There is exis
in ..."
Also, I wonder whether the InvalidOid hack in SS_assign_special_param
requires commentary. It might be safer to use a valid type OID there,
perhaps VOIDOID or INTERNALOID.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
5(i::text), 1, 1) FROM
generate_series($start,$end) i;"
);
This about halved the runtime of the TAP test, and it changed the coverage
footprint not at all according to lcov. (Said coverage is only marginally
better than what we get without running the bloom TAP test, AFAICT.)
It see
less so as an owner of some
fairly slow buildfarm critters. I'd say that this might be the
reason the TAP test wasn't part of the standard tests to begin with.
Is there anything we can do to cut the runtime of the TAP test to
the point where running it by default wouldn't be s
mpiler *should* allow "char **" to be cast to "const char **"
silently, but that isn't necessarily what happens in the real world.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
the declaration of
LWLockTrancheArray and verify that it's char **, because we trust the
compiler to whine if char ** isn't assignment-compatible with that.
But if we left off the cast and just assigned the function result directly
to the variable, then there would be nothing directly tyin
We could expand that by mentioning the possibility of wrapper functions,
but it seems long enough already.
Comments?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
much like saying that a person
who knows a sudo password might as well do everything they ever do as
root.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Michael Paquier writes:
> On Fri, Nov 10, 2017 at 7:05 AM, Tom Lane wrote:
>> I did miss the need to fix the docs, and am happy to put in some strong
>> wording about the security hazards of these functions while fixing the
>> docs. But I do not think that leaving them wit
port/lo_export), one might reasonably consider the unlocked form as
more risky than the locked form, and hence not wish to have to give out
privileges to both at once.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
ut in some strong
wording about the security hazards of these functions while fixing the
docs. But I do not think that leaving them with hardwired superuser
checks is an improvement over being able to control them with GRANT.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Michael Paquier writes:
> On Thu, Nov 9, 2017 at 6:05 AM, Tom Lane wrote:
>> Another idea would be to invent a new external flag bit "INV_WRITE_ONLY",
>> so that people who wanted true write-only could get it, without breaking
>> backwards-compatible behavior. Bu
when ALTER SYSTEM
>> is issued.
> Interesting... IMHO this typo should be backpatched to 9.4 when ALTER
> SYSTEM was introduced.
Agreed, and done.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
anything silly.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
er);
Yeah, the way it is now seems outright broken. It will try to do
get_bin_version on the new cluster before having done validate_exec
there, violating its own comment.
I think we should change this as a bug fix, independently of whatever
else you had in mind to do here.
Thomas Munro writes:
> On Thu, Nov 9, 2017 at 6:27 PM, Tom Lane wrote:
>> Is there really much interest in Bonjour support on non-macOS platforms?
>> I hadn't heard that anybody but Apple was invested in it.
> Not from me. My only interest here was to pipe up because
ocks). These other
ideas seem a lot riskier.
(But see recent conversation where I discouraged Alvaro from holding
extension locks across BRIN summarization activity. We'll need to look
and make sure that nobody else has had creative ideas like that.)
regards, tom lan
Thomas Munro writes:
> On Thu, Nov 9, 2017 at 5:03 PM, Tom Lane wrote:
>> Is the AC_SEARCH_LIBS configure call needed to make PG build with the
>> FreeBSD package?
> Yes. My take is that the commit was correct: the library is needed
> for --with-bonjour to work on n
Thomas Munro writes:
> On Thu, Nov 9, 2017 at 1:39 PM, Tom Lane wrote:
>> Hm, the library on F25 is also avahi's. Digging in the archives, I find
>> this old thread reporting the same behavior:
>> https://www.postgresql.org/message-id/flat/17824.1252293423%40sss.pgh.p
Luke Lonergan writes:
> On 11/8/17, 3:00 PM, "Tom Lane" wrote:
>> BTW, when I try this on Fedora 25, it builds cleanly but the feature
>> doesn't seem to work --- I get this at postmaster start:
>> ...
>> I wonder which libdns_sd you are using.
> lib
hich libdns_sd you are using.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
out quoting.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
el_workers = 4);
Yup, that's wrong. Fix pushed, thanks!
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[gethostbyname], [nsl])' instead of
`AC_CHECK_LIB([nsl], [gethostbyname])'.
If Luke wants to check that that works for him, I can check it on
macOS.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t
was also living dangerously, though in a different way: it remembered
a refcount it hadn't actually applied yet.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
erably with a comment about why it's like this.)
Another idea would be to invent a new external flag bit "INV_WRITE_ONLY",
so that people who wanted true write-only could get it, without breaking
backwards-compatible behavior. But I'm inclined to wait for some field
demand to show u
t measure the speed of
PageRepairFragmentation. Rather, we should take a look at what happens
subsequently given a physically-ordered set of tuples. I can recall
Andres or someone moaning awhile ago about lack of locality of access in
index page searches --- maybe applying that approach while vacuumi
rt() for the
> reasons mentioned in the comments in gen_qsort_tuple.pl, viz:
+1 for somebody trying that (I'm not volunteering, though).
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
Peter Eisentraut writes:
> On 10/7/17 16:46, Tom Lane wrote:
>> Accordingly I propose the attached patch. If anyone's interested in
>> experimenting on other platforms, we might be able to refine/complicate
>> the FLUSH_DISTANCE selection further, but I think this is p
Robert Haas writes:
> On Tue, Nov 7, 2017 at 4:39 PM, Tom Lane wrote:
>> What I'm getting from the standard pgbench measurements, on both machines,
>> is that this patch might be a couple percent slower than HEAD, but that is
>> barely above the noise floor so I'
Peter Eisentraut writes:
> On 10/31/17 14:23, Tom Lane wrote:
>> Why not use VOIDOID for the prorettype value?
> We need a way to distinguish functions that are callable by SELECT and
> procedures that are callable by CALL.
Do procedures of this ilk belong in pg_proc at all?
like that. However,
if we can make it smaller as well as faster, that seems like a win
even if it's not a measurable fraction of most workloads.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ts of quals they need to check depending
on the join order.
So the bottom line here is how much is it going to cost us to add this
additional refinement in cost estimation, and is it worth it given our
extremely poor level of accuracy in expression cost estimation. Color
me dubious.
surements, on both machines,
is that this patch might be a couple percent slower than HEAD, but that is
barely above the noise floor so I'm not too sure about it.
So I think we should seriously consider the attached, but it'd be a
good idea to benchmark it on a wider variety of platform
velopers to use the same late-model version of pg_dump
while producing output to go into the VCS. That won't be a 100%
solution, because some of the version-specific output is generated
on the backend side, but I bet it would improve matters a lot.
regards, tom la
Magnus Hagander writes:
> On Mon, Nov 6, 2017 at 4:46 PM, Tom Lane wrote:
>> Hm, around here it's no match -> spam bucket. But in any case, why
> I think you're quite uncommon in that setup.
Interesting, because "it's not addressed to me (or any list I'
Magnus Hagander writes:
> On Mon, Nov 6, 2017 at 4:40 PM, Tom Lane wrote:
>> I suggest doing that the other way 'round. Otherwise, the email
>> about the change will inevitably go into a lot of peoples' bit
>> buckets if they haven't adjusted their mail filte
haven't adjusted their mail filters yet.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
allowing it to clients sharing the same snapshot
would help.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
something's not right about the design ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
that
>> information.
> I certainly agree.
Doesn't the EXPLAIN (BUFFERS) output already address this?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
on, ie, can downstream servers make sense of the data.
Maybe that's not any worse than the issues you get with non-core
index AMs, but I'm not sure.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
... at
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=42de8a0255c2509bf179205e94b9d65f9d6f3cf9
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
ng release notes.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
UVpKuyu6SpNjF=yhwu4c4us5jgvgx...@mail.gmail.com
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I wrote:
> Have not looked at the 0002 patch yet.
I looked at that one, and it seems to be a potential win with no
downside, so pushed. (I tweaked it slightly to avoid an unnecessary
conflict with the test patch I posted earlier.)
regards, tom lane
--
Sent via pg
Jeff Janes writes:
> With this v3 patch (assuming this is the one you just committed
> as ec42a1dcb30de235b252f6d4) am now getting make check failures.
There's a followup commit already :-(
regards, tom lane
--
Sent via pgsql-hackers mailing list (pg
Michael Paquier writes:
> On Fri, Nov 3, 2017 at 1:10 AM, Amit Kapila wrote:
>> On Fri, Nov 3, 2017 at 2:54 AM, Tom Lane wrote:
>>> I've marked the CF entry closed. However, I'm not sure if we're quite
>>> done with this thread. Weren't we
isions since.
> I think we should update it to current upstream source, then, just like
> we (are supposed to) do for any other piece of code we adopt.
+1 ... also, is that upstream still the best reference?
regards, tom lane
--
Sent via pgsql-hackers mailing list
Claudio Freire writes:
> On Thu, Nov 2, 2017 at 11:46 PM, Tom Lane wrote:
>> BTW, the originally given test case shows no measurable improvement
>> on my box.
> I did manage to reproduce the original test and got a consistent improvement.
It occurred to me that I could
Alvaro Herrera writes:
> Tom Lane wrote:
>> It might work to build the new key in a context that's initially a
>> child of CurrentMemoryContext, then reparent it to be a child of
>> CacheMemoryContext when done.
> That's another way (than the PG_TRY block), b
f FK inserts, the referencing table when cascading a PK change).
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Eisentraut writes:
> On 10/31/17 10:56, Tom Lane wrote:
>>> Some functions have a strtol()-like behavior
>>> where they take in a const char * and return a pointer into that as
>>> another argument. In those cases, I added a cast or two.
>> ... but I&#x
Alvaro Herrera writes:
> Tom Lane wrote:
>> Do we still need the complication in brinsummarize to discriminate
>> against the last partial range? Now that the lock consideration
>> is gone, I think that might be a wart.
> In the case of VACUUM, it's not desirable
so, shouldn't the passed-in heapBlk always be a multiple of
pagesPerRange already?
Do we still need the complication in brinsummarize to discriminate
against the last partial range? Now that the lock consideration
is gone, I think that might be a wart.
regards, tom l
dly measure any benefit from
the patch at all, I'm not in the best position to test different
values for that cutoff.
Have not looked at the 0002 patch yet.
regards, tom lane
diff --git a/src/backend/storage/page/bufpage.c b/src/backend/storage/page/bufpage.c
index
Fabien COELHO writes:
> [ pgbench-enum-meta-2.patch ]
Pushed with some trivial cosmetic adjustments (pgindent changed
it more than I did).
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscript
Alvaro Herrera writes:
> Tom Lane wrote:
>> So what would happen if we just don't summarize partial ranges?
> Index scan would always have to read all the heap pages for that partial
> range. Maybe not a big issue, but when you finish loading a table, it'd
> be
nt assignments to
pd_lower.
I've marked the CF entry closed. However, I'm not sure if we're quite
done with this thread. Weren't we going to adjust nbtree and hash to
be more aggressive about labeling their metapages as REGBUF_STANDARD?
regards, tom lane
ildHeapScan counts. Maybe we should adjust that?
regards, tom lane
diff --git a/contrib/pgstattuple/pgstatapprox.c b/contrib/pgstattuple/pgstatapprox.c
index 5bf0613..68211c6 100644
*** a/contrib/pgstattuple/pgstatapprox.c
--- b/contrib/pgstattuple/pgstatapprox.c
*
Alvaro Herrera writes:
> Tom Lane wrote:
>> If VACUUM and brin_summarize_new_values both ignore the partial
>> range, then what else would request this? Can't we just decree
>> that we don't summarize the partial range, period?
> brin_summarize_range() can
e_new_values both ignore the partial
range, then what else would request this? Can't we just decree
that we don't summarize the partial range, period?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
Alvaro Herrera writes:
> Tom Lane wrote:
>> Where are we on this --- do you want me to push the brin_doupdate
>> fix I proposed, or were you intending to merge that into a
>> larger patch?
> Please push your fixes, I'll post my proposed patch for the other bug
>
brin_doupdate
fix I proposed, or were you intending to merge that into a
larger patch? If I'm to do it, is there a reason not to back-patch
to all branches with BRIN?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
efined variables doesn't make it a good way to do that.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
slab as long as it saw the List header's "is_linear" flag was
true.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
David Rowley writes:
> On 3 November 2017 at 03:17, Tom Lane wrote:
>> We've jacked up the List API and driven a new implementation underneath
>> once before. Maybe it's time to do that again.
> Maybe, but the new implementation is not going to do well with pla
back-patching pain. Plus we'll then have *four*
different linked-list implementations in the backend, which sure
seems like too many.
We've jacked up the List API and driven a new implementation underneath
once before. Maybe it's time to do that again.
reg
Andres Freund writes:
> Do we care about people upgrading to unreleased versions? We could do
> nothing, document it in the release notes, or ???
Do nothing.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
the
next, but at least it's not assuming that the all-visible state
will stay the same.
I'm going to mark the CF entry closed, but if you feel like working
on the cost estimate business, feel free to submit another patch
for that.
regards, tom lane
--
Sent via
Michael Paquier writes:
> On Fri, Oct 27, 2017 at 11:15 AM, Tom Lane wrote:
>> We could consider back-patching the attached to cover this, but
>> I'm not entirely sure it's worth the trouble, because I haven't
>> thought of any non-silly use-cases in the
Ashutosh Bapat writes:
> On Wed, Nov 1, 2017 at 3:15 AM, Tom Lane wrote:
>> here's a patch to fix the planner so that eval costs and selectivity of
>> HAVING quals are factored into the appropriate plan node numbers.
>> ...
>> + /* Add cost of qual, if any -
icular chunk of code. It's meant to catch something like "name not
found" but could produce this too.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
whether the row passes the qual or not.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ed a conformant subset of the standard syntax.
Oh well.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e off the word ROW; but it is a critical distinction if we're ever to
get to the point of allowing other composite-returning constructs here,
for example composite-returning functions.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
have relevant statistics.
Comments? If anyone wants to do a real review of this, I'm happy to stick
it into the upcoming CF; but without an expression of interest, I'll just
push it. I don't think there's anything terribly controversial here.
regards,
has survived
without error for quite a bit longer than its former MTBF. There
might still be some issues though in other code paths.
regards, tom lane
diff --git a/src/backend/access/brin/brin_pageops.c b/src/backend/access/brin/brin_pageops.c
index 80f803e..b0f86f3 100644
*
Alvaro Herrera writes:
> Tom Lane wrote:
>> I really don't understand how any of this "let's release the buffer
>> lock and then take it back later" logic is supposed to work reliably.
> So summarize_range first inserts the placeholder tuple, which is there
ettype seems like a pretty bad idea. Why not use VOIDOID
for the prorettype value? Or if there is some reason why "void" isn't the
right pseudotype, maybe you should invent a new one, analogous to the
"trigger" and "event_trigger" pseudotypes.
are quite a few unqualified casts in pg_dump, but AFAICS
all the rest are OK because the search_path is just pg_catalog.
But I did find psql's describe.c making a similar mistake :-(.
Pushed that along with your fix.
regards, tom lane
--
Sent via pgsql-hackers mailing
nsane from a concurrency
standpoint that brin_getinsertbuffer is calling RecordPageWithFreeSpace
while holding at least one and possibly two buffer locks. Shouldn't
that be done someplace else?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
AS
sequence_type,
pg_dump doesn't particularly care whether the column comes back marked
as 'name' or 'text' or 'unknown'.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
think it's very good design.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
wtypes to behave
differently from those on other rowtypes.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Michael Paquier writes:
> On Tue, Oct 31, 2017 at 4:56 AM, Tom Lane wrote:
>> Yeah, we're still missing an understanding of why we didn't see it
>> before; the inadequate locking was surely there before.
> Because 24992c6d has added a check o
Alvaro Herrera writes:
> Tom Lane wrote:
>> So: I put the blame on the fact that summarize_range() thinks that
>> the tuple offset it has for the placeholder tuple is guaranteed to
>> hold good, even across possibly-long intervals where it's holding
>> no lock on t
lems is beyond my familiarity
with the BRIN code. It looks like it might be nontrivial :-(
regards, tom lane
diff --git a/src/backend/access/brin/brin_pageops.c b/src/backend/access/brin/brin_pageops.c
index 80f803e..04ad804 100644
*** a/src/backend/access/brin/brin_pageops.c
--- b/src/back
Tomas Vondra writes:
> On 10/30/2017 09:03 PM, Tom Lane wrote:
>> [ scratches head ... ] Not sure how that could've introduced any
>> problems? Will look.
> Not sure, but I can confirm Michael's findings - I've been unable to
> reproduce the issue on 1a4b
inutes to show up... So, bisecting
> with a test that looks for core files for 20 minutes, I am seeing that
> the following commit is actually at fault:
> commit 24992c6db9fd40f342db1f22747ec9e56483796d
> Author: Tom Lane
> Date: Fri Sep 9 19:00:59 2016 -0400
> Rewrite PageIn
s more Python-savvy than I am. So I'll stick it into
the upcoming commitfest as a separate item.
regards, tom lane
diff --git a/contrib/hstore_plpython/expected/hstore_plpython.out b/contrib/hstore_plpython/expected/hstore_plpython.out
index df49cd5..1ab
e details from the in-core SP-GiST support functions.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
overy. You're really into restore-from-
backup territory at that point.
I'm content now that removing the secondary checkpoint is an OK
decision. (This isn't a review of Simon's patch, though.)
regards, tom lane
--
Sent via pgsql-hackers mailing list
al*.)
It might work to build the new key in a context that's initially a
child of CurrentMemoryContext, then reparent it to be a child of
CacheMemoryContext when done. But you'd have to look at whether that
would end up wasting long-lived memory, if the build process generates
any cruft in the s
rt functions then do not have to consider
the possibility that they're handed a toast-compressed value. I have
not checked whether that really matters for cube.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
character varying
We could consider back-patching the attached to cover this, but
I'm not entirely sure it's worth the trouble, because I haven't
thought of any non-silly use-cases in the absence of domains
over composite. Comments?
regards, tom lane
1 - 100 of 48047 matches
Mail list logo
