Tom Lane t...@sss.pgh.pa.us 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
Greg Smith g...@2ndquadrant.com 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
On Sun, Feb 13, 2011 at 12:09, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Greg Smith g...@2ndquadrant.com 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
On Sun, Feb 13, 2011 at 12:04:20AM -0500, Robert Haas wrote:
On Sat, Feb 12, 2011 at 10:45 AM, Noah Misch n...@leadboat.com wrote:
That said, I've tried both constructions, and I marginally prefer the end
result
with AlteredTableInfo.verify. ?I've inlined ATColumnChangeRequiresRewrite
Magnus Hagander mag...@hagander.net 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
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
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
+++
On Tue, Feb 8, 2011 at 19:52, Magnus Hagander mag...@hagander.net 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
On Fri, Feb 11, 2011 at 11:23 AM, Stephen Frost sfr...@snowman.net wrote:
Updated patch attached, full git log below.
The documentation for csvlog_fields should probably use literal
around the default value.
The sentence that begins For details on what these fields are should
hyperlink the
* Robert Haas (robertmh...@gmail.com) wrote:
The documentation for csvlog_fields should probably use literal
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
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us 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.
On Sun, Feb 13, 2011 at 12:56:03PM +0100, Dimitri Fontaine wrote:
Magnus Hagander mag...@hagander.net 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
On Mon, Feb 7, 2011 at 13:43, Fujii Masao masao.fu...@gmail.com 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)
Tom Lane t...@sss.pgh.pa.us 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
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
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us 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
Michael Banck mba...@debian.org 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
Noah Misch n...@leadboat.com 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
Tom Lane t...@sss.pgh.pa.us 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
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us 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
On Sun, Feb 13, 2011 at 6:50 AM, Noah Misch n...@leadboat.com 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
Tom Lane t...@sss.pgh.pa.us writes:
Tom Lane t...@sss.pgh.pa.us 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
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us 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
On Sun, Jan 30, 2011 at 11:12 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Sun, Jan 30, 2011 at 10:44 AM, Jeff Janes jeff.ja...@gmail.com 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
Tom Lane t...@sss.pgh.pa.us 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
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
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
Magnus Hagander mag...@hagander.net 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
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
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 bright
David E. Wheeler da...@kineticode.com 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
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 know
David E. Wheeler da...@kineticode.com 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
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 da...@kineticode.com 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
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
On Fri, Feb 11, 2011 at 11:23 AM, Stephen Frost sfr...@snowman.net wrote:
Updated patch attached, full git log below.
Thanks again for the review. Updated patch attached.
The documentation for csvlog_fields should probably use literal
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 use
Thanks for the review!
On Thu, Feb 10, 2011 at 11:25 PM, Magnus Hagander mag...@hagander.net 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
On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
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 that
On 02/14/2011 01:27 AM, Tom Lane wrote:
Magnus Hagandermag...@hagander.net 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
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 is
hi,
all of the following answers are with the patch you provided in
other mail applied.
YAMAMOTO Takashi y...@mwd.biglobe.ne.jp 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
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
45 matches
Mail list logo
