On Wed, 2008-04-16 at 22:18 -0400, Robert Treat wrote:
> > * USING query can be a VALUES clause if we wish to do single/few row
> > operations, so MERGE can be used for bulk-loading and OLTP
> >
> > * There is no RETURNING option for MERGE, nor for any INSERT/UPDATE
> > sub-clauses
>
> Is there a
Greg Sabino Mullane wrote:
I agree that we should do that, but the thread on -hackers ("Autovacuum
vs statement_timeout") wasn't totally conclusive. Greg Sabine Mullane
and Peter Eisentraut argued that we shouldn't, but neither provided a
plausible use case where a statement_timeout on restoring
Alvaro Herrera wrote:
Bruce Momjian wrote:
Alvaro Herrera wrote:
Maybe this means that we should give pgindent a run over the back
branches.
Yea, that thought has crossed our minds, but the problem is that there
is little testing of back branches so it would be risky.
That's a fair point,
On Wednesday 16 April 2008 14:58, Simon Riggs wrote:
> I've analysed various flavours of MERGE command to understand and
> propose what we should use for PostgreSQL.
>
> The results aren't what you'd expect from a quick flick through the
> standard, so lets look at my main concerns:
>
> 1. The simp
Gregory Stark wrote:
That's why waiting until feature freeze was so awful from my point of view.
There was never any time left to return patches to the author so Tom ended up
reworking any patches we really wanted.
Some patches went back and forth a few times even after feature freeze.
Ma
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Workflow A:
>
> 1. You post patch to pgsql-patches
> 2. a committer picks it up immediately, and commits it.
I'm more interested in knowing what happens when a committer *doesn't* commit
it. Personally I would almost rather a committer not commit
PFC wrote:
> Let's try this quick & dirty implementation of a local
> count-delta cache
> using a local in-memory hashtable (ie. {}).
> CREATE OR REPLACE FUNCTION update_count( key TEXT, delta INTEGER )
>RETURNS INTEGER
> AS $$
> if key in GD:
> GD[key] += delta
> els
Tom Lane wrote
> Transaction commit is an exceedingly subtle and carefully structured
> thing. Throwing random user-defined code into it ain't gonna happen.
Deferred constraint triggers currently run random user-defined code. This'll do
me.
Regards,
Stephen Denne.
Disclaimer:
At the Datamail G
The whole thing is a bit of an abuse of what the mechanism
was intended
for, and so I'm not sure we should rejigger GUC's behavior to make it
more pleasant, but on the other hand if we're not ready to provide a
better substitute ...
In my experiments with materialized views, I identified these
"Stephen Denne" <[EMAIL PROTECTED]> writes:
> Aside: It is currently more cumbersome to get a function to run, if needed,
> at commit. Ideal solution would be something like "EXECUTE ON COMMIT
> my_function()" or maybe "SAVEPOINT my_name ON COMMIT my_function()", but
> these suggestions are made
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > I am reviewing the psql wrap patch and just used pgindent today to clean
> > > it up. (pgindent did not add any extra spacing changes.) Patch
> > > reviewers should probably be able to run pgindent.
> >
>
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am reviewing the psql wrap patch and just used pgindent today to clean
> > it up. (pgindent did not add any extra spacing changes.) Patch
> > reviewers should probably be able to run pgindent.
>
> Well, that means nobody in the wo
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am reviewing the psql wrap patch and just used pgindent today to clean
> it up. (pgindent did not add any extra spacing changes.) Patch
> reviewers should probably be able to run pgindent.
Well, that means nobody in the world can review except you, b
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> I suggested to you awhile back that we could keep a typedef file on the
> repository, saving one step.
That kind of sucks since it means you get conflicts when you update if you've
run it yourself.
Is there a reason we can't write makefiles which ge
On Wed, Apr 16, 2008 at 4:54 PM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> Joshua D. Drake escribió:
>
> > That is an interesting idea. Something like:
> >
> > pg_restore -E "SET STATEMENT_TIMEOUT=0; SET MAINTENANCE_WORK_MEM=1G" ?
>
> We already have it -- it's called PGOPTIONS.
>
Ok but is n
Tom Lane wrote
> "Stephen Denne" <[EMAIL PROTECTED]> writes:
> > From: Tom Lane [mailto:[EMAIL PROTECTED]
> >> As for 2) and 3), can't you look into the pg_settings view?
>
> > pg_settings view doesn't contain custom variables created
> on the fly,
>
> Really? [ pokes around ... ] Hm, you're r
Chris Browne wrote:
> > That is much a more radical use of pgindent than it has had in the past
> > but it is certainly possible.
>
> Well, supposing you're cleaning up a patch after someone has generated
> it in bad style, it would seem like rather less work to use pgindent
> to impose style poli
On Wed, 16 Apr 2008, Joshua D. Drake wrote:
I've added a redirect at http://wiki.postgresql.org/wiki/CommitFest
which currently points to May, but should be updated whenever we close
a commitfest against new submissions.
We should also update the FAQ.
I wouldn't bother with that yet. That w
Joshua D. Drake escribió:
> On Wed, 16 Apr 2008 18:50:28 -0400
> Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> > Actually, it's probably more important to be selectable at restore
> > time than at dump time, so if you're doing just one ...
I think the patch posted by Joshua at the start of this thr
On Wed, 16 Apr 2008 18:50:28 -0400
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
>
> Alex Hunsaker wrote:
> >
> >
> > Sorry if i missed the obvious reason not to do this... but if its a
> > command line option the user can choose. Why not something like
> > this (i did it for pg_dump only...)
> >
Alex Hunsaker wrote:
Sorry if i missed the obvious reason not to do this... but if its a
command line option the user can choose. Why not something like this
(i did it for pg_dump only...)
Actually, it's probably more important to be selectable at restore time
than at dump time, so if
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> Alvaro Herrera wrote:
>>> Maybe this means that we should give pgindent a run over the back
>>> branches.
>>
>> Yea, that thought has crossed our minds, but the problem is that there
>> is little testing of back branches so it wo
On Wed, Apr 16, 2008 at 4:32 PM, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> On Wed, 16 Apr 2008 15:22:31 -0700
>
> "Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
>
>
> > On Wed, 16 Apr 2008 22:17:30 -
> > "Greg Sabino Mullane" <[EMAIL PROTECTED]> wrote:
> >
> > > I don't think it's fair to s
On Wed, 16 Apr 2008 15:22:31 -0700
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
> On Wed, 16 Apr 2008 22:17:30 -
> "Greg Sabino Mullane" <[EMAIL PROTECTED]> wrote:
>
> > I don't think it's fair to simply discard the use cases provided as
> > "implausible" and demand one more to your liking.
[EMAIL PROTECTED] (Bruce Momjian) writes:
> Chris Browne wrote:
>> >> Would it be a terrible idea to...
>> >>
>> >> - Draw the indent code from NetBSD into src/tools/pgindent
>> >> - Build it _in place_ inside the code tree (e.g. - don't assume
>> >> it will get installed in /usr/local/bin)
>>
On Wed, 16 Apr 2008 22:17:30 -
"Greg Sabino Mullane" <[EMAIL PROTECTED]> wrote:
> I don't think it's fair to simply discard the use cases provided as
> "implausible" and demand one more to your liking. I strongly dislike
> having a giant dump file written that has non-vital configuration
> va
On Wed, Apr 16, 2008 at 05:22:17PM -0400, Tom Lane wrote:
> I dunno about "intentional", but the API exposed by libpq for COPY
> doesn't really permit any other behavior: you push all the data and
> then look to see if it worked or not.
Oh? I expected the PQputData would return -1 as stated by the
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> I agree that we should do that, but the thread on -hackers ("Autovacuum
> vs statement_timeout") wasn't totally conclusive. Greg Sabine Mullane
> and Peter Eisentraut argued that we shouldn't, but neither provided a
> plausible use case where
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Maybe this means that we should give pgindent a run over the back
> > branches.
>
> Yea, that thought has crossed our minds, but the problem is that there
> is little testing of back branches so it would be risky.
That's a fair point, though I won
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
ISTM that we must fix the bgwriter so that ForgetDatabaseFsyncRequests
causes PendingUnlinkEntrys for the doomed DB to be thrown away too.
Because of the asynchronous nature of ForgetDatabaseFsy
Alvaro Herrera wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> > > I hate to say it but pgindent formatting changes are usually made in
> > > cases where you or the community want pgindent to improve its indenting.
> > > :-)
> > > So we improve pgindent but pay for it i
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I hate to say it but pgindent formatting changes are usually made in
> > cases where you or the community want pgindent to improve its indenting. :-)
> > So we improve pgindent but pay for it in backpatching difficulties. :-(
>
> Ye
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> ISTM that we must fix the bgwriter so that ForgetDatabaseFsyncRequests
>> causes PendingUnlinkEntrys for the doomed DB to be thrown away too.
> Because of the asynchronous nature of ForgetDatabaseFsyncRequests, this
> still isn't
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It's bad enough that Bruce whacks around his copy from time to time :-(.
> I hate to say it but pgindent formatting changes are usually made in
> cases where you or the community want pgindent to improve its indenting. :-)
> So we impr
Tom Lane wrote:
> We could possibly fix libpq to start dropping the data on the floor
> if it sees an error reply already pending, but that's only going
> to be an incremental change.
I think this incremental change makes a lot of sense. What point is
there in transmitting the data over the netw
Tom Lane wrote:
> The main problem I see with "pgindent early and often" is that it only
> works well if everyone is using exactly the same pgindent code (and
> exactly the same typedef list). Otherwise you just get buried in
> useless whitespace diffs.
>
> It's bad enough that Bruce whacks aroun
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> I notice that while doing bulk-loads that any errors detected by the
> backend arn't noticed by libpq until right at the end. Is this
> intentional?
I dunno about "intentional", but the API exposed by libpq for COPY
doesn't really permit any oth
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Apr 17, 2008 at 1:16 AM, Tom Lane wrote:
> "Brendan Jurd" writes:
>
> >> If we don't want to meddle with xmltype/bytea/VarChar at all, we'll
> >> have to revert those changes, and I'll have to seriously scale back
> >> the cleanup patch I w
Chris Browne <[EMAIL PROTECTED]> writes:
> Would it be a terrible idea to...
>
> - Draw the indent code from NetBSD into src/tools/pgindent
I am not real eager to become maintainers of our own indent fork, which
is what you propose. (Just for starters, what will we have to do to
make it run on n
Martijn,
* Martijn van Oosterhout ([EMAIL PROTECTED]) wrote:
> Is there anything that can be done? I've tried putting in
> PQconsumeInput in places but it doesn't appear to help.
I certainly hope something can be done, I've noticed this exact same
issue myself and it's very annoying. I've resort
Hi,
I notice that while doing bulk-loads that any errors detected by the
backend arn't noticed by libpq until right at the end. Is this
intentional? Looking at the code we have this comment in putCopyData:
/*
* Process any NOTICE or NOTIFY messages that might be pending in the
* input buf
Merlin Moncure wrote:
I've been mostly following this discussion on
this particular topic but have absolutely no idea what, if anything,
to do on the wiki in terms of submitting patch.
I think the short answer right now to this and to Joshua's original
question is: to submit a patch do w
On Thu, 17 Apr 2008 06:19:49 +1000
"Brendan Jurd" <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Thu, Apr 17, 2008 at 6:03 AM, Merlin Moncure wrote:
> > One small point here. I've been mostly following this discussion
> > on this particular topic but have a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Apr 17, 2008 at 6:03 AM, Merlin Moncure wrote:
> One small point here. I've been mostly following this discussion on
> this particular topic but have absolutely no idea what, if anything,
> to do on the wiki in terms of submitting patch.
Heikki Linnakangas wrote:
> Based on my observations, there's basically three different workflows a
> patch can follow (assuming the patch gets committed in the end):
>
> Workflow A:
>
> 1. You post patch to pgsql-patches
> 2. a committer picks it up immediately, and commits it.
>
> Workflow B:
Brendan Jurd wrote:
> > OK. FYI, what would be really nice would be for someone to review and
> > apply the patch or give the author feedback so we could avoid adding it
> > to the wiki at all.
>
> Bruce,
>
> Yes, that would be nice! But not likely in practice, unless your
> patch happens to
Chris Browne wrote:
> >> Would it be a terrible idea to...
> >>
> >> - Draw the indent code from NetBSD into src/tools/pgindent
> >> - Build it _in place_ inside the code tree (e.g. - don't assume
> >> it will get installed in /usr/local/bin)
> >> - Thus have the ability to run it in place?
> >
On Wed, Apr 16, 2008 at 3:47 PM, Brendan Jurd <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 17, 2008 at 5:17 AM, Bruce Momjian
> > Andrew Dunstan wrote:
> > > Bruce Momjian wrote:
> > > >
>
> > > > This is one of the reasons I didn't want to add wiki maintenance to my
> > > > already full workl
Tom Lane wrote:
Actually ... what if the same DB OID and relfilenode get re-made before
the checkpoint? Then we'd be unlinking live data. This is improbable
but hardly less so than the scenario the PendingUnlinkEntry code was
put in to prevent.
ISTM that we must fix the bgwriter so that Forget
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Apr 17, 2008 at 5:17 AM, Bruce Momjian
wrote:
> Andrew Dunstan wrote:
> > Bruce Momjian wrote:
> > >
> > > This is one of the reasons I didn't want to add wiki maintenance to my
> > > already full workload. Instead I am having to field co
[EMAIL PROTECTED] (Bruce Momjian) writes:
> Chris Browne wrote:
>> [EMAIL PROTECTED] (Bruce Momjian) writes:
>> > Magnus Hagander wrote:
>> >> > And I think adopting surrounding naming, commeting, coding conventions
>> >> > should come naturally as it can aide in copy-pasting too :)
>> >>
>> >> I
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> > Frankly, I am getting pretty tired of people complaining about what I am
> > doing. Perhaps I should just stop and let everyone else deal with
> > things. I have lots of things I would rather be doing.
> >
> > This is one of the reasons I did
I've analysed various flavours of MERGE command to understand and
propose what we should use for PostgreSQL.
The results aren't what you'd expect from a quick flick through the
standard, so lets look at my main concerns:
1. The simplest syntax is for SQL:2003. The syntax for DB2, SQL Server
and
Andrew Dunstan wrote:
> BTW, I don't see why the wiki can't pick up patches that were submitted
> before it started.
Of course it can. This one wasn't added initially because I didn't see it.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Compan
On Wed, 16 Apr 2008 14:24:34 -0400 (EDT)
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > If you are going to review the patch and apply or reply to the
> > author, at one point is it supposed to be on the wiki?
>
> I have no idea. If not dealt with, it will be on my web page once the
> next commit
Peter Eisentraut wrote:
Am Dienstag, 15. April 2008 schrieb Zdenek Kotala:
JavaDB and Firebird community use Jira
Jira had already been rejected many years ago because it is not open source.
Jira is also tremendously slow. Not a good system when an individual
has to move quickly th
Joshua D. Drake wrote:
On Wed, 16 Apr 2008 13:59:50 -0400
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
If you posted it last month then it was too late for the commit-fest
that started on March 1, IIRC, so the fact that you didn't get
feedback is hardly surprising - a commit-fest is like a
mini-f
I wrote:
> I realized that we failed to plug all the gaps of this type,
> because relcache.c contains *internal* cache load/reload operations
> that aren't protected. In particular the LOAD_CRIT_INDEX macro
> calls invoke relcache load on indexes that aren't locked. So they'd
> be at risk from a
Bruce Momjian wrote:
Frankly, I am getting pretty tired of people complaining about what I am
doing. Perhaps I should just stop and let everyone else deal with
things. I have lots of things I would rather be doing.
This is one of the reasons I didn't want to add wiki maintenance to my
alread
Joshua D. Drake wrote:
> On Wed, 16 Apr 2008 14:13:53 -0400 (EDT)
> Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> > > > I review it and apply or reply to the author. The wiki had
> > > > started being updated after your submission so this is a
> > > > transitionary phase.
> > >
> > > Wait... appl
Andrew Dunstan wrote:
> > If you posted it last month then it was too late for the
> > commit-fest that started on March 1, IIRC, so the fact that you
> > didn't get feedback is hardly surprising - a commit-fest is like a
> > mini-feature-freeze.
> >
> O.k. then
On Wed, 16 Apr 2008 21:20:17 +0300
Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> > My patch addresses all three, unless I am misunderstanding your
> > meaning. The patch does the following:
> >
> > After connection with pg_dump it executes set statement_timeout = 0;
> > This fixed the pg_dump t
On Wed, 16 Apr 2008 14:13:53 -0400 (EDT)
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > > I review it and apply or reply to the author. The wiki had
> > > started being updated after your submission so this is a
> > > transitionary phase.
> >
> > Wait... apply where? The wiki? or to the tree?
>
>
Joshua D. Drake wrote:
On Wed, 16 Apr 2008 21:04:17 +0300
Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
To quote Tom:
I think we need to be careful to distinguish three situations:
* statement_timeout during pg_dump
* statement_timeout during pg_restore
* statement_timeout during psql reading
Bruce Momjian wrote:
Joshua D. Drake wrote:
On Wed, 16 Apr 2008 14:10:30 -0400 (EDT)
Bruce Momjian <[EMAIL PROTECTED]> wrote:
Joshua D. Drake wrote:
On Wed, 16 Apr 2008 13:59:50 -0400
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
If you posted it last month then it was
Joshua D. Drake wrote:
> On Wed, 16 Apr 2008 14:10:30 -0400 (EDT)
> Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> > Joshua D. Drake wrote:
> > > On Wed, 16 Apr 2008 13:59:50 -0400
> > > Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> > >
> > > >
> > > > If you posted it last month then it was too lat
On Wed, 16 Apr 2008 14:10:30 -0400 (EDT)
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Joshua D. Drake wrote:
> > On Wed, 16 Apr 2008 13:59:50 -0400
> > Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > If you posted it last month then it was too late for the
> > > commit-fest that started
Joshua D. Drake wrote:
> On Wed, 16 Apr 2008 13:59:50 -0400
> Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
> >
> > If you posted it last month then it was too late for the commit-fest
> > that started on March 1, IIRC, so the fact that you didn't get
> > feedback is hardly surprising - a commit-f
On Wed, 16 Apr 2008 21:04:17 +0300
Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> To quote Tom:
> > I think we need to be careful to distinguish three situations:
> >
> > * statement_timeout during pg_dump
> > * statement_timeout during pg_restore
> > * statement_timeout during psql reading a pg
Joshua D. Drake wrote:
What is the feedback on this patch? Is there anything I need to do to
get it into the next commit fest?
Yes, go add it to the wiki page ;-):
http://wiki.postgresql.org/wiki/CommitFest:May
I agree that we should do that, but the thread on -hackers ("Autovacuum
vs stateme
On Wed, 16 Apr 2008 13:59:50 -0400
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
> If you posted it last month then it was too late for the commit-fest
> that started on March 1, IIRC, so the fact that you didn't get
> feedback is hardly surprising - a commit-fest is like a
> mini-feature-freeze.
Joshua D. Drake wrote:
Hello,
Could someone break out exactly what the process is "now" for
submitting a patch? Last month I sent a patch for pg_dump which never
got feedback (at least on thread). I just asked and alvaro asked me to
add it to the commitfest page. Which I have done but I think
Hello,
Could someone break out exactly what the process is "now" for
submitting a patch? Last month I sent a patch for pg_dump which never
got feedback (at least on thread). I just asked and alvaro asked me to
add it to the commitfest page. Which I have done but I think we need to
known all the st
On Wed, 16 Apr 2008 13:36:50 -0400
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Joshua D. Drake wrote:
>
> > What is the feedback on this patch? Is there anything I need to do
> > to get it into the next commit fest?
>
> Please add it to the commitfest wiki page.
>
> http://wiki.postgresql.org/w
Joshua D. Drake wrote:
> What is the feedback on this patch? Is there anything I need to do to
> get it into the next commit fest?
Please add it to the commitfest wiki page.
http://wiki.postgresql.org/wiki/CommitFest:May
--
Alvaro Herrerahttp://www.CommandPrompt
Bruce Momjian wrote:
> Chris Browne wrote:
> > Would it be a terrible idea to...
> >
> > - Draw the indent code from NetBSD into src/tools/pgindent
> > - Build it _in place_ inside the code tree (e.g. - don't assume
> > it will get installed in /usr/local/bin)
> > - Thus have the ability to ru
On Tue, 11 Mar 2008 11:07:27 -0700
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Tue, 11 Mar 2008 10:46:23 -0700
> "Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
>
> And the -c version :) (thanks bruce)
>
> Joshua D. Drake
>
What is the fe
Chris Browne wrote:
> [EMAIL PROTECTED] (Bruce Momjian) writes:
> > Magnus Hagander wrote:
> >> > And I think adopting surrounding naming, commeting, coding conventions
> >> > should come naturally as it can aide in copy-pasting too :)
> >>
> >> I think pg_indent has to be made a lot more portable
Added to TODO:
* Implement the non-threaded Avahi service discovery protocol
http://archives.postgresql.org/pgsql-hackers/2008-02/msg00939.php
http://archives.postgresql.org/pgsql-patches/2008-02/msg00097.php
http://archives.postgresql.org/pgsql-hackers/2008-03/msg01211.php
http://archiv
[EMAIL PROTECTED] (Bruce Momjian) writes:
> Magnus Hagander wrote:
>> > And I think adopting surrounding naming, commeting, coding conventions
>> > should come naturally as it can aide in copy-pasting too :)
>>
>> I think pg_indent has to be made a lot more portable and easy to use
>> before that
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> The closest thing I can think of to an automated test is to run repeated
> >> sets of the parallel regression tests, and each time SIGTERM a randomly
> >> chosen backend at a randomly chosen time. Then see if anyt
Chris Browne wrote:
> [EMAIL PROTECTED] (Tom Lane) writes:
> > Magnus Hagander <[EMAIL PROTECTED]> writes:
> >> I think pg_indent has to be made a lot more portable and easy to use
> >> before that can happen :-) I've run it once or twice on linux machines,
> >> and it comes out with huge changes c
On Wed, 16 Apr 2008 12:36:50 -0400 (EDT)
Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> If the patch submitters hasn't read the developers' FAQ, we assume
> they are not interested in improving the style of their patch.
I think that point is fairly flawed in consideration. I know for a fact
that I
Chris Browne <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Tom Lane) writes:
>> Every so often there are discussions of going over to GNU indent
>> instead. Presumably that would solve the portability problem.
>> The last time we tried it (which was a long time ago) it seemed
>> to have too man
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The closest thing I can think of to an automated test is to run repeated
>> sets of the parallel regression tests, and each time SIGTERM a randomly
>> chosen backend at a randomly chosen time. Then see if anything "funny"
> Yep, that
[EMAIL PROTECTED] (Tom Lane) writes:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> I think pg_indent has to be made a lot more portable and easy to use
>> before that can happen :-) I've run it once or twice on linux machines,
>> and it comes out with huge changes compared to what Bruce gets on
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I'm willing to enable a SIGTERM-based pg_terminate_backend for 8.4
> >> if there is some reasonable amount of testing done during this
> >> development cycle to try to expose any problems.
>
> > If someone can c
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'm willing to enable a SIGTERM-based pg_terminate_backend for 8.4
>> if there is some reasonable amount of testing done during this
>> development cycle to try to expose any problems.
> If someone can come up with an automated scrip
Magnus Hagander wrote:
> > And I think adopting surrounding naming, commeting, coding conventions
> > should come naturally as it can aide in copy-pasting too :)
>
> I think pg_indent has to be made a lot more portable and easy to use
> before that can happen :-) I've run it once or twice on linux
Brendan Jurd wrote:
> > The idea that we "fix" stylistic issues on the fly is not sustainable.
> > We should offer help and mentorship to new patch submitters in all
> > areas (including stylistic) but they should do the work. It is the only
> > way we will mold them to submit patches in the pr
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am starting to think we need to analyze the source code rather than
> > testing, because of what we are testing for.
>
> I was thinking about that a bit more, in connection with trying to
> verbalize why I don't like your patch ;-)
I have just installed the rpm found at:
http://www.postgresql.org/ftp/binary/v8.2.7/linux/rpms/redhat/rhel-4-i386/
and the status option generates an error:
$ /etc/init.d/postgresql status
pidof: invalid options on command line!
pidof: invalid options on command line!
-p is stopped
I was abl
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> I wonder if this would help to clean up the equivalence class hacks in
>> Greg's ordered append patch?
>
> Pretty hard to say at this early stage,
I've started to have some doubts myself about stuffing a
Gregory Stark <[EMAIL PROTECTED]> writes:
> No, I meant the earlier patch which you rejected with the flag in MyProc. I
> realize there were other issues but the initial concern was that it wouldn't
> respond promptly because it would wait for CHECK_FOR_INTERRUPTS.
No, that's not the concern in th
Tom Lane wrote:
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
If we don't want to meddle with xmltype/bytea/VarChar at all, we'll
have to revert those changes, and I'll have to seriously scale back
the cleanup patch I was about to post.
Still not sure where we stand on the above.
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I wonder if this would help to clean up the equivalence class hacks in
> Greg's ordered append patch?
Pretty hard to say at this early stage, but the more I think about it
the more I like the idea of never using the same Var to represent two
values
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Florian suggested a scheme where the xid and epoch is embedded in the
filename, but that's unnecessarily complex. We could just make
relfilenode a 64-bit integer. 2^64 should be enough for everyone.
Doesn't fix the problem unless
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
>> If we don't want to meddle with xmltype/bytea/VarChar at all, we'll
>> have to revert those changes, and I'll have to seriously scale back
>> the cleanup patch I was about to post.
> Still not sure where we stand on the above. To cast, or not to cast?
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> "Tom Lane" <[EMAIL PROTECTED]> writes:
>>> No, we wouldn't, because a SIGTERM can only actually fire at a
>>> CHECK_FOR_INTERRUPTS() call. You'd just need to be sure there wasn't
>>> one in the cleanup code.
>
>
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> No, we wouldn't, because a SIGTERM can only actually fire at a
>> CHECK_FOR_INTERRUPTS() call. You'd just need to be sure there wasn't
>> one in the cleanup code.
> Wait, huh? In that case I don't see what advan
1 - 100 of 131 matches
Mail list logo
