On Mon, 2010-09-20 at 18:24 -0400, Robert Haas wrote:
> I feel like that's really nice and simple.
There are already 5 separate places to configure to make streaming rep
work in a 2 node cluster (master.pg_hba.conf, master.postgresql.conf,
standby.postgresql.conf, standby.recovery.conf, password
2010/9/23 Marko Tiikkaja :
> On 2010-09-17 4:48 AM, Hitoshi Harada wrote:
>>
>> 2010/9/15 Hitoshi Harada:
>>>
>>> Well, I didn't know it is allowed. That would look like the way to go.
>>
>> I made changes to the previous version, so that it avoids to resolve
>> CTE name duplication.
>
> This patch
On Thu, Sep 23, 2010 at 04:59, Andrew Dunstan wrote:
>>> Also, couldn't we just set up the cvsserver on its own VM with a limited
>>> amount of disk space, and not worry too much about any "DOS threat"?
>>> If somebody does do this, block them and reinitialize that server.
>>
>> We could do that,
On 23/09/10 02:14, Kevin Grittner wrote:
There is a rub on the other point, though. Without transaction
information you have no way of telling whether TN committed before
T0, so you would need to assume that it did. So on this count,
there is bound to be some increase in false positives leading
On 09/22/2010 10:26 AM, Magnus Hagander wrote:
On Wed, Sep 22, 2010 at 16:23, Tom Lane wrote:
Magnus Hagander writes:
Any user can point their cvs client at the repository. And check out
an arbitrary branch, tag *or individual commit*. Doing so will create
a 50Mb sqlite database on the serv
At 2010-09-22 22:19:45 -0400, t...@sss.pgh.pa.us wrote:
>
> I can demonstrate that this is not so. Try a "git add" on such a file.
Works fine for me with v1.7.3 (no warnings, no need for add -f). What
version do you use?
If I try to add an untracked file which is already ignored, then I get
the
Abhijit Menon-Sen writes:
> At 2010-09-22 20:54:19 -0400, t...@sss.pgh.pa.us wrote:
>> However, it seems that git isn't so willing to tell you about gitignore
>> patterns that cover too much, i.e. match files that are already in the
>> repository.
> If .gitignore specifies a pattern that matches
On 23 September 2010 11:28, Abhijit Menon-Sen wrote:
>> This seems pretty dangerous, especially for people who are willing to
>> rely on "git commit -a" :-(
>
> There is no danger. "git commit -a" will commit changes to files that
> match .gitignore but are already in the repository. (I vaguely re
At 2010-09-22 20:54:19 -0400, t...@sss.pgh.pa.us wrote:
>
> However, it seems that git isn't so willing to tell you about gitignore
> patterns that cover too much, i.e. match files that are already in the
> repository.
If .gitignore specifies a pattern that matches something that's already
in the
Robert Haas writes:
> On Wed, Sep 22, 2010 at 8:54 PM, Tom Lane wrote:
>> Is there any automated sanity check that we can run to find this sort
>> of problem? I suspect that we probably have got some errors in the
>> .gitignore files, particularly in the back branches, and it would be
>> nice to
On Wed, Sep 22, 2010 at 8:54 PM, Tom Lane wrote:
> It's not hard to tell if we're missing a file that ought to be listed
> in .gitignore --- git status will find that problem soon enough.
> However, it seems that git isn't so willing to tell you about gitignore
> patterns that cover too much, i.e.
On Wed, Sep 22, 2010 at 9:00 PM, Tom Lane wrote:
> Robert Haas writes:
>> Technically, there's no reason why we can't do this for 9.1. What we
>> can do is change the name of the "time with timezone" type to
>> something like "oldtimetz", keeping the current OID. And then we can
>> add a new ty
Robert Haas writes:
> Technically, there's no reason why we can't do this for 9.1. What we
> can do is change the name of the "time with timezone" type to
> something like "oldtimetz", keeping the current OID. And then we can
> add a new type called "time with timezone". [ with large amounts of
It's not hard to tell if we're missing a file that ought to be listed
in .gitignore --- git status will find that problem soon enough.
However, it seems that git isn't so willing to tell you about gitignore
patterns that cover too much, i.e. match files that are already in the
repository. I found
On Wed, Sep 22, 2010 at 7:20 PM, Josh Berkus wrote:
>
>> timestamptz stores GMT; it doesn't store timezone separately.
>> (If it did, we'd need more than 8 bytes...)
>
> Oh, yeah. Duh.
>
>> Because we haven't lifted a finger to optimize it.
>
> Well, that's a direct answer. Ok, will put it in th
Heikki Linnakangas wrote:
> (starting yet another thread to stay focused)
>
> Having mulled through all the recent discussions on synchronous
> replication, ISTM there is pretty wide consensus that having a registry
> of all standbys in the master is a good idea. Even those who don't think
> it
On 2010-09-17 4:48 AM, Hitoshi Harada wrote:
2010/9/15 Hitoshi Harada:
Well, I didn't know it is allowed. That would look like the way to go.
I made changes to the previous version, so that it avoids to resolve
CTE name duplication.
This patch still doesn't address the issue Tom raised here:
Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Sep 22, 2010 at 4:04 PM, Alvaro Herrera
> > wrote:
> >> As far as I can see, I need to go to the master clone, run a checkout
> >> and pull on each branch, and *then* a pull on the local clone updates to
> >> the latest head on that branch. ?It is
Thanks for the tips.
In our case, SIGINT makes more sense. I'll use that.
Regards
On Tue, Sep 21, 2010 at 7:50 PM, Fujii Masao wrote:
> 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 t
On 2010-09-23 1:16 AM, Bernd Helmle wrote:
INSERT INTO vfoo VALUES('helmle', 2) RETURNING *;
text | id
+
helmle | 2
(1 row)
SELECT * FROM vfoo;
text | id
---+
bernd | 2
(1 row)
This is solvable by a properly designed trigger function, but maybe we need
to do som
> timestamptz stores GMT; it doesn't store timezone separately.
> (If it did, we'd need more than 8 bytes...)
Oh, yeah. Duh.
> Because we haven't lifted a finger to optimize it.
Well, that's a direct answer. Ok, will put it in the list of "TODO next
time we change the on-disk format".
--
Josh Berkus writes:
>> It's the same, because the limits are calendar based (particularly,
>> the Julian-date functions) and not dependent on the representation.
> Hmmm? Just storing dates for the range described (until the year
> 294,000) takes 8bytes by my calculations. And that's without the
Heikki Linnakangas wrote:
> When a transaction is commits, its predicate locks must be held,
> but it's not important anymore *who* holds them, as long as
> they're hold for long enough.
>
> Let's move the finishedBefore field from SERIALIZABLEXACT to
> PREDICATELOCK. When a transaction commits,
On Wed, Sep 22, 2010 at 6:56 PM, David Fetter wrote:
> On Wed, Sep 22, 2010 at 06:03:16PM -0400, Tom Lane wrote:
>> "Joshua D. Drake" writes:
>> > I mean, it took us forever to require Perl 5.8.
>>
>> ... and we still make a point of not having a hard requirement for
>> that. If you don't want p
> It's the same, because the limits are calendar based (particularly,
> the Julian-date functions) and not dependent on the representation.
Hmmm? Just storing dates for the range described (until the year
294,000) takes 8bytes by my calculations. And that's without the 3
bytes for the time zone
On Wed, Sep 22, 2010 at 06:03:16PM -0400, Tom Lane wrote:
> "Joshua D. Drake" writes:
> > I mean, it took us forever to require Perl 5.8.
>
> ... and we still make a point of not having a hard requirement for
> that. If you don't want plperl, you can build from a tarball with
> no perl at all.
>
Josh Berkus writes:
> Also, what is the real range of our 8-byte *integer* timestamp?
>>
>> See the fine manual. I believe the limits have more to do with
>> calendar arithmetic than with the nominal range of 2^64 microseconds.
> I'm asking based on that. The docs only give the limits for a *f
--On 5. September 2010 09:09:55 +0100 Dean Rasheed
wrote:
I had a first look on your patch, great work!
Attached is an updated patch with more tests and docs, and a few minor
code tidy ups. I think that the INSTEAD OF triggers part of the patch
is compliant with Feature T213 of the SQL 200
> The above case is one where I can see your point and it does sound
> easier in that case. But I then think: "What happens after failover?".
> We would then need to have 12 different standby.conf files, one on each
> standby that describes what the setup would look like if that standby
> became t
Excerpts from Alvaro Herrera's message of mié sep 22 16:57:24 -0400 2010:
> Apparently the only difference is that the initial clone needs to be
> done with --bare:
> git clone --bare ssh://g...@gitmaster.postgresql.org/postgresql.git
Okay, it works with --bare --mirror. I'm going to update
"Joshua D. Drake" writes:
> I mean, it took us forever to require Perl 5.8.
... and we still make a point of not having a hard requirement for
that. If you don't want plperl, you can build from a tarball with
no perl at all.
Given the project history, I can't see us turning a dependency
we just
On 22 September 2010 22:58, Kenneth Marshall wrote:
> On Wed, Sep 22, 2010 at 10:54:53PM +0100, Thom Brown wrote:
>> On 22 September 2010 22:01, Josh Berkus wrote:
>> > All,
>> >
>> > I was just checking on our year-2027 compliance, and happened to notice
>> > that time with time zone takes up 12
On Sep 22, 2010, at 2:08 PM, David Fetter wrote:
> It's not about naming platforms for exclusion. It's about requiring
> functionalities for *in*clusion.
Passes all tests.
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:/
>> Also, what is the real range of our 8-byte *integer* timestamp?
>
> See the fine manual. I believe the limits have more to do with
> calendar arithmetic than with the nominal range of 2^64 microseconds.
I'm asking based on that. The docs only give the limits for a *float*
timestamp. I'd li
On Wed, Sep 22, 2010 at 10:54:53PM +0100, Thom Brown wrote:
> On 22 September 2010 22:01, Josh Berkus wrote:
> > All,
> >
> > I was just checking on our year-2027 compliance, and happened to notice
> > that time with time zone takes up 12 bytes. ?This seems peculiar, given
> > that timestamp with
Josh Berkus writes:
> I was just checking on our year-2027 compliance, and happened to notice
> that time with time zone takes up 12 bytes. This seems peculiar, given
> that timestamp with time zone is only 8 bytes, and at my count we only
> need 5 for the time with microsecond precision. What's
On 22 September 2010 22:01, Josh Berkus wrote:
> All,
>
> I was just checking on our year-2027 compliance, and happened to notice
> that time with time zone takes up 12 bytes. This seems peculiar, given
> that timestamp with time zone is only 8 bytes, and at my count we only
> need 5 for the time
On 09/22/2010 04:55 PM, Tom Lane wrote:
(In particular, I'm avoiding Andrew's preferred alternative with the
extra local repository; I don't want an asynchronous buffer between me
and the real repository. I guess if you had a really bad network
connection it could be useful, but considering
On Wed, 2010-09-22 at 14:08 -0700, David Fetter wrote:
> It's not about naming platforms for exclusion. It's about requiring
> functionalities for *in*clusion.
I repeat:
> Perhaps you could suggest some more specific ideas of your proposal?
I mean, it took us forever to require Perl 5.8.
Josh
On Wed, Sep 22, 2010 at 02:02:18PM -0700, Joshua D. Drake wrote:
> On Wed, 2010-09-22 at 13:58 -0700, David Fetter wrote:
> > On Wed, Sep 22, 2010 at 04:28:04PM -0400, Tom Lane wrote:
> > > David Fetter writes:
> > > > We can start by supporting only platforms git runs on, this being
> > > > the f
On Wed, 2010-09-22 at 13:58 -0700, David Fetter wrote:
> On Wed, Sep 22, 2010 at 04:28:04PM -0400, Tom Lane wrote:
> > David Fetter writes:
> > > We can start by supporting only platforms git runs on, this being
> > > the first in what I'd picture as a set of base requirements.
> >
> > Sounds lik
All,
I was just checking on our year-2027 compliance, and happened to notice
that time with time zone takes up 12 bytes. This seems peculiar, given
that timestamp with time zone is only 8 bytes, and at my count we only
need 5 for the time with microsecond precision. What's up with that?
Also, w
On Wed, Sep 22, 2010 at 04:28:04PM -0400, Tom Lane wrote:
> David Fetter writes:
> > We can start by supporting only platforms git runs on, this being
> > the first in what I'd picture as a set of base requirements.
>
> Sounds like allowing the tail to wag the dog.
"Runs git" is actually not a b
Excerpts from Alvaro Herrera's message of mié sep 22 16:48:28 -0400 2010:
> Excerpts from Aidan Van Dyk's message of mié sep 22 16:20:15 -0400 2010:
> > I think what you want in this case (where you have a local "master"
> > repositroy, and clone your work of them) is to make your master
> > repos
Robert Haas writes:
> On Wed, Sep 22, 2010 at 4:04 PM, Alvaro Herrera
> wrote:
>> As far as I can see, I need to go to the master clone, run a checkout
>> and pull on each branch, and *then* a pull on the local clone updates to
>> the latest head on that branch. It is not enough to pull when the
Excerpts from Aidan Van Dyk's message of mié sep 22 16:20:15 -0400 2010:
> On Wed, Sep 22, 2010 at 4:04 PM, Alvaro Herrera
> wrote:
>
> > As far as I can see, I need to go to the master clone, run a checkout
> > and pull on each branch, and *then* a pull on the local clone updates to
> > the late
On 09/22/2010 04:38 PM, Robert Haas wrote:
On Wed, Sep 22, 2010 at 4:17 PM, David Fetter wrote:
What say?
"No." :-)
I'd be fine with dropping support for ancient platforms if it lets us
do something cool that we can't otherwise do, but there's no value in
doing it just because we can.
C
On Wed, Sep 22, 2010 at 4:17 PM, David Fetter wrote:
> What say?
"No." :-)
I'd be fine with dropping support for ancient platforms if it lets us
do something cool that we can't otherwise do, but there's no value in
doing it just because we can.
--
Robert Haas
EnterpriseDB: http://www.enterpri
On Wed, Sep 22, 2010 at 4:04 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mar sep 21 13:43:28 -0400 2010:
>
>> Oops. I left out a step. Fixed.
>
> Hmm, it still doesn't work. I can pull into the normal clone and it
> works, but when I run a "git pull" in one of the local c
David Fetter writes:
> We can start by supporting only platforms git runs on, this being the
> first in what I'd picture as a set of base requirements.
Sounds like allowing the tail to wag the dog.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
On Wed, 2010-09-22 at 13:17 -0700, David Fetter wrote:
> Folks,
>
> While it's interesting to note, in an historical sense, that a
> platform most recently updated when 1999 was still in the future, I
> think it's time we did a little pruning.
>
> We can start by supporting only platforms git run
On Wed, Sep 22, 2010 at 01:17:54PM -0700, David Fetter wrote:
> Folks,
>
> While it's interesting to note, in an historical sense, that a
> platform most recently updated when 1999 was still in the future, I
> think it's time we did a little pruning.
>
> We can start by supporting only platforms
On 9/22/10 1:17 PM, David Fetter wrote:
> While it's interesting to note, in an historical sense, that a
> platform most recently updated when 1999 was still in the future, I
> think it's time we did a little pruning.
It is unclear to me what problem you're trying to solve.
--
On Wed, Sep 22, 2010 at 4:04 PM, Alvaro Herrera
wrote:
> As far as I can see, I need to go to the master clone, run a checkout
> and pull on each branch, and *then* a pull on the local clone updates to
> the latest head on that branch. It is not enough to pull when the
> master branch is checked
Folks,
While it's interesting to note, in an historical sense, that a
platform most recently updated when 1999 was still in the future, I
think it's time we did a little pruning.
We can start by supporting only platforms git runs on, this being the
first in what I'd picture as a set of base requi
Tom Lane wrote:
Yeb Havinga writes:
We intend to implement $subject, so instead of mycursor CURSOR (myparm text) IS
SELECT myparm; OPEN mycursor('A'); it would be possible to do OPEN
mycursor(myparm := 'A');
Is this really worth the trouble? Is it supported by any other DBMS?
Are c
On Wed, 2010-09-22 at 21:05 +0100, Thom Brown wrote:
> On 22 September 2010 19:50, Josh Berkus wrote:
> > All:
> >
> > I feel compelled to point out that, to date, there have been three times
> > as many comments on what format the configuration file should be as
> > there have been on what option
On 22 September 2010 19:50, Josh Berkus wrote:
> All:
>
> I feel compelled to point out that, to date, there have been three times
> as many comments on what format the configuration file should be as
> there have been on what options it should support and how large numbers
> of replicas should be
Excerpts from Robert Haas's message of mar sep 21 13:43:28 -0400 2010:
> Oops. I left out a step. Fixed.
Hmm, it still doesn't work. I can pull into the normal clone and it
works, but when I run a "git pull" in one of the local clones, it says
it's up to date even when there are commits that I
On Wed, Sep 22, 2010 at 20:38, Tom Lane wrote:
> Magnus Hagander writes:
>> On Wed, Sep 22, 2010 at 20:28, Kevin Grittner
>> wrote:
>>> Magnus Hagander wrote:
>>>
>> Done and applied.
>>>
>>> I just did `make world`, `make check`, `sudo make install-world`, and
>>> `make installcheck-world`. I
Tom Lane wrote:
Robert Haas writes:
On Wed, Sep 22, 2010 at 1:09 PM, Joshua D. Drake wrote:
On Wed, 2010-09-22 at 13:00 -0400, Robert Haas wrote:
But it CAN'T be a system catalog, because, among other problems, that
rules out cascading slaves, which are a feature a lot of peop
On 19/09/10 21:57, I wrote:
Putting that aside for now, we have one very serious problem with this
algorithm:
While they [SIREAD locks] are associated with a transaction, they must
survive
a successful COMMIT of that transaction, and remain until all overlapping
> transactions complete.
Long
All:
I feel compelled to point out that, to date, there have been three times
as many comments on what format the configuration file should be as
there have been on what options it should support and how large numbers
of replicas should be managed.
--
-- Josh Be
"Joshua D. Drake" writes:
> Unless I am missing something the catalog only needs information for its
> specific cluster. E.g; My Master is, I am master for.
I think the "cluster" here is composed of all and any server partaking
into the replication network, whatever its role and cascading level,
Magnus Hagander writes:
> On Wed, Sep 22, 2010 at 20:28, Kevin Grittner
> wrote:
>> Magnus Hagander wrote:
>>
> Done and applied.
>>
>> I just did `make world`, `make check`, `sudo make install-world`, and
>> `make installcheck-world`. I was left with these showing in my `git
>> status`:
> A
On Wed, Sep 22, 2010 at 20:28, Kevin Grittner
wrote:
> Magnus Hagander wrote:
>
>> Done and applied.
>
> I just did `make world`, `make check`, `sudo make install-world`, and
> `make installcheck-world`. I was left with these showing in my `git
> status`:
Ahh. Clearly I didn't run the regressio
Magnus Hagander wrote:
> Done and applied.
I just did `make world`, `make check`, `sudo make install-world`, and
`make installcheck-world`. I was left with these showing in my `git
status`:
# Untracked files:
# (use "git add ..." to
On Wed, 2010-09-22 at 13:26 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Sep 22, 2010 at 1:09 PM, Joshua D. Drake
> > wrote:
> >> On Wed, 2010-09-22 at 13:00 -0400, Robert Haas wrote:
> >>> But it CAN'T be a system catalog, because, among other problems, that
> >>> rules out cascadin
Robert Haas writes:
> On Wed, Sep 22, 2010 at 1:09 PM, Joshua D. Drake
> wrote:
>> On Wed, 2010-09-22 at 13:00 -0400, Robert Haas wrote:
>>> But it CAN'T be a system catalog, because, among other problems, that
>>> rules out cascading slaves, which are a feature a lot of people
>>> probably want
On Wed, Sep 22, 2010 at 19:23, Tom Lane wrote:
> Magnus Hagander writes:
>> On Wed, Sep 22, 2010 at 17:08, Tom Lane wrote:
>>> Sure, I can look. Where are these tarballs anyway?
>
>> They're up on the ftp site - ftp://ftp.postgresql.org/pub/snapshot/.
>> dev and stable/8.4 are updated.
>
> Both
Magnus Hagander writes:
> On Wed, Sep 22, 2010 at 17:08, Tom Lane wrote:
>> Sure, I can look. Where are these tarballs anyway?
> They're up on the ftp site - ftp://ftp.postgresql.org/pub/snapshot/.
> dev and stable/8.4 are updated.
Both of those look pretty sane from here.
"Kevin Grittner" wrote:
> Well, that didn't work much better.
I decided I'd reached my limit on this. I fell back to a suggestion
made a while back, and just created a patch from the old repository
and applied it to the new one. I've pushed it to the public repo,
but haven't yet had a chance
On Wed, Sep 22, 2010 at 1:09 PM, Joshua D. Drake wrote:
> On Wed, 2010-09-22 at 13:00 -0400, Robert Haas wrote:
>
>> > I mean really?
>> >
>> > ALTER CLUSTER ENABLE [SYNC] REPLICATION ON db.foobar.com PORT 5432 ALIAS
>> > CRITICAL;
>> > ALTER CLUSTER SET REPLICATION CRITICAL RECEIVE FOR 2;
>> > AL
On 22/09/10 20:02, Heikki Linnakangas wrote:
On 22/09/10 20:00, Robert Haas wrote:
But it CAN'T be a system catalog, because, among other problems, that
rules out cascading slaves, which are a feature a lot of people
probably want to eventually have.
FWIW it could be a system catalog backed by
Heikki Linnakangas wrote:
> On 22/09/10 20:00, Robert Haas wrote:
> > But it CAN'T be a system catalog, because, among other problems, that
> > rules out cascading slaves, which are a feature a lot of people
> > probably want to eventually have.
>
> FWIW it could be a system catalog backed by a fl
Excerpts from Hitoshi Harada's message of mié sep 22 12:54:45 -0400 2010:
> > Maybe we can find some better wording of the above?
>
> Your point is true, but I believe it's still ok because the section is
> a tutorial for novices. If you start to explain everything here,
> readers don't want to r
On Wed, 2010-09-22 at 13:00 -0400, Robert Haas wrote:
> > I mean really?
> >
> > ALTER CLUSTER ENABLE [SYNC] REPLICATION ON db.foobar.com PORT 5432 ALIAS
> > CRITICAL;
> > ALTER CLUSTER SET REPLICATION CRITICAL RECEIVE FOR 2;
> > ALTER CLUSTER SET REPLICATION CRITICAL FSYNC FOR 2;
> > ALTER CLUSTE
On Wed, Sep 22, 2010 at 8:12 AM, Simon Riggs wrote:
Not speaking to the necessity of standby registration, but...
>> Thinking of this as a sysadmin, what I want is to have *one place* I can
>> go an troubleshoot my standby setup. If I have 12 synch standbys and
>> they're creating too much load
On 22/09/10 20:00, Robert Haas wrote:
But it CAN'T be a system catalog, because, among other problems, that
rules out cascading slaves, which are a feature a lot of people
probably want to eventually have.
FWIW it could be a system catalog backed by a flat file. But I'm not in
favor of that fo
On Wed, Sep 22, 2010 at 12:51 PM, Joshua D. Drake
wrote:
> On Wed, 2010-09-22 at 17:43 +0100, Thom Brown wrote:
>
>> So...
>>
>> sync_rep_services = {critical: recv=2, fsync=2, replay=1;
>> important: fsync=3;
>> reporting: recv=2, apply=1}
>>
>> becomes
On Wed, Sep 22, 2010 at 10:19 AM, Heikki Linnakangas
wrote:
>>> Should we allow multiple standbys with the same name to connect to
>>> the master?
>>
>> No. The point of naming them is to uniquely identify them.
>
> Hmm, that situation can arise if there's a network glitch which leads the
> stan
2010/9/22 Dennis Björklund :
> In
>
> http://www.postgresql.org/docs/9.0/static/tutorial-window.html
>
> it say
>
> "Although avg will produce the same result no matter what order it
> processes the partition's rows in, this is not true of all window
> functions. When needed, you can control that
Robert Haas wrote:
> > What is it about add/deletes that it doesn't do? ?Is the problem 'git
> > add' creates a stage already? ?How is that a problem?
>
> Tom is slightly incorrect. Deletions work fine with git commit -a.
> git already knows about the files, so everything just works. However,
>
On Wed, 2010-09-22 at 17:43 +0100, Thom Brown wrote:
> So...
>
> sync_rep_services = {critical: recv=2, fsync=2, replay=1;
> important: fsync=3;
> reporting: recv=2, apply=1}
>
> becomes ...
>
> sync_rep_services.critical.recv = 2
> sync_rep_services.cr
On Wed, Sep 22, 2010 at 17:08, Tom Lane wrote:
> Magnus Hagander writes:
>> On Wed, Sep 22, 2010 at 16:50, Tom Lane wrote:
>>> Do you still need someone to do that, and what do you want done exactly?
>
>> Just a second set of eyes that the output looks reasonable for being a
>> snapshot generate
On Wed, Sep 22, 2010 at 12:40 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian writes:
>> > There is no need for 'git add' because once you are done you can use git
>> > commmit -a in each branch to add all modifications and commit them.
>>
>> git commit -a is not a universal solution.
Thom Brown wrote:
> On 22 September 2010 17:23, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> [server]
> >> guc=value
> >>
> >> or
> >>
> >> server.guc=value
> > ?
> >
> > Yes, this was my idea too. ?It uses our existing config file format.
> >
>
> So...
>
> sync_rep_services
At 2010-09-22 19:21:45 +0300, pete...@gmx.net wrote:
>
> Well, let's see. If someone can figure out the git equivalent of
>
> if cvs -q update | egrep -q '^(U|P) '; then
> # ... something changed, so run the update ...
> fi
I think you want:
git pull
if [ $(git rev-parse HEAD) != $(gi
Excerpts from Peter Eisentraut's message of mié sep 22 12:21:45 -0400 2010:
> Well, let's see. If someone can figure out the git equivalent of
>
> if cvs -q update | egrep -q '^(U|P) '; then
> # ... something changed, so run the update ...
> fi
>
> (assuming, for simplicity, that the current
On 22 September 2010 17:23, Bruce Momjian wrote:
> Robert Haas wrote:
>> [server]
>> guc=value
>>
>> or
>>
>> server.guc=value
>
>
> Yes, this was my idea too. It uses our existing config file format.
>
So...
sync_rep_services = {critical: recv=2, fsync=2, replay=1;
On Wed, Sep 22, 2010 at 12:21 PM, Peter Eisentraut wrote:
> On ons, 2010-09-22 at 16:03 +0200, Magnus Hagander wrote:
>> That basically means that git-cvsserver is completely useless in a
>> public scenario as it stands. An easier way to DOS our server is hard
>> to find, really.
>>
>> Now, if we
Tom Lane wrote:
> Bruce Momjian writes:
> > There is no need for 'git add' because once you are done you can use git
> > commmit -a in each branch to add all modifications and commit them.
>
> git commit -a is not a universal solution. In particular, the patch
> I was dealing with yesterday invo
Robert Haas wrote:
> [server]
> guc=value
>
> or
>
> server.guc=value
Yes, this was my idea too. It uses our existing config file format.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible fo
On ons, 2010-09-22 at 16:03 +0200, Magnus Hagander wrote:
> That basically means that git-cvsserver is completely useless in a
> public scenario as it stands. An easier way to DOS our server is hard
> to find, really.
>
> Now, if we can limit this by IP address, that would be ok. I assume we
> can
Peter Eisentraut wrote:
> 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),
> H
On Wed, Sep 22, 2010 at 6:03 AM, Dennis Björklund wrote:
> In
>
> http://www.postgresql.org/docs/9.0/static/tutorial-window.html
>
> it say
>
> "Although avg will produce the same result no matter what order it
> processes the partition's rows in, this is not true of all window
> functions. When
On Wed, Sep 22, 2010 at 10:19 AM, Heikki Linnakangas
wrote:
>> No. The point of naming them is to uniquely identify them.
>
> Hmm, that situation can arise if there's a network glitch which leads the
> standby to disconnect, but the master still considers the connection as
> alive. When the stand
Yeb Havinga writes:
> We intend to implement $subject, so instead of
> mycursor CURSOR (myparm text) IS SELECT myparm;
> OPEN mycursor('A');
> it would be possible to do
> OPEN mycursor(myparm := 'A');
Is this really worth the trouble? Is it supported by any other DBMS?
Are cursors used so mu
Elvis Pranskevichus wrote:
> Instead of filtering non-merge commits I would suggest doing git
> rebase on the latest revision of the old git repo. That way you
> will get a set of commits that should apply cleanly. The reason
> it is failing now is that it is impossible for git am to do a
> 3-
Andrew Dunstan writes:
> On 09/22/2010 10:23 AM, Tom Lane wrote:
>> If we're going to let people in by IP address, maybe we could let legacy
>> buildfarm members in by IP address. It doesn't seem particularly
>> helpful to expect each buildfarm owner to solve this problem for
>> themselves. I'd
1 - 100 of 182 matches
Mail list logo
