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
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.
--
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
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 length
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?
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:
I think a better
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)---
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
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
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's on the
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'll be committing
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 in
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
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 needed
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
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:
I think a better
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:
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
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 successfully
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.
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
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
happened, no
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
commit
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 you
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
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 can run
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 performance
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 mapped
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, no
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 the
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, and the
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
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
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
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 stuff in the
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 bugs
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
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
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 stuff held for
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
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 only in V2
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
---(end of
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
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 Bruce
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):
...
PostgreSQL 8.3
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. (ie.
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
the following
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 fixed in
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 indexes
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
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
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 LW_SHARED
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,
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() function
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 of
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 it.
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, returned
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'll put some
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 sure
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 answer,
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
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 the
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 any of this is
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.
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
NULL
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 -rs. These are used in the build
environment to create all the SUBSYS.o object files.
I was
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
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
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 review
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 that last
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 when pages can get flushed
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
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 should
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 won't
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 flushed to disk).
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 hard to
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
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
78 matches
Mail list logo
