Tom Lane wrote:
There is, although I think a large fraction of it will get bounced as
"needs more work", which should reduce the pressure. We'll just be
trying to give feedback to let the patch authors move forward, which
will not take as much time as actually committing would take.
The current
Hello,
I have been testing a migration for a week now trying to get it into a
reasonable state. This is what we have:
Restore file 220G
8.2.6 and 8.3.0 are configured identically:
shared_buffers = 8000MB
work_mem = 32MB
maintenance_work_mem = 512MB
fsync = off
full_page_writes = off
checkpoint_
On Feb 6, 2008 1:52 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Josh Berkus escribió:
>
> > I think we might want to do something along the lines of what Stefan set up
> > (at least I think it was he) for the end of 8.4 on developer.postgresql.org.
> > Bruce's patch list is easy to update, but
Zdenek Kotala wrote:
> Tom Lane wrote:
> > Zdenek Kotala <[EMAIL PROTECTED]> writes:
> >> Tom Lane wrote:
> >>> If you only got 2% out of it, it's not even worth thinking about how to
> >>> fix the serious bugs that approach would create (primarily, lack of
> >>> control over when pages can get flu
Tom Lane wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > Just thinking that we'll need somewhere to park the new patches which
> > roll in during a commit fest.
>
> Bruce has always kept two patch queues, one for the current version and
> one for the stuff held for the next version. This
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
O.k. I am not too interested in starting a whole war here (again) but
for the record, we have what appears to be a perfectly working
capability to move from cvs to svn. So *if* review board is something
we really like, the SCM shou
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> O.k. I am not too interested in starting a whole war here (again) but
> for the record, we have what appears to be a perfectly working
> capability to move from cvs to svn. So *if* review board is something
> we really like, the SCM should not be the
"Zdenek Kotala" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Zdenek Kotala <[EMAIL PROTECTED]> writes:
>>> Tom Lane wrote:
If you only got 2% out of it, it's not even worth thinking about how to
fix the serious bugs that approach would create (primarily, lack of
control over whe
On Wed, 06 Feb 2008 18:50:34 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> > I've read some developers appreciating the way review board works:
> > http://review-board.org/
> > http://code.google.com/p/reviewboard/
> > http://code.google.com/p/reviewboard/wiki/UserBasics
>
> Hmm, the info on
Dimitri Fontaine <[EMAIL PROTECTED]> writes:
> Le Wednesday 06 February 2008 21:35:54 Peter Eisentraut, vous avez écrit :
>> Yes, I feel we could use a group writeable patch queue of some sort.
>> Perhaps an IMAP server setup could do the job.
> I've read some developers appreciating the way revi
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I don't know if anyone has a makefile for it, but the following seems to work
> for me:
> pgsql/src/backend$ cc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
> -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g
> -L../../
On Wed, 6 Feb 2008, Magnus Hagander wrote:
Is it technically possible to set permissions on a per-page basis?
Technically possible? Of course. It's sure not easy to do, though; the
Mediawiki team considers having any real ACL structure added onto their
code a non-feature and last time I ch
Paul van den Bogaard wrote:
> The SunStudio compiler we are using fortunately has an option for
> this. Unfortunately there are restrictions. One restriction I face is
> its inability to deal with "ld -r"s. These are used in the build
> environment to create all the SUBSYS.o object files.
>
>
On Feb 3, 2008 7:41 PM, Jaime Casanova <[EMAIL PROTECTED]> wrote:
> On Feb 3, 2008 7:26 PM, Omar Bettin <[EMAIL PROTECTED]> wrote:
> > Probably I am on the wrong place but for me NULL on numbers means 0 or ZERO.
> > I know about standards...
> >
>
> NULL means unknown value, ZERO is a known value
Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
Josh Berkus escribió:
I think we might want to do something along the lines of what Stefan set
up (at least I think it was he) for the end of 8.4 on
developer.postgresql.org. Bruce's patch list is easy to update, but hard
to read. I'
On Wed, 06 Feb 2008 22:07:06 +0100
Magnus Hagander <[EMAIL PROTECTED]> wrote:
> Joshua D. Drake wrote:
> > On Wed, 06 Feb 2008 15:46:22 -0500
> > Tom Lane <[EMAIL PROTECTED]> wrote:
> >
> >> Seems like a wiki page with links to pgsql-patches archive entries
> >> would be easy. But an issue for
Le Wednesday 06 February 2008 21:35:54 Peter Eisentraut, vous avez écrit :
> Alvaro Herrera wrote:
> > Easy to update for Bruce -- for anyone else it is impossible to update
> > AFAIK.
>
> Yes, I feel we could use a group writeable patch queue of some sort.
> Perhaps an IMAP server setup could do
Tom Lane wrote:
Zdenek Kotala <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
If you only got 2% out of it, it's not even worth thinking about how to
fix the serious bugs that approach would create (primarily, lack of
control over when pages can get flushed to disk).
You can flush a pages by msyn
Joshua D. Drake wrote:
On Wed, 06 Feb 2008 15:46:22 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
Seems like a wiki page with links to pgsql-patches archive entries
would be easy. But an issue for any of this is who has permissions
to edit the queue? I concur that "Bruce only" is the wrong answe
On Wed, 06 Feb 2008 15:46:22 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> Seems like a wiki page with links to pgsql-patches archive entries
> would be easy. But an issue for any of this is who has permissions
> to edit the queue? I concur that "Bruce only" is the wrong answer,
> but I'm not sur
Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> Josh Berkus escribió:
>>> I think we might want to do something along the lines of what Stefan set
>>> up (at least I think it was he) for the end of 8.4 on
>>> developer.postgresql.org. Bruce's patch list is easy to update, but hard
>>> to read. I'l
On Feb 6, 2008 9:56 AM, Dave Page <[EMAIL PROTECTED]> wrote:
> Whenever a commit fest is in progress, the
> focus will shift from development to review, feedback and commit of
> patches. Each fest will continue until all patches in the queue have
> either been committed to the CVS repository, retur
Alvaro Herrera wrote:
> Josh Berkus escribió:
> > I think we might want to do something along the lines of what Stefan set
> > up (at least I think it was he) for the end of 8.4 on
> > developer.postgresql.org. Bruce's patch list is easy to update, but hard
> > to read. I'll put some effort into i
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Wed, 2008-02-06 at 14:42 -0500, Tom Lane wrote:
>> Not really, considering the extremely limited use of LW_SHARED in lock.c
>> (GetLockConflicts is used only by CREATE INDEX CONCURRENTLY, and
>> GetLockStatusData only by the pg_locks view). For the type
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> If you only got 2% out of it, it's not even worth thinking about how to
>> fix the serious bugs that approach would create (primarily, lack of
>> control over when pages can get flushed to disk).
> You can flush a pages by msync() func
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
On Wed, Feb 06, 2008 at 02:57:39AM -0500, Kris Jurka wrote:
On Tue, 5 Feb 2008, Tom Lane wrote:
2. We could retroactively redefine the contents of
AuthenticationGSSContinue as carrying a length word after the
authentication type code,
On Wed, 2008-02-06 at 14:42 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > There were only 2 lock delays for FirstLockMgrLock in SHARED mode, so it
> > seems believable that there were 0 lock delays in EXCLUSIVE mode.
>
> Not really, considering the extremely limited use of L
Simon Riggs <[EMAIL PROTECTED]> writes:
> There were only 2 lock delays for FirstLockMgrLock in SHARED mode, so it
> seems believable that there were 0 lock delays in EXCLUSIVE mode.
Not really, considering the extremely limited use of LW_SHARED in lock.c
(GetLockConflicts is used only by CREATE I
Tom Lane wrote:
Zdenek Kotala <[EMAIL PROTECTED]> writes:
I tried to use memory mapped files (mmap) for clog and I think it should be also
possible way. I got about 2% better performance, but it needs more testing.
If you only got 2% out of it, it's not even worth thinking about how to
fix the
On Wednesday 06 February 2008 13:56, Alvaro Herrera wrote:
> Robert Treat wrote:
> > it looks as if the indexes on pg_class have become corrupt. (ie. reindex
> > claimes duplicate rows, which do not show up when doing count()
> > manipulations on the data). As it turns out, I can't drop these inde
Robert Treat <[EMAIL PROTECTED]> writes:
> I'm trying to do some data recovery on an 8.1.9 system.
> ...
> I also did some digging to find the original error on xlog replay and it
> was "failed to re-find parent key in "763769" for split pages 21032/21033".
Hmm, the only known cause of that was
On Wed, 2008-02-06 at 13:55 -0500, Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > "Staale Smedseng" <[EMAIL PROTECTED]> writes:
> >> Also, an interesting observation is that the hot locks seem to have
> >> changed from v8.2 to v8.3, making the ProcArrayLock more contended. See
> >>
Robert Treat wrote:
> I'm trying to do some data recovery on an 8.1.9 system. The brief history is
> the system crashed, attempted to do xlog replay but that failed. I did a
> pg_resetxlog to get something that would startup, and it looks as if the
> indexes on pg_class have become corrupt. (
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Staale Smedseng" <[EMAIL PROTECTED]> writes:
>> Also, an interesting observation is that the hot locks seem to have
>> changed from v8.2 to v8.3, making the ProcArrayLock more contended. See
>> the following outputs:
>>
>> PostgreSQL 8.2 (32-bit):
>> ..
Josh Berkus escribió:
> I think we might want to do something along the lines of what Stefan set up
> (at least I think it was he) for the end of 8.4 on developer.postgresql.org.
> Bruce's patch list is easy to update, but hard to read. I'll put some effort
> into it.
Easy to update for Bruc
I'm trying to do some data recovery on an 8.1.9 system. The brief history is
the system crashed, attempted to do xlog replay but that failed. I did a
pg_resetxlog to get something that would startup, and it looks as if the
indexes on pg_class have become corrupt. (ie. reindex claimes duplicat
The plan looks great. I am +1
> -Original Message-
> From: [EMAIL PROTECTED]
>
> ---(end of
> broadcast)---
> TIP 4: Have you searched our list archives?
>
>http://archives.postgresql.org
>
---(e
Magnus Hagander <[EMAIL PROTECTED]> writes:
> On Wed, Feb 06, 2008 at 02:57:39AM -0500, Kris Jurka wrote:
>> On Tue, 5 Feb 2008, Tom Lane wrote:
>>> 2. We could retroactively redefine the contents of
>>> AuthenticationGSSContinue as carrying a length word after the
>>> authentication type code, but
I'm not sure 32-bit and 64-bit cases are going to be directly
comparable. We
could have a problem with cache line aliasing on only one or the
other for
example.
Agreed, this is likely comparing apples and oranges. I'll see if I can
get a one-to-one comparison done (these were the numbers I
On Wednesday 06 February 2008 09:09, Tom Lane wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > Just thinking that we'll need somewhere to park the new patches which
> > roll in during a commit fest.
>
> Bruce has always kept two patch queues, one for the current version and
> one for the stu
On Wed, 2008-02-06 at 18:44 +0100, Staale Smedseng wrote:
> > What is the frequency distribution of lock wait time on ProcArrayLock?
>
> See below for wait time distributions for ProcArrayLock (both shared and
> exclusive). The time measured is from entry into LWLockAcquire() until
> return. I've
> What is the frequency distribution of lock wait time on ProcArrayLock?
See below for wait time distributions for ProcArrayLock (both shared and
exclusive). The time measured is from entry into LWLockAcquire() until
return. I've recorded the same data in two different resolutions (ms,
and us for
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> I tried to use memory mapped files (mmap) for clog and I think it should be
> also
> possible way. I got about 2% better performance, but it needs more testing.
If you only got 2% out of it, it's not even worth thinking about how to
fix the serious bug
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> we added a March fest in part to have a "practice run" without too much
>> stuff being on the plate.
> OK, that makes some sense, although I don't know about the "not much
> stuff on the plate". We presumably have quite a lot of stuf
Currently trying to "enhance" the way we can make binaries that run
on Solaris. One thing I found was a scalability bottleneck in the
use of the ProcArrayLock. (this one has also been reported by a
couple of my colleagues).
One big user of this lock is GetSnapshotData. After it has taken
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I would rather set a target and modify it if necessary based on
experience than have none at all.
We felt that we'd like to get a couple of fests under our belts before
trying to nail down very many rules. The process will g
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> Just thinking that we'll need somewhere to park the new patches which
> roll in during a commit fest.
Bruce has always kept two patch queues, one for the current version and
one for the stuff held for the next version. This won't change anything
except
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I would rather set a target and modify it if necessary based on
> experience than have none at all.
We felt that we'd like to get a couple of fests under our belts before
trying to nail down very many rules. The process will get more
formalized later,
Gregory Stark napsal(a):
"Simon Riggs" <[EMAIL PROTECTED]> writes:
I wonder how hard it would be to shove the clog into regular shared memory
pages and let the clock sweep take care of adjusting the percentage of shared
mem allocated to the clog versus data pages.
I tried to use memory mapp
Dave Page wrote:
On Feb 6, 2008 4:24 PM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
I would rather set a target and modify it if necessary based on
experience than have none at all.
The danger of not doing so is that we'll be in almost constant 'commit
fest' mode.
Yes, that is somet
On Feb 6, 2008 4:24 PM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
>
>
> I would rather set a target and modify it if necessary based on
> experience than have none at all.
>
> The danger of not doing so is that we'll be in almost constant 'commit
> fest' mode.
Yes, that is something we discussed
Simon Riggs wrote:
On Wed, 2008-02-06 at 16:41 +0100, Magnus Hagander wrote:
I don't think the two syntaxes compete. I want to be able to say
"everything before", "data" and "everything after" without having to
remember to specify --what=tables,views,sequences,kitchensink etc.
Especially since y
Dave Page wrote:
On Feb 6, 2008 3:57 PM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
I would like to see this tied down some more. The time for the commit
fests is too open ended. I think we should say something like "All
commit fests will run no more than two weeks, except for the final
comm
This all sounds very promising.
On Feb 6, 2008 7:56 PM, Dave Page <[EMAIL PROTECTED]> wrote:
> Each fest will continue until all patches in the queue have
> either been committed to the CVS repository, returned to the author
> for additional work, or rejected outright, and until that has
> happene
On Wed, Feb 06, 2008 at 03:13:24PM +, Simon Riggs wrote:
> pg_dump allows you to specify -s --schema-only, or -a --data-only.
>
> The -s option creates the table, as well as creating constraints and
> indexes. These objects need to be dropped prior to loading, if we are to
> follow the perform
On Feb 6, 2008 3:57 PM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
> I would like to see this tied down some more. The time for the commit
> fests is too open ended. I think we should say something like "All
> commit fests will run no more than two weeks, except for the final
> commit fest which c
Am Mittwoch, 6. Februar 2008 schrieb Andrew Dunstan:
> I would like to see this tied down some more. The time for the commit
> fests is too open ended. I think we should say something like "All
> commit fests will run no more than two weeks, except for the final
> commit fest which can run for one
Simon wrote:
> My proposal is to provide two additional modes:
> --schema-pre-load corresponding to (1) above
> --schema-post-load corresponding to (3) above
Sounds nice.
For a large schema we might rather want one switch that dumps 2 files,
no ?
Probably also better from a mvcc perspective.
And
Dave Page wrote:
Hackers,
As you know we've finally released PostgreSQL 8.3, after a development
cycle that lasted well over a year despite our original plans for a 6
month cycle. The core team are aware that there are a number of
factors that contributed to this slippage:
- Lack of prompt an
On Wed, 2008-02-06 at 16:41 +0100, Magnus Hagander wrote:
> Where would you load primary keys and such contrants? Pre- or post dump? I
> think the case could be made for either one...
Post dump. If the constraint was successfully in place when we performed
the dump then it should work successfull
Simon Riggs wrote:
My proposal is to provide two additional modes:
--schema-pre-load corresponding to (1) above
--schema-post-load corresponding to (3) above
This would then allow this sequence of commands
pg_dump --schema-pre-load
pg_dump --data-only
pg_dump --schema-post-load
to be logic
Earlier, I proposed a Segment Visibility Map as part of my design of new
partitioning feature proposals. This idea has been spun-off into a
completely **separate** proposal because SVM has merit enough to be
worthy of implementation on its own:
http://developer.postgresql.org/index.php/Segment_Vis
On Tue, Feb 05, 2008 at 09:47:16PM +, Dave Page wrote:
> On Feb 5, 2008 5:56 PM, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> >
> > Dave Page wrote:
> > > On Feb 5, 2008 3:24 PM, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> > >> On Mon, Jan 28, 2008 at 06:27:05PM +, Pavel Golub wrote:
> > >
pg_dump allows you to specify -s --schema-only, or -a --data-only.
The -s option creates the table, as well as creating constraints and
indexes. These objects need to be dropped prior to loading, if we are to
follow the performance recommendations in the docs. But the only way to
do that is to man
"Staale Smedseng" <[EMAIL PROTECTED]> writes:
> The stack trace shows that the only time the lock is acquired
> exclusively is from the call to ProcArrayEndTransaction() in
> CommitTransaction().
I'm not sure but I think that's only true in 8.3. As I understood it in 8.2
transaction start also ne
On Feb 6, 2008 2:44 PM, Magnus Hagander <[EMAIL PROTECTED]> wrote:
>
> Good start. /me thinks it should be on the website. We've usually announced
> our feature freeze dates there... (in less details, sure, but something
> there)
Feel free - you've been hacking that recently!
/D
On Wed, 2008-02-06 at 15:30 +0100, Staale Smedseng wrote:
> On Mon, 2008-02-04 at 19:46, Simon Riggs wrote:
> > We've got various facilities now for looking at LWLock waits, but I'd
> > like to have more information about the *reasons* for lock waits.
> >
> > I know its possible to get backtraces
On Wed, Feb 06, 2008 at 02:42:35PM +, Dave Page wrote:
> On Feb 6, 2008 1:49 PM, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> > On Wed, Feb 06, 2008 at 08:56:51AM +, Dave Page wrote:
> > > Hackers,
> >
> > Looks great and well-thought through. Let's hope it works out!
> >
> > I assume you'l
On Feb 6, 2008 1:49 PM, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 06, 2008 at 08:56:51AM +, Dave Page wrote:
> > Hackers,
>
> Looks great and well-thought through. Let's hope it works out!
>
> I assume you'll be committing this info to the developer section on the
> website?
It'
On Mon, 2008-02-04 at 19:46, Simon Riggs wrote:
> We've got various facilities now for looking at LWLock waits, but I'd
> like to have more information about the *reasons* for lock waits.
>
> I know its possible to get backtraces in Dtrace at various tracepoints
> but that can be fairly hard to in
I note that in HeapTupleSatisfies... we call
TransactionIdIsCurrentTransactionId() explicitly and then call it again
in TransactionIdIsInProgress(). Which means we also end up checking
twice whether each xid is normal also.
It would seem easier to make a check TransactionIdIsRecent() early and
i
On Wed, Feb 06, 2008 at 08:56:51AM +, Dave Page wrote:
> Hackers,
Looks great and well-thought through. Let's hope it works out!
I assume you'll be committing this info to the developer section on the
website?
//Magnus
---(end of broadcast)---
On Tue, Feb 05, 2008 at 09:47:16PM +, Dave Page wrote:
> On Feb 5, 2008 5:56 PM, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> >
> > Dave Page wrote:
> > > On Feb 5, 2008 3:24 PM, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> > >> On Mon, Jan 28, 2008 at 06:27:05PM +, Pavel Golub wrote:
> > >
On Wed, 2008-02-06 at 08:56 +, Dave Page wrote:
> Hackers,
+1 Very much in favour.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archi
On Wed, Feb 06, 2008 at 02:57:39AM -0500, Kris Jurka wrote:
>
>
> On Tue, 5 Feb 2008, Tom Lane wrote:
>
> >The problem seems to be that AuthenticationGSSContinue messages carry
> >a variable-length payload, and the V2 protocol doesn't really cope with
> >that because it doesn't have a message le
Hackers,
As you know we've finally released PostgreSQL 8.3, after a development
cycle that lasted well over a year despite our original plans for a 6
month cycle. The core team are aware that there are a number of
factors that contributed to this slippage:
- Lack of prompt and early review of pat
Marc G. Fournier wrote:
> Actually, "branch in one to two weeks" has been the status quo almost since
> day one ... not that I'm against "branch on release", I'm only saying that
> we've followed this same procedure on branching since ... forever.
That is incorrect. See earlier in this thread.
-
On Tue, 5 Feb 2008, Tom Lane wrote:
The problem seems to be that AuthenticationGSSContinue messages carry
a variable-length payload, and the V2 protocol doesn't really cope with
that because it doesn't have a message length word.
1. If the GSSContinue payload is self-identifying about its len
78 matches
Mail list logo
