I haven't quite finished reviewing this, but here is the position so
far. I'm going to continue with some performance and other tests, but
I'm posting this for discussion in the mean time.
1) General patch issues
- applies cleanly and passes regression
- one small warning with ecpg parser buil
Hi,
On 09/21/2010 05:48 PM, Kevin Grittner wrote:
> OK, I'd say it's a little rough yet, but it works. Is this
> reasonable?:
>
> http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=b8eca245ab63725d0fbfc3b5969f4a17fc765f2c
I only get a: "404 - Unknown commit object" on
On 22/09/10 03:25, Joshua D. Drake wrote:
Why is this in the config file at all. It should be:
synchronous_replication = TRUE/FALSE
Umm, what does this do?
then
ALTER CLUSTER ENABLE REPLICATION FOR FOO;
ALTER CLUSTER SET keep_connect ON FOO TO TRUE;
Or some such thing.
I like a configura
How can I increase the stack depth limit ? Is it only by modifying the
postgres.conf file, but there I cannot increase the stack depth beyond 4
MB.
Actually, my problem is that, when I set the stack base address of the
child thread using the POSIX library function "pthread_setstackaddr()", I
am u
Hey all,
Okay, as Robert points, "0" code in successful messages seems as waste
of bytes. But according to the documentation, "All messages emitted by the
PostgreSQL server are assigned five-character error codes that follow the
SQL
standard's conventions for "SQLSTATE" codes." - the first sen
On 21/09/10 18:12, 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
tell the user to edit.
I'm not a big fan of XML either.
...
Hi,
On 09/21/2010 08:05 PM, Simon Riggs wrote:
> Hmm, no reason? The reason is that the alternative is that the session
> would hang until a standby arrived that offered that level of service.
> Why would you want that behaviour? Would you really request that option?
I think I now agree with Simo
On 22/09/10 11:14, sub...@cse.iitb.ac.in wrote:
How can I increase the stack depth limit ? Is it only by modifying the
postgres.conf file, but there I cannot increase the stack depth beyond 4
MB.
Actually, my problem is that, when I set the stack base address of the
child thread using the POSIX
[moving to pgsql-hackers; this isn't the simple bug I initially
suspected it might be]
On 20/09/10 03:10, Tom Lane wrote:
> Craig Ringer writes:
>> One of the correctly encoded messages is "Unexpected EOF received on
>> client connection"
>
>> One of the incorrectly encoded (shift-JIS) messages
Hi all!
It seems that the git move has broken the generation of the automatic
snapshot tarballs - has anybody yet looked into what it would take to
move those to fetching from git?
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscript
(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's *necessary* for synchronous replic
On 09/22/2010 04:18 AM, Heikki Linnakangas wrote:
On 21/09/10 18:12, 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
tell the u
On 22/09/10 11:33, Stefan Kaltenbrunner wrote:
Hi all!
It seems that the git move has broken the generation of the automatic
snapshot tarballs - has anybody yet looked into what it would take to
move those to fetching from git?
BTW, there is a nice command called in git to create tarballs:
gi
On Wed, Sep 22, 2010 at 10:47, Heikki Linnakangas
wrote:
> On 22/09/10 11:33, Stefan Kaltenbrunner wrote:
>>
>> Hi all!
>>
>> It seems that the git move has broken the generation of the automatic
>> snapshot tarballs - has anybody yet looked into what it would take to
>> move those to fetching fro
On Wed, Sep 22, 2010 at 9:47 AM, Andrew Dunstan wrote:
>
> The ini file format is not flexible enough, IMNSHO. If we're going to adopt
> a new config file format it should have these characteristics, among others:
>
> well known (let's not invent a new one)
> supports hierarchical structure
> reas
On 22/09/10 12:03, sub...@cse.iitb.ac.in wrote:
Actually, I used palloc() to set the stack base address.
And I am trying to create only a single thread, then also it is causing
problem.
Actually, I created all the data-structures using palloc(), then I am
passing these to the child thread. Even i
On ons, 2010-09-22 at 10:33 +0200, Stefan Kaltenbrunner wrote:
> It seems that the git move has broken the generation of the automatic
> snapshot tarballs - has anybody yet looked into what it would take to
> move those to fetching from git?
Depends on what's "broken" about it, but I notice that
On ons, 2010-09-22 at 16:25 +0800, Craig Ringer wrote:
> A single log file should obviously be in a single encoding, it's the
> only sane way to do things. But which encoding is it in? And which
> *should* it be in?
We need to produce the log output in the server encoding, because that's
how we ne
On Wed, Sep 22, 2010 at 11:29, Peter Eisentraut wrote:
> On ons, 2010-09-22 at 10:33 +0200, Stefan Kaltenbrunner wrote:
>> It seems that the git move has broken the generation of the automatic
>> snapshot tarballs - has anybody yet looked into what it would take to
>> move those to fetching from g
On Wed, Sep 22, 2010 at 11:11 AM, Magnus Hagander wrote:
> On Wed, Sep 22, 2010 at 11:29, Peter Eisentraut wrote:
>> On ons, 2010-09-22 at 10:33 +0200, Stefan Kaltenbrunner wrote:
>>> It seems that the git move has broken the generation of the automatic
>>> snapshot tarballs - has anybody yet loo
Peter Eisentraut wrote:
On ons, 2010-09-22 at 10:33 +0200, Stefan Kaltenbrunner wrote:
It seems that the git move has broken the generation of the automatic
snapshot tarballs - has anybody yet looked into what it would take to
move those to fetching from git?
Depends on what's "broken" about
On Wed, Sep 22, 2010 at 12:19, Dave Page wrote:
> On Wed, Sep 22, 2010 at 11:11 AM, Magnus Hagander wrote:
>> On Wed, Sep 22, 2010 at 11:29, Peter Eisentraut wrote:
>>> On ons, 2010-09-22 at 10:33 +0200, Stefan Kaltenbrunner wrote:
It seems that the git move has broken the generation of the
On Tue, Sep 21, 2010 at 10:33 PM, Itagaki Takahiro
wrote:
> I didn't read previous discussions, but did we have consensus that "number
> of tuples" is better than other units for the parameter? For example,
> "threshold bytes" or "percentage in a page" also seems to be reasonable for
> me.
I thi
On Wed, Sep 22, 2010 at 10:33, Stefan Kaltenbrunner
wrote:
> Hi all!
>
> It seems that the git move has broken the generation of the automatic
> snapshot tarballs - has anybody yet looked into what it would take to move
> those to fetching from git?
I think this should be working now. I made this
On Wed, Sep 22, 2010 at 4:18 AM, Dmitriy Igrishin wrote:
> Okay, as Robert points, "0" code in successful messages seems as waste
> of bytes. But according to the documentation, "All messages emitted by the
> PostgreSQL server are assigned five-character error codes that follow the
> SQL
> sta
Magnus Hagander wrote:
On Wed, Sep 22, 2010 at 10:33, Stefan Kaltenbrunner
wrote:
Hi all!
It seems that the git move has broken the generation of the automatic
snapshot tarballs - has anybody yet looked into what it would take to move
those to fetching from git?
I think this should be workin
On Tue, Sep 21, 2010 at 10:58 PM, Pei He wrote:
> 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
> app
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 order using ORDER BY within
OVER."
While it
On Tue, Sep 21, 2010 at 11:42 PM, Pei He wrote:
> 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.
See MaxHeapTuplesPerPage and MaxIndexTuplesPerPage.
> I am not quite sure
At 2010-09-21 21:20:06 -0400, t...@sss.pgh.pa.us wrote:
>
> So it seems like maybe we still need some more thought about how to
> recognize related commits in different branches.
I'd suggest using "git cherry-pick -x" (or something similar) to mark
backported patches:
-x When recording the c
On Thu, Sep 16, 2010 at 5:46 AM, Peter Eisentraut wrote:
> Following up on my previous patch [0], here is a fairly complete
> implementation of this feature. The general description and
> implementation outline of the previous message still apply. This patch
> contains documentation and regressi
On 09/22/2010 04:54 AM, Dave Page wrote:
On Wed, Sep 22, 2010 at 9:47 AM, Andrew Dunstan wrote:
The ini file format is not flexible enough, IMNSHO. If we're going to adopt
a new config file format it should have these characteristics, among others:
well known (let's not invent a new one)
sup
On Wed, Sep 22, 2010 at 05:47, 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-pick is
On Wed, Sep 22, 2010 at 12:07 PM, Andrew Dunstan wrote:
>
>
> On 09/22/2010 04:54 AM, Dave Page wrote:
>>
>> On Wed, Sep 22, 2010 at 9:47 AM, Andrew Dunstan
>> wrote:
>>>
>>> The ini file format is not flexible enough, IMNSHO. If we're going to
>>> adopt
>>> a new config file format it should hav
On ons, 2010-09-22 at 12:22 +0200, Magnus Hagander wrote:
> Mind you, I think bf members will need tweaking anyway, since they
> will assume the old style cvs layout. AFAICT, git-cvsserver will
> export each branch as a module, rather than one module as pgsql. We
> can obviously get that working fo
On Wed, Sep 22, 2010 at 13:20, Peter Eisentraut wrote:
> On ons, 2010-09-22 at 12:22 +0200, Magnus Hagander wrote:
>> Mind you, I think bf members will need tweaking anyway, since they
>> will assume the old style cvs layout. AFAICT, git-cvsserver will
>> export each branch as a module, rather tha
On 22/09/2010 5:45 PM, Peter Eisentraut wrote:
On ons, 2010-09-22 at 16:25 +0800, Craig Ringer wrote:
A single log file should obviously be in a single encoding, it's the
only sane way to do things. But which encoding is it in? And which
*should* it be in?
We need to produce the log output in
Peter Eisentraut wrote:
On ons, 2010-09-22 at 12:22 +0200, Magnus Hagander wrote:
Mind you, I think bf members will need tweaking anyway, since they
will assume the old style cvs layout. AFAICT, git-cvsserver will
export each branch as a module, rather than one module as pgsql. We
can obviously
Magnus Hagander wrote:
On Wed, Sep 22, 2010 at 13:20, Peter Eisentraut wrote:
On ons, 2010-09-22 at 12:22 +0200, Magnus Hagander wrote:
Mind you, I think bf members will need tweaking anyway, since they
will assume the old style cvs layout. AFAICT, git-cvsserver will
export each branch as a mo
On Wed, Sep 22, 2010 at 12:25 PM, Craig Ringer
wrote:
> I don't think that's an OK answer, myself. Mixed encodings with no
> delineation in one file = bug as far as I'm concerned. You can't even rely
> on being able to search the log anymore. You'll only get away with it when
> using languages tha
On ons, 2010-09-22 at 13:25 +0200, Magnus Hagander wrote:
> On Wed, Sep 22, 2010 at 13:20, Peter Eisentraut wrote:
> > We need to have a fix for this before we can do any more backbranch
> > releases.
>
> Fix for what, exactly? (assuming that people update their bf animals of
> course)
For the
On Wed, Sep 22, 2010 at 13:28, Stefan Kaltenbrunner
wrote:
> Magnus Hagander wrote:
>>
>> On Wed, Sep 22, 2010 at 13:20, Peter Eisentraut wrote:
>>>
>>> On ons, 2010-09-22 at 12:22 +0200, Magnus Hagander wrote:
Mind you, I think bf members will need tweaking anyway, since they
will
On Wed, Sep 22, 2010 at 13:38, Peter Eisentraut wrote:
> On ons, 2010-09-22 at 13:25 +0200, Magnus Hagander wrote:
>> On Wed, Sep 22, 2010 at 13:20, Peter Eisentraut wrote:
>> > We need to have a fix for this before we can do any more backbranch
>> > releases.
>>
>> Fix for what, exactly? (assumi
On 09/22/2010 07:07 AM, Magnus Hagander wrote:
On Wed, Sep 22, 2010 at 05:47, 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'l
On Wed, Sep 22, 2010 at 13:47, Andrew Dunstan wrote:
>
>
> On 09/22/2010 07:07 AM, Magnus Hagander wrote:
>>
>> On Wed, Sep 22, 2010 at 05:47, Tom Lane wrote:
>>>
>>> Bruce Momjian writes:
However, keep in mind that creating a branch in every existing backpatch
branch is going to
On ons, 2010-09-22 at 12:20 +0100, Dave Page wrote:
> > No, it's really not hierarchical. It only has goes one level deep.
>
> I guess pgAdmin/wxWidgets are broken then :-)
>
> [Servers]
> Count=5
> [Servers/1]
> Server=localhost
Well, by that logic, even what we have now for postgresql.conf is
On ons, 2010-09-22 at 13:45 +0200, Magnus Hagander wrote:
> On Wed, Sep 22, 2010 at 13:38, Peter Eisentraut wrote:
> > For the NLS workflow, we need to have some kind of CVS server that
> > serves up all supported branches. Changing the URL or the module name
> > or whatever is fine.
>
> I thoug
On 09/22/2010 07:20 AM, Dave Page wrote:
On Wed, Sep 22, 2010 at 12:07 PM, Andrew Dunstan wrote:
On 09/22/2010 04:54 AM, Dave Page wrote:
On Wed, Sep 22, 2010 at 9:47 AM, Andrew Dunstan
wrote:
The ini file format is not flexible enough, IMNSHO. If we're going to
adopt
a new config file f
On Wed, Sep 22, 2010 at 12:50 PM, Peter Eisentraut wrote:
> On ons, 2010-09-22 at 12:20 +0100, Dave Page wrote:
>> > No, it's really not hierarchical. It only has goes one level deep.
>>
>> I guess pgAdmin/wxWidgets are broken then :-)
>>
>> [Servers]
>> Count=5
>> [Servers/1]
>> Server=localhost
On 09/22/2010 06:22 AM, Magnus Hagander wrote:
Mind you, I think bf members will need tweaking anyway, since they
will assume the old style cvs layout. AFAICT, git-cvsserver will
export each branch as a module, rather than one module as pgsql. We
can obviously get that working for the HEAD br
On Tue, Sep 21, 2010 at 22:23, Tom Lane wrote:
> 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
On Wed, Sep 22, 2010 at 5:43 PM, Heikki Linnakangas
wrote:
> So let's put synchronous replication aside for now, and focus on standby
> registration first. Once we have that, the synchronous replication patch
> will be much smaller and easier to review.
Though I agree with standby registration, I
On 09/22/2010 07:57 AM, Dave Page wrote:
On Wed, Sep 22, 2010 at 12:50 PM, Peter Eisentraut wrote:
On ons, 2010-09-22 at 12:20 +0100, Dave Page wrote:
No, it's really not hierarchical. It only has goes one level deep.
I guess pgAdmin/wxWidgets are broken then :-)
[Servers]
Count=5
[Servers
On Wed, Sep 22, 2010 at 1:25 PM, Andrew Dunstan wrote:
> XML is not the only alternative - please don't use it as a straw man. For
> example, here is a fragment from the Bacula docs using their hierarchical
> format:
>
> FileSet {
> Name = Test
> Include {
> File = /home/xxx/test
> Opt
On ons, 2010-09-22 at 19:25 +0800, Craig Ringer wrote:
> Yep, I tend to think that'd be the right way to go. It'd still be a bit
> of a pain, though, as messages written to stdout/stderr by the
> postmaster should be in the system encoding, but messages written to the
> log files should be in th
On 09/22/2010 08:32 AM, Dave Page wrote:
On Wed, Sep 22, 2010 at 1:25 PM, Andrew Dunstan wrote:
XML is not the only alternative - please don't use it as a straw man. For
example, here is a fragment from the Bacula docs using their hierarchical
format:
FileSet {
Name = Test
Include {
Robert Haas wrote:
> I'm not even sure that it would be correct to say "All error
> messages...", unless elog(ERROR, "can't happen") throws something
> into that field.
If it doesn't, it should. Probably 'XX000' (internal_error).
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hacker
Markus Wanner wrote:
> I only get a: "404 - Unknown commit object" on that link. Did you
> push your work?
Yeah, but it has since been blown away (at my request) as part of my
attempt to get it based on the new git conversion. Sorry about
that. Attached is an mbox representation of what was
On Wed, Sep 22, 2010 at 13:45, Magnus Hagander wrote:
> On Wed, Sep 22, 2010 at 13:38, Peter Eisentraut wrote:
>> On ons, 2010-09-22 at 13:25 +0200, Magnus Hagander wrote:
>>> On Wed, Sep 22, 2010 at 13:20, Peter Eisentraut wrote:
>>> > We need to have a fix for this before we can do any more ba
On Tue, Sep 21, 2010 at 9:20 PM, Tom Lane wrote:
> So it seems like maybe we still need some more thought about how to
> recognize related commits in different branches. Or at the very least,
> we need a best-practice document explaining how to manage this --- we
> shouldn't expect every committe
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 --staged >/t
On ons, 2010-09-22 at 19:44 +0900, Itagaki Takahiro wrote:
> * CREATE TABLE (LIKE table_with_collation) doesn't inherit collations.
> We need to copy collations by default, or add INCLUDING COLLATE option.
OK, should be easy to fix.
> * upper() doesn't work if a column has a collation.
> It s
Craig Ringer writes:
> On 22/09/2010 5:45 PM, Peter Eisentraut wrote:
>> We need to produce the log output in the server encoding, because that's
>> how we need to send it to the client.
> That doesn't mean it can't be recoded for writing to the log file,
> though. Perhaps it needs to be. It sho
On Wed, Sep 22, 2010 at 9:01 AM, Andrew Dunstan wrote:
> I can't imagine trying to configure Bacula using ini file format - the mind
> just boggles. Frankly, I'd rather stick with our current config format than
> change to something as inadequate as ini file format.
Perhaps we need to define a li
On Wed, Sep 22, 2010 at 8:21 AM, Fujii Masao wrote:
> What if the number of standby entries in standby.conf is more than
> max_wal_senders? This situation is allowed if we treat standby.conf
> as just access control list like pg_hba.conf. But if we have to ensure
> that all the registered standbys
Peter Eisentraut writes:
> On ons, 2010-09-22 at 19:25 +0800, Craig Ringer wrote:
>> I still wonder if, rather than making this configurable, the right
>> choice is to force logging to UTF-8 (with BOM) across the board,
> I don't think this would make things better or easier. At some point
> yo
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 involved additions and removals
So, I found (with some helpful hints from Robert who caught the final
nail in the coffin) a good reason why we really can't run a
git-cvsserver globally.
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 50M
On 22/09/10 16:54, Robert Haas wrote:
On Wed, Sep 22, 2010 at 8:21 AM, Fujii Masao wrote:
What if the number of standby entries in standby.conf is more than
max_wal_senders? This situation is allowed if we treat standby.conf
as just access control list like pg_hba.conf. But if we have to ensure
On Tue, Sep 21, 2010 at 10:32 PM, Abhijit Menon-Sen wrote:
> That's not it. I ran the same git gc command on my old repository, and
> it didn't make any difference to the size. (I didn't try with a larger
> window size, though.)
Probably lots of it has to do with the delta chains themselves. Th
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 server with cache information about that
> head.
> That basically means that git-cvsserver is comp
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 server with cache information about that
>> he
Andrew Gierth writes:
> My opinion is that the gist-implementation section of the docs needs
> to be substantially expanded so that it explains, for each support
> function, exactly what the function is expected to do.
Yes, the GIST (and GIN) parts of the docs are really pretty bad.
> If it woul
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 also note that if they could run g
sub...@cse.iitb.ac.in writes:
> How can I increase the stack depth limit ? Is it only by modifying the
> postgres.conf file, but there I cannot increase the stack depth beyond 4
> MB.
> Actually, my problem is that, when I set the stack base address of the
> child thread using the POSIX library fu
Robert Haas writes:
> On Wed, Sep 22, 2010 at 4:18 AM, Dmitriy Igrishin wrote:
>> Okay, as Robert points, "0" code in successful messages seems as waste
>> of bytes. But according to the documentation, "All messages emitted by the
>> PostgreSQL server are assigned five-character error codes t
Stefan Kaltenbrunner writes:
> Magnus Hagander wrote:
>> I think this should be working now. I made this change to mk-snapshot,
>> and a similar one to mk-stable_snapshot. I have run the snapshot
>> generation for master, and the one for 8.4 should finish in a
>> minute or so. I have disabled the
Hello list,
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');
The idea is to
* in pl_exec.exec_stmt_forc, detect if a positional parameter or named
parameter is used.
*
On Wed, Sep 22, 2010 at 16:50, Tom Lane wrote:
> Stefan Kaltenbrunner writes:
>> Magnus Hagander wrote:
>>> I think this should be working now. I made this change to mk-snapshot,
>>> and a similar one to mk-stable_snapshot. I have run the snapshot
>>> generation for master, and the one for 8.4 sh
On Tue, 2010-09-21 at 17:04 -0700, Josh Berkus wrote:
> > 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".
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 generated now.
Sure, I can look. Where are these tarballs any
On Wed, Sep 22, 2010 at 10:30 AM, Tom Lane wrote:
>> If it would help, I'm prepared to put some time towards actually
>> writing something up for this.
>
> That would be outstanding.
+1. Or really, plus several.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres C
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
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-
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
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
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
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 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
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
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
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
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;
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
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
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
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.
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, 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
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,
>
1 - 100 of 182 matches
Mail list logo
