Buildfarm results remind me that I forgot to think about updating the
MSVC perl scripts to match the recent changes in pgxs.mk. I think the
relevant points are:
1. Install .control files matching the entries in EXTENSION.
2. If EXTENSION is defined, the default value of MODULEDIR should be
taken
hi,
all of the following answers are with the patch you provided in
other mail applied.
> YAMAMOTO Takashi wrote:
>
>> i have seen this actually happen. i've confirmed the creation of
>> the loop with the attached patch. it's easily reproducable with
>> my application. i can provide the full
hi,
> I wrote:
>
>> it seems likely that such a cycle might be related to this new
>> code not properly allowing for some aspect of tuple cleanup.
>
> I found a couple places where cleanup could let these fall through
> the cracks long enough to get stale and still be around when a tuple
> ID
On 02/14/2011 01:27 AM, Tom Lane wrote:
Magnus Hagander writes:
Unfortunately, one of the worst-case scenarios appears to have
happened - a machine did not come back up after a reboot.
...
We'll get back to you with more information as soon as we have it.
I didn't see any followup to this?
Appendix F (contrib.sgml and its subsidiary files) is pretty consistent
about using "module" to refer to a contrib, uh, module.
I considered doing a search-and-replace to change this to "extension",
but I'm not convinced that's a good idea. I think "extension" means a
specific kind of SQL object
On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas
wrote:
> I added a XLogWalRcvSendReply() call into XLogWalRcvFlush() so that it also
> sends a status update every time the WAL is flushed. If the walreceiver is
> busy receiving and flushing, that would happen once per WAL segment, which
> seems
On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas
wrote:
> I committed the patch with those changes, and some minor comment tweaks and
> other kibitzing.
+* 'd' means a standby reply wrapped in a COPY BOTH packet.
+*/
Typo: s/COPY BOTH/CopyData
+ msgtype = pq_getmsg
Thanks for the review!
On Thu, Feb 10, 2011 at 11:25 PM, Magnus Hagander wrote:
> I see that the docs part of the patch removes the mentioning of
> reporting servers - is that intentional, or a mistake? Seems that
> usecase still remains, no?
It was intentional, but I agree with you. I re-added
Andrew,
* Andrew Dunstan (and...@dunslane.net) wrote:
> See the discussion back around the the 8.1 release (IIRC) when we
> added the HEADER option.
I recall seeing it and not agreeing with it then. :)
> >If I wanted something to throw away the first record of a file before
> >loading it, I'd us
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Feb 11, 2011 at 11:23 AM, Stephen Frost wrote:
> > Updated patch attached, full git log below.
Thanks again for the review. Updated patch attached.
> The documentation for csvlog_fields should probably use
> around the default val
"David E. Wheeler" writes:
> On Feb 13, 2011, at 4:59 PM, Tom Lane wrote:
>> I suppose if you really wanted foo.sql to always be the head version,
>> you could do something like "cp foo.sql foo--$VERSION.sql" as part of
>> the build process in the Makefile.
> That would be okay. Is $EXTVERSION st
On Feb 13, 2011, at 4:59 PM, Tom Lane wrote:
> I think after a couple of releases you'd be shipping something like
>
> foo--1.0.sql
> foo--1.1.sql
> foo--1.0--1.1.sql
> foo--2.0.sql
> foo--1.1--2.0.sql
>
> and it'll soon get to be a mess if your SCM doesn't clearly
"David E. Wheeler" writes:
> On Feb 13, 2011, at 4:46 PM, Tom Lane wrote:
>> (2) I think that the normal use-case would not involve removing the old
>> file, so this is moot anyhow.
> Oh. So one normally will ship, for an extension "foo", only "foo.sql" and any
> necssary upgrade scripts?
I thi
On Feb 13, 2011, at 4:46 PM, Tom Lane wrote:
>> I sure would like it if the install script with no version in it
>> corresponded to the latest version. Otherwise, one must rename the file
>> every time one does a release. And as you're noting, you lose Git history
>> that way.
>
> (1) git does
"David E. Wheeler" writes:
> I sure would like it if the install script with no version in it corresponded
> to the latest version. Otherwise, one must rename the file every time one
> does a release. And as you're noting, you lose Git history that way.
(1) git does know it's a rename, it's jus
On Feb 13, 2011, at 11:34 AM, Tom Lane wrote:
> OK, so with that, attached is an example of the complete conversion diff
> for a contrib module (hstore in particular). Although "git status"
> reports hstore--1.0.sql as being a rename of hstore.sql.in, "git diff"
> doesn't seem to be exceedingly b
On 02/13/2011 08:26 AM, Stephen Frost wrote:
This would be called a 'header' in most typical CSV scenarios.
Unfortunately, last I checked (maybe it's changed?), COPY w/ HEADER just
throws the header away instead of doing anything useful with it. If it
actually used the header to build the colu
Magnus Hagander writes:
> Unfortunately, one of the worst-case scenarios appears to have
> happened - a machine did not come back up after a reboot.
> ...
> We'll get back to you with more information as soon as we have it.
I didn't see any followup to this?
gitmaster seems to be responding as o
On 02/12/2011 05:33 PM, Noah Misch wrote:
On Sat, Feb 12, 2011 at 03:42:17PM -0600, Kevin Grittner wrote:
In two hours of testing with a 90GB production database, the copy
patch on top of HEAD ran 0.6% faster than HEAD for pg_dumpall
(generating identical output files), but feeding that in to
On 02/12/2011 05:10 AM, Ralf Wildenhues wrote:
Hello, and sorry for the delay,
* Peter Rosin wrote on Sat, Jan 29, 2011 at 02:26:24PM CET:
Or is plain 'ar' used somewhere instead of 'x86_64-w64-mingw32-ar'?
Automake outputs 'AR = ar' in Makefile.in for rules creating old
libraries iff neithe
Tom Lane writes:
> Yes, it should be unnecessary given the search_path setup done by
> execute_extension_script(). Also, I think that a relocatable
> extension's script should not be subject to @extschema@ substitution,
> no matter what.
Oh I'm just realizing that my reasoning predates the searc
On Sun, Jan 30, 2011 at 11:12 PM, Fujii Masao wrote:
> On Sun, Jan 30, 2011 at 10:44 AM, Jeff Janes wrote:
>> I do not understand what doing so gets us.
>>
>> Say we previously received 2/3 of a WAL file, and replayed most of it.
>> So now the shared buffers have data that has been synced to that
Dimitri Fontaine writes:
> Tom Lane writes:
>> OK, so with that, attached is an example of the complete conversion diff
>> for a contrib module (hstore in particular). Although "git status"
> I see you're not using the @extschema@ placeholder in the upgrade
> script. It is intentional?
Yes, i
Tom Lane writes:
>> Tom Lane writes:
>>> I think it's better to keep it working as a textual substitution.
Thinking about this some more, it has the advantage that the effects of
the control file settings are kept within the script file processing and
pg_extension catalog. The only backend impa
On Sun, Feb 13, 2011 at 6:50 AM, Noah Misch wrote:
>> Yikes.
>> I didn't like that Assert much, but maybe we need it, because this is
>> scary.
>
> Can you elaborate on the fear-inducing aspect? I don't mind re-adding the
> Assert, but it seems that some positive understanding of the assumption'
Dimitri Fontaine writes:
> Tom Lane writes:
>> I think it's better to keep it working as a textual substitution.
>> That poses the least risk of breaking scripts that work today ---
>> who's to say that somebody might not be relying on the substitution
>> happening someplace else than CREATE FUNC
Tom Lane writes:
> I think it's better to keep it working as a textual substitution.
> That poses the least risk of breaking scripts that work today ---
> who's to say that somebody might not be relying on the substitution
> happening someplace else than CREATE FUNCTION's shlib string?
Fair enoug
Noah Misch wrote:
> On Sat, Feb 12, 2011 at 03:42:17PM -0600, Kevin Grittner wrote:
>> Do you see any reason that COPY FROM should be significantly
>> *faster* with the patch?
>
> No. Up to, say, 0.5% wouldn't be too surprising, but 8.4% is
> surprising.
> What is the uncertainty of that fig
Michael Banck writes:
> As pbuilder just runs debootstrap on --create and (Debian) debootstrap
> supports the Ubuntu releases, this is not an issue.
Great. It seems that a single amd64 build VM would allow us to build
all those binary packages for i386 and amd64, for several debian and
ubuntu re
Dimitri Fontaine writes:
> Tom Lane writes:
>> I'm hesitant to have any substitutions that happen unconditionally,
>> but we could add a control parameter like
>> module_pathname = '$libdir/hstore'
>> and then things would be pretty clean.
> Ok. Maybe the simpler would be to make the current co
On 11-02-12 05:58 AM, Jan Urbański wrote:
On 11/02/11 10:53, Jan Urbański wrote:
On 10/02/11 22:26, Steve Singer wrote:
Here's an updated patch with documentation. It's an incremental patch on
top of the latest explicit-subxacts version.
This looks fine. I've attached a one word documentati
Tom Lane writes:
> Or are you suggesting substituting for MODULE_PATHNAME during CREATE
> EXTENSION, and not during "make" at all? That would work I guess.
That's my idea, sorry not having made it clear enough. We have $libdir
which is expanded server-side AFAIUI, I though we would have $shlib
On Mon, Feb 7, 2011 at 13:43, Fujii Masao wrote:
> Hi,
>
> When I ran pg_basebackup with -x, -P and -v options, I encountered
> the following odd output.
>
> $ pg_basebackup -D hoge -x -P -v
> xlog start point: 0/220
> 33708/17322 kB (100%) 1/1 tablespaces (
> )02)
>
> "02)"
On Sun, Feb 13, 2011 at 12:56:03PM +0100, Dimitri Fontaine wrote:
> Magnus Hagander writes:
> > Yes, since according to a comment somewhere the same issue will
> > bubble
> > into ubuntu soon. At this point, definitely 8.04 and 10.04, and
> > probably 10.10. If things can be easily automated, it w
Dimitri Fontaine writes:
> Tom Lane writes:
>> But contrib/spi is exactly the case where it *won't* work. We need to
>> somehow figure out that $libdir/autoinc is what to substitute in
>> autoinc-1.0.sql, $libdir/insert_username in insert_username-1.0.sql,
>> etc.
> Indeed. That's why I'm prop
* Robert Haas (robertmh...@gmail.com) wrote:
> The documentation for csvlog_fields should probably use
> around the default value.
>
> The sentence that begins "For details on what these fields are" should
> hyperlink the referenced sections of the documentation.
>
> The function prototype you a
On Fri, Feb 11, 2011 at 11:23 AM, Stephen Frost wrote:
> Updated patch attached, full git log below.
The documentation for csvlog_fields should probably use
around the default value.
The sentence that begins "For details on what these fields are" should
hyperlink the referenced sections of the
On Tue, Feb 8, 2011 at 19:52, Magnus Hagander wrote:
> Hi!
>
> The PostgreSQL Infrastructure Team will be performing scheduled
> maintenance on the server that is hosting gitmaster.postgresql.org the
> coming sunday, Feb 13th. While we expect this to only cause a very
> short downtime for the serv
psql -l doesn't process psqlrc. Historically, this was probably not
useful, hence no one cared. But with the linestyle option it's useful.
So I propose the attached tweak.
diff --git i/src/bin/psql/startup.c w/src/bin/psql/startup.c
index 4f3815a..10713e9 100644
--- i/src/bin/psql/startup.c
+++
Here is a patch that implements make check support for the PLs and a
make check-world target.
I found the lack of this quite annoying while reviewing the load of
PL/Python patches. There did not appear to be a reason why it wasn't
done before.
Support for make check in contrib would also be nice
Magnus Hagander writes:
> I think i386 and amd64 are enough, really. We could add more later if
> necessary, but i don't think we need to.
Ok.
> I assume this can be easily virtualized - e.g. having one VM for each
> version and just boot it up, update all dependencis, build, and shut
> down? in
On Sun, Feb 13, 2011 at 12:04:20AM -0500, Robert Haas wrote:
> On Sat, Feb 12, 2011 at 10:45 AM, Noah Misch wrote:
> > That said, I've tried both constructions, and I marginally prefer the end
> > result
> > with AlteredTableInfo.verify. ?I've inlined ATColumnChangeRequiresRewrite
> > into
> > A
On Sun, Feb 13, 2011 at 12:09, Dimitri Fontaine wrote:
> Greg Smith writes:
>> What the RPM packaging does is run this (approximately):
>
> Well building the debian package also run make check. My question is if
> that's enough QA here for us?
Don't the RPM building guys (Hi, Devrim!) also run
Greg Smith writes:
> What the RPM packaging does is run this (approximately):
Well building the debian package also run make check. My question is if
that's enough QA here for us?
The other side of things if that we will need to provide for a debian
repository with support for at least lenny an
Tom Lane writes:
>> My take here is to way that in this case, the current (9.1) way to deal
>> with the situation is to have multiple extensions when you have multiple
>> shlibs. After all we know that multiple extensions from the same
>> Makefile works, thanks to contrib/spi (I mean extension/sp
45 matches
Mail list logo
