Re: [HACKERS] Simple Column reordering

[Simon Riggs]

On Thu, 2007-02-22 at 20:07 -0600, Andrew Dunstan wrote:
> Simon Riggs wrote:
> >
> > I propose that at CREATE TABLE time, the column ordering is re-ordered
> > so that the table columns are packed more efficiently. This would be a
> > physical re-ordering, so that SELECT * and COPY without explicit column
> > definitions would differ from the original CREATE TABLE statement.
> >
> > This would be an optional feature, off by default, controlled by a
> > USERSET GUC
> > optimize_column_order = off (default) | on
> >
> 
> 
> Umm, you want a GUC setting to enable standards-breaking behaviour and
> that will be obsolete when we do column ordering right, which is not
> likely to be more than one release away, and could even still happen in
> this coming release?

If this is standards-breaking as you say, I would withdraw immediately.
I checked the SQL standard and could not see how this would do so. The
standard states SELECT * would return columns in order; it doesn't say
what that order should be, nor does CREATE TABLE enforce the ordering to
be the same as it has specified, AFAICS. Please correct me and I will
withdraw. Practical issues seem far stronger drivers than standards
issues here, which is why the parameter would default=off.

If the full implementation exists and works, I would welcome it. This
proposal is really aimed at what we do if that doesn't occur; we must
wait to see if it will. I see that many users would want to get
something sooner rather than later. That isn't a commercial perspective,
I see that as a PostgreSQL advocacy perspective.

I also see that we are forcing change into the on-disk format of heaps
in this release. If we defer this to another release then we would be
effectively changing the on-disk format again in next release.

-- 
  Simon Riggs 
  EnterpriseDB   http://www.enterprisedb.com



---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] Simple Column reordering

[Lukas Kahwe Smith]

Simon Riggs wrote:


If this is standards-breaking as you say, I would withdraw immediately.
I checked the SQL standard and could not see how this would do so. The
standard states SELECT * would return columns in order; it doesn't say
what that order should be, nor does CREATE TABLE enforce the ordering to
be the same as it has specified, AFAICS. Please correct me and I will
withdraw. Practical issues seem far stronger drivers than standards
issues here, which is why the parameter would default=off.


I did not follow the entire thread. I just wanted to point out that IIRC 
MS SQL Server (and maybe also Sybase) do automatically optimize the 
internal order of how columns are stored to move fixed length (which 
also means non NULLable for these two servers) columns to the left. 
Maybe this will serve as a reference point (not necessarily for 
standards compliance of course).


regards,
Lukas

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] Simple Column reordering

[Zeugswetter Andreas ADI SD]

> I don't understand the reluctance to implementing all of it.  
> The most serious objection I've seen, from Andreas IIRC, is 
> that it would make drivers' lives more difficult; but really, 
> drivers have to cope with dropped columns today which is a

Yes, I already said, that my objection is probably moot in face of
drop column.
 
> pain, and ISTM this proposal (not this one here, but the 
> three-column proposal) would make that a bit simpler.

Do all of them support dropped columns correctly, yet ?

Andreas

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [HACKERS] Simple Column reordering

[Guillaume Smet]

Hi Simon,

On 2/23/07, Simon Riggs <[EMAIL PROTECTED]> wrote:

If this is standards-breaking as you say, I would withdraw immediately.
I checked the SQL standard and could not see how this would do so. The
standard states SELECT * would return columns in order; it doesn't say
what that order should be, nor does CREATE TABLE enforce the ordering to
be the same as it has specified, AFAICS. Please correct me and I will
withdraw.


Phil Currier seems to have a preliminary proposition so I think we
should wait for his patch. AFAICS in what he did, the physical
position is not tied to the column ordering and it's better IMHO. It
doesn't seem very intrusive and it doesn't change the "visible"
behavior of PostgreSQL.
Personnaly, I really need my column ordering. When I create my table,
I put the columns in a logical order and I need they stay as I created
them (for \d for example - on a large table I make semantic groups so
I can find the field names more easily).
And I think a lot of people do it as well so I'm not sure people would
use a GUC which changes that much their habits.

--
Guillaume

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Simple Column reordering

[Zeugswetter Andreas ADI SD]

> > If this is standards-breaking as you say, I would withdraw
immediately.
> > I checked the SQL standard and could not see how this would do so.
The 
> > standard states SELECT * would return columns in order; it doesn't
say

Imho the create table order is implied. What other order would they mean
with "in order" ?
 
> > what that order should be, nor does CREATE TABLE enforce the
ordering 
> > to be the same as it has specified, AFAICS. Please correct me and I 
> > will withdraw. Practical issues seem far stronger drivers than 
> > standards issues here, which is why the parameter would default=off.
> 
> I did not follow the entire thread. I just wanted to point 
> out that IIRC MS SQL Server (and maybe also Sybase) do 
> automatically optimize the internal order of how columns are 
> stored to move fixed length (which also means non NULLable 
> for these two servers) columns to the left. 
> Maybe this will serve as a reference point (not necessarily 
> for standards compliance of course).

If you state that, it is imho also important to note that this is not
externally visible. select * is not altered.
I think we can have this based on Phil's patch. Simon would probably be
willing to extend it to choose the best physical order during create
table time. And the first step would be done.

The next step could then be to "fix" drop column and add "add column
before"
eighter using a 3rd column or using the existing 2.

Andreas


---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Simple Column reordering

[Simon Riggs]

On Fri, 2007-02-23 at 09:46 +0100, Guillaume Smet wrote:
> Hi Simon,
> 
> On 2/23/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
> > If this is standards-breaking as you say, I would withdraw immediately.
> > I checked the SQL standard and could not see how this would do so. The
> > standard states SELECT * would return columns in order; it doesn't say
> > what that order should be, nor does CREATE TABLE enforce the ordering to
> > be the same as it has specified, AFAICS. Please correct me and I will
> > withdraw.
> 
> Phil Currier seems to have a preliminary proposition so I think we
> should wait for his patch. 

That is exactly what I've said also, so it is good we agree.

I had read that Phil had declined to work on it further; I hope he
changes his mind on that.

-- 
  Simon Riggs 
  EnterpriseDB   http://www.enterprisedb.com



---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] [COMMITTERS] pgsql: Change $(CC) to $(COMPILER) on Solaris gcc so -m64 is passed into

[Peter Eisentraut]

Am Dienstag, 20. Februar 2007 23:45 schrieb Bruce Momjian:
> Log Message:
> ---
> Change $(CC) to $(COMPILER) on Solaris gcc so -m64 is passed into the
> shared link line.

While that change might be OK, putting critical flags such as -m64 into CFLAGS 
is wrong, and therefore this change would be irrelevant with respect to the 
actual problem.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Simple Column reordering

[Albe Laurenz]

Simon Riggs wrote:
>>> I propose that at CREATE TABLE time, the column ordering is
re-ordered
>>> so that the table columns are packed more efficiently. This would be
a
>>> physical re-ordering, so that SELECT * and COPY without explicit
column
>>> definitions would differ from the original CREATE TABLE statement.

How about INSERTs without column names? Wouldn't that also cease to
work?

In particular, 'pg_dump --format=plain --inserts' would produce unusable
output unless --attribute-inserts is also given, right?

Yours,
Laurenz Albe 

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] Simple Column reordering

[Guillaume Smet]

On 2/23/07, Simon Riggs <[EMAIL PROTECTED]> wrote:

I had read that Phil had declined to work on it further; I hope he
changes his mind on that.


IIRC he just said he wasn't interested to work on the visible ordering
part (as in MySQL) and I don't think it's a problem as even if it's
related it's a different problem.

--
Guillaume

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match

Re: [HACKERS] tsearch in core patch, for inclusion

[Peter Eisentraut]

Am Donnerstag, 22. Februar 2007 18:07 schrieb Markus Schiltknecht:
> > I agree so enhancing parser oabout not standard construct isn't good.
>
> Generally? Wow! This would mean PostgreSQL would always lack behind
> other RDBSes, regarding ease of use. Please don't do that!

You are confusing making a full-text index and configuring the full-text 
engine.  Tsearch already gives you a standard CREATE INDEX variant to do the 
former.  The discussion here is about the latter, and notably Oracle uses 
functions there.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] tsearch in core patch, for inclusion

[Peter Eisentraut]

Am Donnerstag, 22. Februar 2007 14:33 schrieb Teodor Sigaev:
> \df says only types of arguments, not a meaning.

Only if you don't provide argument names.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] Simple Column reordering

[Peter Eisentraut]

Am Freitag, 23. Februar 2007 09:08 schrieb Simon Riggs:
> If this is standards-breaking as you say, I would withdraw immediately.
> I checked the SQL standard and could not see how this would do so. The
> standard states SELECT * would return columns in order; it doesn't say
> what that order should be,

b) Otherwise, the  “*” is equivalent to a  
sequence in which each  is a column reference that 
references a column of T and each column of T is referenced exactly once. The 
columns are referenced in the ascending sequence of their ordinal position 
within T.

> nor does CREATE TABLE enforce the ordering to 
> be the same as it has specified, AFAICS.

b) The column descriptors of every column of T, according to the Syntax Rules 
and General Rules of Subclause 11.4, “”, applied to the 
s contained in TEL, in the order in which they were 
specified.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

[HACKERS] Data Restore from WAL

[Vishal Arora]

Hi,
I would like to know how the data is been read from WAL file. If anyone can 
help me with the WAL file structure. What are the basic functions used by a 
pg_restore call.


Thanks
Visahal

_
With tax season right around the corner, make sure to follow these few 
simple tips. 
http://articles.moneycentral.msn.com/Taxes/PreparationTips/PreparationTips.aspx?icid=HMFebtagline



---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org

Re: [HACKERS] Simple Column reordering

[Simon Riggs]

On Fri, 2007-02-23 at 11:25 +0100, Peter Eisentraut wrote:
> Am Freitag, 23. Februar 2007 09:08 schrieb Simon Riggs:
> > If this is standards-breaking as you say, I would withdraw immediately.
> > I checked the SQL standard and could not see how this would do so. The
> > standard states SELECT * would return columns in order; it doesn't say
> > what that order should be,
> 
> b) Otherwise, the  “*” is equivalent to a  
> sequence in which each  is a column reference that 
> references a column of T and each column of T is referenced exactly once. The 
> columns are referenced in the ascending sequence of their ordinal position 
> within T.

Which begs the question: what is their ordinal position? If we change
the ordinal position at CREATE TABLE time then the SELECT * would still
work per standard. So the next point is the important one:

> > nor does CREATE TABLE enforce the ordering to 
> > be the same as it has specified, AFAICS.
> 
> b) The column descriptors of every column of T, according to the Syntax Rules 
> and General Rules of Subclause 11.4, “”, applied to the 
> s contained in TEL, in the order in which they were 
> specified.

I read both of these phrases prior to posting the original suggestion.

My reading was that this was about constraints on columns, not the
columns themselves, when that phrase was taken in context. I take it you
think that reading was wrong?

I'm not a lawyer, so I'll not argue too close to the edge.

Suggestion withdrawn.

-- 
  Simon Riggs 
  EnterpriseDB   http://www.enterprisedb.com



---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] Data Restore from WAL

[Heikki Linnakangas]

Vishal Arora wrote:
I would like to know how the data is been read from WAL file. If anyone 
can help me with the WAL file structure. What are the basic functions 
used by a pg_restore call.


pg_restore has nothing to do with WAL.

AFAIK the best description of the WAL file structure is in the comments 
in the source code. I'd suggest starting by reading the header files 
under src/include/access/xlog.h and src/include/access/xlog_utils.h, and 
 the source file in src/backend/access/transam/xlog.c.


Basically each file in pg_xlog (aka WAL segment) is divided into fixed 
size pages, and pages are filled with WAL records.


For more information on the internals of pg_restore, look at the 
corresponding source and header files in src/bin/pg_dump.


Mind you, both the WAL file format and the binary pg_dump/pg_restore 
file format are internal to PostgreSQL, and not designed to be readable 
by external applications. The format can also change between releases.


--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

   http://www.postgresql.org/about/donate

Re: [HACKERS] Simple Column reordering

[Peter Eisentraut]

Am Freitag, 23. Februar 2007 12:25 schrieb Simon Riggs:
> My reading was that this was about constraints on columns, not the
> columns themselves, when that phrase was taken in context. I take it you
> think that reading was wrong?

I see nothing there that speaks of constraints.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] Simple Column reordering

[Andrew Dunstan]

Simon Riggs wrote:

On Fri, 2007-02-23 at 11:25 +0100, Peter Eisentraut wrote:
  

Am Freitag, 23. Februar 2007 09:08 schrieb Simon Riggs:


If this is standards-breaking as you say, I would withdraw immediately.
I checked the SQL standard and could not see how this would do so. The
standard states SELECT * would return columns in order; it doesn't say
what that order should be,
  
b) Otherwise, the  “*” is equivalent to a  
sequence in which each  is a column reference that 
references a column of T and each column of T is referenced exactly once. The 
columns are referenced in the ascending sequence of their ordinal position 
within T.



Which begs the question: what is their ordinal position? If we change
the ordinal position at CREATE TABLE time then the SELECT * would still
work per standard.

  


That's quite a stretch. Surely "their ordinal position" can't mean 
"their ordinal position as arbitrarily determined at CREATE TABLE time 
by the implementation".


I really don't think that we can accept under any circumstances a 
situation where something as simple as this breaks:


 create table foo (x text, y int);
 insert into foo values ('qwerty',1);

Physical storage optimization must not have any SQL level visibility or 
consequences, IMNSHO, regardless of what we do about providing mutable 
display order.


If you really want an interim solution, what about a builtin function 
that would explicitly mutate the definition and table contents (if any) 
along the lines you want? (assuming that's lots less work than just 
doing the whole thing right to start with). Or even one which just 
*displayed* the optimal order might be sufficient assistance to DBAs who 
want to take advantage of this.


cheers

andrew

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [Monotone-devel] Re: [HACKERS] SCMS question

[Alvaro Herrera]

Richard Levitte - VMS Whacker wrote:
> In message <[EMAIL PROTECTED]> on Fri, 23 Feb 2007 07:57:53 +0100, Markus 
> Schiltknecht <[EMAIL PROTECTED]> said:
> 
> markus> Uh, yah. But I was refering to the "lots of opinions on what
> markus> replacement system to use". This has not much to do with the
> markus> want or need (for lack of a better alternative) to stay with
> markus> CVS, IMO.
> 
> Oh, it's an academic discussion?  Sorry, didn't catch that.

It's only academic because Monotone is not ready.  As soon as it is
ready we will be pushing much harder.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] Simple Column reordering

[Simon Riggs]

On Fri, 2007-02-23 at 07:52 -0500, Andrew Dunstan wrote:

> I really don't think that we can accept under any circumstances a 
> situation where something ... breaks:

Yes, I've accepted that, in response to Peter earlier today.

> If you really want an interim solution, what about a builtin function 
> that would explicitly mutate the definition and table contents (if any) 
> along the lines you want? (assuming that's lots less work than just 
> doing the whole thing right to start with). Or even one which just 
> *displayed* the optimal order might be sufficient assistance to DBAs who 
> want to take advantage of this.

I think the only interim solution now is to put functionality into
PgAdmin et al to optimize the column order.

-- 
  Simon Riggs 
  EnterpriseDB   http://www.enterprisedb.com



---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [Monotone-devel] Re: [HACKERS] SCMS question

[Alvaro Herrera]

[EMAIL PROTECTED] wrote:
> On Fri, Feb 23, 2007 at 10:42:13AM -0300, Alvaro Herrera wrote:
> > Richard Levitte - VMS Whacker wrote:
> > > In message <[EMAIL PROTECTED]> on Fri, 23 Feb 2007 07:57:53 +0100, Markus 
> > > Schiltknecht <[EMAIL PROTECTED]> said:
> > > 
> > > markus> Uh, yah. But I was refering to the "lots of opinions on what
> > > markus> replacement system to use". This has not much to do with the
> > > markus> want or need (for lack of a better alternative) to stay with
> > > markus> CVS, IMO.
> > > 
> > > Oh, it's an academic discussion?  Sorry, didn't catch that.
> > 
> > It's only academic because Monotone is not ready.  As soon as it is
> > ready we will be pushing much harder.
> 
> This invites the obvious question -- in which ways in monotone not 
> ready?  Not that I'm trying to imply that monotone *is* ready, of 
> course.

Time to get the initial pull is too long, mostly.  Also, having the
policy branch stuff will be good, if nothing else because it'll mean
having 1.0 out, in turn meaning UI stability, etc.  And getting Markus'
work on the CVS import will be good too (I haven't tried converting
Postgres' entire CVS repo in a while, and that certainly is a must).

I don't think we're going to get a one-shot migration, so Cristof's work
on CVS takeover would be really nice to have so that some of us can
create an "alternative" repo and cater for those that will continue to
use CVS for a while.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] Simple Column reordering

[Tom Lane]

"Simon Riggs" <[EMAIL PROTECTED]> writes:
> If this is standards-breaking as you say, I would withdraw immediately.
> I checked the SQL standard and could not see how this would do so. The
> standard states SELECT * would return columns in order; it doesn't say
> what that order should be, nor does CREATE TABLE enforce the ordering to
> be the same as it has specified, AFAICS.

SQL92 7.9  defines the meaning of SELECT * as

b) Otherwise, the  "*" is equivalent to a  sequence in which each  is a
   that references a column of T and each
  column of T is referenced exactly once. The columns are ref-
  erenced in the ascending sequence of their ordinal position
  within T.

11.3  says

 2) The degree of the table being created is initially set to 0; the
General Rules of Subclause 11.4, "" specify
the degree of the table being created during the definition of
columns in that table.

and 11.4  says

 4) The degree of the table T being defined in the containing  or  or altered by the
containing  is increased by 1.

 5) A column descriptor is created that describes the column being
defined.    The ordinal position included
in the column descriptor is equal to the degree of T.

Now, I will grant you that it doesn't actually say anywhere that the
column definitions in CREATE TABLE must be processed left to right, but
if they meant this behavior to be implementation-dependent they would
have said so.  Given the number of places in the spec in which semantics
are directly dependent on ordinal position, I cannot think that that is
intended --- for example, the behavior of  becomes
completely undefined if column ordinal positions aren't fixed.

regards, tom lane

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] [Monotone-devel] Re: SCMS question

[Chris Browne]

[EMAIL PROTECTED] (Richard Levitte - VMS Whacker) writes:
> In message <[EMAIL PROTECTED]> on Thu, 22 Feb 2007 17:38:26 +0100, Markus 
> Schiltknecht <[EMAIL PROTECTED]> said:
>
> markus> > So far, I'm getting the sense that there are a lot of
> markus> > opinions on what replacement system to use, a bit carelessly
> markus> > before having answered the above questions thoroughly.
> markus> 
> markus> How did you get that impression?
>
> You said it yourself: Most PostgreSQL developers currently want to
> stay with CVS.

I'm not certain that is, statistically, the case.

> Unless there's a majority that wants to move on, I doubt there will be
> a move.  In the end, it has to be a group effort, or it will simply
> not happen.

The trouble is that there needs to be a sufficient plurality in favor
of *a particular move onwards* in order for it to happen.

Right now, what we see is:

- Some that are fine with status quo
- Some that are keen on Subversion
- Others keen on Monotone
- Others considering other options; Darcs, Git, Mercurial, Arch...

There's no majority there, for sure.  No plurality, either.

There has been a "convulsion" of activity surrounding SCM in the last
couple of years, and I think that the brief trouble that the Linux
kernel had with Bitkeeper going away has been an *excellent* thing as
it drew developers to work on the (long languishing) SCM problem.

It looks as though there is a strong "plurality" of PostgreSQL
developers that are waiting for some alternative to become dominant.
I suspect THAT will never happen.

I think instead, that we will see three or maybe four of the newer
SCMs being jointly dominant.

- Subversion has a clear body of happy-enough users for Subversion to
continue.

- Git, being the Linux kernel SCM, will continue unless some
heretofore undiscovered fatal flaw bites it.

- Mercurial seems to have enough user projects to be viable.
(OpenSolaris, ALSA, Xen, ZFS for Linux are probably recognizable
names...)

It seems plausible that one of [Arch, Darcs, Monotone] would also
survive.

This contradicts the notion of there being any single dominant
successor to CVS; if that were the case, that would make a migration
clear.

I think, instead, that we'll continue to see a multiplicity of
choices, meaning that the best we can do is to eventually pick one.
There isn't enough of a 'plurality' of support for any one SCM to
allow that to take place now.
-- 
(reverse (concatenate 'string "ofni.secnanifxunil" "@" "enworbbc"))
http://linuxfinances.info/info/finances.html
Rules of  the Evil Overlord #189. "I  will never tell the  hero "Yes I
was the one who  did it, but you'll never be able  to prove it to that
incompetent  old fool."  Chances  are, that  incompetent  old fool  is
standing behind the curtain."  

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] What is CheckPoint.undo needed for?

[Florian G. Pflug]

Tom Lane wrote:

Alvaro Herrera <[EMAIL PROTECTED]> writes:

I think you should increase pg_control version.


And the WAL page-header version, since this also changes WAL contents.


Here is an updated version. I've incremeted XLOG_PAGE_MAGIC and
PG_CONTROL_VERSION by one.

greetings, Florian Pflug

Index: src/backend/access/transam/xlog.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/access/transam/xlog.c,v
retrieving revision 1.264
diff -a -u -r1.264 xlog.c
--- src/backend/access/transam/xlog.c   14 Feb 2007 05:00:40 -  1.264
+++ src/backend/access/transam/xlog.c   23 Feb 2007 15:09:09 -
@@ -4039,7 +4039,6 @@
/* Set up information for the initial checkpoint record */
checkPoint.redo.xlogid = 0;
checkPoint.redo.xrecoff = SizeOfXLogLongPHD;
-   checkPoint.undo = checkPoint.redo;
checkPoint.ThisTimeLineID = ThisTimeLineID;
checkPoint.nextXidEpoch = 0;
checkPoint.nextXid = FirstNormalTransactionId;
@@ -4698,9 +4697,8 @@
wasShutdown = (record->xl_info == XLOG_CHECKPOINT_SHUTDOWN);
 
ereport(LOG,
-(errmsg("redo record is at %X/%X; undo record is at %X/%X; shutdown 
%s",
+(errmsg("redo record is at %X/%X; shutdown %s",
 checkPoint.redo.xlogid, checkPoint.redo.xrecoff,
-checkPoint.undo.xlogid, checkPoint.undo.xrecoff,
 wasShutdown ? "TRUE" : "FALSE")));
ereport(LOG,
(errmsg("next transaction ID: %u/%u; next OID: %u",
@@ -4730,20 +4728,17 @@
if (XLByteLT(RecPtr, checkPoint.redo))
ereport(PANIC,
(errmsg("invalid redo in checkpoint record")));
-   if (checkPoint.undo.xrecoff == 0)
-   checkPoint.undo = RecPtr;
 
/*
 * Check whether we need to force recovery from WAL.  If it appears to
 * have been a clean shutdown and we did not have a recovery.conf file,
 * then assume no recovery needed.
 */
-   if (XLByteLT(checkPoint.undo, RecPtr) ||
-   XLByteLT(checkPoint.redo, RecPtr))
+   if (XLByteLT(checkPoint.redo, RecPtr))
{
if (wasShutdown)
ereport(PANIC,
-   (errmsg("invalid redo/undo record in shutdown 
checkpoint")));
+   (errmsg("invalid redo record in shutdown 
checkpoint")));
InRecovery = true;
}
else if (ControlFile->state != DB_SHUTDOWNED)
@@ -5850,10 +5845,9 @@
{
CheckPoint *checkpoint = (CheckPoint *) rec;
 
-   appendStringInfo(buf, "checkpoint: redo %X/%X; undo %X/%X; "
+   appendStringInfo(buf, "checkpoint: redo %X/%X; "
 "tli %u; xid %u/%u; oid %u; 
multi %u; offset %u; %s",
 checkpoint->redo.xlogid, 
checkpoint->redo.xrecoff,
-checkpoint->undo.xlogid, 
checkpoint->undo.xrecoff,
 checkpoint->ThisTimeLineID,
 checkpoint->nextXidEpoch, 
checkpoint->nextXid,
 checkpoint->nextOid,
Index: src/bin/pg_controldata/pg_controldata.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/pg_controldata/pg_controldata.c,v
retrieving revision 1.32
diff -a -u -r1.32 pg_controldata.c
--- src/bin/pg_controldata/pg_controldata.c 8 Dec 2006 19:50:53 -   
1.32
+++ src/bin/pg_controldata/pg_controldata.c 23 Feb 2007 15:09:09 -
@@ -168,9 +168,6 @@
printf(_("Latest checkpoint's REDO location:%X/%X\n"),
   ControlFile.checkPointCopy.redo.xlogid,
   ControlFile.checkPointCopy.redo.xrecoff);
-   printf(_("Latest checkpoint's UNDO location:%X/%X\n"),
-  ControlFile.checkPointCopy.undo.xlogid,
-  ControlFile.checkPointCopy.undo.xrecoff);
printf(_("Latest checkpoint's TimeLineID:   %u\n"),
   ControlFile.checkPointCopy.ThisTimeLineID);
printf(_("Latest checkpoint's NextXID:  %u/%u\n"),
Index: src/bin/pg_resetxlog/pg_resetxlog.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/pg_resetxlog/pg_resetxlog.c,v
retrieving revision 1.57
diff -a -u -r1.57 pg_resetxlog.c
--- src/bin/pg_resetxlog/pg_resetxlog.c 10 Feb 2007 14:58:55 -  1.57
+++ src/bin/pg_resetxlog/pg_resetxlog.c 23 Feb 2007 15:09:09 -
@@ -464,7 +464,6 @@
 
ControlFile.checkPointCopy.redo.xlogid = 0;
ControlFile.checkPointCopy.redo.xrecoff = SizeOfXLogLongPHD;
-   ControlFile.checkPointCopy.undo = ControlFile.checkPointCopy.redo;

Re: [HACKERS] SCMS question

[Alvaro Herrera]

Warren Turkal wrote:
> On Thursday 22 February 2007 20:39, Alvaro Herrera wrote:
> > > Git is also pretty cool, too. You can even present a CVS interface on a
> > > git repository. That might address the build farm issue.
> >
> > But it wasn't portable, last time I checked.
> 
> Git is in the FreeBSD ports. The cvs gateway server comes with it AFAIK.

Sorry, I mean Windows.  We're taken pains to ensure Postgres runs on
Windows, we're not going to abandon that platform now.

And there's a lot of platforms on which we'd have to make sure Monotone
also runs on.  Our buildfarm currently has
http://buildfarm.postgresql.org/cgi-bin/show_status.pl

NetBSD
OpenBSD
FreeBSD
Max OS X
Tru64 5.0 (cc V6.1-011, on alpha)
AIX 5.2 (on powerpc)
Solaris 10
UnixWare 7.1.4 (cc 4.2, on "isa", whatever that is)
Cygwin
Native Windows: XP, 2000, 2003
Several flavors of Linux

Probably all those that can run GCC will have no problem with Monotone.
But what about the AIX, Tru64, Unixware entries?  Do they even have C++
compilers?

I don't think Git runs on all these.

It's not on the buildfarm but HP-UX is also used.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

[HACKERS] osprey dumped core on 8.2

[Alvaro Herrera]

Osprey is a NetBSD running on m68k

http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=osprey&dt=2007-02-22%2023:00:18

It dumped core running VACUUM:

--- 1,5 
  VACUUM;
! server closed the connection unexpectedly
!   This probably means the server terminated abnormally
!   before or while processing the request.
! connection to server was lost


The stack trace report looks incomplete:

== stack trace: 
pgsql.27009/src/test/regress/tmp_check/data/postgres.core ==
Core was generated by `postgres'.
Program terminated with signal 11, Segmentation fault.
#0  0x001f74d6 in AllocSetAlloc (context=0x307d10, size=16777212) at aset.c:546
546 if (set->blocks != NULL)

It's missing the "bt" part.


I don't understand how can this happen, given that "set" cannot be NULL
at this point.

-- 
Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4
"Puedes elegir el color de tu auto -- siempre y cuando sea negro."
 (Henry Ford)

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] Simple Column reordering

[Jim C. Nasby]

On Fri, Feb 23, 2007 at 02:09:55PM +, Simon Riggs wrote:
> > If you really want an interim solution, what about a builtin function 
> > that would explicitly mutate the definition and table contents (if any) 
> > along the lines you want? (assuming that's lots less work than just 
> > doing the whole thing right to start with). Or even one which just 
> > *displayed* the optimal order might be sufficient assistance to DBAs who 
> > want to take advantage of this.
> 
> I think the only interim solution now is to put functionality into
> PgAdmin et al to optimize the column order.

Well, if it comes to that it would be good to have pgAdmin et all driven
by logic in the database, so that people using psql can benefit as well.
Perhaps a function that is passed an existing table and re-creates it in
optimal order (if it's empty...). Or at least spits out a CREATE TABLE
statement for you that's in optimal order.
-- 
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] Simple Column reordering

[Alvaro Herrera]

Jim C. Nasby wrote:
> On Fri, Feb 23, 2007 at 02:09:55PM +, Simon Riggs wrote:
> > > If you really want an interim solution, what about a builtin function 
> > > that would explicitly mutate the definition and table contents (if any) 
> > > along the lines you want? (assuming that's lots less work than just 
> > > doing the whole thing right to start with). Or even one which just 
> > > *displayed* the optimal order might be sufficient assistance to DBAs who 
> > > want to take advantage of this.
> > 
> > I think the only interim solution now is to put functionality into
> > PgAdmin et al to optimize the column order.
> 
> Well, if it comes to that it would be good to have pgAdmin et all driven
> by logic in the database, so that people using psql can benefit as well.
> Perhaps a function that is passed an existing table and re-creates it in
> optimal order (if it's empty...). Or at least spits out a CREATE TABLE
> statement for you that's in optimal order.

That's just working around the fact that the engine is not smart enough
to do the right thing (semi-) automatically.  We don't support that kind
of operation, just like we don't support optimizer hints.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] autovacuum next steps, take 2

[Alvaro Herrera]

Jim C. Nasby wrote:
> On Thu, Feb 22, 2007 at 10:32:44PM -0500, Matthew T. O'Connor wrote:

> > I'm not sure this is a great idea, but I don't see how this would result 
> > in large numbers of workers working in one database.   If workers work 
> > on tables in size order, and exit as soon as they catch up to an older 
> > worker, I don't see the problem.  Newer works are going to catch-up to 
> > older workers pretty quickly since small tables will vacuum fairly quickly.
> 
> The reason that won't necessarily happen is because you can get large
> tables popping up as needing vacuuming at any time.

Right.

We know that a table that needs frequent vacuum necessarily has to be
small -- so maybe have the second worker exit when it catches up with
the first, or when the next table is above 1 GB, whichever happens
first.  That way, only the first worker can be processing the huge
tables.  The problem with this is that if one of your hot tables grows
a bit larger than 1 GB, you suddenly have a change in autovacuuming
behavior, for no really good reason.

And while your second worker is processing the tables in the hundreds-MB
range, your high-update 2 MB tables are neglected :-(

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] timestamp subtraction (was Re: [SQL] formatting intervals with to_char)

[Jim C. Nasby]

Yes, but if it was '2004-01-02 01:00:00'-'2004-01-01 00:00:00' it should
return 25:00:00, not 1 day 1:00.

I agree with Tom that this should be changed; I'm just arguing that we
might well need a backwards-compatibility solution for a while. At the
very least we'd need to make this change very clear to users.

On Tue, Feb 20, 2007 at 08:07:11PM -0500, Bruce Momjian wrote:
> 
> One problem with removing justify_hours() is that this is going to
> return '24:00:00', rather than '1 day:
>   
>   test=> select '2004-01-02 00:00:00'::timestamptz - '2004-01-01
>   00:00:00'::timestamptz;
>?column?
>   --
>24:00:00
>   (1 row)
> 
> ---
> 
> Jim Nasby wrote:
> > On Oct 5, 2006, at 11:50 AM, Tom Lane wrote:
> > > regression=# select ('2006-09-15 23:59:00'::timestamp - '2006-09-01  
> > > 09:30:41'::timestamp);
> > >  ?column?
> > > --
> > >  14 days 14:28:19
> > > (1 row)
> > >
> > > should be reporting '350:28:19' instead.
> > >
> > > This is a hack that was done to minimize the changes in the regression
> > > test expected outputs when we changed type interval from months/ 
> > > seconds
> > > to months/days/seconds.  But I wonder whether it wasn't a dumb idea.
> > > It is certainly inconsistent, as noted in the code comments.
> > >
> > > I'm tempted to propose that we remove the justify_hours call, and tell
> > > anyone who really wants the old results to apply justify_hours() to  
> > > the
> > > subtraction result for themselves.  Not sure what the fallout would  
> > > be,
> > > though.
> > 
> > I suspect there's applications out there that are relying on that  
> > being nicely formated for display purposes.
> > 
> > I agree it should be removed, but we might need a form of backwards  
> > compatibility for a version or two...
> > --
> > Jim Nasby[EMAIL PROTECTED]
> > EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)
> > 
> > 
> > 
> > ---(end of broadcast)---
> > TIP 3: Have you checked our extensive FAQ?
> > 
> >http://www.postgresql.org/docs/faq
> 
> -- 
>   Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
>   EnterpriseDB   http://www.enterprisedb.com
> 
>   + If your life is a hard drive, Christ can be your backup. +
> 
> ---(end of broadcast)---
> TIP 2: Don't 'kill -9' the postmaster

-- 
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] [Monotone-devel] Re: SCMS question

[Andreas Pflug]

Chris Browne wrote:
> The trouble is that there needs to be a sufficient plurality in favor
> of *a particular move onwards* in order for it to happen.
>
> Right now, what we see is:
>
> - Some that are fine with status quo
> - Some that are keen on Subversion
> - Others keen on Monotone
> - Others considering other options; Darcs, Git, Mercurial, Arch...
>
> There's no majority there, for sure.  No plurality, either.
>
> There has been a "convulsion" of activity surrounding SCM in the last
> couple of years, and I think that the brief trouble that the Linux
> kernel had with Bitkeeper going away has been an *excellent* thing as
> it drew developers to work on the (long languishing) SCM problem.
>
> It looks as though there is a strong "plurality" of PostgreSQL
> developers that are waiting for some alternative to become dominant.
> I suspect THAT will never happen.
>   
It probably _can_ never happen, because that would have to be a
one-for-all solution, embracing both centric and distributed
repositories, combining contradictionary goals. So the first question to
answer is: Will PostgreSQL continue with a single repository (the
project was managed very successfully this way for a long time), or try
a distributed approach. IMHO facts would quote for a central repository,
which would drastically reduce SCM candidates.

Regards,
Andreas



---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] SCMS question

[Joshua D. Drake]

> Moreover work on things like bitmapped indexes that other people want to help
> on is hampered by this need to be mailing around patches. If two or three
> people submit changes (based possibly on different old versions of the patch)
> the main developer has to merge them into his version of the patch by hand and
> mail out a new patch. The whole point of a revision control system is to
> provide tools to make that easier.

O.k. everyone pay attention, I am about to agree with Greg! ;)

Greg are their tools to migrate CVS to monotone or whatever your
favorite is? The reason I ask is that I migrate the CVS to SVN every 4
hours I think it is and it isn't perfect.

You get weird messages in the logs that don't track right. Remember, we
have a very large repo.

Anyway, my point is, if we have those tools, why don't we do a
migration, have some peer review on the migration and actually make an
argument based on the results versus the theory?

I am happy to help with this any way I can, because I would love to see
CVS take a big diving leap off the backend of mysql into the truncated
data set of hell.

Joshua D. Drake


-- 

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/


---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Status of Hierarchical Queries

[Jim C. Nasby]

On Thu, Feb 22, 2007 at 07:59:35AM +, Gregory Stark wrote:
> "Gavin Sherry" <[EMAIL PROTECTED]> writes:
> 
> > On Thu, 22 Feb 2007, Gregory Stark wrote:
> >
> >> But in a simple recursive tree search you have a node which wants to do a 
> >> join
> >> between the output of tree level n against some table to produce tree level
> >> n+1. It can't simply execute the plan to produce tree level n since that's 
> >> the
> >> same tree it's executing itself. If it calls the Init method on itself 
> >> it'll
> >> lose all its state.
> >>
> >> There's another reason it can't just execute the previous node. You really
> >> don't want to recompute all the results for level n when you go to produce
> >> level n+1. You want to keep them around from the previous iteration. 
> >> Otherwise
> >> you have an n^2 algorithm.
> >
> > Right. When I've spent some idle cycles thinking through this in the past
> > I figured that in a non-trivial query, we'd end up with a bunch of
> > materialisations, one for each level of recursion. That sounds very ugly.
> 
> Well as long as you have precisely one for each level of recursion I think
> you're doing ok. The problem is if you do it the naive way you calculate the
> first level, then for the second level you recalculate the first level again,
> then for the third level you recalculate both of the previous two, ... So you
> end up with n copies of the first level, n-1 copies of the second level, ...
> 
> If you reuse the result sets for subsequent recursive calls then you actually
> only need to keep then nth level around until you're done generating the n+1
> level.
> 
> The trick is being able to have two different call sites in the plan tree
> pulling records out of the Materialize node at different points in the result
> set. That currently isn't possible.

So it's sounding like the best we can get in 8.3 is WITH doing
single-level subquery replacement?
-- 
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] Priorities for users or queries?

[Jim C. Nasby]

On Wed, Feb 21, 2007 at 04:14:35PM +, Jos?? Orlando Pereira wrote:
> Benjamin Arai wrote:
> > Is there a way to give priorities to queries or users? Something similar to 
> > NICE in Linux. My goal is to give the updating (backend) application a very 
> > low priority and give the web application a high priority to avoid
> > disturbing the user experience.  
> >
> > Thanks in advance!
> 
> You might want to look at the following, as they mention a PostgreSQL 
> prototype:
> 
> http://www.cs.cmu.edu/~natassa/aapubs/conference/priority mechanisms.pdf

That URL should be...
http://www.cs.cmu.edu/~natassa/aapubs/conference/priority%20mechanisms.pdf

There has been extensive discussion on the bizgres list about ways to
implement priorities, and I believe that paper was mentioned. You should
look at the archives.
-- 
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

[HACKERS] Proposal for Implenting read-only queries during wal replay (SoC 2007)

[Florian G. Pflug]

Hi

I plan to submit a proposal for implementing support for
read-only queries during wal replay as a "Google Summer of Code 2007"
project.

I've been browsing the postgres source-code for the last few days,
and came up with the following plan for a implementation.

I'd be very interested in any feedback on the propsoal - especially
of the "you overlooked this an that, it can never work that way" kind ;-)

greetings, Florian Pflug

Implementing read-only quries during wal archive replay
---

Submitter: Florian Pflug <[EMAIL PROTECTED]>

Abstract:
Implementing full support for read-only queries during
wal archive replay is splitted into multiple parts, where
each part offeres additional functionality over what
postgres provides now. This makes tackling this as a
"Google Summer of Code 2007" project feasable, and guarantees
that at least some progress is made, even if solving the
whole problem turns out to be harder then previously
thought.

Parts/Milestones of the implementation:
A) Allow postgres to be started in read-only mode. After
   initial wal recovery, postgres doesn't perform writes
   anymore. All transactions started are implicitly in
   readonly mode. All transactions will be assigned dummy
   transaction ids, which never make it into the clog.
B) Split StartupXLOG into two steps. The first (Recovery) will process
   only enough wal to bring the system into a consistent state,
   while the second one (Replay) replays the archive until it finds no
   more wal segments. This replay happens in chunks, such that
   after a chunk all *_safe_restartpoint functions return true.
C) Combine A) and B), in the simplest possible way.
   Introduce a global R/W lock, which is taken by the Replay part
   of B) in write mode before replaying a chunk, then released,
   and immediatly reaquired before replaying the next chunk.
   The startup sequence is modified to do only the Recovery part
   where is is doing StartupXLOG now, and to lauch an extra process
   (similar to bgwriter) to do the second (Replay) part in the background.
   The system is then started up in read-only mode, with the addition
   that the global R/W lock is taken in read mode before starting any
   transaction. Thus, while a transaction is running, no archive replay
   happens.

Benefits:
*) Part A) alone might be of value for some people in the embedded world,
   or people who want to distribute software the use postgres. You could
   e.g. distribute a CD with a large, read-only database, and your application
   would just need to start postmaster to be able to query it directly from
   the CD.
*) Read-only hot standby is a rather simple way to do load-balancing, if
   your application doesn't depend on the data being absolutely up-to-date.
*) Even if this isn't used for load-balancing, it gives the DBA an
   easy way to check how far a PITR slave is lagging behind, therefore
   making PITR replication more user-friendly.

Open Questions/Problems
*) How do read-only transactions obtain a snapshot? Is it sufficient
   to just create an "empty" snapshot for them, meaning that they'll
   always look at the clog to obtain a transaction's state?
*) How many places to attempt to issue writes? How hard is it to
   silence them all while in read-only mode.
*) How does the user interface look like? I'm currently leaning towards
   a postgresql.conf setting read_only=yes. This would put postgres
   into read-only mode, and if a recovery.conf is present, archive
   replay would run as a background process.

Limitations:
*) The replaying process might be starved, letting the slave fall
   further and further behind the master. Only true if the slave
   executes a lot of queries, though.
*) Postgres would continue to run in read-only mode, even after finishing
   archive recovery. A restart would be needed to switch it into read-write
   mode again. (I probably wouldn't be too hard to do that switch without
   a restart, but it seems better to tackle this after the basic features
   are working)

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] osprey dumped core on 8.2

[Tom Lane]

Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Osprey is a NetBSD running on m68k

Yeah, it's been failing consistently on the 8.2 branch for a while, but
not either 8.1 or HEAD, which is awfully strange.

> Program terminated with signal 11, Segmentation fault.
> #0  0x001f74d6 in AllocSetAlloc (context=0x307d10, size=16777212) at 
> aset.c:546
> 546   if (set->blocks != NULL)

> I don't understand how can this happen, given that "set" cannot be NULL
> at this point.

I talked to Remi about this last month, and we concluded that the core
dump is probably really at the line just prior, where it's trying to
stick a marker at the end of the used space:

((char *) AllocChunkGetPointer(chunk))[size] = 0x7E;

But neither of us could see how that could happen unless malloc is
outright broken.  Remi did some gdb'ing that seemed to indicate
that malloc had failed to provide a block as large as it claimed:

: =?ISO-8859-1?Q?R=E9mi_Zara?= <[EMAIL PROTECTED]> writes:
: > (gdb) info locals
: > block = 0x4395000
: > chunk = 0x4395010
: > priorfree = 0x5395020
: > chunk_size = 16777216
: > blksize = 70864912
: > (gdb) p *block
: > $5 = {aset = 0x306d10, next = 0x0, freeptr = 0x5395020 , endptr = 0x5395020 }
: 
: Well, that's pretty dang interesting.  If the end of the block is indeed
: out of bounds as gdb claims, that'd explain why it crashes right here
: (actually the crash would be induced by the preceding line of code,
: where it tries to store a marker byte).  But how can that be, unless
: malloc is completely broken?  And if it is, why's it only affecting the
: 8.2 branch?  I'm confused.

and it kinda tailed off there ...

regards, tom lane

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] SCMS question

[Andrew Dunstan]

Joshua D. Drake wrote:

Moreover work on things like bitmapped indexes that other people want to help
on is hampered by this need to be mailing around patches. If two or three
people submit changes (based possibly on different old versions of the patch)
the main developer has to merge them into his version of the patch by hand and
mail out a new patch. The whole point of a revision control system is to
provide tools to make that easier.



O.k. everyone pay attention, I am about to agree with Greg! ;)

Greg are their tools to migrate CVS to monotone or whatever your
favorite is? The reason I ask is that I migrate the CVS to SVN every 4
hours I think it is and it isn't perfect.
  


Are you going to do trials for just Monotone, or will you include 
alternatives like, say, Mercurial (which seems to have quite a bit of 
traction, and should appeal to you as it's written in Python)?


There is a generic conversion tool called Tailor that might help you: 
http://www.darcs.net/DarcsWiki/Tailor


cheers

andrew


---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Proposal for Implenting read-only queries during wal replay (SoC 2007)

[Doug Knight]

Hi,
Here's some feedback, this is a feature that would be very useful to a
project I am currently working on. 

Doug

On Fri, 2007-02-23 at 17:34 +0100, Florian G. Pflug wrote:
> Hi
> 
> I plan to submit a proposal for implementing support for
> read-only queries during wal replay as a "Google Summer of Code 2007"
> project.
> 
> I've been browsing the postgres source-code for the last few days,
> and came up with the following plan for a implementation.
> 
> I'd be very interested in any feedback on the propsoal - especially
> of the "you overlooked this an that, it can never work that way" kind ;-)
> 
> greetings, Florian Pflug
> 
> Implementing read-only quries during wal archive replay
> ---
> 
> Submitter: Florian Pflug <[EMAIL PROTECTED]>
> 
> Abstract:
> Implementing full support for read-only queries during
> wal archive replay is splitted into multiple parts, where
> each part offeres additional functionality over what
> postgres provides now. This makes tackling this as a
> "Google Summer of Code 2007" project feasable, and guarantees
> that at least some progress is made, even if solving the
> whole problem turns out to be harder then previously
> thought.
> 
> Parts/Milestones of the implementation:
> A) Allow postgres to be started in read-only mode. After
> initial wal recovery, postgres doesn't perform writes
> anymore. All transactions started are implicitly in
> readonly mode. All transactions will be assigned dummy
> transaction ids, which never make it into the clog.
> B) Split StartupXLOG into two steps. The first (Recovery) will process
> only enough wal to bring the system into a consistent state,
> while the second one (Replay) replays the archive until it finds no
> more wal segments. This replay happens in chunks, such that
> after a chunk all *_safe_restartpoint functions return true.
> C) Combine A) and B), in the simplest possible way.
> Introduce a global R/W lock, which is taken by the Replay part
> of B) in write mode before replaying a chunk, then released,
> and immediatly reaquired before replaying the next chunk.
> The startup sequence is modified to do only the Recovery part
> where is is doing StartupXLOG now, and to lauch an extra process
> (similar to bgwriter) to do the second (Replay) part in the background.
> The system is then started up in read-only mode, with the addition
> that the global R/W lock is taken in read mode before starting any
> transaction. Thus, while a transaction is running, no archive replay
> happens.
> 
> Benefits:
> *) Part A) alone might be of value for some people in the embedded world,
> or people who want to distribute software the use postgres. You could
> e.g. distribute a CD with a large, read-only database, and your 
> application
> would just need to start postmaster to be able to query it directly from
> the CD.
> *) Read-only hot standby is a rather simple way to do load-balancing, if
> your application doesn't depend on the data being absolutely up-to-date.
> *) Even if this isn't used for load-balancing, it gives the DBA an
> easy way to check how far a PITR slave is lagging behind, therefore
> making PITR replication more user-friendly.
> 
> Open Questions/Problems
> *) How do read-only transactions obtain a snapshot? Is it sufficient
> to just create an "empty" snapshot for them, meaning that they'll
> always look at the clog to obtain a transaction's state?
> *) How many places to attempt to issue writes? How hard is it to
> silence them all while in read-only mode.
> *) How does the user interface look like? I'm currently leaning towards
> a postgresql.conf setting read_only=yes. This would put postgres
> into read-only mode, and if a recovery.conf is present, archive
> replay would run as a background process.
> 
> Limitations:
> *) The replaying process might be starved, letting the slave fall
> further and further behind the master. Only true if the slave
> executes a lot of queries, though.
> *) Postgres would continue to run in read-only mode, even after finishing
> archive recovery. A restart would be needed to switch it into read-write
> mode again. (I probably wouldn't be too hard to do that switch without
> a restart, but it seems better to tackle this after the basic features
> are working)
> 
> ---(end of broadcast)---
> TIP 5: don't forget to increase your free space map settings
> 

Re: [HACKERS] Proposal for Implenting read-only queries during wal replay (SoC 2007)

[Tom Lane]

"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> I plan to submit a proposal for implementing support for
> read-only queries during wal replay as a "Google Summer of Code 2007"
> project.

You are discussing this on the wrong list.

> B) Split StartupXLOG into two steps. The first (Recovery) will process
> only enough wal to bring the system into a consistent state,

How will you know what that is?

> C) Combine A) and B), in the simplest possible way.
> Introduce a global R/W lock, which is taken by the Replay part
> of B) in write mode before replaying a chunk, then released,
> and immediatly reaquired before replaying the next chunk.

That seems certain to result in intolerable performance, for both the
queries and the replay process.

regards, tom lane

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] autovacuum next steps, take 2

[Jim C. Nasby]

On Fri, Feb 23, 2007 at 01:22:17PM -0300, Alvaro Herrera wrote:
> Jim C. Nasby wrote:
> > On Thu, Feb 22, 2007 at 10:32:44PM -0500, Matthew T. O'Connor wrote:
> 
> > > I'm not sure this is a great idea, but I don't see how this would result 
> > > in large numbers of workers working in one database.   If workers work 
> > > on tables in size order, and exit as soon as they catch up to an older 
> > > worker, I don't see the problem.  Newer works are going to catch-up to 
> > > older workers pretty quickly since small tables will vacuum fairly 
> > > quickly.
> > 
> > The reason that won't necessarily happen is because you can get large
> > tables popping up as needing vacuuming at any time.
> 
> Right.
> 
> We know that a table that needs frequent vacuum necessarily has to be
> small -- so maybe have the second worker exit when it catches up with
> the first, or when the next table is above 1 GB, whichever happens
> first.  That way, only the first worker can be processing the huge
> tables.  The problem with this is that if one of your hot tables grows
> a bit larger than 1 GB, you suddenly have a change in autovacuuming
> behavior, for no really good reason.
> 
> And while your second worker is processing the tables in the hundreds-MB
> range, your high-update 2 MB tables are neglected :-(

That's why I'm thinking it would be best to keep the maximum size of
stuff for the second worker small. It probably also makes sense to tie
it to time and not size, since the key factor is that you want it to hit
the high-update tables every X number of seconds.

If we wanted to get fancy, we could factor in how far over the vacuum
threshold a table is, so even if the table is on the larger size, if
it's way over the threshold the second vacuum will hit it.

You know, maybe the best way to handle this is to force both vacuums to
exit after a certain amount of time, probably with a longer time limit
for the first vacuum in a database. That would mean that after
processing a large table for 10 minutes, the first vacuum would
exit/re-evaluate what work needs to be done. That would mean
medium-sized tables wouldn't get completely starved.
-- 
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] Simple Column reordering

[Jim C. Nasby]

First, it would absolutely be best if we just got the full blown patch
into 8.3 and were done with it. I don't think anyone's arguing against
that... it's a question of what we can do if that can't happen (and it
does sound like the patch lost it's maintainer when the direction
changed towards doing both physical and logical ordering code at the
same time).

On Fri, Feb 23, 2007 at 01:04:14PM -0300, Alvaro Herrera wrote:
> Jim C. Nasby wrote:
> > On Fri, Feb 23, 2007 at 02:09:55PM +, Simon Riggs wrote:
> > > > If you really want an interim solution, what about a builtin function 
> > > > that would explicitly mutate the definition and table contents (if any) 
> > > > along the lines you want? (assuming that's lots less work than just 
> > > > doing the whole thing right to start with). Or even one which just 
> > > > *displayed* the optimal order might be sufficient assistance to DBAs 
> > > > who 
> > > > want to take advantage of this.
> > > 
> > > I think the only interim solution now is to put functionality into
> > > PgAdmin et al to optimize the column order.
> > 
> > Well, if it comes to that it would be good to have pgAdmin et all driven
> > by logic in the database, so that people using psql can benefit as well.
> > Perhaps a function that is passed an existing table and re-creates it in
> > optimal order (if it's empty...). Or at least spits out a CREATE TABLE
> > statement for you that's in optimal order.
> 
> That's just working around the fact that the engine is not smart enough
> to do the right thing (semi-) automatically.  We don't support that kind
> of operation, just like we don't support optimizer hints.

Except it's kind of the opposite... in this case, the database actually
knows better about what fields have what alignment, etc. At least if
users can get what the database says will be the best order they can use
that should they choose to.

I also don't see why we should restrict that information to users of
pgAdmin or other 3rd party tools and not support those that just use
psql.
-- 
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] [Monotone-devel] Re: SCMS question

[Martijn van Oosterhout]

On Fri, Feb 23, 2007 at 09:12:27AM -0500, Chris Browne wrote:
> It looks as though there is a strong "plurality" of PostgreSQL
> developers that are waiting for some alternative to become dominant.
> I suspect THAT will never happen.

Actually, I think that if one of the SCMs provides some kind of server
interface that allows clients to keep using the CVS client if they
want, they would get significant traction. If only because it allows
people and existing tools to keep working while providing extra
possibilities.

IOW provide a nice upgrade path for the transition and a lot of the
problems switching go away. 

Then again, it's probably nowhere near as easy as I make it sound :)

Have a nice day,
-- 
Martijn van Oosterhout  http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to 
> litigate.


signature.asc
Description: Digital signature

Re: [HACKERS] SCMS question

[Jim C. Nasby]

On Fri, Feb 23, 2007 at 08:32:34AM -0800, Joshua D. Drake wrote:
> I am happy to help with this any way I can, because I would love to see
> CVS take a big diving leap off the backend of mysql into the truncated
> data set of hell.

That quote made the whole argument coming up again worthwhile. :)
-- 
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] [Monotone-devel] Re: SCMS question

[A.M.]

On Feb 23, 2007, at 11:24 , Andreas Pflug wrote:




It probably _can_ never happen, because that would have to be a
one-for-all solution, embracing both centric and distributed
repositories, combining contradictionary goals. So the first  
question to

answer is: Will PostgreSQL continue with a single repository (the
project was managed very successfully this way for a long time), or  
try
a distributed approach. IMHO facts would quote for a central  
repository,

which would drastically reduce SCM candidates.


Any distributed SCM can be inherently be used as a central repo. The  
project leaders would merely designate one place from whence builds  
are generated and developers would simply sync with the "central" repo.


In fact, distributed SCMs fit the open source development model  
better because any failure of the "central" repo (crash, buy-out,  
sabotage, needing a project fork) cannot cause chaos: a new "central"  
repo is designated- essentially an instant failover.


Cheers,
M

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

   http://www.postgresql.org/about/donate

Re: [HACKERS] Proposal for Implenting read-only queries during wal replay (SoC 2007)

[Florian G. Pflug]

Tom Lane wrote:

"Florian G. Pflug" <[EMAIL PROTECTED]> writes:

I plan to submit a proposal for implementing support for
read-only queries during wal replay as a "Google Summer of Code 2007"
project.


You are discussing this on the wrong list.

So what list would be more appropriate?


B) Split StartupXLOG into two steps. The first (Recovery) will process
only enough wal to bring the system into a consistent state,


How will you know what that is?

With the same logic that postgres uses now to bring an file-system backup
into a consistent state when doing PITR.


C) Combine A) and B), in the simplest possible way.
Introduce a global R/W lock, which is taken by the Replay part
of B) in write mode before replaying a chunk, then released,
and immediatly reaquired before replaying the next chunk.


That seems certain to result in intolerable performance, for both the
queries and the replay process.


That depends entirely on the usecase. And besides, this limitation could
and probably would be adressed in the future. I think a step-by-step
approach is more likely to be successfull then attempting to solve
all problems at once.

greetings, Florian Pflug




---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] [Monotone-devel] Re: SCMS question

[Joshua D. Drake]

Martijn van Oosterhout wrote:
> On Fri, Feb 23, 2007 at 09:12:27AM -0500, Chris Browne wrote:
>> It looks as though there is a strong "plurality" of PostgreSQL
>> developers that are waiting for some alternative to become dominant.
>> I suspect THAT will never happen.

Actually it has. The problem is different SCMS offer different things.

If you are looking for a CVS replacement, that replacement is SVN. I
don't think anyone can reasonably argue against that statement.

If you are looking for something that is not a CVS replacement, but
offers SCM and has different features (like mercurial) then I agree with
you.

Sincerely,

Joshua D. Drake


> 
> Actually, I think that if one of the SCMs provides some kind of server
> interface that allows clients to keep using the CVS client if they
> want, they would get significant traction. If only because it allows
> people and existing tools to keep working while providing extra
> possibilities.
> 
> IOW provide a nice upgrade path for the transition and a lot of the
> problems switching go away. 
> 
> Then again, it's probably nowhere near as easy as I make it sound :)
> 
> Have a nice day,


-- 

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/


---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [HACKERS] SCMS question

[Andrew Hammond]

On Feb 22, 9:49 am, [EMAIL PROTECTED] (Alvaro Herrera) wrote:
> Andrew Dunstan wrote:
> > It's also fair to say that this is a subject about which we usually get
> > much more noise from partisans of other SCM systems than from the
> > relatively small number of people who actually have to maintain the
> > postgresql code. (As Tom has pointed out, our biggest pain point is the
> > occasional wish to move things across directories.)

While annoying, this is something that really only a problem for the
CVS maintainer (and anyone who's stuck waiting for the maintainer to
shuffle stuff). I suggest that while it would be nice to solve this
problem, it's more of a bonus side-effect rather than a significant
benefit to changing SCMs.

> For example, currently if I have a patch and somebody reviews it and
> opines that I have to change foo to bar; then I resubmit the patch.  How
> do they find out whether I actually changed foo to bar?  Currently there
> are two alternatives:
>
> 1. trust that I did it
> 2. review the whole patch again
>
> With a distributed SCM, I could just patch the code and commit a new
> revision in my branch to just change foo to bar, and then the reviewer
> can check that I truly did what he wanted.
>
> Another easy thing to do is to track the current HEAD in a branch of
> mine.  Keeping patches up to date in parallel with other developments is
> easier.

Alvaro's arguments above suggest a significant, ongoing pay-off for
everyone who writes patches, everyone who reviews patches and everyone
who has to maintain separate patches. I won't attempt to quantify this
pay-off, but it looks pretty significant to me.

Andrew


---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] SCMS question

[Bruce Momjian]

Gregory Stark wrote:
> You're still merging patches and reviewing patches by hand, without any of the
> tools to, for example, view incremental changes in the branch, view the logs
> of the branch, merge the branch into the code automatically taking into
> account the known common ancestor. Instead of receiving a 20k patch without
> any tools to work with it you would be given a branch name and be able to view
> and merge it into the main branch using the tools.

I don't see this as a win.  I understand the ability to see the patch as
separate revisions by the user, but for patch application, we really
need to see the diff -c of the entire patch.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] SCMS question

[Alvaro Herrera]

Bruce Momjian wrote:
> Gregory Stark wrote:
> > You're still merging patches and reviewing patches by hand, without any of 
> > the
> > tools to, for example, view incremental changes in the branch, view the logs
> > of the branch, merge the branch into the code automatically taking into
> > account the known common ancestor. Instead of receiving a 20k patch without
> > any tools to work with it you would be given a branch name and be able to 
> > view
> > and merge it into the main branch using the tools.
> 
> I don't see this as a win.  I understand the ability to see the patch as
> separate revisions by the user, but for patch application, we really
> need to see the diff -c of the entire patch.

The fact that you're still thinking in "patch application" means you're
still stuck in the CVS worldview.  To "apply a patch" in a distributed
SCM(*) really means to merge a branch into the main development branch.
Of course, you can still see the entire "diff -c" if you want.


(*) I'm not sure if this is true of all distributed SCMs, or just a
property of Monotone.  Really it's the only one I follow more-or-less
closely.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] SCMS question

[Bruce Momjian]

Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Gregory Stark wrote:
> > > You're still merging patches and reviewing patches by hand, without any 
> > > of the
> > > tools to, for example, view incremental changes in the branch, view the 
> > > logs
> > > of the branch, merge the branch into the code automatically taking into
> > > account the known common ancestor. Instead of receiving a 20k patch 
> > > without
> > > any tools to work with it you would be given a branch name and be able to 
> > > view
> > > and merge it into the main branch using the tools.
> > 
> > I don't see this as a win.  I understand the ability to see the patch as
> > separate revisions by the user, but for patch application, we really
> > need to see the diff -c of the entire patch.
> 
> The fact that you're still thinking in "patch application" means you're
> still stuck in the CVS worldview.  To "apply a patch" in a distributed
> SCM(*) really means to merge a branch into the main development branch.
> Of course, you can still see the entire "diff -c" if you want.

How do I modify the patch before application if it comes from a branch?

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] SCMS question

[Alvaro Herrera]

Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> > > Gregory Stark wrote:
> > > > You're still merging patches and reviewing patches by hand, without any 
> > > > of the
> > > > tools to, for example, view incremental changes in the branch, view the 
> > > > logs
> > > > of the branch, merge the branch into the code automatically taking into
> > > > account the known common ancestor. Instead of receiving a 20k patch 
> > > > without
> > > > any tools to work with it you would be given a branch name and be able 
> > > > to view
> > > > and merge it into the main branch using the tools.
> > > 
> > > I don't see this as a win.  I understand the ability to see the patch as
> > > separate revisions by the user, but for patch application, we really
> > > need to see the diff -c of the entire patch.
> > 
> > The fact that you're still thinking in "patch application" means you're
> > still stuck in the CVS worldview.  To "apply a patch" in a distributed
> > SCM(*) really means to merge a branch into the main development branch.
> > Of course, you can still see the entire "diff -c" if you want.
> 
> How do I modify the patch before application if it comes from a branch?

You commit your change to the branch.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] SCMS question

[Bruce Momjian]

Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> > > Bruce Momjian wrote:
> > > > Gregory Stark wrote:
> > > > > You're still merging patches and reviewing patches by hand, without 
> > > > > any of the
> > > > > tools to, for example, view incremental changes in the branch, view 
> > > > > the logs
> > > > > of the branch, merge the branch into the code automatically taking 
> > > > > into
> > > > > account the known common ancestor. Instead of receiving a 20k patch 
> > > > > without
> > > > > any tools to work with it you would be given a branch name and be 
> > > > > able to view
> > > > > and merge it into the main branch using the tools.
> > > > 
> > > > I don't see this as a win.  I understand the ability to see the patch as
> > > > separate revisions by the user, but for patch application, we really
> > > > need to see the diff -c of the entire patch.
> > > 
> > > The fact that you're still thinking in "patch application" means you're
> > > still stuck in the CVS worldview.  To "apply a patch" in a distributed
> > > SCM(*) really means to merge a branch into the main development branch.
> > > Of course, you can still see the entire "diff -c" if you want.
> > 
> > How do I modify the patch before application if it comes from a branch?
> 
> You commit your change to the branch.

My typical cycle is to take the patch, apply it to my tree, then cvs
diff and look at the diff, adjust the source, and rerun until I like the
diff and apply.  How do I do that with this setup?

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] Proposal for Implenting read-only queries during wal replay (SoC 2007)

[Tom Lane]

"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> You are discussing this on the wrong list.

> So what list would be more appropriate?

My mistake, I read the message header and saw "Postgresql-General" ...
did not look at the actual address ...

regards, tom lane

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [HACKERS] Simple Column reordering

[Bruce Momjian]

Lukas Kahwe Smith wrote:
> Simon Riggs wrote:
> 
> > If this is standards-breaking as you say, I would withdraw immediately.
> > I checked the SQL standard and could not see how this would do so. The
> > standard states SELECT * would return columns in order; it doesn't say
> > what that order should be, nor does CREATE TABLE enforce the ordering to
> > be the same as it has specified, AFAICS. Please correct me and I will
> > withdraw. Practical issues seem far stronger drivers than standards
> > issues here, which is why the parameter would default=off.
> 
> I did not follow the entire thread. I just wanted to point out that IIRC 
> MS SQL Server (and maybe also Sybase) do automatically optimize the 
> internal order of how columns are stored to move fixed length (which 
> also means non NULLable for these two servers) columns to the left. 
> Maybe this will serve as a reference point (not necessarily for 
> standards compliance of course).

And that optimized ordering shows up with SELECT *?

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] SCMS question

[Ron Mayer]

Bruce Momjian wrote:
> 
> My typical cycle is to take the patch, apply it to my tree, then cvs
> diff and look at the diff, adjust the source, and rerun until I like the
> diff and apply.  How do I do that with this setup?

The most similar to what you're doing would be to
merge the patch's branch into yours.   It's about
exactly the same amount of work as applying a
patch (a one liner if there are no conflicts).

>From that point you could continue exactly as you are now - with the
additional benefit(?) that the checkin history of the branch should (I
hope) be preserved through the merge process so the SCM's history would
let you see which changes from the patch came from the submitter and which
changes came from the modifications in your tree.



(I think this SCM requirements list
  
http://changelog.complete.org/posts/528-Whose-Distributed-VCS-Is-The-Most-Distributed.html
 is one of the more interesting.
 The two features I like about the distributed systems are
   # 5. Branching preserves full history
   # 6. Merging preserves full history.
 so the history of the branch (including which changes
 came from the submitter and which were modifications
 in your tree) are preserved when they're eventually
 committed to head.)

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] SCMS question

[Alvaro Herrera]

Bruce Momjian wrote:

> My typical cycle is to take the patch, apply it to my tree, then cvs
> diff and look at the diff, adjust the source, and rerun until I like the
> diff and apply.  How do I do that with this setup?

The same, except that you don't need to take the patch out of an email
and into the repository -- the new code is already in the repository,
sitting in someone's own branch.  You can commit into that branch all
the adjustments you want; and when you consider it ready, the only thing
you have to do is "propagate" the change to the main development branch.

Yes, it's nice.  Consider this: Andrew develops some changes to PL/perl
in his branch.  Neil doesn't like something in those changes, so he
commits a fix there.  In the meantime, Tom has been busy with his own
stuff and committing to the main branch; Andrew can track those changes
by propagating from the main branch to his branch -- he doesn't need to
fall behind and update his modified tree once a month and deal with
umpteen conflicts.

Of course, you can _also_ do the patch by email and correct stuff if you
want.  It's just not the best way to do it.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] SCMS question

[Bruce Momjian]

Alvaro Herrera wrote:
> Bruce Momjian wrote:
> 
> > My typical cycle is to take the patch, apply it to my tree, then cvs
> > diff and look at the diff, adjust the source, and rerun until I like the
> > diff and apply.  How do I do that with this setup?
> 
> The same, except that you don't need to take the patch out of an email
> and into the repository -- the new code is already in the repository,
> sitting in someone's own branch.  You can commit into that branch all
> the adjustments you want; and when you consider it ready, the only thing
> you have to do is "propagate" the change to the main development branch.
> 
> Yes, it's nice.  Consider this: Andrew develops some changes to PL/perl
> in his branch.  Neil doesn't like something in those changes, so he
> commits a fix there.  In the meantime, Tom has been busy with his own
> stuff and committing to the main branch; Andrew can track those changes
> by propagating from the main branch to his branch -- he doesn't need to
> fall behind and update his modified tree once a month and deal with
> umpteen conflicts.
> 
> Of course, you can _also_ do the patch by email and correct stuff if you
> want.  It's just not the best way to do it.

How to people get a branch?  Do they have their own logins?

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 6: explain analyze is your friend

[HACKERS] 5 Weeks till feature freeze or (do you know where your patch is?)

[Joshua D. Drake]

Hello,

5 weeks to feature freeze folks. Please provide updates including if you
think you will have a patch submitted before feature freeze. Be
realistic, if you can't make it -- say so.


Alvaro Herrera: Autovacuum improvements (maintenance window etc..)
Gavin Sherry: Bitmap Indexes (on disk), possible basic Window functions
Greg Stark: WITH/Recursive Queries?
Andrei Kovalesvki: Some Win32 work with Magnus
Magnus Hagander: VC++ support (thank goodness)
Heikki Linnakangas: Vacuum for Bitmap Indexes, Group Index Tuples
Oleg Bartunov: Tsearch2 in core
Neil Conway: Patch Review (including enums), pg_fcache
PeterE: XML
ITAGAKI Takahiro: Dead space map, load distributed checkpoints
Stephen Frost: Default permission per object/schema
Tom Lane: Cost based functions, operator overhaul, Plan Invalidation?
Simon Riggs: HOT ( you know he just is )
Pavan Deolasee: HOT ( never met him )
Teodor Sigaev: Tsearch2 in core (with Oleg)
Jeff Davis: Synchronized scanning
Henry Hotz: GSSAPI (with Magnus)
Andrew Dunstan: Something with COPY? Andrew?
David Fetter: Arrays of compound types

Looking for updates on Updateable views. Anyone? Bueller?

Vertical projects:

Pavel Stehule: PLpsm
Alexey Klyukin: PLphp
Andrei Kovalesvki: ODBCng
Neil Conway: pgmemcache
Josh Drake: pgmemcache


This close to feature freeze it is really time for people to get
pounding on patch review!!!

Sincerely,

Joshua D. Drake





-- 

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/


---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [HACKERS] 5 Weeks till feature freeze or (do you know where your patch is?)

[Andrew Dunstan]

Joshua D. Drake wrote:

Andrew Dunstan: Something with COPY? Andrew?

  


The only thing I can think of is to remove the support for ancient COPY 
syntax from psql's \copy, as suggested here: 
http://archives.postgresql.org/pgsql-hackers/2007-02/msg01078.php


That's hardly a feature - more a matter of tidying up.



Neil Conway: pgmemcache
Josh Drake: pgmemcache
  



what does this refer to?


cheers

andrew

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] 5 Weeks till feature freeze or (do you know where your patch is?)

[Joshua D. Drake]

>>
>> Neil Conway: pgmemcache
>> Josh Drake: pgmemcache
>>   
> 
> 
> what does this refer to?

Neil is cleaning up the code, I am cleaning up the docs.

Joshua D. Drake

> 
> 
> cheers
> 
> andrew
> 


-- 

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/


---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] 5 Weeks till feature freeze or (do you know where your patch is?)

[Joshua D. Drake]

> The only thing I can think of is to remove the support for ancient COPY
> syntax from psql's \copy, as suggested here:
> http://archives.postgresql.org/pgsql-hackers/2007-02/msg01078.php
> 
> That's hardly a feature - more a matter of tidying up.

I thought you were being sponsored for something?

Joshua D. Drake


-- 

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/


---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] 5 Weeks till feature freeze or (do you know where your patch is?)

[Gregory Stark]

"Joshua D. Drake" <[EMAIL PROTECTED]> writes:

> Greg Stark: WITH/Recursive Queries?

Uhm, I posted two weeks ago saying I had to shelve that temporarily. 

On the other hand I've submitted a patch to reduce the storage overhead of
varlenas under 128 bytes by 3-7 bytes each.

-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] 5 Weeks till feature freeze or (do you know where your patch is?)

[Joshua D. Drake]

Gregory Stark wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> 
>> Greg Stark: WITH/Recursive Queries?
> 
> Uhm, I posted two weeks ago saying I had to shelve that temporarily. 

I can't read every email :)

Can someone pick this up? This would be the second time that this has
been dropped. Anyone?

> 
> On the other hand I've submitted a patch to reduce the storage overhead of
> varlenas under 128 bytes by 3-7 bytes each.

Cool!

Joshua D. Drake





-- 

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/


---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

[HACKERS] urgent: upgraded to 8.2, getting kernel panics

[Merlin Moncure]

Ok,

This may the wrong place to look for answers to this, but I figured it
couldn't hurt...so here goes:

On friday we upgraded a critical backend server to postgresql 8.2
running on fedora core 4.  Since then we have received three kernel
panics during periods of moderate to high load (twice during the
pg_dump backup run).

Platform is IBM x360 series running SCSI, software raid on the backplane.

After the first crash we yum updated the system which obviously did
not fix the problem.  I was leaning hardware problem until this last
time and I was able to catch the following off the terminal:

BUG: spinlock recursion CPU0 postmaster...not tainted.
bunch of other stuff ending in:
Kernel Panic: not syncing: Bad locking

One of the other developers snapped a picture of the kernel panic with
his digital camera and is going to send over the pictures when he gets
home this evening.

Has anybody seen any problem like this or have any suggestions about
possible resolution...should I be posting to the LKML?  Any
suggestions are welcome and appreciated.

At this juncture we are going to downgrade the postmaster back to 8.1
and see if that fixes the panics.  If it doesn't this discussion is
over but if it does we are extremely curious about looking for a fix
for this issue...we have about 8 weeks of development that is on hold
until we can put a 8.2 server in production.  Management has already
authorized a new server but they want a 100% guarantee this is going
to fix the problem.

thanks in advance,
merlin

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

   http://www.postgresql.org/about/donate

[HACKERS] Re: [GENERAL] 5 Weeks till feature freeze or (do you know where your patch is?)

[Jeff Davis]

On Fri, 2007-02-23 at 13:24 -0800, Joshua D. Drake wrote:
> Jeff Davis: Synchronized scanning

I am still on target. I'm scheduling some benchmarks on real hardware
and real queries in the next week or two. If those show the results I
expect, I'll be ready before feature freeze.

Regards,
Jeff Davis


---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [HACKERS] [GENERAL] urgent: upgraded to 8.2, getting kernel panics

[Devrim GUNDUZ]

On Fri, 2007-02-23 at 17:14 -0500, Merlin Moncure wrote:

> BUG: spinlock recursion CPU0 postmaster...not tainted.



> Has anybody seen any problem like this or have any suggestions about
> possible resolution...should I be posting to the LKML?  

AFAIR (+ some quick Googling), this is related to a problem in kernel.
You may need to update to a newer Fedora release since FC4 is not
supported anymore :(. 

Even if you report to LKML, they will probably suggest you using a newer
kernel. However, I think system will not let you compile a new kernel
and panic again during a high load... So...

If you have a free space, install a newer Fedora release on this system,
mount the existing $PGDATA and try if this fixes the problem...
-- 
Devrim GÜNDÜZ
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/




signature.asc
Description: This is a digitally signed message part

Re: [HACKERS] Re: [GENERAL] 5 Weeks till feature freeze or (do you know where your patch is?)

[Josh Berkus]

Jeff,

> I am still on target. I'm scheduling some benchmarks on real hardware
> and real queries in the next week or two. If those show the results I
> expect, I'll be ready before feature freeze.

Send me a patch against 8.2.3 and I'll pass it to the Sun benchmarking 
team.

-- 
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] Proposal for Implenting read-only queries during wal replay (SoC 2007)

[Heikki Linnakangas]

Florian G. Pflug wrote:

I plan to submit a proposal for implementing support for
read-only queries during wal replay as a "Google Summer of Code 2007"
project.

I've been browsing the postgres source-code for the last few days,
and came up with the following plan for a implementation.

I'd be very interested in any feedback on the propsoal - especially
of the "you overlooked this an that, it can never work that way" kind ;-)


I had the same thought roughly two years ago:

http://archives.postgresql.org/pgsql-hackers/2005-11/msg01043.php

People weren't very interested in having a read-only mode. I think it 
would be a nice feature if it's not too complicated.


--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] SCMS question

[Tom Lane]

Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Yes, it's nice.  Consider this: Andrew develops some changes to PL/perl
> in his branch.  Neil doesn't like something in those changes, so he
> commits a fix there.  In the meantime, Tom has been busy with his own
> stuff and committing to the main branch; Andrew can track those changes
> by propagating from the main branch to his branch -- he doesn't need to
> fall behind and update his modified tree once a month and deal with
> umpteen conflicts.

Yah know, the one bit of these pitches that always sounds like pure
snake oil is the claim that they offer some kind of mechanical solution
to merge conflicts.  AFAICS that has nothing to do with the SCMS in use
and everything to do with whether your "diff" command is AI-complete.

I note also that CVS does have the ability to merge changes across
branches, we just choose not to use it that way.

regards, tom lane

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] Proposal for Implenting read-only queries during wal replay (SoC 2007)

[Glen Parker]

I'll throw in my vote, I would find this quite useful.

-Glen


Florian G. Pflug wrote:

I plan to submit a proposal for implementing support for
read-only queries during wal replay as a "Google Summer of Code 2007"
project.

I've been browsing the postgres source-code for the last few days,
and came up with the following plan for a implementation.

I'd be very interested in any feedback on the propsoal - especially
of the "you overlooked this an that, it can never work that way" kind ;-)




---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match

Re: [HACKERS] Proposal for Implenting read-only queries during wal replay (SoC 2007)

[Josh Berkus]

> People weren't very interested in having a read-only mode. I think it
> would be a nice feature if it's not too complicated.

Actually, I think there's high demand for it off this list.  Effectively it 
would allow our "warm backup mode" to become a "hot backup mode".   As SoC 
admin, I'd vote for such a proposal unless someone explains to me why it's 
impossible.

-- 
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] Proposal for Implenting read-only queries during wal replay (SoC 2007)

[Joshua D. Drake]

Josh Berkus wrote:
>> People weren't very interested in having a read-only mode. I think it
>> would be a nice feature if it's not too complicated.
> 
> Actually, I think there's high demand for it off this list.  Effectively it 
> would allow our "warm backup mode" to become a "hot backup mode".   As SoC 
> admin, I'd vote for such a proposal unless someone explains to me why it's 
> impossible.

One thing I would like noted, is whoever does SoC work for PostgreSQL
this year, needs to work *with* the community. Otherwise there is no point.

A good example of the wrong way to do it is the Full Disjunctions
project. Great idea, Great project, not bitrot and hard space because it
hasn't been touched or maintained sense release.

In order to get it into core, it would have needed a lot of work. Let's
make sure we don't duplicate the issue.

Joshua D. Drake




-- 

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/


---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] urgent: upgraded to 8.2, getting kernel panics

[Tom Lane]

"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> On friday we upgraded a critical backend server to postgresql 8.2
> running on fedora core 4.

Umm ... why that particular choice of OS?  Red Hat dropped update
support for FC4 some time ago, and AFAIK the Fedora Legacy project
is not getting things done.  How old is the kernel you're using?

> At this juncture we are going to downgrade the postmaster back to 8.1
> and see if that fixes the panics.

Even assuming that Postgres is related to the panics, I don't think you
will find anyone maintaining that a kernel panic is not the kernel's
problem.  If an application *is* able to provoke a kernel panic, the
standard description of the problem would be "critical kernel security
flaw".

regards, tom lane

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [HACKERS] [COMMITTERS] pgsql: Update Solaris FAQ.

[Peter Eisentraut]

Bruce Momjian wrote:
> Log Message:
> ---
> Update Solaris FAQ.

Could someone please translate this to English first?

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] [COMMITTERS] pgsql: Update Solaris FAQ.

[Bruce Momjian]

Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > Log Message:
> > ---
> > Update Solaris FAQ.
> 
> Could someone please translate this to English first?

Updated text:

9) Can I compile PostgreSQL with Kerberos v5 support?

Kerberos is integrated in OpenSolaris and will be integrated in Solaris
10u4. Kerberos v5 support is implemented by the GSS security libary
which contains Kerberos v5 functions. However, the library is private
and the interface might change without notice.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] [COMMITTERS] pgsql: Update Solaris FAQ.

[Joshua D. Drake]

Bruce Momjian wrote:
> Peter Eisentraut wrote:
>> Bruce Momjian wrote:
>>> Log Message:
>>> ---
>>> Update Solaris FAQ.
>> Could someone please translate this to English first?
> 
> Updated text:
> 
> 9) Can I compile PostgreSQL with Kerberos v5 support?
> 
> Kerberos is integrated in OpenSolaris and will be integrated in Solaris
> 10u4. Kerberos v5 support is implemented by the GSS security libary
> which contains Kerberos v5 functions. However, the library is private
> and the interface might change without notice.

That doesn't answer the question ;)

Joshua D. Drake



-- 

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/


---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [HACKERS] [COMMITTERS] pgsql: Update Solaris FAQ.

[Bruce Momjian]

Joshua D. Drake wrote:
> Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> >> Bruce Momjian wrote:
> >>> Log Message:
> >>> ---
> >>> Update Solaris FAQ.
> >> Could someone please translate this to English first?
> > 
> > Updated text:
> > 
> > 9) Can I compile PostgreSQL with Kerberos v5 support?
> > 
> > Kerberos is integrated in OpenSolaris and will be integrated in Solaris
> > 10u4. Kerberos v5 support is implemented by the GSS security libary
> > which contains Kerberos v5 functions. However, the library is private
> > and the interface might change without notice.
> 
> That doesn't answer the question ;)

Good point.  I think I need to just add "Yes," to the first sentence.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] [COMMITTERS] pgsql: Update Solaris FAQ.

[Joshua D. Drake]

Bruce Momjian wrote:
> Joshua D. Drake wrote:
>> Bruce Momjian wrote:
>>> Peter Eisentraut wrote:
 Bruce Momjian wrote:
> Log Message:
> ---
> Update Solaris FAQ.
 Could someone please translate this to English first?
>>> Updated text:
>>>
>>> 9) Can I compile PostgreSQL with Kerberos v5 support?
>>>
>>> Kerberos is integrated in OpenSolaris and will be integrated in Solaris
>>> 10u4. Kerberos v5 support is implemented by the GSS security libary
>>> which contains Kerberos v5 functions. However, the library is private
>>> and the interface might change without notice.
>> That doesn't answer the question ;)
> 
> Good point.  I think I need to just add "Yes," to the first sentence.

Yeah I think that will do it :)

Joshua D. Drake




-- 

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/


---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] SCMS question

[Warren Turkal]

On Friday 23 February 2007 15:50, you wrote:
> How to people get a branch?  Do they have their own logins?

If monotone is something like Git, you just create it in your local working 
copy and push is somewhere public when you are ready, or you can just 
generate the changeset and submit that.

wt
-- 
Warren Turkal (w00t)

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] Proposal for Implenting read-only queries during wal replay (SoC 2007)

[Jim C. Nasby]

On Fri, Feb 23, 2007 at 10:57:24PM +, Heikki Linnakangas wrote:
> Florian G. Pflug wrote:
> >I plan to submit a proposal for implementing support for
> >read-only queries during wal replay as a "Google Summer of Code 2007"
> >project.
> >
> >I've been browsing the postgres source-code for the last few days,
> >and came up with the following plan for a implementation.
> >
> >I'd be very interested in any feedback on the propsoal - especially
> >of the "you overlooked this an that, it can never work that way" kind ;-)
> 
> I had the same thought roughly two years ago:
> 
> http://archives.postgresql.org/pgsql-hackers/2005-11/msg01043.php
> 
> People weren't very interested in having a read-only mode. I think it 
> would be a nice feature if it's not too complicated.

Every customer I've ever talked to about HA has either asked about it or
thought it was a great idea. We should definitely do it if it's not a
load of difficult..
-- 
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] 5 Weeks till feature freeze or (do you know where your patch is?)

[Bruce Momjian]

Also, I have several heavy patches in the patch queue that I am not
comfortable reviewing/applying:

http://momjian.postgresql.org/cgi-bin/pgpatches

---

Joshua D. Drake wrote:
> Hello,
> 
> 5 weeks to feature freeze folks. Please provide updates including if you
> think you will have a patch submitted before feature freeze. Be
> realistic, if you can't make it -- say so.
> 
> 
> Alvaro Herrera: Autovacuum improvements (maintenance window etc..)
> Gavin Sherry: Bitmap Indexes (on disk), possible basic Window functions
> Greg Stark: WITH/Recursive Queries?
> Andrei Kovalesvki: Some Win32 work with Magnus
> Magnus Hagander: VC++ support (thank goodness)
> Heikki Linnakangas: Vacuum for Bitmap Indexes, Group Index Tuples
> Oleg Bartunov: Tsearch2 in core
> Neil Conway: Patch Review (including enums), pg_fcache
> PeterE: XML
> ITAGAKI Takahiro: Dead space map, load distributed checkpoints
> Stephen Frost: Default permission per object/schema
> Tom Lane: Cost based functions, operator overhaul, Plan Invalidation?
> Simon Riggs: HOT ( you know he just is )
> Pavan Deolasee: HOT ( never met him )
> Teodor Sigaev: Tsearch2 in core (with Oleg)
> Jeff Davis: Synchronized scanning
> Henry Hotz: GSSAPI (with Magnus)
> Andrew Dunstan: Something with COPY? Andrew?
> David Fetter: Arrays of compound types
> 
> Looking for updates on Updateable views. Anyone? Bueller?
> 
> Vertical projects:
> 
> Pavel Stehule: PLpsm
> Alexey Klyukin: PLphp
> Andrei Kovalesvki: ODBCng
> Neil Conway: pgmemcache
> Josh Drake: pgmemcache
> 
> 
> This close to feature freeze it is really time for people to get
> pounding on patch review!!!
> 
> Sincerely,
> 
> Joshua D. Drake
> 
> 
> 
> 
> 
> -- 
> 
>   === The PostgreSQL Company: Command Prompt, Inc. ===
> Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
> Providing the most comprehensive  PostgreSQL solutions since 1997
>  http://www.commandprompt.com/
> 
> Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
> PostgreSQL Replication: http://www.commandprompt.com/products/
> 
> 
> ---(end of broadcast)---
> TIP 7: You can help support the PostgreSQL project by donating at
> 
> http://www.postgresql.org/about/donate

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] SCMS question

[Florian Weimer]

* Bruce Momjian:

>> The fact that you're still thinking in "patch application" means you're
>> still stuck in the CVS worldview.  To "apply a patch" in a distributed
>> SCM(*) really means to merge a branch into the main development branch.
>> Of course, you can still see the entire "diff -c" if you want.
>
> How do I modify the patch before application if it comes from a branch?

You refuse to merge until you reach a point which is acceptable.  One
large project even gets so far as to ask the submitter to clean up
history before merging it, so that all that polishing is gone and does
not show up after the merge.  In the official tree, there's just a
clean sequence of incremental patches.

I'm not really sure if this is the right model for every project.
Personally, I'm a fan of the write-after-approval approach: per ACL,
everybody has got full write access, but most developers might only
apply their patches after some review and a formal go-ahead.  This has
the advantage that everyone can fix obvious mistakes or back out wrong
patches if necessary, and it nicely distributes the integration
overhead.

But obviously, there are fairly successful projects which use very
different models, and switching just because the technology is there
to do things differently doesn't make much sense.  But once you run
into problems like tagging a release taking hours, you should really
contemplate a move to Subversion. 8-P

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] Simple Column reordering

[Lukas Kahwe Smith]

Bruce Momjian wrote:

Lukas Kahwe Smith wrote:

Simon Riggs wrote:


If this is standards-breaking as you say, I would withdraw immediately.
I checked the SQL standard and could not see how this would do so. The
standard states SELECT * would return columns in order; it doesn't say
what that order should be, nor does CREATE TABLE enforce the ordering to
be the same as it has specified, AFAICS. Please correct me and I will
withdraw. Practical issues seem far stronger drivers than standards
issues here, which is why the parameter would default=off.
I did not follow the entire thread. I just wanted to point out that IIRC 
MS SQL Server (and maybe also Sybase) do automatically optimize the 
internal order of how columns are stored to move fixed length (which 
also means non NULLable for these two servers) columns to the left. 
Maybe this will serve as a reference point (not necessarily for 
standards compliance of course).


And that optimized ordering shows up with SELECT *?


no .. like i said its just the internal order ..
I think I learned this piece of information from reading "SQL 
performance tuning" by Peter and Trudy .. dont have the book here right 
now to give a page number.


regards,
Lukas



---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org

developer wiki (was Re: [HACKERS] SCMS question)

[Warren Turkal]

On Friday 23 February 2007 00:55, Lukas Kahwe Smith wrote:
> Anyone who followed the thread willing to list the mentioned
> requirements as well as the pro's and con's of the differnent options in
> the developer wiki [1]?

Does the dev wiki even have a link from the site? I can't find a link under 
[1].

[1]http://www.postgresql.org/developer/

wt
-- 
Warren Turkal (w00t)

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] [GENERAL] pg_autovacuum should allow NULL values

[Tom Lane]

I wrote:
> I don't find this particularly important, because we have never intended
> direct update of catalog entries to be a primary way of interacting with
> the system.  The current pg_autovacuum setup is a stopgap until the dust
> has settled enough that we know what sort of long-term API we want for
> autovacuum.

I just had an epiphany about that.  We've wanted to avoid setting the
autovacuum knobs in stone, because it's pretty obvious they're not
ready, and that has prevented us from inventing any nice SQL syntax for
managing the per-table settings.

Meanwhile, the storage-parameter infrastructure got added in 8.2.
Isn't that an absolutely ideal framework for managing per-table autovac
settings?  We could drop the separate pg_autovacuum catalog altogether
and keep all the info in pg_class.reloptions.  Advantages:

* The infrastructure is all there already, including ALTER TABLE and
pg_dump support.

* The parameter names are not SQL keywords, and the syntax isn't
hardwired to any particular set of them.  So it would be fairly painless
to change the set of supported parameters, with or without backwards
compatibility to keep on recognizing an old parameter.

Disadvantages:

* Wouldn't be forwards-compatible with any hacks that people might
currently have to dump and restore pg_autovacuum contents.  But you
could probably make a script to read your existing table and emit
ALTER TABLE SET commands instead.

regards, tom lane

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

[HACKERS] Re: 5 Weeks till feature freeze or (do you know where your patch is?)

[Lukas Kahwe Smith]

Joshua D. Drake wrote:

Hello,

5 weeks to feature freeze folks. Please provide updates including if you
think you will have a patch submitted before feature freeze. Be
realistic, if you can't make it -- say so.


Alvaro Herrera: Autovacuum improvements (maintenance window etc..)
Gavin Sherry: Bitmap Indexes (on disk), possible basic Window functions
Greg Stark: WITH/Recursive Queries?
Andrei Kovalesvki: Some Win32 work with Magnus
Magnus Hagander: VC++ support (thank goodness)
Heikki Linnakangas: Vacuum for Bitmap Indexes, Group Index Tuples
Oleg Bartunov: Tsearch2 in core
Neil Conway: Patch Review (including enums), pg_fcache
PeterE: XML
ITAGAKI Takahiro: Dead space map, load distributed checkpoints
Stephen Frost: Default permission per object/schema
Tom Lane: Cost based functions, operator overhaul, Plan Invalidation?
Simon Riggs: HOT ( you know he just is )
Pavan Deolasee: HOT ( never met him )
Teodor Sigaev: Tsearch2 in core (with Oleg)
Jeff Davis: Synchronized scanning
Henry Hotz: GSSAPI (with Magnus)
Andrew Dunstan: Something with COPY? Andrew?
David Fetter: Arrays of compound types

Looking for updates on Updateable views. Anyone? Bueller?


Afaik Bernd is working in this one and he is targetting 8.4

Looks like we are doing redundant work here:
http://developer.postgresql.org/index.php/Todo:WishlistFor83

Where/how do you maintained your todo list Joshua? Would love to join 
"forces" on this one .. especially since I send out emails to many of 
the above noted people. If we both send emails to everybody they might 
get ticked off ..


regards,
Lukas

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

   http://www.postgresql.org/about/donate

Re: [HACKERS] SCMS question

[Ron Mayer]

Alvaro Herrera wrote:

> Yes, it's nice.  Consider this: Andrew develops some changes to PL/perl
> in his branch.  Neil doesn't like something in those changes, so he
> commits a fix there.  

If I understand right, another advantage is that the SCM will keep
track of which of those changes came from Neil and which from Andrew
and that this history will be preserved when eventually merged with head.
In contrast, with CVS I think  detailed history of changes within Andrew's
branch would be lost and only recorded as one large checkin in CVS.
Right?

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] Re: 5 Weeks till feature freeze or (do you know where your patch is?)

[Joshua D. Drake]

> 
> Looks like we are doing redundant work here:
> http://developer.postgresql.org/index.php/Todo:WishlistFor83
> 
> Where/how do you maintained your todo list Joshua? Would love to join
> "forces" on this one .. especially since I send out emails to many of
> the above noted people. If we both send emails to everybody they might
> get ticked off ..

I just took the replies from my 10 week email and merged them. I tried
to use the wiki but got fed up with my login/edit privelages not working :)

Joshua D. Drake



> 
> regards,
> Lukas
> 
> ---(end of broadcast)---
> TIP 7: You can help support the PostgreSQL project by donating at
> 
>http://www.postgresql.org/about/donate
> 


-- 

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/


---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] SCMS question

[Jim C. Nasby]

On Fri, Feb 23, 2007 at 04:24:29PM -0700, Warren Turkal wrote:
> On Friday 23 February 2007 15:50, you wrote:
> > How to people get a branch?  Do they have their own logins?
> 
> If monotone is something like Git, you just create it in your local working 
> copy and push is somewhere public when you are ready, or you can just 
> generate the changeset and submit that.

One additional benefit... we've talked about allowing certain patches to
be automatically verified by the buildfarm to guard against bitrot and
provide additional testing, but one of the big issues has been how to
distribute those patches. Using a distributed SCM would make it easier
to do this; we'd just have to supply buildfarm machines with a list of
approved branches that they should be pulling from (or perhaps some SCMs
would allow a means of tagging that).
-- 
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] [GENERAL] pg_autovacuum should allow NULL values

[Jim C. Nasby]

On Fri, Feb 23, 2007 at 06:47:52PM -0500, Tom Lane wrote:
> I wrote:
> > I don't find this particularly important, because we have never intended
> > direct update of catalog entries to be a primary way of interacting with
> > the system.  The current pg_autovacuum setup is a stopgap until the dust
> > has settled enough that we know what sort of long-term API we want for
> > autovacuum.
> 
> I just had an epiphany about that.  We've wanted to avoid setting the
> autovacuum knobs in stone, because it's pretty obvious they're not
> ready, and that has prevented us from inventing any nice SQL syntax for
> managing the per-table settings.
> 
> Meanwhile, the storage-parameter infrastructure got added in 8.2.
> Isn't that an absolutely ideal framework for managing per-table autovac
> settings?  We could drop the separate pg_autovacuum catalog altogether
> and keep all the info in pg_class.reloptions.  Advantages:
> 
> * The infrastructure is all there already, including ALTER TABLE and
> pg_dump support.
> 
> * The parameter names are not SQL keywords, and the syntax isn't
> hardwired to any particular set of them.  So it would be fairly painless
> to change the set of supported parameters, with or without backwards
> compatibility to keep on recognizing an old parameter.
> 
> Disadvantages:
> 
> * Wouldn't be forwards-compatible with any hacks that people might
> currently have to dump and restore pg_autovacuum contents.  But you
> could probably make a script to read your existing table and emit
> ALTER TABLE SET commands instead.

Actually, if we wanted to we should be able to create a view that takes
the place of the current pg_autovacuum. With appropriate rules and some
functions, you could probably even make it updatable.
-- 
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] SCMS question

[Gregory Stark]

"Tom Lane" <[EMAIL PROTECTED]> writes:

> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Yes, it's nice.  Consider this: Andrew develops some changes to PL/perl
>> in his branch.  Neil doesn't like something in those changes, so he
>> commits a fix there.  In the meantime, Tom has been busy with his own
>> stuff and committing to the main branch; Andrew can track those changes
>> by propagating from the main branch to his branch -- he doesn't need to
>> fall behind and update his modified tree once a month and deal with
>> umpteen conflicts.
>
> Yah know, the one bit of these pitches that always sounds like pure
> snake oil is the claim that they offer some kind of mechanical solution
> to merge conflicts.  AFAICS that has nothing to do with the SCMS in use
> and everything to do with whether your "diff" command is AI-complete.

Well there is some difference in that it's easier to do that when you have the
common ancestor.

But it has more to do with being able to see the changes other people are
making. In the above scenario imagine Neil had just emailed the fix and Andrew
hadn't seen it for a week. Or more importantly that Neil had emailed the fix
and someone else had also emailed a different fix somewhere else. Because they
couldn't see each others changes they have no idea when they're generating the
patch that they're generating it against old versions.

> I note also that CVS does have the ability to merge changes across
> branches, we just choose not to use it that way.

And the reason why, I assume, is because it's hard to grant access to CVS
without granting access to do anything at all to the whole repository. And CVS
is fragile enough that that's pretty scary. There are lots of ways someone
could mess up a CVS repository.

The distributed systems sound neat and do sound like they match our style of
working. But they seem like a big leap for a project that's still using a
buggy unmaintained pile of spaghetti code for fear of change. Subversion is
the path of least resistance in that nothing has to change, we can choose to
use new features if we want but otherwise it's basically a CVS 2.0 with a new
name (and active maintenance).

-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] 5 Weeks till feature freeze or (do you know where your patch is?)

[Gregory Stark]

"Gregory Stark" <[EMAIL PROTECTED]> writes:

> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>
>> Greg Stark: WITH/Recursive Queries?
>
> Uhm, I posted two weeks ago saying I had to shelve that temporarily. 
>
> On the other hand I've submitted a patch to reduce the storage overhead of
> varlenas under 128 bytes by 3-7 bytes each.

oops, that's actually 3-6 bytes.

-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] Proposal for Implenting read-only queries during wal replay (SoC 2007)

[Florian G. Pflug]

Heikki Linnakangas wrote:

Florian G. Pflug wrote:

I plan to submit a proposal for implementing support for
read-only queries during wal replay as a "Google Summer of Code 2007"
project.

I've been browsing the postgres source-code for the last few days,
and came up with the following plan for a implementation.

I'd be very interested in any feedback on the propsoal - especially
of the "you overlooked this an that, it can never work that way" kind ;-)


I had the same thought roughly two years ago:

http://archives.postgresql.org/pgsql-hackers/2005-11/msg01043.php

People weren't very interested in having a read-only mode. I think it 
would be a nice feature if it's not too complicated.


I think "main" feature would be supporting read-only queries on PITR
slaves. But creating a read-only mode seemed to me (and to you too, it
seems ;-) ) like a good first step towards that goal.

After reading tom's reply to your original proposal, I agree that
supporting a write-protected datadir is not a true subset of
supporting read-only queries on PITR slaves. But I still think
that tackling the read-only datadir support is a good first step -
not the least because it'll help me to get familiar with the
relevent parts of the backend.

I've been thinking about your "trick" of writing "readonly" into
the postmaster.pid file to switch postgres into read-only mode.
On the one hand, it's really neat - if solves the problem of not
being able to create a pid file in the datadir in ro mode, while
on the other hand making sure that there *is* a pid file. But
if I went that way, it would mean there would be *three* configfiles
you have to get right for a working PITR slave with read-only query
support - postgresql.conf, recovery.conf, and postmaster.pid.

So I think I'll rather go with a postgresql.conf setting. I'd
allow three values "hard", "soft" and "off".
"hard" would prevent all writes to the datadir, while
"soft" would be the setting of choice for a PITR slave.

In the "soft" case, postgres would still write a postmaster.pid,
and so be protected against other running postmasters.
In the "hard" case, there would be no such protection - but since
there would be no writes anyway, you don't risk data corruption
in case another postmaster was running - the worst the would happen
is that the read-only postmaster crashes.

greetings, Florian Pflug


---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] SCMS question

[Andrew Dunstan]

Gregory Stark wrote:

"Tom Lane" <[EMAIL PROTECTED]> writes:
  

I note also that CVS does have the ability to merge changes across
branches, we just choose not to use it that way.



And the reason why, I assume, is because it's hard to grant access to CVS
without granting access to do anything at all to the whole repository. And CVS
is fragile enough that that's pretty scary. There are lots of ways someone
could mess up a CVS repository.
  


Every project I have been on that has used cross branch merge  with CVS 
has tied itself in knots. Branch and never merge is by far the sanest 
way to operate. This is true regardless of any privs issue.


The elephant in the room is that merging is *the* hard problem in SCM 
systems. Last time I wrestled with merge it was using ClearCase and 
drove me nuts.



The distributed systems sound neat and do sound like they match our style of
working. But they seem like a big leap for a project that's still using a
buggy unmaintained pile of spaghetti code for fear of change. Subversion is
the path of least resistance in that nothing has to change, we can choose to
use new features if we want but otherwise it's basically a CVS 2.0 with a new
name (and active maintenance).

  


There is some truth in that. Also, many of the new systems have a little 
way to go on maturity - I'd like to see the dust settle some in this area.


cheers

andrew


---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] Proposal for Implenting read-only queries during wal replay (SoC 2007)

[Florian G. Pflug]

Josh Berkus wrote:

People weren't very interested in having a read-only mode. I think it
would be a nice feature if it's not too complicated.


Actually, I think there's high demand for it off this list.  Effectively it 
would allow our "warm backup mode" to become a "hot backup mode".   As SoC 
admin, I'd vote for such a proposal unless someone explains to me why it's 
impossible.


From my point of view, the most subtle point of the whole proposal is
if not doing
wal-replay _and_ quries at the same time, but rather one after the other,
really solves all the locking issues.

My line of reasoning is that stopping wal replay at a arbitrary point,
and then starting a read-only transaction with an "empty snapshot" (meaning
that all exactly those transactions marked as comitted in the clog are 
assumed to be visible to the transaction) is exactly the same as sending

the backend a SIGKILL when it just wrote the wal record in question,
and then restarting postgres, and starting a transaction.

Since later won't lead to problems today, doing the formed for hot standby
should not lead to problems too.

There reason that I put "Process wal in chucks such that all 
*_safe_restartpoint" functions return true at the end of a chunk" was

the be on the safe side, not because I could find any actual problem
if that requirement was dropped.

Can anyone find a flaw in those arguments?

greetings, Florian Pflug

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match

Re: [GENERAL] [HACKERS] urgent: upgraded to 8.2, getting kernel panics

[CAJ CAJ]

On 2/23/07, Tom Lane <[EMAIL PROTECTED]> wrote:


"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> On friday we upgraded a critical backend server to postgresql 8.2
> running on fedora core 4.

Umm ... why that particular choice of OS?  Red Hat dropped update
support for FC4 some time ago, and AFAIK the Fedora Legacy project
is not getting things done.  How old is the kernel you're using?

> At this juncture we are going to downgrade the postmaster back to 8.1
> and see if that fixes the panics.

Even assuming that Postgres is related to the panics, I don't think you
will find anyone maintaining that a kernel panic is not the kernel's
problem.  If an application *is* able to provoke a kernel panic, the
standard description of the problem would be "critical kernel security
flaw".



I vaguely remember running into spinlock problems with FC4 and it wasn't due
to PostgreSQL. We didn't have database running on FC4.

If you are running a critical server you should switch to atleast CentOS.

Re: [HACKERS] SCMS question

[Warren Turkal]

On Friday 23 February 2007 08:30, Alvaro Herrera wrote:
> Sorry, I mean Windows.  We're taken pains to ensure Postgres runs on
> Windows, we're not going to abandon that platform now.

This is why I would propose the use of the CVS gateway on top of git. Also, 
Wikipedia claims there is a MingW32 port of git underway.

> And there's a lot of platforms on which we'd have to make sure Monotone
> also runs on.  Our buildfarm currently has
> http://buildfarm.postgresql.org/cgi-bin/show_status.pl

Again, the CVS gateway should allow them to continue to function with minimal 
changes. Over time, they could be moved to Git.

wt
-- 
Warren Turkal (w00t)

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Proposal for Implenting read-only queries during wal replay (SoC 2007)

[Tom Lane]

"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> My line of reasoning is that stopping wal replay at a arbitrary point,
> and then starting a read-only transaction with an "empty snapshot" (meaning
> that all exactly those transactions marked as comitted in the clog are 
> assumed to be visible to the transaction) is exactly the same as sending
> the backend a SIGKILL when it just wrote the wal record in question,
> and then restarting postgres, and starting a transaction.

The hole in that reasoning is that no one would be satisfied with the
behavior of a Postgres database that was being forcibly restarted every
few seconds.  Yeah, we won't lose transactions that have been promised
committed, but losing a large fraction of transactions-in-progress won't
please anyone.  Nor will queries on a slave that's behaving like that
provide an accurate model of what the same queries would produce if issued
on the master.

regards, tom lane

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] SCMS question

[Alvaro Herrera]

Warren Turkal wrote:
> On Friday 23 February 2007 08:30, Alvaro Herrera wrote:
> > Sorry, I mean Windows.  We're taken pains to ensure Postgres runs on
> > Windows, we're not going to abandon that platform now.
> 
> This is why I would propose the use of the CVS gateway on top of git. Also, 
> Wikipedia claims there is a MingW32 port of git underway.

To be frank, I don't like Git's data model.  Git has always seemed
much too complex to use to me.  I have more than enough with a single
distributed SCM.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

[HACKERS] Re: [GENERAL] 5 Weeks till feature freeze or (do you know where your patch is?)

[Magnus Hagander]

Joshua D. Drake wrote:



> Magnus Hagander: VC++ support (thank goodness)

I would much appreciate more people testing and commenting on this one,
from the version in CVS head.



//Magnus

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] SCMS question

[Warren Turkal]

On Friday 23 February 2007 17:30, Gregory Stark wrote:
> The distributed systems sound neat and do sound like they match our style
> of working. But they seem like a big leap for a project that's still using
> a buggy unmaintained pile of spaghetti code for fear of change. Subversion
> is the path of least resistance in that nothing has to change, we can
> choose to use new features if we want but otherwise it's basically a CVS
> 2.0 with a new name (and active maintenance).

The interesting thing about Git is that is has two way sync support for a SVN 
repository also. You could run a Git repository pushing changes in real time 
to a SVN repository and present a CVS frontend also. I would like to try 
converting the CVS repository of PostgreSQL to Git and try setting some of 
this stuff up. Does anyone know how I could get the CVS repository files?

wt
-- 
Warren Turkal (w00t)

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate