On 21/09/10 04:18, Josh Berkus wrote:
... or did we just forget to remove it?
Backwards-compatibility? ;-) There hasn't been any pressing reason to
remove it.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list
On Mon, 2010-09-20 at 22:42 +0100, Thom Brown wrote:
On 20 September 2010 22:14, Robert Haas robertmh...@gmail.com wrote:
Well, if you need to talk to all the other standbys and see who has
the furtherst-advanced xlog pointer, it seems like you have to have a
list somewhere of who they all
On Tue, Sep 21, 2010 at 06:00, Tom Lane t...@sss.pgh.pa.us wrote:
Back here I asked what we were going to do about .gitignore files:
http://archives.postgresql.org/pgsql-hackers/2010-08/msg01232.php
The thread died off when the first git conversion attempt crashed and
burned; but not before it
On Sat, Sep 18, 2010 at 4:36 AM, Dimitri Fontaine
dfonta...@hi-media.com wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Fri, 2010-09-17 at 21:20 +0900, Fujii Masao wrote:
What synchronization level does each combination of sync_replication
and sync_replication_service lead to?
There are
Hi,
Tom Lane írta:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
It doesn't feel right to always accept PQputCopyData in COPY OUT mode,
though. IMHO there should be a new COPY IN+OUT mode.
Yeah, I was going to make the same complaint. Breaking basic
Simon Riggs írta:
On Fri, 2010-09-17 at 18:22 +0900, Fujii Masao wrote:
On Fri, Sep 17, 2010 at 5:09 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
That said, there's a few small things that can be progressed regardless of
the details of synchronous replication.
On 09/21/2010 02:49 AM, Robert Haas wrote:
OK. At least for me, what is important is not only how many GUCs
there are but how likely they are to require tuning and how easy it
will be to know what the appropriate value is. It seems fairly easy
to tune the maximum number of background
Robert Haas robertmh...@gmail.com writes:
So, here, we have two quite different things to be concerned
about. First is the configuration, and I say that managing a distributed
setup will be easier for the DBA.
Yeah, I disagree with that, but I suppose it's a question of opinion.
I'd be
On Sun, Sep 19, 2010 at 7:20 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Sep 18, 2010 at 5:42 PM, Josh Berkus j...@agliodbs.com wrote:
There are considerable benefits to having a standby registry with a
table-like interface. Particularly, one where we could change
replication via
On 21 September 2010 09:29, Fujii Masao masao.fu...@gmail.com wrote:
On Sun, Sep 19, 2010 at 7:20 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Sep 18, 2010 at 5:42 PM, Josh Berkus j...@agliodbs.com wrote:
There are considerable benefits to having a standby registry with a
table-like
On Tue, Sep 21, 2010 at 9:34 AM, Thom Brown t...@linux.com wrote:
I really don't think an XML config would improve anything. In fact it
would just introduce more ways to break the config by the mere fact it
has to be well-formed. I'd be in favour of one similar to
pg_hba.conf, because then,
Guillaume Lelarge írta:
Le 15/07/2010 17:48, Joshua D. Drake a écrit :
On Thu, 2010-07-15 at 16:20 +0100, Simon Riggs wrote:
On Thu, 2010-07-15 at 11:05 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
The biggest turn off that most people
On 21 September 2010 09:37, Dave Page dp...@pgadmin.org wrote:
On Tue, Sep 21, 2010 at 9:34 AM, Thom Brown t...@linux.com wrote:
I really don't think an XML config would improve anything. In fact it
would just introduce more ways to break the config by the mere fact it
has to be well-formed.
Sorry, I missed a bug when we create a typed table using composite
type which has been altered.
postgres=# CREATE TYPE comp_1 AS (x int, y int, z int);
CREATE TYPE
postgres=# ALTER TYPE comp_1 DROP ATTRIBUTE y;
ALTER TYPE
postgres=# CREATE TABLE t1 OF comp_1;
ERROR: cache lookup
On Mon, Sep 20, 2010 at 3:27 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
However, the wait forever behavior becomes useful if you have a monitoring
application outside the DB that decides when enough is enough and tells the
DB that the slave can be considered dead. So wait
On 21/09/10 11:52, Thom Brown wrote:
My fear would be standby.conf would be edited by users who don't
really know XML and then we'd have 3 different styles of config to
tell the user to edit.
I'm not a big fan of XML either. That said, the format could use some
hierarchy. If we add many more
On Tue, Sep 21, 2010 at 05:38, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Ok, I've pushed a new repository to both gitmaster and the
postgresql-migration.git mirror, that has this setting.
NOTE! Do a complete wipe of your repository before you clone this
On Tue, Sep 21, 2010 at 1:06 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I suppose you already know my votes, but here they are again just in case.
...
Centralize.
...
All the build products in a normal build.
I don't understand your preference for this
On Tue, Sep 21, 2010 at 4:52 AM, Boszormenyi Zoltan z...@cybertec.at wrote:
I think it's related to making this work:
SELECT * FROM db.schema.table;
Which is a non-starter, I think. Every function in the system that
thinks an OID uniquely identifies a database object would need to
modified,
On Tue, Sep 21, 2010 at 13:12, Robert Haas robertmh...@gmail.com wrote:
On Tue, Sep 21, 2010 at 1:06 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I suppose you already know my votes, but here they are again just in case.
...
Centralize.
...
All the build
license, just to be on the safe side.
Sorry for my insincere manner. Surely I read his code.
Do you know his contact address? I cannot find it...
--
Itagaki Takahiro
basic_json-20100921.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On Tue, Sep 21, 2010 at 8:38 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
Sorry for my insincere manner. Surely I read his code.
Do you know his contact address? I cannot find it...
It alarms me quite a bit that someone who is a committer on this
project would accidentally copy code
On Tue, Sep 21, 2010 at 9:54 PM, Robert Haas robertmh...@gmail.com wrote:
It alarms me quite a bit that someone who is a committer on this
project would accidentally copy code from another project with a
different license into PostgreSQL. How does that happen? And how
much got copied,
On Tue, Sep 21, 2010 at 4:23 AM, Markus Wanner mar...@bluegap.ch wrote:
On 09/21/2010 02:49 AM, Robert Haas wrote:
OK. At least for me, what is important is not only how many GUCs
there are but how likely they are to require tuning and how easy it
will be to know what the appropriate value
On tis, 2010-09-21 at 00:55 -0400, Robert Haas wrote:
One of the infelicities of
git is that 'git status' shows the untracked files at the bottom. So
if you have lots of unignored stuff floating around, the information
about which files you've actually changed or added to the index
scrolls
On Tue, Sep 21, 2010 at 16:27, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2010-09-21 at 00:55 -0400, Robert Haas wrote:
One of the infelicities of
git is that 'git status' shows the untracked files at the bottom. So
if you have lots of unignored stuff floating around, the information
On tis, 2010-09-21 at 00:00 -0400, Tom Lane wrote:
3. What are the ignore filesets *for*, in particular should they list
just the derived files expected in a distribution tarball, or all the
files in the set of build products in a normal build?
My personal vote: Forget the whole thing.
I have
On Tue, Sep 21, 2010 at 8:12 AM, Magnus Hagander mag...@hagander.net wrote:
Breaking it up was quite trivial. Here's what I came up with after
building on my box. I'm sure there are some on other platforms showing
up, but this should be the majority.
I just realized it does not include
Peter Eisentraut pete...@gmx.net writes:
On tis, 2010-09-21 at 00:00 -0400, Tom Lane wrote:
3. What are the ignore filesets *for*, in particular should they list
just the derived files expected in a distribution tarball, or all the
files in the set of build products in a normal build?
My
On Mon, Sep 20, 2010 at 11:31 AM, Colin 't Hart colinth...@gmail.com wrote:
I think to_date is the wrong gadget to use here. You should probably be
using the date input routine and trapping any data exception. e.g.:
test_date := date_in(textout(some_text));
In plpgsql you'd put that
On Tue, Sep 21, 2010 at 11:02 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
On tis, 2010-09-21 at 00:00 -0400, Tom Lane wrote:
3. What are the ignore filesets *for*, in particular should they list
just the derived files expected in a distribution tarball, or
On tis, 2010-09-21 at 14:12 +0200, Magnus Hagander wrote:
Breaking it up was quite trivial. Here's what I came up with after
building on my box. I'm sure there are some on other platforms showing
up, but this should be the majority.
Note that shared library names are platform dependent.
--
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 21/09/10 11:52, Thom Brown wrote:
My fear would be standby.conf would be edited by users who don't
really know XML and then we'd have 3 different styles of config to
tell the user to edit.
I'm not a big fan of XML either.
...
On 21/09/10 18:02, Tom Lane wrote:
Peter Eisentrautpete...@gmx.net writes:
On tis, 2010-09-21 at 00:00 -0400, Tom Lane wrote:
3. What are the ignore filesets *for*, in particular should they list
just the derived files expected in a distribution tarball, or all the
files in the set of build
On Tue, Sep 21, 2010 at 11:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 21/09/10 11:52, Thom Brown wrote:
My fear would be standby.conf would be edited by users who don't
really know XML and then we'd have 3 different styles of
Magnus Hagander mag...@hagander.net writes:
Breaking it up was quite trivial. Here's what I came up with after
building on my box. I'm sure there are some on other platforms showing
up, but this should be the majority.
I just realized it does not include contrib, but's that a mechanical
copy
I just went to do my usual merge from the git version of HEAD (at
git://git.postgresql.org/git/postgresql.git), and it seemed to be
doing an awful lot of work to prepare to attempt the merge. That
leads me to think that the newly converted git, or a copy of it, is
now at that location, which is
On Mon, Sep 20, 2010 at 05:48:40PM -0700, fazool mein wrote:
Hi,
I want to shut down the server under certain conditions that can be
checked inside a backend process. For instance, while running
symmetric
Synchronous?
replication, if the primary dies, I want the the walreceiver to
On 09/21/2010 03:46 PM, Robert Haas wrote:
Wait, are we in violent agreement here? An overall limit on the
number of parallel jobs is exactly what I think *does* make sense.
It's the other knobs I find odd.
Note that the max setting I've been talking about here is the maximum
amount of *idle*
On 09/21/2010 11:20 AM, Heikki Linnakangas wrote:
On 21/09/10 18:02, Tom Lane wrote:
Peter Eisentrautpete...@gmx.net writes:
On tis, 2010-09-21 at 00:00 -0400, Tom Lane wrote:
3. What are the ignore filesets *for*, in particular should they list
just the derived files expected in a
On 21/09/10 18:28, Kevin Grittner wrote:
I just went to do my usual merge from the git version of HEAD (at
git://git.postgresql.org/git/postgresql.git), and it seemed to be
doing an awful lot of work to prepare to attempt the merge. That
leads me to think that the newly converted git, or a copy
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
I'm not excited about inventing an API with just one use-case;
it's unlikely that you actually end up with anything generally
useful. (SHM_QUEUE seems like a case in point...) Especially
when there are so many other constraints on what
Robert Haas robertmh...@gmail.com writes:
I think it would be useful to have a way of testing whether a cast to
a given type will succeed. The biggest problem with the
exception-catching method is not that it requires writing a function
(which, IMHO, is no big deal) but that exception
On Tue, Sep 21, 2010 at 11:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I think it would be useful to have a way of testing whether a cast to
a given type will succeed. The biggest problem with the
exception-catching method is not that it requires
On Tue, Sep 21, 2010 at 11:31 AM, Markus Wanner mar...@bluegap.ch wrote:
On 09/21/2010 03:46 PM, Robert Haas wrote:
Wait, are we in violent agreement here? An overall limit on the
number of parallel jobs is exactly what I think *does* make sense.
It's the other knobs I find odd.
Note that
On 09/21/2010 11:28 AM, Kevin Grittner wrote:
I just went to do my usual merge from the git version of HEAD (at
git://git.postgresql.org/git/postgresql.git), and it seemed to be
doing an awful lot of work to prepare to attempt the merge. That
leads me to think that the newly converted git, or
* Andrew Dunstan and...@dunslane.net [100921 11:59]:
I was just mentioning to Magnus a couple of hours ago on chat that this
would create headaches for some people.
Basically, AIUI, you have to move the old repo aside and freshly clone
the new repo.
I haven't migrated my development
Andrew Dunstan and...@dunslane.net wrote:
Basically, AIUI, you have to move the old repo aside and freshly
clone the new repo.
I was assuming that, but it's good to have confirmation. What about
my repo at
http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git ?
Can that be reset
A starvation scenario is what worries me:
Lets say we have a slow complex transaction with many tables involved.
Concurrently smaller transactions begins and commits .
Wouldn't it be possible for a starvation scenario where the slower
transaction will
never run to completion but give a
On September 21, 2010 12:08:49 pm Kevin Grittner wrote:
Andrew Dunstan and...@dunslane.net wrote:
Basically, AIUI, you have to move the old repo aside and freshly
clone the new repo.
I was assuming that, but it's good to have confirmation. What about
my repo at
On 09/21/2010 12:07 PM, Aidan Van Dyk wrote:
But probably the easiest way, if you have a nice clean history, is to
use git formatpatch. This produces a nice series of patches, with
your commit message, and content, and dates, all preserved, ready for
re-applying (git am can do that
At 2010-09-21 11:59:09 -0400, and...@dunslane.net wrote:
However, that does mean losing the private commit history. I'm not
sure much can be done about that, unless you migrate each commit
separately, which could be painful.
It doesn't have to be painful.
Determine what patches from the old
At 2010-09-21 11:02:30 -0400, t...@sss.pgh.pa.us wrote:
So you really do need git ignore to ignore all build products;
otherwise you'll have lots of chatter in git status.
Right.
I usually put build products into a top-level build directory and put
build/ in my top-level .gitignore (but I
Magnus Hagander mag...@hagander.net writes:
On Tue, Sep 21, 2010 at 05:38, Tom Lane t...@sss.pgh.pa.us wrote:
For the archives' sake, below are the missing historical tags that
match available tarballs, plus re-instantiation of the Release_2_0
and Release_2_0_0 tags on non-manufactured
On Tue, Sep 21, 2010 at 12:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Tue, Sep 21, 2010 at 05:38, Tom Lane t...@sss.pgh.pa.us wrote:
For the archives' sake, below are the missing historical tags that
match available tarballs, plus re-instantiation
I wrote:
Magnus Hagander mag...@hagander.net writes:
Go for it.
Done.
Having done that, I now realize that the historical tag release-6-3
is identical to what I applied as REL6_3. It would probably be
reasonable to remove release-6-3, if that's still possible, but
I'm not clear on how.
Robert Haas robertmh...@gmail.com writes:
On Tue, Sep 21, 2010 at 12:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Done. The commit hook seems to be a bit verbose about that sort of
thing ... is it worth trying to collapse the pgsql-committers messages
into one email?
I was thinking the same
On Tue, Sep 21, 2010 at 18:47, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Sep 21, 2010 at 12:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Done. The commit hook seems to be a bit verbose about that sort of
thing ... is it worth trying to collapse the
Magnus Hagander mag...@hagander.net writes:
On Tue, Sep 21, 2010 at 18:47, Tom Lane t...@sss.pgh.pa.us wrote:
True. We will be creating four or five tags at a time during
back-branch update cycles, but those might well arrive in separate
pushes anyway, depending on how Marc chooses to arrange
Dan S strd...@gmail.com wrote:
A starvation scenario is what worries me:
Lets say we have a slow complex transaction with many tables
involved. Concurrently smaller transactions begins and commits .
Wouldn't it be possible for a starvation scenario where the slower
transaction will
Excerpts from Robert Haas's message of mar sep 21 11:56:51 -0400 2010:
On Tue, Sep 21, 2010 at 11:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The problem here is that putting the exception handling in C doesn't
make things any better: it's still slow and inefficient. And in the
general case
On Tue, Sep 21, 2010 at 12:57 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
What is the likelyhood that there exists an update pattern that
always give the failure in the slow transaction ?
I don't know how to quantify that. I haven't seen it yet in
testing, but many of my tests so
I looked at this patch a bit. I'm fairly unhappy that it seems to be
inventing a brand new mechanism to do something the ts parser can
already do. Why didn't you code the url-part mechanism using the
existing support for compound words?
I am not familiar with compound word implementation
On Tue, Sep 21, 2010 at 17:27, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Breaking it up was quite trivial. Here's what I came up with after
building on my box. I'm sure there are some on other platforms showing
up, but this should be the majority.
I just
Excerpts from Magnus Hagander's message of lun sep 20 12:49:28 -0400 2010:
Committers can (and should! please test!) clone from git clone
ssh://g...@gitmaster.postgresql.org/postgresql.git.
Please do *NOT* commit or push anything to this repository yet though:
The repo is there - all the
Your changes are somewhat fine. It will get you tokens with _
characters in it. However, it is not nice to mix your new token with
existing token like NUMWORD. Give a new name to your new type of
token .. probably UnderscoreWord. Then on seeing _, move to a state
that can identify the new token.
On 21/09/10 20:32, Alvaro Herrera wrote:
What I find is that after doing the local clone for the branch, i.e.
git clone postgresql REL9_0_STABLE
this clones only the master branch somehow, not the other branches; so
when I later run
git checkout REL9_0_STABLE
on that clone, it fails with
Alvaro Herrera alvhe...@commandprompt.com writes:
On Tue, Sep 21, 2010 at 11:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The problem here is that putting the exception handling in C doesn't
make things any better:
So we could refactor the input functions so that there's an internal
function
On Tue, Sep 21, 2010 at 1:32 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Magnus Hagander's message of lun sep 20 12:49:28 -0400 2010:
Committers can (and should! please test!) clone from git clone
ssh://g...@gitmaster.postgresql.org/postgresql.git.
Please do *NOT*
On Tue, Sep 21, 2010 at 6:02 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
So we could refactor the input functions so that there's an internal
function that returns the accepted datum in the OK case and an ErrorData
for the failure case. The regular input function would just throw the
Magnus Hagander mag...@hagander.net writes:
On Tue, Sep 21, 2010 at 17:27, Tom Lane t...@sss.pgh.pa.us wrote:
Why does this entry have a / when none of the rest do? Shouldn't
we be consistent about that?
We should. I've removed it.
The difference is that zic matches zic in any subdirectory
On Mon, Sep 20, 2010 at 9:44 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Sep 21, 2010 at 9:48 AM, fazool mein fazoolm...@gmail.com wrote:
Hi,
I want to shut down the server under certain conditions that can be
checked
inside a backend process. For instance, while running
On Tue, Sep 21, 2010 at 8:32 AM, David Fetter da...@fetter.org wrote:
On Mon, Sep 20, 2010 at 05:48:40PM -0700, fazool mein wrote:
Hi,
I want to shut down the server under certain conditions that can be
checked inside a backend process. For instance, while running
symmetric
On Tue, Sep 21, 2010 at 1:45 PM, Greg Stark gsst...@mit.edu wrote:
On Tue, Sep 21, 2010 at 6:02 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
So we could refactor the input functions so that there's an internal
function that returns the accepted datum in the OK case and an ErrorData
Elvis Pranskevichus e...@prans.net wrote:
Here's a quick and easy way to move dev history to a new repo:
$ cd postgresql.old
$ git checkout yourbranch
# stream your commits into a patch mailbox
$ git format-patch --stdout master..HEAD patches.mbox
# switch to the new repo
$ cd
On Tue, Sep 21, 2010 at 20:01, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Elvis Pranskevichus e...@prans.net wrote:
Here's a quick and easy way to move dev history to a new repo:
$ cd postgresql.old
$ git checkout yourbranch
# stream your commits into a patch mailbox
$ git
On Tue, 2010-09-21 at 16:58 +0900, Fujii Masao wrote:
On Sat, Sep 18, 2010 at 4:36 AM, Dimitri Fontaine
dfonta...@hi-media.com wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Fri, 2010-09-17 at 21:20 +0900, Fujii Masao wrote:
What synchronization level does each combination of
Excerpts from Tom Lane's message of mar sep 21 13:41:32 -0400 2010:
Alvaro Herrera alvhe...@commandprompt.com writes:
On Tue, Sep 21, 2010 at 11:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The problem here is that putting the exception handling in C doesn't
make things any better:
So we
On 21/09/10 21:01, Kevin Grittner wrote:
That still leaves me wondering how I get that out to my public git
repo without someone resetting it on the server. Or do I have the
ability to clean out the old stuff at:
ssh://g...@git.postgresql.org/users/kgrittn/postgres.git
so that I can push the
Robert Haas robertmh...@gmail.com writes:
On Tue, Sep 21, 2010 at 1:32 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I tried to follow the instructions on the Wiki but they didn't work.
Oops. I left out a step. Fixed.
While we're discussing possible errors on that page ... at the
On Tue, Sep 21, 2010 at 19:46, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Tue, Sep 21, 2010 at 17:27, Tom Lane t...@sss.pgh.pa.us wrote:
Why does this entry have a / when none of the rest do? Shouldn't
we be consistent about that?
We should. I've
Magnus Hagander mag...@hagander.net wrote:
The cleanest is probably if I wipe the repo on git.postgresql.org
for you, and you then re-push from scratch. Does thta work for
you?
Sure. Thanks.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On 21/09/10 21:10, Tom Lane wrote:
While we're discussing possible errors on that page ... at the bottom of
the page under the multiple workdirs alternative are these recipes for
re-syncing your local checkouts:
git checkout REL9_0_STABLE
git pull
git checkout master
On tis, 2010-09-21 at 11:27 -0400, Tom Lane wrote:
rather than global ignore patterns for *.a and *.so.[0-9]
Probably rather *.so.[0-9.]+
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Tue, Sep 21, 2010 at 20:16, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Magnus Hagander mag...@hagander.net wrote:
The cleanest is probably if I wipe the repo on git.postgresql.org
for you, and you then re-push from scratch. Does thta work for
you?
Sure. Thanks.
done, should be
Everyone using git diff in color mode will already or soon be aware that
psql, for what I can only think is an implementation oversight, produces
trailing whitespace in the table headers, like this:
two | f1 $
-+$
| asdfghjkl;$
| d34aaasdf$
(2 rows)$
($ is the
On tis, 2010-09-21 at 20:04 +0200, Magnus Hagander wrote:
The cleanest is probably if I wipe the repo on git.postgresql.org for
you, and you then re-push from scratch.
We probably need a solution that doesn't require manual intervention for
everyone separately.
--
Sent via pgsql-hackers
Magnus Hagander mag...@hagander.net writes:
Have we decided to do this? If so, I'll start backpatching it...
Yeah, go for it.
BTW, a look at the recommended GitExclude on the wiki suggests that
we need these two additional global exclusions:
*.mo... for NLS builds
On 09/21/2010 05:59 PM, Robert Haas wrote:
Oh, wow. Is there another limit on the total number of bgworkers?
There currently are three GUCs that control bgworkers:
max_background_workers
min_spare_background_workers
max_spare_background_workers
The first replaces the former
On 09/21/2010 02:10 PM, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
On Tue, Sep 21, 2010 at 1:32 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I tried to follow the instructions on the Wiki but they didn't work.
Oops. I left out a step. Fixed.
While we're discussing
On Tue, Sep 21, 2010 at 20:21, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2010-09-21 at 11:27 -0400, Tom Lane wrote:
rather than global ignore patterns for *.a and *.so.[0-9]
Probably rather *.so.[0-9.]+
Any particular reason not to just do .so.*?
--
Magnus Hagander
Me:
On Tue, Sep 21, 2010 at 20:28, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2010-09-21 at 20:04 +0200, Magnus Hagander wrote:
The cleanest is probably if I wipe the repo on git.postgresql.org for
you, and you then re-push from scratch.
We probably need a solution that doesn't require
Hi.
This is a follow up and updated patch on several old discussions:
http://archives.postgresql.org/pgsql-hackers/2009-07/msg01065.php
http://archives.postgresql.org/pgsql-admin/2010-04/msg00164.php
http://archives.postgresql.org/pgsql-hackers/2009-06/msg00831.php
First patch:
On Tue, Sep 21, 2010 at 20:29, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Have we decided to do this? If so, I'll start backpatching it...
Yeah, go for it.
BTW, a look at the recommended GitExclude on the wiki suggests that
we need these two additional
Magnus Hagander mag...@hagander.net writes:
On Tue, Sep 21, 2010 at 20:21, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2010-09-21 at 11:27 -0400, Tom Lane wrote:
rather than global ignore patterns for *.a and *.so.[0-9]
Probably rather *.so.[0-9.]+
Any particular reason not to just do
On Tue, Sep 21, 2010 at 20:59, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Tue, Sep 21, 2010 at 20:21, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2010-09-21 at 11:27 -0400, Tom Lane wrote:
rather than global ignore patterns for *.a and *.so.[0-9]
At 2010-09-21 12:45:20 -0400, t...@sss.pgh.pa.us wrote:
Having done that, I now realize that the historical tag release-6-3
is identical to what I applied as REL6_3. It would probably be
reasonable to remove release-6-3, if that's still possible, but
I'm not clear on how.
You can safely
Magnus Hagander mag...@hagander.net writes:
On Tue, Sep 21, 2010 at 20:59, Tom Lane t...@sss.pgh.pa.us wrote:
Just paranoia, I guess. I can't actually see a reason why we'd have
any committable files in the tree matching that pattern. OTOH, we
probably also need the same type of pattern for
On Tue, Sep 21, 2010 at 21:32, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Tue, Sep 21, 2010 at 20:59, Tom Lane t...@sss.pgh.pa.us wrote:
Just paranoia, I guess. I can't actually see a reason why we'd have
any committable files in the tree matching that
Magnus Hagander mag...@hagander.net writes:
My gitignore manpage doesn't say anything about supporting regular
expressions at all. And actually adding the line proposed by Peter
doesn't work.
Yeah, I was wondering about that. They're meant to be shell patterns
not regexps, I think.
What
1 - 100 of 175 matches
Mail list logo
