On Thu, May 17, 2007 at 07:51:34PM -0400, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Are we going to apply this?
Not in the form submitted so far, but I trust Magnus is working on
fixing it.
I am. Most likely won't have time to look at it properly until after pgcon,
though.
On 5/17/07, Tom Lane [EMAIL PROTECTED] wrote:
Andrew Hammond [EMAIL PROTECTED] writes:
On 5/17/07, Tom Lane [EMAIL PROTECTED] wrote:
What are the grounds for defining it that way rather than some other
way?
The only alternative that came to mind when I wrote it was using a
numeric
instead
Zdenek Kotala wrote:
Heikki Linnakangas wrote:
- heap page diagnostic functions
I would like to take this review (after PGCon).
Too late, Bruce applied it already :).
More eyeballs on it still wouldn't hurt of course.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Heikki Linnakangas wrote:
- heap page diagnostic functions
I would like to take this review (after PGCon).
Zdenek
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
On 5/18/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
When I start working on a subject, I make a new checkout from the local
repository to a designated directory under pg_sandbox-directory. For
example, when I started working on the mvcc-safe cluster patch:
~/pg_sandbox$ cvs -d
On Sun, 2007-05-13 at 18:28 +0200, Pavel Stehule wrote:
I understand better it. Second cluster has to be an clone of first
cluster. - don't use initdb for second cluster. Is possible add this
notice to pg_standby's README?
The README says that you should read the main docs, which do describe
Greg Smith wrote:
On Thu, 17 May 2007, David Fetter wrote:
Would you be interested in providing this meat? You're uniquely
qualified because your shins still smart from all the things you
barked them on :)
Unfortunately I'm temporarily on the other side of this problem; all the
time I have
Pavan Deolasee wrote:
For primitive version control, I make a diff after any significant changes:
~/pg_sandbox/pgsql.cluster$ cvs diff -cN cluster-mvcc-1.patch
I usually commit each version and tag the tree. That helps me to get
diff between two versions as well.
Doesn't that confuse
On 5/18/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Pavan Deolasee wrote:
For primitive version control, I make a diff after any significant
changes:
~/pg_sandbox/pgsql.cluster$ cvs diff -cN cluster-mvcc-1.patch
I usually commit each version and tag the tree. That helps me to get
On Fri, May 18, 2007 at 12:52:20PM +0200, Robert Mach wrote:
Before presenting possible errors, I divided them into physical and
logical errors. Physical errors will refer to errors in the structure of
pages and tuples, whereas logical errors will depict errors that cause
incorrect
Tom Lane wrote:
Arjen van der Meijden told me that according to the tweakers.net
benchmark, HEAD is noticeably slower than 8.2.4, and I soon confirmed
here that for small SELECT queries issued as separate transactions,
there's a significant difference. I think much of the difference stems
Heikki Linnakangas wrote:
Zdenek Kotala wrote:
Heikki Linnakangas wrote:
- heap page diagnostic functions
I would like to take this review (after PGCon).
Too late, Bruce applied it already :).
Yes ... Never mind
What's about
- full page writes improvement
but I will have time after
Zdenek Kotala wrote:
Heikki Linnakangas wrote:
Zdenek Kotala wrote:
Heikki Linnakangas wrote:
- heap page diagnostic functions
I would like to take this review (after PGCon).
Too late, Bruce applied it already :).
Yes ... Never mind
You know, the fact that it was applied does not
Alvaro Herrera wrote:
Zdenek Kotala wrote:
Heikki Linnakangas wrote:
Zdenek Kotala wrote:
Heikki Linnakangas wrote:
- heap page diagnostic functions
I would like to take this review (after PGCon).
Too late, Bruce applied it already :).
Yes ... Never mind
You know, the
Alvaro Herrera wrote:
Alvaro Herrera wrote:
Zdenek Kotala wrote:
Heikki Linnakangas wrote:
Zdenek Kotala wrote:
Heikki Linnakangas wrote:
- heap page diagnostic functions
I would like to take this review (after PGCon).
Too late, Bruce applied it already :).
Yes ... Never mind
You know,
Alvaro Herrera wrote:
Sorry, I wasn't trying to say that we should follow the Linux model all
that closely. I know there are regressions in the point zero
releases, and that there are bugs.
This morning a friend IM'ed me a comment about Martin Michlmayr's PhD
thesis, which is about release
On Thu, May 17, 2007 at 11:02:31PM -0400, Greg Smith wrote:
On Thu, 17 May 2007, David Fetter wrote:
Would you be interested in providing this meat? You're uniquely
qualified because your shins still smart from all the things you
barked them on :)
Unfortunately I'm temporarily on the
On Fri, May 18, 2007 at 12:05:55PM -0400, Alvaro Herrera wrote:
there are no obvious, glaring mistakes could go a long way. (I have
this weird idea that I should not apply a patch unless someone else says
hey, looks OK to me. Somehow, the mere lack of objections does not
increase my
On Thu, May 17, 2007 at 12:30:45PM -0700, Joshua D. Drake wrote:
It seems that it may be useful to allow something like:
DROP INDEX NOWAIT.
The idea being, that the terminal will come back, the index will be
dropped in the background. If it doesn't drop, it rollback like normal
and
On Fri, May 18, 2007 at 12:33:11AM +0800, Cui Shijun wrote:
Thank you for your suggestions, I am thinking about Full page writes
improvement. It seems not so complicated, just fit for a novice like
me.
I'll work on it. :-)
Updated on
On Fri, May 18, 2007 at 03:21:00PM +0200, Zdenek Kotala wrote:
What's about
- full page writes improvement
but I will have time after PGCon.
Added you to the list for that at
http://developer.postgresql.org/index.php/Todo:PatchStatus
--
Jim Nasby
On Fri, 2007-18-05 at 11:47 -0500, Jim C. Nasby wrote:
Assuming the concurrent psql stuff gets in, do you still see a use for
this?
I think concurrent psql (and/or async libpq) is the right way to handle
this sort of requirement. DROP INDEX NOWAIT is hacky, and would be
difficult (impossible?)
Joshua D. Drake [EMAIL PROTECTED] writes:
Yes. As cool as concurrent psql is... the majority of our users don't
use it. They use PgAdminIII.
So? IIRC pgAdmin can open up multiple connections already.
This should be client agnostic imo.
Just to be perfectly clear: the odds of making a
Jim C. Nasby wrote:
On Thu, May 17, 2007 at 12:30:45PM -0700, Joshua D. Drake wrote:
It seems that it may be useful to allow something like:
DROP INDEX NOWAIT.
The idea being, that the terminal will come back, the index will be
dropped in the background. If it doesn't drop, it rollback like
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Yes. As cool as concurrent psql is... the majority of our users don't
use it. They use PgAdminIII.
So? IIRC pgAdmin can open up multiple connections already.
This should be client agnostic imo.
Just to be perfectly clear: the odds
Neil Conway wrote:
On Fri, 2007-18-05 at 11:47 -0500, Jim C. Nasby wrote:
Assuming the concurrent psql stuff gets in, do you still see a use for
this?
I think concurrent psql (and/or async libpq) is the right way to handle
this sort of requirement. DROP INDEX NOWAIT is hacky, and would be
On Fri, 2007-18-05 at 13:29 -0400, Alvaro Herrera wrote:
I think what Joshua really wants is an equivalent of this
That's not what his original email asked for, at any rate.
start:
BEGIN;
LOCK TABLE foo IN ACCESS EXCLUSIVE MODE NOWAIT;
-- if fail, rollback and go to start
On Fri, May 18, 2007 at 01:39:56PM -0400, Neil Conway wrote:
On Fri, 2007-18-05 at 13:29 -0400, Alvaro Herrera wrote:
I think what Joshua really wants is an equivalent of this
That's not what his original email asked for, at any rate.
start:
BEGIN;
LOCK TABLE foo IN ACCESS
Bruce Momjian wrote:
In talking to people who are assigned to review patches or could review
patches, I often get the reply, Oh, yea, I need to do that.
Would it inspire more people to learn enough to become patch
reviewers if patch authors scheduled walkthroughs of their
patches with question
Hi,
I'm attempting a patch that would allow the COPY
command to copy into a view. I needed to code
something so as to get a clue, but the design has
not been discussed so I'm posting here rather
than the patches list.
I had a wee bit of discussion about this on IRC.
There was a suggestion to
I'm not sure exactly why you want to do with this, but it seems very
similar to what you can already do using prepared statements. Instead
of saying
COPY INTO (statement) (column [, ...])
a1,a2,a3,...,an
b1,b2,b3,...,bn
c1,c2,c3,...,cn
\.
You could instead say:
BEGIN WORK
PREPARE
Alvaro Herrera wrote:
Having the Linux process still in memory, I started thinking that maybe
what we need, is a sign-off process, whereby developer A reviews other
developers' patches, make comments, and when the commented-on developer
(call him B) has fixed the issues that A had, then A
Andrew Dunstan wrote:
Alvaro Herrera wrote:
Having the Linux process still in memory, I started thinking that maybe
what we need, is a sign-off process, whereby developer A reviews other
developers' patches, make comments, and when the commented-on developer
(call him B) has fixed the
Alvaro Herrera [EMAIL PROTECTED] writes:
In order to make patch review more effective, perhaps we could use some
tools to help us. How about
http://www.chipx86.com/blog/?p=222
I kinda think this is emphasizing the wrong end of the process. Code
everything, then ask for comments is about as
On 05/18/2007 07:05:50 PM, Robert Haas wrote:
I'm not sure exactly why you want to do with this, but it seems very
similar to what you can already do using prepared statements. Instead
of saying
COPY INTO (statement) (column [, ...])
a1,a2,a3,...,an
b1,b2,b3,...,bn
c1,c2,c3,...,cn
\.
I
On 05/18/2007 08:59:11 PM, Tom Lane wrote:
I'd like to see something that emphasizes review and feedback at the
stages of germinal idea, rough functional spec, implementation
concept,
etc. Reviewing the actual code is good too, but if that's the first
stage that you ask for help at, you are
On Fri, 2007-18-05 at 21:59 -0400, Tom Lane wrote:
I kinda think this is emphasizing the wrong end of the process.
I don't disagree, but I think a tool like this would still be enormously
helpful (to me, at any rate). While there's more to the process of
feature development than just mailing
37 matches
Mail list logo
