On tis, 2010-09-21 at 18:31 -0400, Bruce Momjian wrote:
> Also, doesn't some SQL standard require oids, so we should have a way
> to enable them by default for all tables?
>From some DB2 example:
CREATE TYPE BusinessUnit_t AS
(Name VARCHAR(20),
Headcount INT);
CREATE TABLE BusinessUnit
On September 21, 2010 11:47:30 pm Tom Lane wrote:
> Bruce Momjian writes:
> > However, keep in mind that creating a branch in every existing backpatch
> > branch is going to create even more backpatching monkey-work.
>
> Monkey-work is scriptable though. It'll all be worth it if git
> cherry-pic
On 22/09/10 04:20, Tom Lane wrote:
Okay, so now that I've actually done a couple of multi-branch commits...
I'm using the multiple-work-directory arrangement suggested on our wiki
page. The work flow seems to boil down to:
* Prepare patch in master
* Stage patch with git add
* git diff --stage
On sön, 2010-09-19 at 13:51 -0400, Tom Lane wrote:
> Hmm. If we had a \dnS option, what I would sorta expect it to do is
> show the "system" schemas pg_catalog and information_schema. The
> toast
> and temp schemas seem like a different category somehow. On the other
> hand, if we did it like th
On Sep 21, 2010, at 8:19 PM, Tom Lane wrote:
> You sure about the "staged" part?
Yes, I do it all the time (I make a lot of mistakes).
> Offhand I think I like Andrew's recommendation of a shortlived branch
> better. In essence your idea is using the tip of "master" itself as a
> shortlived bra
2010/9/22 Hitoshi Harada :
> 2010/9/22 Pavel Stehule :
>> Hello
>>
>> I found probably hard problem in cooperation with window functions :(
>>
>> tuplesort_begin_datum creates child context inside aggcontext. This
>> context is used for tuplestore. But when this function is called from
>> WindowAgg
On 2010-09-22 04:33, Itagaki Takahiro wrote:
On Wed, Sep 22, 2010 at 3:44 AM, Jesper Krogh wrote:
Command to set "tuples_per_page" is:
ALTER TABLE set (tuples_per_page = X)
where 1<= X<= 32.
The tuples_per_page means *minimal* number of tuples in a page, right?
A page may contain mo
2010/9/22 Hitoshi Harada :
> 2010/9/22 Pavel Stehule :
>> 2010/9/21 Robert Haas :
>>> On Tue, Sep 21, 2010 at 4:28 PM, Pavel Stehule
>>> wrote:
> * Cosmetic coding style should be more appropriate, including trailing
> white spaces and indentation positions.
can you specify wher
On Sep 21, 2010, at 11:19 PM, Tom Lane wrote:
>
> Offhand I think I like Andrew's recommendation of a shortlived branch
> better. In essence your idea is using the tip of "master" itself as a
> shortlived branch, which is maybe a bit too cute. If you get distracted
> and need to do something el
Bruce Momjian writes:
> However, keep in mind that creating a branch in every existing backpatch
> branch is going to create even more backpatching monkey-work.
Monkey-work is scriptable though. It'll all be worth it if git
cherry-pick is even marginally smarter about back-merging the actual
pat
Hi,
In ctid, there are the block num, and the tuple offset inside the block.
How can I know the maximum number of tuples in a block?
The block size would be BLCKSZ.
I am not quite sure where is the best place to find the size of the tuple in
a table.
Thanks
--
Pei
Bruce Momjian writes:
> The problem is that the cherrypicks will often have to modified, and it
> can take +20 minutes to resolve some of them.
To say nothing of actually *testing* the patch in each branch, which is
Strongly Recommended if it didn't apply cleanly. I've not infrequently
spent man
David Christensen writes:
> Is the issue here the clock time spent between the commits, i.e., the
> possibility that someone is going to push to the specific branches in between
> or the date/time that the commit itself displays? Because if it's
> specifically commit time that's at issue, I be
Bruce Momjian wrote:
> > Offhand I think I like Andrew's recommendation of a shortlived branch
> > better. In essence your idea is using the tip of "master" itself as a
> > shortlived branch, which is maybe a bit too cute. If you get distracted
>
> True.
However, keep in mind that creating a br
Tom Lane wrote:
> "David E. Wheeler" writes:
> > On Sep 21, 2010, at 8:01 PM, Bruce Momjian wrote:
> >>> Then they'd all be patched and staged.
> >>
> >> If I understand correctly, that 'git reset' will mark all branch changes
> >> as staged but not committed, and then you can commit all branches
"David E. Wheeler" writes:
> On Sep 21, 2010, at 8:01 PM, Bruce Momjian wrote:
>>> Then they'd all be patched and staged.
>>
>> If I understand correctly, that 'git reset' will mark all branch changes
>> as staged but not committed, and then you can commit all branches at
>> once and push it. Is
David E. Wheeler wrote:
>
> On Sep 21, 2010, at 8:01 PM, Bruce Momjian wrote:
>
> >> Then they'd all be patched and staged.
> >
> > If I understand correctly, that 'git reset' will mark all branch changes
> > as staged but not committed, and then you can commit all branches at
> > once and push
2010/9/22 Pavel Stehule :
> Hello
>
> I found probably hard problem in cooperation with window functions :(
>
> tuplesort_begin_datum creates child context inside aggcontext. This
> context is used for tuplestore. But when this function is called from
> WindowAgg_Aggregates context - someone drops
David Christensen wrote:
> > If I commit in master
> > before I start working on 9.0, and so on back, then the commits will be
> > separated in time by a significant amount, thus destroying any chance of
> > having git_topo_order recognize them as related. So we're back up
> > against the problem
On Sep 21, 2010, at 8:01 PM, Bruce Momjian wrote:
>> Then they'd all be patched and staged.
>
> If I understand correctly, that 'git reset' will mark all branch changes
> as staged but not committed, and then you can commit all branches at
> once and push it. Is that right?
Right.
David
--
> If I commit in master
> before I start working on 9.0, and so on back, then the commits will be
> separated in time by a significant amount, thus destroying any chance of
> having git_topo_order recognize them as related. So we're back up
> against the problem of git not really understanding the
David E. Wheeler wrote:
> On Sep 21, 2010, at 6:20 PM, Tom Lane wrote:
>
> > While this isn't much worse than what I was used to with CVS, it's
> > definitely not better. I think that I could simplify transferring the
> > patch back to older branches if I could use git cherry-pick. However,
> >
Hi Tom,
The bitmapset works for me.
I want to implement the operator for the following query:
Select * from a left join b on a.id = b.id order by b.id;
In a left outer join, I want the tuples that have matches in the inner table
appear first. So, the order by clause is need.
If there is a index
On Wed, Sep 22, 2010 at 2:50 AM, fazool mein wrote:
> Yes, I'll be modifying the code. In the walreceiver, I used the following to
> send a shutdown to the postmaster:
>
> kill(getppid(), SIGTERM);
You can use the global variable "PostmasterPid" instead of getppid.
There are three types of shutdo
On Wed, Sep 22, 2010 at 3:44 AM, Jesper Krogh wrote:
> Command to set "tuples_per_page" is:
> ALTER TABLE set (tuples_per_page = X)
> where 1 <= X <= 32.
The tuples_per_page means *minimal* number of tuples in a page, right?
A page may contain more tuples when the size of tuples are small enough
At 2010-09-21 17:53:22 -0400, t...@sss.pgh.pa.us wrote:
>
> > Does anyone know offhand why the sizes are so different?
>
> Magnus did
> git gc --aggressive --prune
> during the conversion. I imagine it's the --aggressive that does it.
That's not it. I ran the same git gc command on my old
2010/9/22 Pavel Stehule :
> 2010/9/21 Robert Haas :
>> On Tue, Sep 21, 2010 at 4:28 PM, Pavel Stehule
>> wrote:
* Cosmetic coding style should be more appropriate, including trailing
white spaces and indentation positions.
>>>
>>> can you specify where, please?
>>
>> I noticed a lot of
On Sep 21, 2010, at 6:20 PM, Tom Lane wrote:
> While this isn't much worse than what I was used to with CVS, it's
> definitely not better. I think that I could simplify transferring the
> patch back to older branches if I could use git cherry-pick. However,
> that only works on already-committed
On 09/21/2010 09:20 PM, Tom Lane wrote:
Okay, so now that I've actually done a couple of multi-branch commits...
I'm using the multiple-work-directory arrangement suggested on our wiki
page. The work flow seems to boil down to:
* Prepare patch in master
* Stage patch with git add
* git diff
On Wed, Sep 22, 2010 at 09:48:12AM +0900, Itagaki Takahiro wrote:
> On Wed, Sep 22, 2010 at 3:28 AM, Peter Eisentraut wrote:
> > 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 whites
On Tue, 2010-09-21 at 19:55 -0400, Robert Haas wrote:
> OK. This is one of the things I don't understand. Why does throwing
> an error imply that we need to abort the current transaction? Why
> can't we just catch the longjmp() and trundle onwards? Obviously,
> that's unsafe if a pretty wide va
(2010/09/22 5:17), Peter Eisentraut wrote:
> On tis, 2010-09-21 at 17:53 +0900, KaiGai Kohei wrote:
>> Sorry, I missed a bug when we create a typed table using composite
>> type which has been altered.
>
>> Perhaps, we also need to patch at transformOfType() to
>> skip attributes with attisdropped
Pei He writes:
> What I want to do is, for a given key return the tuples that Index scan can
> find, and return the rest tuples by a seq scan. So, I need to know which
> tuples have been returned by maintain a bitmap, and to avoid return the same
> tuple twice.
> If I can know the offset of a tup
Okay, so now that I've actually done a couple of multi-branch commits...
I'm using the multiple-work-directory arrangement suggested on our wiki
page. The work flow seems to boil down to:
* Prepare patch in master
* Stage patch with git add
* git diff --staged >/tmp/patch-head
* cd into REL9_0_S
I doesn't realized postgresql can be such clever.
Another problem I just found is after one tuple is deleted, there will be
some slots unoccupied. The offset cannot be computed even know how much
tuples a page can contain.
I need one hash table.
Thanks
--
Pei
On Tue, Sep 21, 2010 at 8:47 PM, Ke
On Wed, Sep 22, 2010 at 3:28 AM, Peter Eisentraut wrote:
> 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,
I think removing trailing whitespace in header
Pei He wrote:
> The offset is the order of a tuple in a Sequential Scan.
That's not a safe assumption. Try starting a sequential scan against
a large table on one connection; then before it finishes, start the
same query on another connection. The second query joins the one
already in progre
Hi Szymon, Kevin,
The offset is the order of a tuple in a Sequential Scan.
What I want to do is, for a given key return the tuples that Index scan can
find, and return the rest tuples by a seq scan. So, I need to know which
tuples have been returned by maintain a bitmap, and to avoid return the sa
> Crazy idea, but could we use format like postgresql.conf by extending
> postgresql.conf syntax, e.g.:
>
> server1.failover = false
> server1.keep_connect = true
>
Why is this in the config file at all. It should be:
synchronous_replication = TRUE/FALSE
then
ALTER CLUSTER ENABLE
On September 21, 2010 07:32:57 pm Kevin Grittner wrote:
> Elvis Pranskevichus wrote:
> > # apply the "patch mailbox"
> > $ git am ../postgresql.old/patches.mbox
>
> That's not working for me.
>
> Applying: Provide two macros for categorizing current transaction
> isolation level (IsXactIsoLevelX
> That said, the timeout option also feels a bit wishy-washy to me. With a
> timeout, acknowledgment of a commit means "your transaction is safely
> committed in the master and slave. Or not, if there was some glitch with
> the slave". That doesn't seem like a very useful guarantee; if you're
> ha
Robert Haas wrote:
> On Tue, Sep 21, 2010 at 7:05 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> I don't understand the argument that we need type input functions to
> >> be protected by a savepoint. ?That seems crazy to me. ?We're taking a
> >> huge performance penalty here to protect against
On Tue, Sep 21, 2010 at 7:05 PM, Tom Lane wrote:
> Robert Haas writes:
>> I don't understand the argument that we need type input functions to
>> be protected by a savepoint. That seems crazy to me. We're taking a
>> huge performance penalty here to protect against something that seems
>> insan
Robert Haas wrote:
> On Tue, Sep 21, 2010 at 11:12 AM, Tom Lane wrote:
> > Heikki Linnakangas 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
> >>> tel
Andres Freund writes:
> On Wednesday 22 September 2010 01:05:39 Tom Lane wrote:
>> Just for starters, what of a palloc() failure?
> Uhm. Isnt a palloc failure a really, really bad example because it will kill
> the session anyway? FATAL+ is not relevant in that context, right?
Huh? It's not fa
Elvis Pranskevichus wrote:
> # apply the "patch mailbox"
> $ git am ../postgresql.old/patches.mbox
That's not working for me.
Applying: Provide two macros for categorizing current transaction
isolation level (IsXactIsoLevelXactSnapshotBased and
IsXactIsoLevelFullySerializable) to replace the
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of mar sep 21 13:41:32 -0400 2010:
>> ...never make this work for anything more complicated than say float8in().
> ... which is what people want anyway. I mean, the day someone requests
> is_sthcomplex, we could happily tell them that the
On Wednesday 22 September 2010 01:05:39 Tom Lane wrote:
> Robert Haas writes:
> > I don't understand the argument that we need type input functions to
> > be protected by a savepoint. That seems crazy to me. We're taking a
> > huge performance penalty here to protect against something that seems
Robert Haas writes:
> I don't understand the argument that we need type input functions to
> be protected by a savepoint. That seems crazy to me. We're taking a
> huge performance penalty here to protect against something that seems
> insane to me in the first instance. Not to mention cutting o
Pei He wrote:
> When I using an index scan, can I get the offset of the tuple in
> the table?
Well, regardless of the type of scan, you can select the ctid
column, which gives the block number and the tuple number within the
block.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hacke
Bruce Momjian writes:
> Tom Lane wrote:
>> Actually, I can think of a fairly sizable reason not to remove it:
>> pg_dump issues "SET default_with_oids" commands in its scripts, and
>> has done for lo these many years. So you'd be breaking backwards
>> compatibility with even-quite-recent dumps.
Tom Lane wrote:
> I wrote:
> > Josh Berkus writes:
> >> On 9/20/10 10:59 PM, Heikki Linnakangas wrote:
> >>> Backwards-compatibility? ;-) There hasn't been any pressing reason to
> >>> remove it.
>
> > Mind you, it wouldn't take a *big* reason to persuade me to remove it.
> > But bigger than that
On Tue, 2010-09-21 at 18:05 -0400, Tom Lane wrote:
> Josh Berkus writes:
> > On 9/20/10 10:59 PM, Heikki Linnakangas wrote:
> >> Backwards-compatibility? ;-) There hasn't been any pressing reason to
> >> remove it.
>
> > Any application which needed it (like OpenACS) just got broken when we
> > r
I wrote:
> Josh Berkus writes:
>> On 9/20/10 10:59 PM, Heikki Linnakangas wrote:
>>> Backwards-compatibility? ;-) There hasn't been any pressing reason to
>>> remove it.
> Mind you, it wouldn't take a *big* reason to persuade me to remove it.
> But bigger than that.
Actually, I can think of a fa
Robert Haas writes:
> On Tue, Sep 21, 2010 at 5:53 PM, Tom Lane wrote:
>> Magnus did
>> git gc --aggressive --prune
>> during the conversion. I imagine it's the --aggressive that does it.
> It's also possible that some of the history cleanup we did might have
> helped, although that's pu
Josh Berkus writes:
> On 9/20/10 10:59 PM, Heikki Linnakangas wrote:
>> Backwards-compatibility? ;-) There hasn't been any pressing reason to
>> remove it.
> Any application which needed it (like OpenACS) just got broken when we
> removed add_missing_from. Let alone the typecasting changes in 8.
On 09/21/2010 05:15 PM, Josh Berkus wrote:
On 9/20/10 10:59 PM, Heikki Linnakangas wrote:
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.
Any application which needed it (like Open
On Tue, Sep 21, 2010 at 5:53 PM, Tom Lane wrote:
> Abhijit Menon-Sen writes:
>> My new clone of git://git.postgresql.org/git/postgresql.git is 196MB,
>> whereas my old clone (last synced around the beginning of September)
>> was 285MB.
>
>> Does anyone know offhand why the sizes are so different?
Abhijit Menon-Sen writes:
> My new clone of git://git.postgresql.org/git/postgresql.git is 196MB,
> whereas my old clone (last synced around the beginning of September)
> was 285MB.
> Does anyone know offhand why the sizes are so different?
Magnus did
git gc --aggressive --prune
during t
Hi.
My new clone of git://git.postgresql.org/git/postgresql.git is 196MB,
whereas my old clone (last synced around the beginning of September)
was 285MB.
Does anyone know offhand why the sizes are so different?
-- ams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
On 21 September 2010 23:02, Pei He wrote:
> Hi,
> When I using an index scan, can I get the offset of the tuple in the table?
>
> Thanks
> --
> Pei
>
What do you mean by "the offset in the table"?
On Sep 21, 2010, at 5:26 PM, Magnus Hagander wrote:
>>
>> I doubt it, unless you want git to put lines in with the commit hash, which
>> is about as close as it gets to a version number.
> You really don't.
+1.
> Get rid of it.
+1.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hack
On Tue, Sep 21, 2010 at 23:15, Andrew Dunstan wrote:
>
>
> On 09/21/2010 05:09 PM, Tom Lane wrote:
>>
>> I was thinking of just removing it, but is there anything that ought to
>> replace it?
>
> I doubt it, unless you want git to put lines in with the commit hash, which
> is about as close as it
On 09/21/2010 05:09 PM, Tom Lane wrote:
I was thinking of just removing it, but is there anything that ought to
replace it?
I doubt it, unless you want git to put lines in with the commit hash,
which is about as close as it gets to a version number.
cheers
andrew
--
Sent via pgsql-hacker
On 9/20/10 10:59 PM, Heikki Linnakangas wrote:
> 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.
Any application which needed it (like OpenACS) just got broken when we
removed a
I was thinking of just removing it, but is there anything that ought to
replace it?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2010/9/21 Robert Haas :
> On Tue, Sep 21, 2010 at 4:28 PM, Pavel Stehule
> wrote:
>>> * Cosmetic coding style should be more appropriate, including trailing
>>> white spaces and indentation positions.
>>
>> can you specify where, please?
>
> I noticed a lot of problems in this area when working o
Hi,
When I using an index scan, can I get the offset of the tuple in the table?
Thanks
--
Pei
On Tue, Sep 21, 2010 at 4:28 PM, Pavel Stehule wrote:
>> * Cosmetic coding style should be more appropriate, including trailing
>> white spaces and indentation positions.
>
> can you specify where, please?
I noticed a lot of problems in this area when working on your \ef /
\sf patch, too. Traili
Hello
I found probably hard problem in cooperation with window functions :(
tuplesort_begin_datum creates child context inside aggcontext. This
context is used for tuplestore. But when this function is called from
WindowAgg_Aggregates context - someone drops all child context every
iteration, and
Magnus Hagander writes:
> On Tue, Sep 21, 2010 at 22:15, Tom Lane wrote:
>> Global patterns look ok to me. Thought you were going to stick leading
>> slashes on all the others?
> Oh, misunderstood. I thought the idea was just slashes in the
> top-level ones, not the leaf ones. But I'll add it t
On tis, 2010-09-21 at 17:53 +0900, KaiGai Kohei wrote:
> Sorry, I missed a bug when we create a typed table using composite
> type which has been altered.
> Perhaps, we also need to patch at transformOfType() to
> skip attributes with attisdropped.
Fixed.
> An additional question. It seems me we
On Tue, Sep 21, 2010 at 22:15, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Sep 21, 2010 at 22:11, Tom Lane wrote:
>>> So it looks like *.dylib is sufficient and we don't need anything with
>>> numbers afterwards for that variant.
>
>> Ok. Just to be clear, here's what I have now:
>
> Gl
Magnus Hagander writes:
> On Tue, Sep 21, 2010 at 22:11, Tom Lane wrote:
>> So it looks like *.dylib is sufficient and we don't need anything with
>> numbers afterwards for that variant.
> Ok. Just to be clear, here's what I have now:
Global patterns look ok to me. Thought you were going to st
I wrote:
> Magnus Hagander writes:
>> Do we know what the exact pattern would be for .sl and .dylib? Are
>> they following the same basic pattern of .sl..?
> Yes, they'll be just the same --- Makefile.shlib treats all those
> extensions alike.
I take that back. Darwin does things differently, b
On 09/21/2010 03:43 PM, Magnus Hagander wrote:
Hmm. Hold on.
My gitignore manpage doesn't say anything about supporting regular
expressions at all. And actually adding the line proposed by Peter
doesn't work.
What works is adding all of:
*.so
*.so.[0-9]
*.so.[0-9].[0-9]
That will break if t
Magnus Hagander 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 works is adding all
On Tue, Sep 21, 2010 at 21:32, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Sep 21, 2010 at 20:59, Tom Lane 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 sa
Magnus Hagander writes:
> On Tue, Sep 21, 2010 at 20:59, Tom Lane 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 .sl and .dylib,
>> so at some p
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 s
On Tue, Sep 21, 2010 at 20:59, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Sep 21, 2010 at 20:21, Peter Eisentraut 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 p
Magnus Hagander writes:
> On Tue, Sep 21, 2010 at 20:21, Peter Eisentraut 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.*?
Just paranoia, I
On Tue, Sep 21, 2010 at 20:29, Tom Lane wrote:
> Magnus Hagander 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:
>
> *.
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:
http://archives.po
On Tue, Sep 21, 2010 at 20:28, Peter Eisentraut 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 manual interve
On Tue, Sep 21, 2010 at 20:21, Peter Eisentraut 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: http://www.hagander.net
On 09/21/2010 02:10 PM, Tom Lane wrote:
Robert Haas writes:
On Tue, Sep 21, 2010 at 1:32 PM, Alvaro Herrera
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 bottom
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 autovacuum_max_wor
Magnus Hagander 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
*.dylib ...
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 mai
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 l
On Tue, Sep 21, 2010 at 20:16, Kevin Grittner
wrote:
> 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. Does thta work for
>> you?
>
> Sure. Thanks.
done, should be available for push now.
--
Magnus
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:
http://www.postgresql.org/mailpref/pgsql-hacker
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
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. Does thta work for
> you?
Sure. Thanks.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscriptio
On Tue, Sep 21, 2010 at 19:46, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Sep 21, 2010 at 17:27, Tom Lane 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" mat
Robert Haas writes:
> On Tue, Sep 21, 2010 at 1:32 PM, Alvaro Herrera
> 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 bottom of
the page under the "multiple workdi
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 r
Excerpts from Tom Lane's message of mar sep 21 13:41:32 -0400 2010:
> Alvaro Herrera writes:
> >> On Tue, Sep 21, 2010 at 11:49 AM, Tom Lane wrote:
> >>> The problem here is that putting the exception handling in C doesn't
> >>> make things any better:
>
> > So we could refactor the input functi
On Tue, 2010-09-21 at 16:58 +0900, Fujii Masao wrote:
> On Sat, Sep 18, 2010 at 4:36 AM, Dimitri Fontaine
> wrote:
> > Simon Riggs writes:
> >> On Fri, 2010-09-17 at 21:20 +0900, Fujii Masao wrote:
> >>> What synchronization level does each combination of sync_replication
> >>> and sync_replicati
1 - 100 of 174 matches
Mail list logo
