On sön, 2010-06-27 at 19:41 -0400, Tom Lane wrote:
> OK, so after some digging I find that, while most of the .so's in our
> build are made using Makefile.shlib, pgxs's "MODULES" build rules
> don't
> use that. Instead they rely on the "%.so: %.o" (and platform-specific
> variants of that) rules f
Andrew Dunstan writes:
> Tom Lane wrote:
>> A somewhat more plausible scenario is that somebody might hope that
>> they could do something like this:
>>
>> echo 'some custom header' >pg.dump
>> pg_dump -Fc >>pg.dump
> What would anyone hope to achieve by such a manoeuvre, even if it
> worked, w
Tom Lane wrote:
A somewhat more plausible scenario is that somebody might hope that
they could do something like this:
echo 'some custom header' >pg.dump
pg_dump -Fc >>pg.dump
I believe that (at least on most Unixen) doing fseeko(fp, 0, SEEK_SET)
would result in overwriting th
Robert Haas writes:
> On Thu, Jun 17, 2010 at 7:25 PM, Tom Lane wrote:
>> Then all you need is a tweak to make the postmaster exit(1) after
>> a crash instead of trying to launch recovery.
> This seems useful to me so here's a patch to implement it.
Hm, is it useful in the absence of the other
Robert Haas writes:
> On Sun, Jun 27, 2010 at 6:19 PM, Tom Lane wrote:
>> A somewhat more plausible scenario is that somebody might hope that
>> they could do something like this:
>>
>>echo 'some custom header' >pg.dump
>>pg_dump -Fc >>pg.dump
> That doesn't actually sound all t
[moving from -performance to -hackers; original subject is: PostgreSQL
as a local in-memory cache]
On Thu, Jun 17, 2010 at 7:25 PM, Tom Lane wrote:
> Josh Berkus writes:
>>> (a) and (d) are probably simple, if by "reprovisioning" you mean
>>> "rm -rf $PGDATA; initdb".
>
>> Exactly. Followed by
On Sun, Jun 27, 2010 at 6:19 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Jun 27, 2010 at 1:42 PM, Tom Lane wrote:
>>> If I change the test to be
>>> fseeko(fp, 0, SEEK_SET)
>>> then it does the right thing.
>
>> Well, I guess it depends on what you think the chances are that the
"Aaron W. Swenson" writes:
> LDFLAGS and LDFLAGS_SL are exported as environment variables that ./configure
> does pick up, and pg_config confirms this. (pg_config also reveals that '--as-
> needed' is tacked onto LDFLAGS, which isn't a problem.)
OK, so after some digging I find that, while most
On Sunday 27 June 2010 10:26:48 you wrote:
> "Aaron W. Swenson" writes:
> > I have a short list of modules that have been built without respecting my
> > LDFLAGS and/or LDFLAGS_SL.
>
> It's difficult to comment on this since you haven't told us what flags
> you wanted to inject, nor exactly how y
Robert Haas wrote:
On Sun, Jun 27, 2010 at 12:04 PM, Mike Fowler wrote:
Thanks again for your help Robert, turns out the fault was in the pg_proc
entry (the 3 up there should've been a two!). Once I took the grammar out it
was quickly obvious where I'd gone wrong.
Glad it was a helpfu
Robert Haas writes:
> On Sun, Jun 27, 2010 at 1:42 PM, Tom Lane wrote:
>> If I change the test to be
>>fseeko(fp, 0, SEEK_SET)
>> then it does the right thing.
> Well, I guess it depends on what you think the chances are that the
> revised test will fail on some other obscure platform.
On Sun, Jun 27, 2010 at 1:42 PM, Tom Lane wrote:
> If I change the test to be
>
> fseeko(fp, 0, SEEK_SET)
>
> then it does the right thing. Since checkSeek() is applied immediately
> after opening the input file this should be OK, but it does limit the
> scope of usefulness of that functio
On Sun, Jun 27, 2010 at 12:04 PM, Mike Fowler wrote:
> Thanks again for your help Robert, turns out the fault was in the pg_proc
> entry (the 3 up there should've been a two!). Once I took the grammar out it
> was quickly obvious where I'd gone wrong.
Glad it was a helpful suggestion.
> Attached
On Sun, Jun 27, 2010 at 12:52:17PM +0100, Simon Riggs wrote:
> On Fri, 2010-06-25 at 20:24 +0200, Pavel Baros wrote:
>
> > ... also you can look at enclosed patch.
>
> No tests == no patch
This isn't quite how I'd have phrased it, and it would be nice if
nobody phrased advice quite this way. :)
I wrote:
> The test that checkSeek() is using is to see whether this works:
> fseeko(fp, 0, SEEK_CUR)
> and apparently on this platform that's a no-op even on an otherwise
> unseekable file.
BTW, I looked in the archives for related discussions and found only the
thread in which the current
While testing a fix for the pg_restore issues mentioned a few days ago,
I noticed that checkSeek() returns true on my old HPUX box even when the
input is in fact not seekable, for instance a pipe. This leads to
pg_restore failing completely in cases where it ought to work, like this:
$ cat vector
Bruce Momjian wrote:
I have added this to the next commit-fest:
https://commitfest.postgresql.org/action/commitfest_view?id=6
Thanks Bruce. Attached is a revised patch which changes the code
slightly such that it uses an older version of the libxml library. I've
added comments to t
and finally in pg_proc.h I have:
DATA(insert OID = 3037 ( xmlexists PGNSP PGUID 12 1 0 0 f f f t f i 3 0
16 "25 142" _null_ _null_ _null_ _null_ xml_exists _null_ _null_ _null_ ));
DESCR("evaluate XPath expression in a boolean context");
It looks like the pg_proc entry is creating an
"Aaron W. Swenson" writes:
> I have a short list of modules that have been built without respecting my
> LDFLAGS and/or LDFLAGS_SL.
It's difficult to comment on this since you haven't told us what flags
you wanted to inject, nor exactly how you tried to inject them, nor what
version of PG you're
I have a short list of modules that have been built without respecting my
LDFLAGS and/or LDFLAGS_SL. They are as follows:
autoinc.so
citext.so
earthdistance.so
insert_username.so
isn.so
lo.so
moddatetime.so
refint.so
tablefunc.so
timetravel.so
tsearch2.so
I have looked arou
On Sat, 2010-06-26 at 21:01 -0400, Robert Haas wrote:
> The section (from that same paper) on parallelizing hash joins and
> merge-join-over-sort is interesting, and I can definitely imagine
> those techniques being a win for us. But I'm not too sure how we'd
> know when to apply them - that is,
On Fri, 2010-06-25 at 20:24 +0200, Pavel Baros wrote:
> ... also you can look at enclosed patch.
No tests == no patch
Always best to work on the tests first, so everybody can see the syntax
you are proposing, and also see if your patch actually works. Otherwise
you may find people disagree and t
On Fri, 2010-06-25 at 10:56 -0700, Josh Berkus wrote:
> >> Shouldn't this be backpatched, or was this a new bug in 9.0?
>
> We've always output bytes. I'd have noticed the discrepancy myself if
> I'd read the actual docs ;-)
We can still output bytes, no problem. The issue is that the parameter
On Wed, 2010-06-23 at 10:48 +0200, Sander, Ingo (NSN - DE/Munich) wrote:
> Sql query "select pg_last_xlog_receive_location(); " does not work
> during startup of standby database.
Thanks for the report.
We need to understand more about what you are saying. There is no error
message with that te
On Thu, 2010-06-24 at 10:32 -0400, Tom Lane wrote:
> Magnus Hagander writes:
> > On Thu, Jun 24, 2010 at 15:39, Heikki Linnakangas
> > wrote:
> >> On 24/06/10 14:41, Magnus Hagander wrote:
> >>> Our versioning policy
> >>> (http://wiki.postgresql.org/wiki/PostgreSQL_Release_Support_Policy)
> >>>
25 matches
Mail list logo
