I wrote:
> Rather than expecting user-level scripts to get this corner case
> right, I suggest that we ought to modify pg_stop_backup and friends
> so that what they return is the last used byte address of WAL, not
> the first unused byte address as now. Then, blindly extracting
> the filename wil
Simon Riggs <[EMAIL PROTECTED]> writes:
> Patch included to implement xlog switching, using an xlog record
> "processing instruction" and forcibly moving xlog pointers.
Applied with revisions. I didn't like the extra state you added to
track whether an xlog switch had occurred --- the more bits o
Quoth [EMAIL PROTECTED] (David Fetter):
> On Fri, Aug 04, 2006 at 02:37:56PM -0700, Neil Conway wrote:
>> On Fri, 2006-08-04 at 12:40 -0700, David Fetter wrote:
>> > While I am not going to reopen the can of worms labeled 'bug
>> > tracker', I think it would be good to have a little more formality
In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] ("Jim
C. Nasby") transmitted:
>> What say?
>
> It's a shame to have a person burn cycles on this, but anything would be
> an improvement over what we've got now.
"Anything" includes some options that would probably *not* be
i
Josh Berkus writes:
>> Proposal C - PITR with in on the fly disk upgrades
>> 1) setup PITR
>> 2) run pg_upgrade on your latest backed up data directories
>> 3) start up the new pg on that data directory in restartable
>> recovery / read-only / hot-standby mode
>> 4) update the recovery log importe
Tom Lane wrote:
> Martijn van Oosterhout writes:
>> On Sat, Aug 05, 2006 at 12:19:54AM -0400, Matthew T. O'Connor wrote:
>>> FTI is a biggie in my mind. I know it ain't happening for 8.2, but is
>>> the general plan to integrate TSearch2 directly into the backend?
>
>> When the Tsearch developers
I'm noticing that if the current XLOG offset is exactly at a segment
boundary (ie, the last wal record just filled the segment) then the
various user-level functions return offsets that could be interpreted
as the start of the next segment, eg
regression=# select pg_switch_xlog();
pg_switch_xlog
[EMAIL PROTECTED] wrote:
Ron Mayer wrote:
We have not had that many cases where lack of
communication was a problem.
One could say too much communication was the problem this time.
I get the impression people implied they'd do something on a TODO
and didn't. Arguably the project had been bett
Ron Mayer wrote:
>
>> We have not had that many cases where lack of
>> communication was a problem.
>
> One could say too much communication was the problem this time.
>
> I get the impression people implied they'd do something on a TODO
> and didn't. Arguably the project had been better off if no
Tom Lane wrote:
I tend to agree --- I don't see much value in trying to institute a
formalized process.
One more problem with the formalized process of claiming features
in advance may stop what I suspect is a significant source of
contributions -- people who add features/patches for internal
w
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> On 8/5/06, Tom Lane <[EMAIL PROTECTED]> wrote:
>> BTW, it occurs to me to wonder whether we've picked a good choice
>> of syntax. I don't remember where the suggestion to use "RETURNING"
>> came from (did we borrow it from another DBMS?).
> Oracle.
Josh Berkus wrote:
I doubt that any TODO system would have 100% participation, and I know that it
would depend on having some non-hacker volunteers updating the information on
behalf of developers who didn't want to use it. However, I think that
getting those volunteers is entirely possible (
Rick,
> The objective is to smoothly upgrade to the new version with minimal
> downtime.
Thanks for jumping in.
> The different proposals as far as I can see are as follows:
>
> Proposal A - the big one time reformatting
> 1) shutdown the db
> 2) run a command that upgrades the data directory to
Neil, all:
> If people are interested in the status of a patch, I think it's fine for
> them to email the person who's volunteered to work on it.
The problem I would like to see resolved is that there is currently no
accurate way to determine who is working on a patch except by comprehensive
-h
On 8/5/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Huh? Why'd you remove it? I can't imagine it makes things
significantly simpler to omit that case, and even if you can't
think of uses for it, I can (taking jobs from a to-do queue for
instance).
It can be added back. Dequeing is a good use-case
On Sat, Aug 05, 2006 at 01:14:25PM -0400, Tom Lane wrote:
> If there's only a small number of possibilities, you could fix it by
> treating these as if they were locale differences --- that is, provide
> multiple expected files test.out, test_1.out, etc.
Frankly I have no idea. I was thinking abou
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> Here's the updated patch with DELETE RETURNING removed. This isn't
> really an issue because no one wanted DELETE RETURNING to begin with.
Huh? Why'd you remove it? I can't imagine it makes things
significantly simpler to omit that case, and even
Michael Meskes <[EMAIL PROTECTED]> writes:
> Some types have different internal sizes on different systems. I wonder
> what we do with these difference as a log file usually prints this info
> which is important for debugging sometimes.
If there's only a small number of possibilities, you could fi
On Fri, Aug 04, 2006 at 12:59:35PM -0400, Tom Lane wrote:
> *** expected/complex-test4.stdout Wed Aug 2 10:14:02 2006
> --- results//complex-test4.stdout Fri Aug 4 12:56:13 2006
> ***
> *** 1,4
> ! Found f=14,07 text=0123456789 b=1
> Found a[0] = 9
> Found a[1] =
Martijn van Oosterhout writes:
> On Sat, Aug 05, 2006 at 12:19:54AM -0400, Matthew T. O'Connor wrote:
>> FTI is a biggie in my mind. I know it ain't happening for 8.2, but is
>> the general plan to integrate TSearch2 directly into the backend?
> When the Tsearch developers say so I think.
Yeah,
The fact is, the existing system worked as it should, though it is often
invisible. We didn't get all the features we wanted, but that isn't
because the system isn't working.
Well that kind of comes back to my point of better communication.
Perhaps a lot of this discussion could have been av
Bruce Momjian wrote:
I can assure you that individual developers were contacted about
completing their items for 8.2, to the extent that some developers got
upset at me because of my insistence. If they were hired by PostgreSQL
companies and I had a relationship with their manager, their mana
All,
In the spirit of our previous discussion, I am writing to inform you
that Mark Cave-Ayland and I will be working on this TODO-item
together. We are thinking through a new design (not based on the
current patch) and will post it to -hackers for approval soon.
--
Jonah H. Harris, Software Ar
There's also supposed to be a wiki set up. There, people can try to
make up tracking lists, project management, task lists, release goals
or whatever on their own. If patterns emerge, we can "formalize" them,
but I feel this would be a good way to try things out.
Well I will re-extend my o
[EMAIL PROTECTED] wrote:
> > [EMAIL PROTECTED] writes:
> >>> I don't object to someone informally polling people who have claimed a
> >>> TODO item and not produced any visible progress for awhile. But I
> >>> think
> >>> anything like "thou shalt report in once a week" will merely drive
> >>> peo
On Fri, Aug 04, 2006 at 06:25:35PM -0700, Joshua D. Drake wrote:
> I have heard you make this argument before, and it is just is not true.
> Even Debian is moving toward a more formal structure as has FreeBSD. You
> seem stuck in this world where everything is still 1994 and all FOSS
> software
Tom Lane wrote:
But a quick troll through the CVS logs shows ...
multi-row VALUES, not only for INSERT but everywhere SELECT is allowed ...
multi-argument aggregates, including SQL2003-standard statistical aggregates ...
standard_conforming_strings can be turned on (HUGE deal for some people) ..
On Sat, Aug 05, 2006 at 12:19:54AM -0400, Matthew T. O'Connor wrote:
> Robert Treat wrote:
> >So, the things I hear most non-postgresql people complain about wrt
> >postgresql are:
> >
> >no full text indexing built in
>
> FTI is a biggie in my mind. I know it ain't happening for 8.2, but is
>
> [EMAIL PROTECTED] writes:
>>> I don't object to someone informally polling people who have claimed a
>>> TODO item and not produced any visible progress for awhile. But I
>>> think
>>> anything like "thou shalt report in once a week" will merely drive
>>> people away from publicly claiming items
On Sat, Aug 05, 2006 at 10:01:30AM +0200, Pavel Stehule wrote:
> I found maybe interesting article
> http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0603wasserman2/
That for the article. I had been meaning to look at DB2, and it gave me a
quick summary.
What I get from the artic
Hello,
I found maybe interesting article
http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0603wasserman2/
good days
Pavel Stehule
_
Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com.
http://www.msn.cz/
Joshua D. Drake wrote:
> Frankly, I don't care if we ever get a bug tracker or use trac.
> However a more formalized communication process is sorely needed
> IMHO.
There's also supposed to be a wiki set up. There, people can try to
make up tracking lists, project management, task lists, release
If people are going to start listing features they want here's some
things I think would be nice. I have no idea though if they would be
useful to anyone else:
1) hierarchical / recursive queries. I realize it's just been
discussed at length but since there was some question as to whether
33 matches
Mail list logo
