tput from configure, particularly the new
lines about CFLAGS?
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
Christoph Berg <m...@debian.org> writes:
> Re: Tom Lane 2017-07-28 <3254.1501276...@sss.pgh.pa.us>
>> Christoph Berg <m...@debian.org> writes:
>>> The plperl segfault on Debian's kfreebsd port I reported back in 2013
>>> is also still present:
>>
"Tels" <nospam-pg-ab...@bloodgate.com> writes:
> On Sun, July 30, 2017 12:22 pm, Tom Lane wrote:
>> Yeah, I looked into that. The closest candidate I can find is that
>> perl 5.10.1 contains Test::More 0.92. However, it's not real clear
>> to me exactly which
happening.
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
ly lightweight per-session
state, but that ain't us.
I think what you need to do is tell SslStream not to expect that PG
servers will do session resumption. (I'm a bit astonished that that
would be its default assumption in the first place, but whatever.)
regards, tom l
Noah Misch <n...@leadboat.com> writes:
> On Sun, Jul 30, 2017 at 12:05:10PM -0400, Tom Lane wrote:
>> Well, OK, but I'd still like to tweak configure so that it records
>> an absolute path for prove rather than just setting PROVE=prove.
>> That way you'd at least be able
"Tels" <nospam-pg-ab...@bloodgate.com> writes:
> On Sun, July 30, 2017 1:21 am, Tom Lane wrote:
>>> So the question is, does anyone care? I wouldn't except that our
>>> documentation appears to claim that we work with Perl "5.8 or later".
> N
Noah Misch <n...@leadboat.com> writes:
> On Sun, Jul 30, 2017 at 01:21:28AM -0400, Tom Lane wrote:
>> I think it'd be a good idea to insist that "prove" be in
>> the same directory we found "perl" in.
> Nah; on my machines, I use /usr/bin/perl and
TINCT will use, ie the default for the data type.
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
ea to insist that "prove" be in
the same directory we found "perl" in.
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
ecause we should only get to that function
through ExecProcNode(). If somehow it's not redundant, please add a
comment explaining why not.
Some other minor cosmetic changes, mostly comment wordsmithing.
I think this (and the previous one) are committable.
regards, tom l
Andres Freund <and...@anarazel.de> writes:
> On 2017-07-26 16:28:38 -0400, Tom Lane wrote:
>> It's certainly possible that there are long-running loops not involving
>> any ExecProcNode recursion at all, but that would be a bug independent
>> of this issue. The CFI
s attachments rather than pasting them into the text in-line.
Poking at it a bit harder with valgrind, it seems that the vast majority
of what it reports as leaks is caused by replace_token(). If we wanted to
reduce memory wastage during initdb, that would be the place to work on.
But I'm dubious that
Daniel Gustafsson <dan...@yesql.se> writes:
> On 27 Jul 2017, at 19:40, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> listTables and listDbRoleSettings print a custom message rather than
>> an empty table for no matches (but in QUIET mode they just do the
>> latter)
Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
>> On 07/27/2017 11:58 PM, Tom Lane wrote:
>>> I wonder if it'd be worth getting the buildfarm
>>> to log the output of "perl -V" so we could get a clearer picture
>>> of what's being teste
l, thanks. I hope people will set up some buildfarm machines with
the formerly-broken configurations.
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
=kfreebsd-amd64=10~beta2-1=1499947011=0
So it'd be interesting to know if it's any better with HEAD ...
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
ole
> mess.)
I think the pain arises mostly from the decision to allow partitions
to not all have identical rowtype. I would have lobbied against that
choice if I'd been paying more attention at the start ... but I wasn't.
regards, tom lane
--
Sent via pgsql-ha
Ashutosh Sharma <ashu.coe...@gmail.com> writes:
> On Fri, Jul 28, 2017 at 10:05 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Uh-huh. So the issue is indeed that they're injecting PERL_IMPLICIT_SYS
>> via a command-line #define rather than putting it into perl's co
rl droppings.)
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
Ashutosh Sharma <ashu.coe...@gmail.com> writes:
> On Fri, Jul 28, 2017 at 7:22 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Assuming that the Perl crew know what they're doing and this list is
>> complete, I notice that not one of the symbols they show as relevant
>&g
ersecting that with what we get
from Perl's ccflags. But that would be a lot more complex, so
I'd rather go with the simpler filter rule for now.
(BTW, you never did tell us exactly what defines you're getting
out of Perl's flags on the problem installation.)
regards
orth getting the buildfarm
to log the output of "perl -V" so we could get a clearer picture
of what's being tested.
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
stashcache is
a macro, so we could make it compile with an "#ifdef PL_stashcache",
but I'm pretty nervous about whether that would be breaking needed
cleanup behavior.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
're browsing in.
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
Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
> On 07/27/2017 04:33 PM, Tom Lane wrote:
>> So I was trying to figure a way to not include XSUB.h except in a very
>> limited part of plperl, like ideally just the .xs files. It's looking
>> like that would
define aTHX_ aTHX,
#endif
As best I can tell, that's absolute brain death on the part of the Perl
crew; it means you can't write working calling code at all without
including XSUB.h, or at least copying-and-pasting this bit out of it.
regards, tom lane
--
Sent
Robert Haas <robertmh...@gmail.com> writes:
> On Wed, Jul 26, 2017 at 2:41 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> The bigger issue is whether there's some failure case this would cause
>> that I'm missing altogether. Thoughts?
> I think dependencies are
Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
> What is the minimal set of extra defines required to sort out the
> handshake fingerprint issue?
Also, exactly what defines do you end up importing in your test build?
regards, tom lane
--
Sent via p
G FOR".
> Attached patch fixes that.
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
Daniel Gustafsson <dan...@yesql.se> writes:
>> On 19 Jun 2017, at 17:32, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> So, if we're getting into enforcing consistency in describe.c, there's
>> lots to do.
> Addressed in attached patch, see list of
served,
> SPI.obj : error LNK2019: unresolved external symbol PerlProc_setjmp
> referenced in function do_plperl_return_next
That's certainly a mess, but how come that wasn't happening before?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers
nywhere, and for that matter
"checked for extended formats" is a masterpiece of unhelpful obfuscation.
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
if you wanted both instrumentation and async support on the same node.
But maybe those two couldn't be arms-length from each other anyway,
in which case it might be fine as-is.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
Stephen Frost <sfr...@snowman.net> writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> AFAICT, pg_dump has no notion that it needs to be careful about the order
>> in which permissions are granted. I did
> I'm afraid that's correct, though I believe that's always been
Andres Freund <and...@anarazel.de> writes:
> On 2017-07-26 15:03:37 -0400, Tom Lane wrote:
>> Hm, that seems kinda backwards to me; I was envisioning the checks
>> moving to the callees not the callers. I think it'd end up being
>> about the same number of occurren
ment call about where to put them.
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
uld work. It says that you can specify (most
of) the same fields that are allowed in a connection string, not that one
of those fields might be taken to *be* a connection string.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
st say you might have
to not use parallel restore with old dumps that contain self-revoke ACLs?)
The bigger issue is whether there's some failure case this would cause
that I'm missing altogether. Thoughts?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgs
ous
either.
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
it for the next pg_upgrade or dump/restore).
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
did not change their results.
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
Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
> On 07/26/2017 09:33 AM, Tom Lane wrote:
>> It might be interesting to look into its copy of IPC::Run and see if
>> the wait technology is different from later versions.
> It's using 0.94 just like my Linux box.
O
it's moot.
Not sure what's involved there code-wise, though, nor whether we'd want
to back-patch.
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
around the problem without upsetting the
> good work you've been doing in reducing TAP test times generally.
I still find this pretty ugly :-(.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
Robert Haas <robertmh...@gmail.com> writes:
> On Tue, Jul 25, 2017 at 10:45 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Instead, I've prepared the attached draft patch, which addresses the
>> problem by teaching pg_backup_archiver.c to process TOC entries in
>
seems safer than just
absorbing everything willy-nilly.
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
ies that need to be broken.
If somebody else wants to try drafting a patch like that, I won't stand
in the way, but I don't wanna do so.
Not clear where we want to go from here. Should we try to get this
into next month's minor releases, or review it in September's commitfest
and back-patch af
s make more sense to me.
Yeah, it makes more sense to me too, but nonetheless that's the result
I get. I suspect there is an element of indeterminacy here.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
ill anyone still care by then?
(Concretely, my concern is that the alpha and beta testing that's happened
so far hasn't covered pre-4.6 ICU at all. I'd be surprised if the
incompatibility you found so far is the only one.)
regards, tom lane
--
Sent via pgsql-hacker
IZATION;
That might be just chance, but my current bet is that Stephen
broke it sometime in the v10 cycle --- especially since we
haven't heard any complaints like this from the field.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
ots of undocumented behaviors in PG; if we tried to explain
every one of them, the docs would become unusably bloated.
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
to go do
something with more tangible benefit, like see if we can make its
REFRESH MATERIALIZED VIEW commands come out at the right time.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscript
Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
> On 07/25/2017 11:25 AM, Tom Lane wrote:
>> Oh. So when was the last time it worked? And why do the buildfarm
>> archives contain apparently-successful log_stage entries for pg_ctl-check
>> on jacana, up thro
Robert Haas <robertmh...@gmail.com> writes:
> On Tue, Jul 25, 2017 at 10:31 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> pg_dump doesn't really support that scenario, and I don't feel any
>> great need to make it do so. Per the comment in dumpProcLang:
> Is thi
Robert Haas <robertmh...@gmail.com> writes:
> On Tue, Jul 25, 2017 at 11:00 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Hm, I had the idea that we were already asking ExtUtils::Embed for that,
>> but now I see we only inquire about LDFLAGS not CCFLAGS. Yes, this sounds
Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
> On 07/25/2017 11:11 AM, Tom Lane wrote:
>> What I'm on about is that jacana still succeeds entirely, more than half
>> the time. If this is a handle-duplication problem, how could it ever
>> succeed?
>
Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
> On 07/24/2017 09:33 PM, Tom Lane wrote:
>> Seems like the TAP test should fail every time, if this is a full
>> description. But maybe it's part of the answer, so it seems worth
>> experimenting in this direct
Tomas Vondra <tomas.von...@2ndquadrant.com> writes:
> On 7/25/17 12:55 AM, Tom Lane wrote:
>> I think the planner basically assumes that reltuples is the live
>> tuple count, so maybe we'd better change VACUUM to get in step.
> Attached is a patch that (I think) does jus
e that to the problematic
field(s).
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
d to be made aware of that.
If that *isn't* the explanation, then we need to find out what is.
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
others based on nothing except estimation errors. I do not think we'd
get a net benefit in plan quality.
If we could do this earlier and adjust the join relation's overall
cardinality estimate, it might be something to consider.
regards, tom lane
--
Sent via pgsql-hacke
l and it is not
> clear why perl is using those flags. Do you think we can do something
> at our end to make it work or someone should check with Perl community
> about it?
It would be a good idea to find somebody who knows more about how these
Perl distros are built.
... but you didn't do that either.
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
gh,
so I wonder how exactly a logical decoding plugin is supposed to make
sense of what it can see here.
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
Rushabh Lathia <rushabh.lat...@gmail.com> writes:
> On Mon, Jul 24, 2017 at 7:23 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Some looking around says that this *isn't* the only place that just
>> blithely assumes that it will find an opfamily entry. But I agree
>>
g Microsoft's documentation suggests that maybe all
we have to do is pass CreateProcessAsUser's bInheritHandles parameter
as FALSE not TRUE in pg_ctl.c. It's not apparent to me that there
are any handles we do need the CMD process to inherit.
regards, tom lane
--
Sent via
live
> The question is - which of the reltuples definitions is the right one?
> I've always assumed that "reltuples = live + dead" but perhaps not?
I think the planner basically assumes that reltuples is the live tuple
count, so maybe we'd better change VACUUM to get in step.
Mat Arye <m...@timescaledb.com> writes:
> On Mon, Jul 24, 2017 at 1:38 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> I'm not really sure why planner hooks would have anything to do with your
>> exposed SQL API?
> Sorry what I meant was i'd like to package differ
not found cases below, either.
Will fix, unless you're already on it?
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
Gilles Darold <gilles.dar...@dalibo.com> writes:
> Le 24/07/2017 à 19:19, Tom Lane a écrit :
>> ... I'm inclined to think in terms of fixing it at that level
>> rather than in pg_dump. It doesn't look like it would be hard to fix:
>> both functions ultimately call
Andres Freund <and...@anarazel.de> writes:
> On 2017-07-21 20:17:54 -0400, Tom Lane wrote:
>>> I dislike having the miscadmin.h include in executor.h - but I don't
>>> quite see a better alternative.
>> I seriously, seriously, seriously dislike that. You
pg_dump. It doesn't look like it would be hard to fix:
both functions ultimately call get_query_def(), it's just that one passes
down a tuple descriptor for the view while the other currently doesn't.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-h
GRANTs from REVOKEs and
putting only the latter at the end. I'm not quite convinced that that's
a good idea but it certainly merits consideration.
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
not checking for that isn't up to project standards.
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 know anything about
ScalarArrayOpExpr, but there's a patch pending to improve that:
https://commitfest.postgresql.org/14/1136/
You should probably build your revised patch as a follow-on to that
one, else we're going to have merge conflicts.
regards, tom lane
--
Sent via
array is coming from a parameter rather
than an ARRAY[] construct. That is, you should be able to do this not
only for ARRAY[x] but for any single-element constant array.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
EOF detection AFAICS.
It's also hard to explain this way why it only fails some of the time.
I think we need to look at what the recent changes were in this area
and try to form a better theory of why it's started to fail here.
regards, tom lane
--
Sent via pgsql-
king that it was an optional optimization, and not something that
is critical for correctness of several different callers. I'm going to
go improve the comments.
Meanwhile, it's still pretty unclear what happened yesterday on
culicidae.
regards, tom lane
--
Sent via
eep
backwards compatibility across versions, your users are probably
going to think differently. The amount of practical freedom you'd
gain here is probably not so much as you're hoping.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
Andres Freund <and...@anarazel.de> writes:
> On 2017-07-18 16:53:43 -0400, Tom Lane wrote:
>> BTW, I don't see why you really need to mess with anything except
>> ExecProcNode? Surely the other cases such as MultiExecProcNode are
>> not called often enough to just
Alvaro Herrera <alvhe...@2ndquadrant.com> writes:
> Tom Lane wrote:
>> We could stabilize this test result by forcing lc_messages = C in
>> the foreign server options. However, that would lose regression
>> coverage of situations where the remote locale is different,
d memory right here; but what we've got is not up to project
standards IMO.
I have some ideas about fixing this by enlisting the help of dynahash.c
explicitly, rather than fooling with "scratch entries". But I haven't
been able yet to write a design for that that doesn't have obvious bugs.
,
but it looks tedious and bulky.
> I have, however, decided not to volunteer to be the one who works on
> that project.
Me either. Any one of these things would require a *lot* of work in
order to have a coherent feature that provided useful behavior across
a bunch of different datatypes.
pecial variable, as we do for LASTOID for instance; but it doesn't
look like that's actually been done yet. We should revisit this
if that feature ever materializes.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
uld mask issues
that the test case ought to find, too.
Maybe set lc_messages = C in the options only for the duration
of these new test cases?
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
, +1. Some of
them have some documentation in them, which you'd need to make sure
is duplicative or else copy it to an appropriate place.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
mpletely bulletproof before 9.6.
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
or-specific knowledge that doesn't exist in the
system today. And as Craig noted, applying that knowledge would
be expensive, even in cases where it failed to help.
So, color me skeptical ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers
iple sessions.
I made some cosmetic updates to the code patch, as well.
I think this is actually a bug fix, and should not wait for the next
commitfest.
regards, tom lane
diff --git a/contrib/postgres_fdw/connection.c b/contrib/postgres_fdw/connection.c
index 8c33dea..8eb47
the <>, for instance "(a.b + b.y) <> a.c". I don't think it's
especially interesting for the present purpose though, since we're going
to end up with 1.0 selectivity in any case where examine_variable can't
find stats.
regards, tom lane
--
Sent v
uld debate the exact constants.
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
uot;ON FALSE".
No, it's normal that an AND of no conditions degenerates to TRUE.
It's like omitting a WHERE clause.
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
ection to a 16MB ring buffer for vacuum when
it is coming out of a 1GB arena ... it just seems like a rather large
fraction of 128MB to give to a background process, especially to each
of several background processes.
Maybe the fraction-of-shared-buffers shouldn't be one size fits all,
but a
e bothered to provide the
view.
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
.3. Although I have a feeling
this might be a mistake in a back-patched bug fix, so that it'd depend
on which 9.3.x you looked at.
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
0. (If you want those values, you should now
get them out of the pg_sequence catalog.)
This should have been called out as a significant incompatibility
in the v10 release notes, but I see that it's not listed in the
right section. Will fix that ...
regards, tom lan
Greg Stark <st...@mit.edu> writes:
> On 19 July 2017 at 00:26, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> It's probably a bit late in the v10 cycle to be taking any risks in
>> this area, but I'd vote for ripping out RememberToFreeTupleDescAtEOX
>> as soon as the v1
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
/9b4ea968-753f-4b5f-b46c-d7d3bf7c8f90%40manitou-mail.org
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
801 - 900 of 46746 matches
Mail list logo