Mark Dilger <hornschnor...@gmail.com> writes:
>> On Nov 15, 2017, at 8:32 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> The stuff in contrib/start-scripts/osx/ does not, as far as I know,
>> work at all on any recent release of macOS, because SystemStarter
>>
I wrote:
> Oliver Ford <ojf...@gmail.com> writes:
>> On Monday, 13 November 2017, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> I don't follow your concern? If "$" is not the correct currency
>>> symbol for the locale, we shouldn't accept it as a match
I wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> On Wed, Nov 15, 2017 at 4:32 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> How do you feel about "win32_more.h"?
>> Seems morally equivalent to what you had before. I think what I would
>&g
east that far back. I don't have access to relevant,
> pre-10.4 machines.
IIRC, I already did test it on 10.6.8, but no harm in your double
checking.
regards, tom lane
I wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> On Wed, Nov 15, 2017 at 10:51 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> 1. Move what's currently in src/include/port/win32.h (a/k/a
>>> pg_config_os.h) to a new file, say src/include/port/win32
Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes:
> On 11/14/17 11:14, Tom Lane wrote:
>> ... Do we really want the existence of
>> a function foo(int) to mean that you can't create a SQL procedure named
>> foo and taking one int argument?
> Yes, that
It wouldn't save a lot, but yeah, doing it in this order seems
a bit silly when you put it like that.
regards, tom lane
e or
after what expand_targetlist() does. I'm doubtful that the
potential savings is worth taking risks there. In particular,
it seems like a good thing that expand_targetlist() verifies the
correct tlist ordering *after* the FDW function has acted.
So now my inclination is to leave this alone.
Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes:
> On 11/23/17 15:39, Tom Lane wrote:
>> I think we should have a discussion about whether it'd be smart
>> to convert the back branches' documentation to XML as well.
> My short answer to that is, I don't have
Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
> On 11/28/2017 12:06 PM, Tom Lane wrote:
>> One thing we'd definitely better do is enable some buildfarm coverage.
>> AFAIK, the only buildfarm animal that's building the docs is guaibasaurus,
>> and it only see
I wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> On Tue, Aug 29, 2017 at 5:14 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> We'd definitely need to do things that way in 9.6. I'm not quite sure
>>> whether it's too late to adopt the clean solution i
; However, when it comes to the stats system, I'd say that on any busy system
> (which would be the ones to care about), the stats structures are still
> going to be *written* a lot more than they are read.
Uh, what? The stats collector doesn't write those files at all except
on-demand.
regards, tom lane
the behavior as the limit is approached and reached.
regards, tom lane
need to see how that interacts with
using pg_ctl. Some documentation might be needed in any case.
regards, tom lane
ad-hoc reindent on some of these files.
regards, tom lane
Mark Dilger <hornschnor...@gmail.com> writes:
>> On Nov 28, 2017, at 11:17 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Hmm. Maybe we should have the plist file set KeepAlive to false not true?
>> This would mean you'd need manual action to restart a failed postmast
much if there are no dead
tuples.
One thing that I think it does do is update the index's pg_class stats
(relpages/reltuples). Maybe it's okay to skip that in this particular
scenario, trusting that auto-analyze would fix it, but that seems
worthy of debate.
regards, tom lane
RWF. Although maybe switching
to owner privileges would be so different as to constitute an unrelated
patch.
regards, tom lane
Thomas Munro <thomas.mu...@enterprisedb.com> writes:
> On Wed, Nov 29, 2017 at 9:47 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> I think that'd be taking it too far, especially given that the dependency
>> on a typedefs list means that the git hook might have a different
tending with back then. (Which I don't recall the
details of; you'll need to trawl the archives. Should be somewhere early
in 2013, though, since we implemented that change in commit 50c19fc76.)
regards, tom lane
Mark Dilger <hornschnor...@gmail.com> writes:
>> On Nov 28, 2017, at 12:47 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> I think that'd be taking it too far, especially given that the dependency
>> on a typedefs list means that the git hook might have a different idea
&
ormal operation, it should
definitely have an ereport (and a non-default errcode).
regards, tom lane
, while
> this statement (which moves a __int128 from one memory location to another
> memory location) expects 16-byte memory alignments. So when either state1
> or state2 is not 16-byte aligned, this crashes.
I believe we already dealt with this:
Author: Tom Lane <t...@sss.pgh.pa.us>
e would break peoples' queries,
probably subtly.
What we need is a way to have a consistent snapshot without implementing
it by copying 100,000 tables' worth of data for every query. Hmm, I heard
of a technique called MVCC once ...
regards, tom lane
lean arrays, too.
regards, tom lane
probably keep the stats tables in a DSM segment; but how would
a backend get a consistent snapshot of them?
regards, tom lane
nt with the
rest of acl.c, but maybe there's some deeper reason? Peter?
regards, tom lane
nd if so why?
regards, tom lane
ackaging
system, not by PG proper. You should proceed by making a new SRPM
and building RPMs from that.
regards, tom lane
Stephen Frost <sfr...@snowman.net> writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I did not look at the patch yet, but TBH if it uses SPI for sub-operations
>> of ALTER TABLE I think that is sufficient reason to reject it out of hand.
> You mean like what ALTER TABLE
Andres Freund <and...@anarazel.de> writes:
> On 2017-11-29 16:39:14 -0500, Tom Lane wrote:
>> Andres Freund <and...@anarazel.de> writes:
>>> FWIW, I think that's a perfectly reasonable choice. Adding complications
>>> in making static assertions work for rand
just want
"we don't support this" to be spelled "#error", rather than dumping off
a load of reasoning about what might happen without functioning static
asserts --- on a weird compiler, no less --- onto our future selves.
regards, tom lane
nd a bit till I found such a query, and committed it.
regards, tom lane
Robert Haas <robertmh...@gmail.com> writes:
> On Wed, Nov 29, 2017 at 11:17 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> The thing that makes me uncomfortable about this is that we used to have a
>> catcache size limitation mechanism, and ripped it out because it ha
possibly be deadlock-free to be trying to grab AccessExclusiveLock
on a partition's parent table when we already have such a lock on the
partition. Which we do, or at least had better, long before we get to
heap_drop_with_catalog.
regards, tom lane
Dean Rasheed <dean.a.rash...@gmail.com> writes:
> On 27 November 2017 at 16:35, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> On looking closer, the reason it's like that in Fujita-san's patch
>> is to minimize the API churn seen by FDW AddForeignUpdateTargets
>> functio
roc is the
same as the value of its last command. There's no such thing as a
proc that doesn't return a value.
regards, tom lane
iscussions of this issue.
regards, tom lane
Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> writes:
> (2017/11/30 7:32), Tom Lane wrote:
>> the output of the foreign join cannot change during EPQ, since the remote
>> server already locked the rows before returning them. The only thing that
>> can change is t
.
regards, tom lane
something badly wrong if we can't.
Thoughts?
regards, tom lane
in the not-too-long run. As such, it'd be okay if it were smaller,
but it seems bigger and more invasive than I could wish for a band-aid.
regards, tom lane
it does not
change errno. This is because there seemed to be other call sites that
were depending on that, not just this one. Anyway, that seemed like a
more future-proof fix than relying on callers to deal with it.
regards, tom lane
Michael Paquier <michael.paqu...@gmail.com> writes:
> On Tue, Dec 5, 2017 at 10:51 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Uh ... I'm confused? That particular change only concerns whether we emit
>> a log message, not whether the action is attempted or succeeds.
regards, tom lane
somebody either copies that
coding pattern into some new script or tweaks the way those existing
scripts are being used.
regards, tom lane
result in slightly worse
code optimization around ereport/elog calls on compilers that
don't have this behavior, but that seems fine to me.
regards, tom lane
is destroyed, seems like what you ought to be using is a memory
context reset callback. Look at MemoryContextRegisterResetCallback and
its callers (there are just a couple at the moment, though I'm fooling
with a patch that will add more).
regards, tom lane
tend to reindent
the Perl code ...
regards, tom lane
Christoph Berg <christoph.b...@credativ.de> writes:
> Debian's reproducible builds project has revealed that the full build
> path gets embedded into server/catalog/schemapg.h:
genbki.pl is hardly our only script that prints its $0 ...
regards, tom lane
re's a matching
user-defined column in the join output then that doesn't happen.
It definitely is a bit unfortunate that the pg_roles view exposes
a user-defined column named "oid", but we felt we had to do that
to avoid breaking user queries that date from when pg_roles was
a plain table.
regards, tom lane
movement on that benchmark, and
it'd be brighter to look for test cases where more contexts are involved.
regards, tom lane
diff --git a/contrib/amcheck/verify_nbtree.c b/contrib/amcheck/verify_nbtree.c
index 868c14e..adbbc44 100644
*** a/con
of the per-context-type functions
these would call, though, because nobody calls those functions directly.
regards, tom lane
Comments, better ideas?
regards, tom lane
int of view I'm not very sure that it's
worth distinguishing cases A and C.
It's conceivable that we could rewrite all the lookup algorithms
so that they didn't require negative cache entries to have good
performance ... but I doubt that that's easy to do.
regards, tom lane
Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes:
> On 12/11/17 17:12, Tom Lane wrote:
>> Hmm, well, surely there's more than one way to do that; the sizeof
>> is just a convenient way to wrap it in C. Wouldn't a typedef serve
>> just as well?
> Here
If we take the lookup path then the bogus element_type will be detected
and reported; if we don't, it won't be.
We could instead add an explicit test for element_type == InvalidOid,
but that's just more duplicative code.
regards, tom lane
able, so you could imagine that AllocSetDelete shoves it
onto a freelist after resetting it, instead of just giving it back to
libc. I'm slightly worried about creating allocation islands that
way, but that problem is probably surmountable, if it's real at all.
However, that seems like a differ
ng up for MSVC. How about this?
Looks ok to me, though I'm not in a position to actually test the
msvc changes.
regards, tom lane
rop reltime/abstime without too many complaints.
Y2038 is coming.)
regards, tom lane
re any good reason not to just define
_WINSOCK_DEPRECATED_NO_WARNINGS unconditionally? Presumably
it would have no effect on VS versions too old to know the symbol.
I'm a bit inclined to move it to win32_port.h, as well,
since that's what includes .
regards, tom lane
d that patch.
regards, tom lane
therwise it looks reasonable.
regards, tom lane
ate to think about whether
float16 is a useful solution. I don't deny that we could get there
someday, but I think putting in float16 now would be a fine example
of having your priorities reversed.
regards, tom lane
Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes:
> On 11/8/17 09:54, Tom Lane wrote:
>> Do procedures of this ilk belong in pg_proc at all? It seems like a large
>> fraction of the attributes tracked in pg_proc are senseless for this
>> purpose. A ne
hmetic.
We have not gone as far as deciding that Postgres will only run on IEEE
hardware, and I don't want to start in pgbench, especially not in
seldom-exercised corner cases.
regards, tom lane
ot that wrong, maybe horribly so. I think it's a bad idea
for progress monitoring to depend on the planner's estimates in any way
whatsoever.
regards, tom lane
typedef name,
to emphasize that what we are classifying is the postmaster
and its children.
regards, tom lane
call is
even syntactically correct. There should be colons in it.
regards, tom lane
s definition
lives in.
regards, tom lane
n to
> if (in->traversalValue)
Agreed, especially since it's done like that in spgscan.c and
geo_spgist.c.
regards, tom lane
Tomas Vondra <tomas.von...@2ndquadrant.com> writes:
> On 11/02/2017 08:15 PM, Tom Lane wrote:
>> However, I'm not sure we're there yet, because there remains a fairly
>> nasty discrepancy even once we've gotten everyone onto the same page
>> about reltuples counti
th Oracle.
regards, tom lane
nes of code as well as a lot of cycles. Likewise in the other two
functions.
regards, tom lane
cal, but regardless of speed it seems like a modularity
violation, in that client backends have to be explicitly aware of
everything that isn't a "client backend".
Maybe it's time to invent something corresponding to AuxProcType
for non "aux" processes, or else to fold all types of Postgres
processes into the same enum.
regards, tom lane
gt;
then it should be added to that thread rather than starting a new one.
But please see the comment I just posted in that thread --- I don't
think we want to continue using order-only dependencies for these
libraries.
regards, tom lane
hoc stuff.
I don't think pgstat has any particular pride of place here. It
should be one consumer of a common API.
The stuff related to AuxProcType is in miscadmin.h, so one possibility
is to put the new enum there. But I could see inventing a whole new
header for this, "utils/proctype.h" or so.
regards, tom lane
Michael Paquier <michael.paqu...@gmail.com> writes:
> On Mon, Nov 20, 2017 at 12:11 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> The stuff related to AuxProcType is in miscadmin.h, so one possibility
>> is to put the new enum there. But I could see inventing a whole new
Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes:
> On 11/17/17 12:16, Tom Lane wrote:
>> I'm confused by the places that change PLy_elog calls to pass NULL:
>>
>> -PLy_elog(ERROR, "could not create globals");
>> +
ntation so that we can tell whether positional notation
was used to begin with.
regards, tom lane
is stored as
a string) to text. So the interesting question here is where are
you getting the XML values from? The stability of the results is
going to be whatever the next level down does.
regards, tom lane
new
expression node type. Also, I'm dubious that it could be made to work
at all for standalone expression evaluation; Param-driven re-evaluation
is only considered when running a plan tree.
regards, tom lane
ion. That
would reflect the fact that expression eval handles them completely
internally.
I'm also wondering about folding CaseTestExpr and CoerceToDomainValue
into the same mechanism. It's not very hard to see those cases as
being the same as a function-based lambda.
regards, tom lane
Robert Haas <robertmh...@gmail.com> writes:
> On Tue, Nov 21, 2017 at 12:05 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Yeah, we probably ought to make more of an effort to regenerate the
>> original query wording. I do not think that forcing positional notat
a volatile function
and the messages are just gone once the function has returned them,
even if you fail to do anything about them because your transaction
fails later?
(I'd be against having a function that returns more than one at a time,
in any case, as that just complicates matters even more.)
regards, tom lane
Robert Haas <robertmh...@gmail.com> writes:
> On Mon, Nov 20, 2017 at 1:40 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> I dunno, it just looks odd to me that when we've set up a test case in
>> which every one of the transactions is guaranteed to exceed the latency
&g
Andres Freund <and...@anarazel.de> writes:
> On November 16, 2017 11:44:52 AM PST, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Yeah, there's no mechanism like that now, but there could be.
> Right, but it doesn't sound that hard to introduce. Basically there'd need to
&g
Glen Knowles <gknow...@ieee.org> writes:
> On Thu, Nov 16, 2017 at 8:37 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> but evidently it chose the wrong cutoff for when to enable that
>> symbol, because woodlouse is (or claims to be) running VS2013.
> It's act
r
I'm not qualified to do that.
Thoughts, objections?
regards, tom lane
Robert Haas <robertmh...@gmail.com> writes:
> On Wed, Nov 15, 2017 at 10:51 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> 1. Move what's currently in src/include/port/win32.h (a/k/a
>> pg_config_os.h) to a new file, say src/include/port/win32_2.h.
> I have no objectio
OK?
Hm, my compiler didn't complain about that. Did yours? The variable
is not changed inside the PG_TRY, so according to my ideas of how
this works, it should be OK. Also, it was like that before, and no
one has reported a problem.
regards, tom lane
it into the
next commitfest.
regards, tom lane
diff --git a/contrib/start-scripts/macos/README b/contrib/start-scripts/macos/README
index ...c4f2d9a .
*** a/contrib/start-scripts/macos/README
--- b/contrib/start-scripts/macos/README
***
*** 0
--- 1,24
+ To make
rong thing with, eg, --foreign-keys before -I.
* I changed the "drop" step to just drop all four tables in one
command; that way avoids having to make any assumption about what
foreign keys exist. (I suppose that constraints leading in different
directions aren't all that likely, but if we're trying to cater to
not-quite-default configurations, we might as well do this.)
* Minor other cosmetic cleanup.
regards, tom lane
entioned, there are no good solutions that would allow us to
keep mangling subject headers. This has been debated extensively already.
regards, tom lane
seems a bit
off topic for that, and I think that test file hardly gets run anyway.
Note this needs to be applied over the patch I posted at
https://postgr.es/m/3626.1510949...@sss.pgh.pa.us
I intend to commit that fairly soon, but it's not in right now.
regards, tom lane
on, I'd like to push this shortly.
regards, tom lane
diff --git a/src/pl/plpgsql/src/pl_exec.c b/src/pl/plpgsql/src/pl_exec.c
index ec480cb..1959d6d 100644
--- a/src/pl/plpgsql/src/pl_exec.c
+++ b/src/pl/plpgsql/src/pl_exec.c
@@ -272,8 +272,7 @@ static ParamListInfo setup
regards, tom lane
Robert Haas <robertmh...@gmail.com> writes:
> On Fri, Dec 8, 2017 at 2:07 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> I'm not sure how we could get away with that. Would it pass muster to do
>> that only when isatty(stdin)? Other ideas?
> What if we made it so t
el's proposal in
https://www.postgresql.org/message-id/cab7npqrpocxjiirhmebefhxvtk7v5jvw4bz82p7oimtsm3t...@mail.gmail.com
If we don't want to throw a hard error for failure to remove files,
it seems like throwing an error for failure to read a temp dir isn't
a great choice either.
regards, tom lane
right that we can design some transmission
procedure that allows stats to be forward-migrated when compatible and
dropped when not.
regards, tom lane
1 - 100 of 15066 matches
Mail list logo
