Re: [HACKERS] Mail thread references in commits

[Joshua Drake]

My solution requires that everything have an issue. E.g., hackers becomes a
tracker.

Sincerely,
 Jd

On Nov 19, 2016 09:04, "Tom Lane"  wrote:

> "Joshua D. Drake"  writes:
> > I wonder if now is the time (again) to consider an issue tracker.
>
> That would make the problem at hand worse, not better, because you'd
> get nothing at all for cases that were too trivial to make an issue
> tracker entry for, or that the committer couldn't be bothered to go
> find in the issue tracker.  We don't even have very widespread adherence
> to the cite-a-message-thread convention yet (so far as I can tell,
> Andres and I are the only committers doing it at all).  Adding another
> step of bureaucracy to our processes is just going to fail miserably.
>
> regards, tom lane
>

Re: [HACKERS] Mail thread references in commits

[Joshua Drake]

Sorry didn't see it.

On Nov 18, 2016 12:44, "Robert Haas" <robertmh...@gmail.com> wrote:

> On Thu, Nov 17, 2016 at 10:43 PM, Joshua Drake <j...@commandprompt.com>
> wrote:
> > Why not hash the URL? Something like:
> >
> > Http://postgresopen.org/archive/743257890976432
>
> I suggested that upthread...
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Re: [HACKERS] Mail thread references in commits

[Joshua Drake]

Why not hash the URL? Something like:

Http://postgresopen.org/archive/743257890976432

Where the hash is derived from the message if?

On Nov 17, 2016 17:40, "Alvaro Herrera"  wrote:
>
> Tom Lane wrote:
> > Andrew Dunstan  writes:
> > > I love seeing references to email threads in commit messages. It would
> > > make them a lot friendlier though if a full http URL were included
> > > instead of just a Message-ID,
> >
> > I've intentionally not done that, because it does not seem very
> > future-proof.  The message ids will hopefully be unique indefinitely far
> > into the future, but the location of our archives could move.
>
> It won't.  We have far too many in the archives to risk breaking them.
> In fact, we (Magnus) went great lengths to implement a system so that
> old-style PHP links (of which we have a bunch in very old archives,
> including in commit messages) continue to work to this day.  We're far
> too invested in the system now, because of how successful it has proved
> to be.
>
> --
> Álvaro Herrerahttps://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

[Joshua Drake]

On Apr 30, 2016 2:07 PM, Oleg Bartunov  wrote:
>
>
>
> On Fri, Apr 29, 2016 at 7:40 PM, Joshua D. Drake  wrote:
>>
> I'd not limited by the companies, individual developes are highly welcome. I'm afraid there are some.
>  
Oh, absolutely. I was just pointing out how a lot of companies are hoarding talent internally for no productive purpose.
Jd
>>
>>
>>
>> Sincerely,
>>
>> JD
>>
>>
>> -- 
>> Command Prompt, Inc.                  http://the.postgres.company/
>>                         +1-503-667-4564
>> PostgreSQL Centered full stack support, consulting and development.
>> Everyone appreciates your honesty, until you are honest with them.
>
>

Re: [HACKERS] pg_prewarm

[Joshua Drake]

So I wrote a prewarming utility. Patch is attached. You can prewarm 
either the OS cache or PostgreSQL's cache, and there are two options for 
prewarming the OS cache to meet different needs. By passing the correct 
arguments to the function, you can prewarm an entire relation or just 
the blocks you choose; prewarming of blocks from alternate relation 
forks is also supported, for completeness. Hope you like it.




+1

Re: [HACKERS] PostgreSQL + Replicator developer meeting 10/28

[Joshua Drake]

On Tue, 28 Oct 2008 19:46:42 +0200
Hannu Krosing [EMAIL PROTECTED] wrote:

 On Mon, 2008-10-27 at 13:42 -0700, Joshua Drake wrote:
  With the recent open sourcing of Replicator, the team has been
  trying to come up with ways to ensure an open development process.
  In that light we have decided to have our first release 1.9 meeting
  on Freenode. All people interested in participating in a discussion
  about the upcoming Replicator 1.9 are welcome to attend.
 
 I missed the meeting at #replicator, but still have some questions

Meeting is still going on. I will answer your questions and post
results this afternoon.

Joshua D. Drake

-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PostgreSQL + Replicator developer meeting 10/28

[Joshua Drake]

On Tue, 28 Oct 2008 19:46:42 +0200
Hannu Krosing [EMAIL PROTECTED] wrote:

   The current topics are:
 
  * New MCP architecture
 
 What's new ? 
 
 I have some doubts about the current architecture based on my reading
 of replicator wiki, but would like to learn about the new
 architecture before spending too much time in studying the old one.

The two obvious problems with the existing MCP architecture is:

 1. Single point of failure
 2. Portability

The new architecture is set to remove both of those. The short version
is the MCP will be moved into the backend. Thus:

Master-MCP|Slave -Slave1
  -Slave2
  -Slave3

The process being, Master sends data to MCP|Slave, MCP|Slave writes it
to disk (optionally restores it) and then forwards it to 1,2,3 who then
receive the data, write it to disk and then restore it.

If master dies, you can promote to any of the slaves and the left over
slaves will connect to the promoted slave and begin receiving updates.

If the MCP|Slave dies a new Slave can begin the MCP|Slave process.

Alvaro or Alexey can speak more technically about implementation than I
can.

 
  * DDL Replication
 
 Is it there alread, or is it just  a planned feature ?

Planned feature.

 
  * How hard would it be to extract DDL replication part and use it as
basis for DDL after trigger support for use in trigger based
replication/auditing like Slony ann pgQ/Londiste ?

Hmm I am not sure. We are pretty deep into the core and only use
triggers for GRANT/REVOKE/CREATE ROLE .

Sincerely,

Joshua D. Drake



-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] PostgreSQL + Replicator developer meeting 10/28

[Joshua Drake]

With the recent open sourcing of Replicator, the team has been trying
to come up with ways to ensure an open development process. In that
light we have decided to have our first release 1.9 meeting on
Freenode. All people interested in participating in a discussion about
the upcoming Replicator 1.9 are welcome to attend. The current topics
are:


* New MCP architecture
* DDL Replication
* Release timeline
* Questions


Replicator is set to be a short cycle release, hopefully landing before
PostgreSQL 8.4. It will support PostgreSQL 8.3 and PostgreSQL 8.4 (when
8.4 is available). We will be meeting in the #replicator channel at
10:00 AM PDT...

Joshua D. Drake

-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] psql Feature request \set query

[Joshua Drake]

On Wed, 22 Oct 2008 19:06:59 -0400
Robert Haas [EMAIL PROTECTED] wrote:

  I think you're asking for more scriptability in psql.  Personally I
  think that would be a great idea, but we need a lot more than what's
  being proposed here.  We'll also need loops, conditionals, etc.
  We've had patches for those submitted over the years, but one at a
  time they are easily rejected because they're so obviously
  incomplete.
 
 We can't do anything unless we do everything is a recipe for
 failure.

True enough, but a car doesn't roll without at least four wheels.

 
 ...Robert
 


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] psql Feature request \set query

[Joshua Drake]

On Wed, 22 Oct 2008 20:43:44 -0400
Robert Haas [EMAIL PROTECTED] wrote:

  True enough, but a car doesn't roll without at least four wheels.
 
 True, but I'm not sure why we'd need three other wheels to make this
 feature roll, or what those three wheels would be.  Personally, I
 would never write a complicated script in psql rather than perl, but I
 can imagine using this interactively instead of cutting and pasting as
 I presently do.
 
 ...Robert
 

So now that we have both agreed with each other, what do we do? :P

Joshua D. Drake

-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Well its official, replicator is BSD

[Joshua Drake]

Hello,

We finally got around to releasing Replicator as FOSS. It is BSD
licensed and available here:

https://projects.commandprompt.com/public/replicator/wiki

(Yes it is a self signed cert, its on the list to fix).

Enjoy folks!

Sincerely,

Joshua D. Drake


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] TODO item: adding VERBOSE option to CLUSTER [with patch]

[Joshua Drake]

On Mon, 13 Oct 2008 15:34:04 -0500
Kevin Grittner [EMAIL PROTECTED] wrote:

 ccdev=# select pg_total_relation_size('DbTranImageStatus');
  pg_total_relation_size
 
  253952
 (1 row)
 
 ccdev=# cluster DbTranImageStatus;
 CLUSTER
 ccdev=# select pg_total_relation_size('DbTranImageStatus');
  pg_total_relation_size
 
   32768
 (1 row)
  
 -Kevin

Although I think it is an interesting bit of information, I find that
if I am going to be clustering, I have already done the above.


Sincerely,

Joshua D. Drake





-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] The Axe list

[Joshua Drake]

On Fri, 10 Oct 2008 16:28:29 -0700
Josh Berkus [EMAIL PROTECTED] wrote:

 Folks,
 
 It's that time again!  Purging antiquated contrib modules.
 
 chkpass: this module is incomplete and does not implement all
 functions it describes.  It's not really even useful as an Example
 since it uses crypt() and not any modern encryption.  And Darcy
 hasn't touched it in 6 years.
 
 intagg: the aggregation function has been obsolete since 7.4 because 
 standard array functionality supports the same.  intagg has a nice 
 equivalent for UNROLL, but it only works for arrays of INT, and only 
 one-dimensional arrays.  Has not been updated since 2001.
 
 Any objections to dropping both of these?

None.


 
 --Josh
 


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Block-level CRC checks

[Joshua Drake]

On Thu, 02 Oct 2008 11:57:30 -0400
Robert Treat [EMAIL PROTECTED] wrote:

 Actually we had someone on irc yesterday explaining how they were
 able to run zfs on debian linux, so that option might be closer than
 you think. 

Its user mode. Not sure I would suggest that from a production server
perspective.

 
 On a side note, I believe there are a couple of companies that do
 postgresql consulting that have pretty good experience running it
 atop solaris... just in case you guys ever do want to do a migration
 or something ;-)

:P

Joshua D. Drake 


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Block-level CRC checks

[Joshua Drake]

On Tue, 30 Sep 2008 14:33:04 -0400
Jonah H. Harris [EMAIL PROTECTED] wrote:

  I'd like to submit this for 8.4, but I want to ensure that -hackers
  at large approve of this feature before starting serious coding.
 
 IMHO, this is a functionality that should be enabled by default (as it
 is on most other RDBMS).  It would've prevented severe corruption in

What other RDMS have it enabled by default?

Sincerely,

Joshua D. Drake

 


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Block-level CRC checks

[Joshua Drake]

On Tue, 30 Sep 2008 13:48:52 -0700
Jeffrey Baker [EMAIL PROTECTED] wrote:


 
 Practically all of them.  Here is a good paper on various checksums,
 their failure rates, and practical applications.
 
 Parity Lost and Parity Regained
 http://www.usenix.org/event/fast08/tech/full_papers/krioukov/krioukov_html/index.html
 

In a related article published in Login called Data Corruption in the
storage stack: a closer look they say:

During a 41-month period we observed more than 400,000 instances of
checksum mistmatches, 8% of which were discovered during RAID
reconstruction, creating the possibility of real data loss.

They also have a wonderful term they mention, Silent Data corruptions.

Joshua D. Drake

[1] Login June 2008

 -jwb


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] parallel pg_restore - WIP patch

[Joshua Drake]

On Fri, 26 Sep 2008 17:10:44 -0400
Andrew Dunstan [EMAIL PROTECTED] wrote:

 Yes, there are several funny things going on, including some stuff
 with dependencies. I'll have a new patch tomorrow with luck. Thanks
 for testing.

O.k. I took at look at the patch itself and although I don't understand
all of it there were a couple of red flags to me:

+ if (ropt-create)
+   die_horribly(AH,modulename,
+parallel restore is
incompatible with --create\n);
+ 

This seems like an odd limitation. In my mind, the schema would not be
restored in parallel. The schema before data would restore as a single
thread. Even the largest schemas would only take minutes (if that).
Thus something like --create should never be a problem.

I also noticed you check if we have zlib? Is it even possible to use
the c format without it? (that would be new to me).

I noticed this line:


+   while((next_work_item = get_next_work_item(AH)) != NULL)
+   {
+   /* XXX need to improve this test in case there is no
table data */
+   /* need to test for indexes, FKs, PK, Unique, etc */
+   if(strcmp(next_work_item-desc,TABLE DATA) == 0)
+   break;
+   (void) _restore_one_te(AH, next_work_item, ropt,
false);
+ 
+   next_work_item-prestored = true;
+ 
+   _reduce_dependencies(AH,next_work_item);
+   }


Intead of the TABLE DATA compare, perhaps it makes sense to back patch
pg_dump to have a line delimiter in the TOC? That way even if there is
no TABLE DATA there would be a delimiter that says:

--- BEGIN TABLE DATA
--- END TABLE DATA

Thus if nothing is there... nothing is there?

+   /* delay just long enough betweek forks to
give the catalog some
+* breathing space. Without this sleep I got 
+* tuple concurrently updated errors.
+*/
+   pg_usleep(50);
+   continue; /* in case the slots are not yet
full */
+   }

Could that be solved with a lock instead? Once the lock is released

Anyway... just some thoughts. I apologize if I misunderstood the patch.

Sincerely,

Joshua D. Drake



 
 cheers
 
 andrew
 


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] parallel pg_restore

[Joshua Drake]

On Wed, 24 Sep 2008 07:52:52 +0100
Simon Riggs [EMAIL PROTECTED] wrote:

  Just as an FYI, by far the number one bottle neck on the multiple
  work restores I was doing was CPU. RAM and IO were never the
  problem.
 
 It would be useful to see a full breakdown of those results.

Its in the archives. We had a ginormous discussion about it about 6
months back (-hackers).

Joshua D. Drake

-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)

[Joshua Drake]

On Wed, 24 Sep 2008 11:58:58 -0400
Tom Lane [EMAIL PROTECTED] wrote:

 The objection comes down to this: it's an extremely large, invasive,
 and probably performance-losing patch, which apparently will be of use
 to only a rather small set of people.  It's not unreasonable to
 discuss just how large that set might be while we debate whether to
 accept the patch.

I know of no one that really uses SELinux because it is a nightmare. On
the other hand, this type of security is required to get into certain
scary tin foil hat producing institutions.

Do we want want to target those respective types of installs. If so,
then we have no choice but to try and make this patch (or similar)
work. If not, then I believe it is entirely too large of a change to
even bother with.

Now and this I think would be a first for PostgreSQL and something that
may cause more trouble than it is worth but we could do:

./configure --enable-selinux # Experimental

And if we find it doesn't work out, we rip it out. Yes, it is a lot of
work. A great many of our community will not participate on this list
and thus will not speak up to the (perceived) considerable demand for
this type of feature. The fact that the gentlemen who wrote the patch
kept it up to date and improved it over two release cycles suggests
that there is significant interest in this somewhere.

Joshua Drake


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Proposal of SE-PostgreSQL patches (for CommitFest:Sep)

[Joshua Drake]

On Wed, 24 Sep 2008 11:38:36 -0700
Josh Berkus [EMAIL PROTECTED] wrote:

 Peter,
 
  Yeah, but do we even have the slightest bit of information about
  what exactly would be required to achieve the required levels?  And
  whether this patch does it?  And whether there would be
  alternative, more desirable ways to achieve a similar level?
 
 Actually, I have some direct communication that SEPostgres will lead
 to PostgreSQL being widely adopted in at least one US government
 agency. Can't say more, of course.  ;-)

/me notes his tin foil hat argument.

Joshua D. Drake

 
 --Josh
 


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Where to Host Project

[Joshua Drake]

On Mon, 22 Sep 2008 19:08:16 +0200
Stefan Kaltenbrunner [EMAIL PROTECTED] wrote:

  OK, cool. Stefan; what's your take on where we're at?
 
 yeah there is a box and a jail I set up a while ago but for various 
 reasons the actual migration (planning and testing) never happened.
 I'm still prepared to handle the required sysadmin level work but I 
 don't have time for anything more fancy right now.

I think one problem we have right now, is nobody knows what it is going
to take. I would expect that our current version is sufficiently old
enough to cause some migration pain?

I know we have two members willing to help that are not Stefan and I.
Which is good, but this doesn't appear to be a small project.

Joshua D. Drake



 
 
 
 Stefan
 


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] parallel pg_restore

[Joshua Drake]

On Tue, 23 Sep 2008 09:14:33 +0200
Stephen R. van den Berg [EMAIL PROTECTED] wrote:

 Joshua D. Drake wrote:
 Andrew Dunstan wrote:
 There are in fact very few letters available, as we've been fairly 
 profligate in our use of option letters in the pg_dump suite.
 
 j and m happen to be two of those that are available.
 
 --max-workers
 
 Perhaps, but please do not use that as justification for using -m.
 That would be equally silly as abbreviating number of workers to -n.

Actually I came up with it because it coincides with existing
terminology. Autovacuum has the concept of max_workers.

Joshua D. Drake

-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] parallel pg_restore

[Joshua Drake]

On Tue, 23 Sep 2008 08:44:19 +0100
Simon Riggs [EMAIL PROTECTED] wrote:

 
 On Mon, 2008-09-22 at 15:05 -0400, Andrew Dunstan wrote:
 
  j and m happen to be two of those that are available.
  
  I honestly don't have a terribly strong opinion about what it
  should be called. I can live with jobs or multi-threads.
 
 Perhaps we can use -j for jobs and -m for memory, so we can set memory
 available across all threads with a single total value.
 
 I can live with jobs or multi-threads also, whichever we decide.
 Neither one is confusing to explain.
 

Memory? Where did that come from. Andrew is that in your spec?

Joshua D. Drake


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] parallel pg_restore

[Joshua Drake]

On Tue, 23 Sep 2008 16:50:43 -0400
Andrew Dunstan [EMAIL PROTECTED] wrote:

 
 
 Simon Riggs wrote:
  On Tue, 2008-09-23 at 12:43 -0700, Joshua Drake wrote:

  On Tue, 23 Sep 2008 08:44:19 +0100
  Simon Riggs [EMAIL PROTECTED] wrote:
 
  
  On Mon, 2008-09-22 at 15:05 -0400, Andrew Dunstan wrote:
 

  j and m happen to be two of those that are available.
 
  I honestly don't have a terribly strong opinion about what it
  should be called. I can live with jobs or multi-threads.
  
  Perhaps we can use -j for jobs and -m for memory, so we can set
  memory available across all threads with a single total value.
 
  I can live with jobs or multi-threads also, whichever we decide.
  Neither one is confusing to explain.
 

  Memory? Where did that come from. Andrew is that in your spec?
  
 
  No, but it's in mine. As I said upthread, no point in making it more
  parallel than memory allows. Different operations need more/less
  memory than others, so we must think about that also. We can
  quickly work out how big a table is, so we can work out how much
  memory it will need to perform sorts for index builds and thus how
  many parallel builds can sensibly take place.
 

 
 If that ever happens it will certainly not be in this go round.
 
 In fact, we have some anecdotal evidence that the point of dimishing 
 returns is not reached until a fairly high degree of parallelism is
 used (Joshua's and my client has been using 24 threads, I believe).

Against 8 cores but yes.

Joshua D. Drake

-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] parallel pg_restore

[Joshua Drake]

On Mon, 22 Sep 2008 17:24:28 +0100
Simon Riggs [EMAIL PROTECTED] wrote:

  More importantly, I'm not convinced it's a good idea. It seems more
  like a footgun that will potentially try to launch thousands of
  simultaneous restore connections. I should have thought that
  optimal performance would be reached at some small multiple (say
  maybe 2?) of the number of CPUs on the server. You could achieve
  unlimited parallelism by saying something like --jobs=9, but
  I'd rather that were done very explicitly instead of as the default
  value of the parameter.
 
 OK, sounds best.
 

I will not argue vehemently here but I will say that jobs doesn't
seem correct. The term workers seems more appropriate.

Sincerely,

Joshua D. Drake

-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Where to Host Project

[Joshua Drake]

On Fri, 19 Sep 2008 11:05:36 -0700
David E. Wheeler [EMAIL PROTECTED] wrote:
 
* LaunchPad
 
  does not offer svn or git, and i think they dont offer a home page  
  service
 
 It uses Bazaar. WTF is that? I've never heard of it.

Another git/mecurial/monotone style SCM. It does however allow
interaction with things like remote git and svn repos :)

Joshua D. Drake

-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PostgreSQL future ideas

[Joshua Drake]

On Fri, 19 Sep 2008 21:54:53 +0200
Gevik Babakhani [EMAIL PROTECTED] wrote:

 
 Dear PG hackers,
 
 Has there been any idea to port PG to a more modern programming
 language like C++? Of course there are some minor obstacles like a
 new OO design, this being a gigantic task to perform and rewriting
 almost everything etc... I am very interested to hear your opinion.
 
 (You can take your M16 and start shooting now)

No shooting required, your email client reached out and killed you when
you hit send.

Joshua D. Drake

 
 Regards,
 Gevik
 
 


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PostgreSQL future ideas

[Joshua Drake]

On Fri, 19 Sep 2008 23:01:15 +0200
Gevik Babakhani [EMAIL PROTECTED] wrote:

 Unless I am very off. C++ is a natural choice when porting
 (upgrading) ANSI C application.
 As far as I know, most universities teach some sort of OO programming
 language like JAVA or C# to help students understand OO programming.
 I understand that C++ is less popular but JAVA/C# would be the wrong
 choice for this.

I think the better question about all of this is:

What is the problem we are trying to solve?

Providing solutions that are looking for problems doesn't help us.

Sincerely,

Joshua D. Drake


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Where to Host Project

[Joshua Drake]

On Thu, 18 Sep 2008 11:22:14 -0700
David E. Wheeler [EMAIL PROTECTED] wrote:

* LaunchPad 


Is backed by PostgreSQL. It is the only logical choice :). Seriously
though it is a good service.

Joshua D. Drake


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Do we really need a 7.4.22 release now?

[Joshua Drake]

On Thu, 18 Sep 2008 16:57:19 -0700
Ron Mayer [EMAIL PROTECTED] wrote:

 (c) are secretly praying for an excuse
 to upgrade anyway.

heh

-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Better auth errors from libpq

[Joshua Drake]

On Thu, 11 Sep 2008 22:59:40 -0400
Tom Lane [EMAIL PROTECTED] wrote:

  psql: FATAL:  Ident authentication failed for user root
  HINT:  Is pg_hba.conf set properly on the server?
 
 Seems pretty useless.  What does set properly mean?  There isn't
 even any good reason to think that the solution to most auth failures
 is to change pg_hba.conf, so I'd bet that this hint is wrong far more
 often than it's right.

I think something like:

psql: FATAL:  Ident authentication failed for user root
HINT: http://www.postgresql.org/docs/8.3/static/client-authentication.html

Would be nice. Heck in most modern terminals the HINT would be
clickable too :)

Sincerely,

Joshua D. Drake
-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Cleanup of GUC units code

[Joshua Drake]

On Mon, 8 Sep 2008 10:32:40 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:

 Gregory Stark wrote:
  Greg Sabino Mullane [EMAIL PROTECTED] writes:
  
   Tom Lane wrote:
   My vote is to reject the patch and work on a config checker.
  
   +1

+1

Joshua D. Drake


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] reducing statistics write overhead

[Joshua Drake]

On Fri, 05 Sep 2008 15:23:18 -0400
Tom Lane [EMAIL PROTECTED] wrote:

 Martin Pihlak [EMAIL PROTECTED] writes:
  So, as a simple optimization I am proposing that the file should be
  only written when some backend requests statistics. This would
  significantly reduce the undesired write traffic at the cost of
  slightly slower stats access.
 
 How necessary is this given the recent fixes to allow the stats file
 to be kept on a ramdisk?

From an usability and integration perspective this patch is a nice
touch. On demand is a nice feature when used correctly.

Sincerely,

Joshua D. Drake

-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Cleanup of GUC units code

[Joshua Drake]

On Wed, 03 Sep 2008 18:32:16 +0300
Hannu Krosing [EMAIL PROTECTED] wrote:

  We have had this discussion before, I even submitted a patch to
  make them case insensitive. In retrospect I was wrong to submit
  that patch. SQL may be case insensitive but units are not. MB !=
  Mb != mb , 
 
 For most people they are equal, and all mean MEGABYTE(S) though
 http://en.wikipedia.org/wiki/MB has lots of other possible meanings
 for each.

O.k. there is an interesting point being made here, For most people.

Which people exactly? Are we talking about the general populous? If so
I would argue that most people don't have a clue what MB, Mb, or mb
is except to say I think that means some kind of speed or capacity.

The above is not our target.

If our definition of most people is, those who are reasonably
technically adept and will be deploying PostgreSQL in production on
some level.

If someone doesn't know the difference between Mb and MB on a
production system, I would not want them anywhere near any instance of
a production system.

If we are going to make sweeping statements (anyone on this thread)
about user-hostile and most people, then we better define what those
mean. This whole argument about making something easier (and incorrect)
for someone who doesn't exist and has not been defined.

I would be hung on this list if I made a similar argument about any
other feature.

 
  I don't think we should encourage in any way for users to do the
  wrong thing.
 
 Can you see any scenario where accepting case insensitive units does
 more damage than just ignoring the conf line with incorrect casing ?

Generally speaking, no I can't think of any damage that could be done
from mixed casing. Especially since we would only accept certain
possibilities, e.g; Mb would equal MB.

It just strikes me as really bad that a project that prides itself on
doing it right is willing to make this type of sacrifice. This isn't
about usability. This is about doing it wrong and actively encouraging
our users that wrong is ok. It could also misinform the user about
what the meaning of the value means.

 
 Or do you mean we should discourage people from editing
 postgresql.conf manually and have them use some tool which prevents
 them entering kb ?

Well that is a whole other argument :P. I would be happy to have that
one on another thread.

Sincerely,

Joshua D. Drake

-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Cleanup of GUC units code

[Joshua Drake]

On Wed, 3 Sep 2008 19:36:19 +0100
Greg Stark [EMAIL PROTECTED] wrote:

 Sure if people want to do it the right way more power to them. What  
 you're talking about is punishing people when they don't live up to  
 your standards.

I think I will defer to Andrew and Alvaro's opinion on the matter.

Sincerely,

Joshua D. Drake


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [patch] GUC source file and line number]

[Joshua Drake]

On Wed, 3 Sep 2008 16:04:12 -0400 (EDT)
Greg Smith [EMAIL PROTECTED] wrote:


 Section question:  with those changes, would it then be reasonable to
 you to keep that column named default instead of giving it a less
 common name?
 
  You are adopting a very narrow mindset, which seems to be that only
  DBAs look at this view.
 
 DBAs are the only group I am always getting questions in this area
 from. Everybody else seemed happy with the status quo, where the
 value wasn't exposed at all and you just looked in guc.c to see what
 it was.

I guess I would ask, Who else would we be targeting this for?. DBAs
seem to be the only logical choice.

Joshua D. Drake
-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Cleanup of GUC units code

[Joshua Drake]

On Wed, 03 Sep 2008 23:10:24 +0300
Hannu Krosing [EMAIL PROTECTED] wrote:

  That would equally solve
  this problem, as well as many others.
 
 AFAIK the config file is checked now, and if the check fails, the
 database won't start.

Like apachectl configcheck ... E.g; we have the ability to check if the
config file is valid before we restart and have an extended outage.

Joshua D. Drake

 
 -
 Hannu
 
 


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Cleanup of GUC units code

[Joshua Drake]

On Thu, 04 Sep 2008 01:26:44 +0300
Hannu Krosing [EMAIL PROTECTED] wrote:

 So Andrews opinion was that Mb (meaning Mbit) is different from MB
 (for megabyte) and that if someone thinks that we define shared
 buffers in megabits can get confused and order wrong kind of network
 card ?

I was actually referring to:

http://archives.postgresql.org/pgsql-hackers/2008-09/msg00206.php

Sincerely,

Joshua D. Drake

-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Proposal: new border setting in psql

[Joshua Drake]

On Fri, 29 Aug 2008 11:23:50 -0500
Jaime Casanova [EMAIL PROTECTED] wrote:

 On Fri, Aug 29, 2008 at 8:45 AM, D'Arcy J.M. Cain [EMAIL PROTECTED]
 wrote:
 
  I'm surprised that we don't have a general option to escape special
  characters.  Perhaps that's the next small enhancement.
 
  darcy=# \pset escape \
 
 
 this looks like we are trying to make cosmetic magic instead of solve
 the real problem...
 what about the idea someone propose of having output formats hooks...
 seems more reasonable to me
 

I am trying to understand why we are having a client do this? If you
want some other type of output, script it.

Joshua D. Drake

-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] can't stop autovacuum by HUP'ing the server

[Joshua Drake]

On Tue, 26 Aug 2008 12:58:59 -0400
Dave Cramer [EMAIL PROTECTED] wrote:

 
 Well, I'm willing to help debug this, however this is a busy
 production database and I need to be able to turn it off for a few
 hours a day. Would changing autovacuum_freeze_max_age be a solution ?

Populate the table pg_autovacuum with all your relations and the
defaults from the postgresql.conf. Then set enabled to FALSE on all the
tuples. When you are ready to turn autovacuum back on, set it to TRUE.

Joshua D. Drake



-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] initdb change

[Joshua Drake]

On Mon, 25 Aug 2008 08:40:17 -0700
David Fetter [EMAIL PROTECTED] wrote:

 Folks,
 
 While initdb allows you to choose a directory for transaction logs, it
 can't already exist, so it can't be in its usual place under $PGDATA.
 I'd like to propose that this be allowed by having an alternate syntax
 for the -X option, namely, existing.
 
 When -X is set to existing, it would check whether pg_xlog is a
 directory and the only thing in $PGDATA.  One way to do that is to add
 a new return code to check_data_dir() and a new branch of the case
 statement after it's called.
 


Why not just implicitly do it? If the directory already exists we throw
a notice saying:

NOTICE: pg_xlog destination already exists, creating pg_xlog underneath
(or some such thing)

 What say?
 
 Cheers,
 David.


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] initdb change

[Joshua Drake]

On Mon, 25 Aug 2008 09:04:01 -0700
David Fetter [EMAIL PROTECTED] wrote:

   When -X is set to existing, it would check whether pg_xlog is a
   directory and the only thing in $PGDATA.  One way to do that is to
   add a new return code to check_data_dir() and a new branch of the
   case statement after it's called.
  
  Why is this useful?  It seems like just extra complication.

At no time should I ask I DBA to do this:

service postgresql stop
mv /var/lib/pgsql/data/pg_xlog /xlogs/pg_xlog
ln -sf /xlogs/pg_xlog /var/lib/pgsql/data/pg_xlog
service postgresql start

We either need to provide a way to initialize it at initdb, allow
xlogs to be in table space or add a GUC for the location.

Sincerely,

Joshua D. Drake

-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] initdb change

[Joshua Drake]

On Mon, 25 Aug 2008 09:42:21 -0700
David Fetter [EMAIL PROTECTED] wrote:

  We either need to provide a way to initialize it at initdb, allow
  xlogs to be in table space or add a GUC for the location.
 
 There's already a way to specify where xlogs should be via
 -X/--xlogdir. 

Sorry should have checked 8.3 initdb instead of 8.2.

 What that doesn't do is put the xlogdir where a DBA
 would naturally expect to find it.  When that DBA doesn't find it in
 the place they expect, very bad knock-on decisions are likely to
 result.

O.k. when using 8.3 I did this:

initdb -D /tmp/foo -X /tmp/xlogs

And I got:

/tmp/foo/pg_xlog which is a link to /tmp/xlogs

That seems perfectly logical. If I (without removing the old initdb) do
this:

/usr/lib/postgresql/8.3/bin/initdb -D /tmp/bar -X /tmp/xlog

I get:

initdb: directory /tmp/xlog exists but is not empty
If you want to store the transaction log there, either
remove or empty the directory /tmp/xlog.
initdb: removing data directory /tmp/bar

I just reread your original message a little slower and see that what
you want is if:

/var/lib/pgsql/data/ exists but is empty you can initdb within that
directory. However if there is anything in it you can not. You are
asking that if pg_xlog exists but is empty that we still be able to use
the DATADIR and you can pass existing so that it will also use pg_xlog
if it is empty.

My take would be to not add a new flag. Instead to implicitly allow it.
If initdb finds that DATADIR and pg_xlog is empty it will use both. 


Sincerely,

Joshua D. Drake








 
 Cheers,
 David.


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] initdb change

[Joshua Drake]

On Mon, 25 Aug 2008 10:12:03 -0700
David Fetter [EMAIL PROTECTED] wrote:

  /var/lib/pgsql/data/ exists but is empty you can initdb within that
  directory. However if there is anything in it you can not. You are
  asking that if pg_xlog exists but is empty that we still be able to
  use the DATADIR and you can pass existing so that it will also use
  pg_xlog if it is empty.
  
  My take would be to not add a new flag. Instead to implicitly allow
  it. If initdb finds that DATADIR and pg_xlog is empty it will use
  both. 
 
 Is there some reason why initdb shouldn't just Do The Right Thing™
 when it finds an empty extant $PGDATA/pg_xlog directory that passes
 the same tests an empty extant $PGDATA would?

That is what I was suggesting.

Joshua D. Drake

 
 Cheers,
 David.


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] initdb change

[Joshua Drake]

On Mon, 25 Aug 2008 13:56:16 -0400
Andrew Dunstan [EMAIL PROTECTED] wrote:
 
 
  That is what I was suggesting.
 
  
 
 Why should the xlog directory be treated specially?

Consider the following:

mount /dev/sda1 /var/lib/pgsql
mount /dev/sdb1 /srv1/pgsql/pg_xlog (which has a link
from /var/lib/pgsql/data/pg_xlog)

initdb -D /var/lib/pgsql/data -X /var/lib/pgsql/data/pg_xlog

Will fail; now you have multiple steps to get everything where it
should be.


 We don't do this
 for any other subdirectory of PGDATA. The extra logic would be a

Well the only other directory it would even matter for would be pg_clog
(maybe). I grant that it is a very little feature that could be lived
without.

 nuisance and for no great gain in functionality that I can see.
 

In an environment where you are provisioning many spindle machines over
many differently mounts and raid configurations it could be useful. The
question is; is it worth it? I don't know. I was just trying to
understand exactly what David was talking about and offer some
suggestions.

 This whole discussion springs from a misconception apparently, so
 let's just move on.

Well that pretty much describes life doesn't it? :)

Sincerely,

Joshua D. Drake




-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Implementing cost limit/delays for insert/delete/update/select

[Joshua Drake]

On Mon, 25 Aug 2008 22:39:54 +0100
Gregory Stark [EMAIL PROTECTED] wrote:
 
 But I think we should consider removing the {auto,}vacuum_cost_delay
 parameter or at least hiding and undocumenting it. It's a foot-gun
 and serves no useful purpose that merely lowering the
 {auto,}vacuum_cost_limit can't serve equally well.

I thought we were already considering some kind of IO tweak for Vacuum,
e.g; you may use up to 5Mb/s or something like that?

Sincerely,

Joshua D. Drake
-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [FINALLY] the TODO list has migrated to Wiki

[Joshua Drake]

On Fri, 22 Aug 2008 14:28:57 -0300
Euler Taveira de Oliveira [EMAIL PROTECTED] wrote:

 Hi,
 
 While we're on this topic, I think we need put a link at [1] heading
 directly to (Official) Todo [2]. What we have ATM is Unofficial Todo
 Detail that is rather inconsistent. We should rename it to Todo
 Detail. Comments?
 
 [1] http://wiki.postgresql.org/wiki/Development_information
 [2] http://wiki.postgresql.org/wiki/Todo
 
 

To my knowledge we do not have an Official Todo.

Joshua D. Drake

-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] A smaller default postgresql.conf

[Joshua Drake]

On Wed, 20 Aug 2008 15:49:39 -
Greg Sabino Mullane [EMAIL PROTECTED] wrote:

 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: RIPEMD160

 Sure, why not? Clarity should always trump brevity. The only people
 who gain from a comment-less file are the ones who are already expert
 in it.

You are right, Clarity always trumps brevity but then again, some
things are only clear if they are brief. Point being, the
documentation in the postgresql.conf isn't really useful and to make it
useful; would make the configuration file itself not useful. A succinct
file with directed links that are explicitly telling you, Don't be
stupid read the docs is a very good idea.

 
 To add some more fuel to the fire, are those in the no-comments,
 bare-bone camp going to argue for cleaning up pg_hba.conf as well?
 

Well I would. I find the pg_hba.conf obnoxious. Especially if we pushed
the documentation to a man page and windows help. 

Sincerely,

Joshua D. Drake



-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [pgsql-www] [FINALLY] the TODO list has migrated to Wiki

[Joshua Drake]

On Wed, 20 Aug 2008 13:12:15 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:


 The move has been approved by Bruce, the current maintainer.  I hope
 that he continues to maintain the new version.

This is great! I only have one small request. The font is really small
and I have pretty good eyesight.

Joshua D. Drake


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [pgsql-www] [FINALLY] the TODO list has migrated to Wiki

[Joshua Drake]

On Wed, 20 Aug 2008 10:53:57 -0700
David Fetter [EMAIL PROTECTED] wrote:


  This is great! I only have one small request. The font is really
  small and I have pretty good eyesight.
 
 Fixed :)

Much better, thanks!

Joshua D. Drake

 
 Cheers,
 David.


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] A smaller default postgresql.conf

[Joshua Drake]

On Tue, 19 Aug 2008 17:11:49 +0200
Magnus Hagander [EMAIL PROTECTED] wrote:

 Alvaro Herrera wrote:
  Hans-Juergen Schoenig wrote:
  
  alternatively we could use some sort of #include mechanism to
  split most important and not so important.
  
  We already have an include mechanism.
 
 Using that to include a file that's full of comments anyway (which is
 all that's left in postgresql.conf at this time, I'm sure) just seems.
 Well. Sub-optimal.

Yes but part of this idea is valid. The fact is the majority of the
postgresql.conf parameters don't need to be in there by default. It
just makes the file an intimidating mess for newbies and I am not
talking about just n00bs but also people coming from other environments
such as MSSQL.

I believe we could probably break the conf down to a reasonable 2 dozen
or less parameters. The rest should just be documented in our
documentation and call it good. We even have static URLs for this (I
seem to have dejavu with this as I am pretty sure I have had this
discussion already).

Joshua D Drake


 
 
 //Magnus
 


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Patch: plan invalidation vs stored procedures

[Joshua Drake]

On Tue, 19 Aug 2008 12:48:06 +0100
Gregory Stark [EMAIL PROTECTED] wrote:

 Hannu Krosing [EMAIL PROTECTED] writes:
 
  Maybe there should be something in postgreSQL docs that warns users
  against using functions in any non-trivial circumstances, as
  functions are not expected to behave like the rest of postgreSQL
  features and there is not plan to fix that ?
 
 Now who's trolling :)

Although I read his remark as sarcastic after reading the entire
thread I have to say it may be a good idea to have the something in
the docs about the limitation. I never think about it anymore
because I am used to the behavior. I can see where and entity
like skype who has I am sure thousands of procedures would have this
as a constant irritant.

Do I think it should be pushed back to 8.3.x; no. It is a feature. I
don't consider the existing behavior a bug. I consider it a limitation
and we don't back patch fixes for limitations. 

Sincerely,

Joshua D. Drake


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] A smaller default postgresql.conf

[Joshua Drake]

On Tue, 19 Aug 2008 12:12:16 -0400
Tom Lane [EMAIL PROTECTED] wrote:

 Joshua Drake [EMAIL PROTECTED] writes:
  Magnus Hagander [EMAIL PROTECTED] wrote:

  Yes but part of this idea is valid. The fact is the majority of the
  postgresql.conf parameters don't need to be in there by default. It
  just makes the file an intimidating mess for newbies and I am not
  talking about just n00bs but also people coming from other
  environments such as MSSQL.
 
 Well, why not just make a one-eighty and say that the default
 postgresql.conf is *empty* (except for whatever initdb puts into it)?

I guess it would depend on what initdb puts into it. I don't really
have a problem ripping out all extra stuff as it would help force
people to read the docs but would we still have 150 parameters?. From a
friendly perspective it would make sense to tone it down to the key
parameters such as shared_buffers, listen_address, work_mem etc... 

We don't need (for example) to have autovacuum in there by default as it
is always on and configured reasonably at this point. If they need to
change autovacuum they should be reading the docs about it first;
the same with bgwriter, fsync, async_commit etc...

 I've never thought that the current contents were especially useful
 as documentation; the kindest thing you can say about 'em is that they
 are duplicative of the SGML documentation.  For novices they aren't
 even adequately duplicative.

I can't argue with this. :)

Sincerely,

Joshua D. Drake



-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] A smaller default postgresql.conf

[Joshua Drake]

On Tue, 19 Aug 2008 12:48:20 -0400
Tom Lane [EMAIL PROTECTED] wrote:

 Joshua Drake [EMAIL PROTECTED] writes:
  Tom Lane [EMAIL PROTECTED] wrote:
  Well, why not just make a one-eighty and say that the default
  postgresql.conf is *empty* (except for whatever initdb puts into
  it)?
 
  I guess it would depend on what initdb puts into it.
 
 Per the code:
 
 max_connections
 shared_buffers
 max_fsm_pages (slated to die anyway in 8.4)
 lc_messages
 lc_monetary
 lc_numeric
 lc_time
 datestyle
 default_text_search_config
 
 The first three of those are derived from probing the SHMMAX setting,
 and the rest are from the initdb-time locale settings.

When I first started to reply I had a list of another dozen or so we
should add but in reality as I think about it; we need only one more
parameter. If we add listen_addresses and a link to the documention for
the rest, I would +1 this.

I was thinking about the apache conf and it is riddled with
documentation, lots and lots of text. I find that either I am irritated
with how much documentation there is (because I already understand the
directive I am working with) or I am frustrated because it doesn't
adequately explain the dependencies.

If we move to the above route, we end up in an environment with a
single source for official documentation and we can always point to
that.

Sincerely,

Joshua D. Drake


 
   regards, tom lane
 


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] A smaller default postgresql.conf

[Joshua Drake]

On Tue, 19 Aug 2008 13:22:34 -0400
Tom Lane [EMAIL PROTECTED] wrote:
 
 I'm really not in favor of having comments in the conf file that try
 to tell you about stuff you might want to set, much less why.  That
 task properly belongs to some kind of introductory chapter in the
 SGML docs. Novice DBAs are unlikely even to *find* the config file,
 let alone look inside it, if there's not an introductory chapter
 telling them about Things They Ought To Do.

I would be willing to work up a patch that does as you suggest.

Sincerely,

Joshua D. Drake



-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] A smaller default postgresql.conf

[Joshua Drake]

On Tue, 19 Aug 2008 12:17:46 -0500
Kevin Grittner [EMAIL PROTECTED] wrote:

 Well, this sure looks scary:
  
 # maintenance_work_mem = 256MB  #webserver with 2GB RAM

I would agree. 2GB isn't that much memory as it is and that is a fairly
heft amount of maintenance_work_mem. This isn't the days when vacuum
ran via cron at 2am anymore. Autovacuum will fire at any time.

  
 But I'm amazed by this, too:
  
 # max_connections = 700  # web application database
  
 How many CPUs and spindles are you assuming there?
  
 My testing and experience suggest applications should use no more than
 4 per CPU plus 2 per spindle, absolute maximum.  Don't you find that a
 connection pool with queuing capability is required for best
 performance with a large number of users?

I just did the math on this and I would say you are correct. I had
never really evaluated in the way you just had but based on some of our
larger installs (32cores, 100 spindles) your math works.

Noting that he actually states it is a webserver connecting there
should absolutely be a pool in front of PostgreSQL.

Joshua D. Drake



-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Patch: plan invalidation vs stored procedures

[Joshua Drake]

On Tue, 19 Aug 2008 14:29:52 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:


  Do I think it should be pushed back to 8.3.x; no. It is a feature. I
  don't consider the existing behavior a bug. I consider it a
  limitation and we don't back patch fixes for limitations. 
 
 The bottom line here is that we don't have the time to explain or
 justify our backpatch policy every time someone shows up with a bug
 that needs to be fixed.

Is our backpatch policy documented? It does not appear to be in
developer FAQ.

Joshua D. Drake


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] A smaller default postgresql.conf

[Joshua Drake]

On Tue, 19 Aug 2008 19:12:47 -
Greg Sabino Mullane [EMAIL PROTECTED] wrote:

 Ugh, you are heading in the wrong direction. The configuration file
 should be well documented: moving the documentation further away
 from it is the wrong idea, especially if it means firing up a web
 browser to do so.

It is impossible to document the postgresql.conf file in a manner that
is truly useful without firing up the reading material in the first
place.

Even with Josh's improvements there are too many variables and we are
just going to have a bunch of people breaking stuff and then
complaining that, well it was suggested in the postgresql.conf. 

 a URL
 for each config for example), but it's a great start. Text space is
 cheap, and having a consistent, well-documented, easy-to-read conf
 file is something worth shooting for.

I have yet to find one; anywhere.

Joshua D. Drake



-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Patch: plan invalidation vs stored procedures

[Joshua Drake]

On Tue, 19 Aug 2008 14:47:13 -0400
Tom Lane [EMAIL PROTECTED] wrote:

 Bruce Momjian [EMAIL PROTECTED] writes:
  Joshua Drake wrote:
  Is our backpatch policy documented? It does not appear to be in
  developer FAQ.
 
  Seems we need to add it.
 
 I'm not sure that I *want* a formal written-down backpatch policy.

Then we write a formal guideline. It really isn't fair to new developers
to not have any idea how they are going to be able to get a patch
applied to older branches. Something like:

Generally speaking we adhere to the following guideline for patches.
   * Security fixes are applied to all applicable branches.
   * Bugfixes are applied to all applicable branches
  * Note: A patch that addresses a known limitation is generally
not backpatched
   * New features are always applied to -HEAD only.

This is not a policy as much as a legend for developers to consider
before they submit their patch.

If we do this, we have the opportunity to just point to the FAQ when
there is no ambiguity. It also increases transparency of the process;
which is always a good thing.

Sincerely,

Joshua D. Drake



-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] A smaller default postgresql.conf

[Joshua Drake]

On Tue, 19 Aug 2008 15:43:11 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:

 Peter Eisentraut wrote:
  On Tuesday 19 August 2008 22:12:47 Greg Sabino Mullane wrote:
   moving the documentation further away from it is the wrong idea,
   especially if it means firing up a web browser to do so.
  
  I can see that argument, but I think we can quite simply solve it
  if we provide a plain-text version of the configuration chapter of
  the documentation.  You can easily grep that in a second window and
  don't have to be in-your-face to users who just want to edit the
  settings.
 
 Hmm, let me suggest providing it as a manpage for postgresql.conf,
 i.e., you run man postgresql.conf and it gives you this manpage
 documenting every option.

and native windows help (egad) but yes that would be good.

Joshua D. Drake 


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Patch: plan invalidation vs stored procedures

[Joshua Drake]

On Tue, 19 Aug 2008 16:22:43 -0400
Andrew Sullivan [EMAIL PROTECTED] wrote:

 A formal policy that's any more detailed than what's in the FAQ today
 is a solution in search of a problem.

Odd that the problem continues to rear its head though isn't it? This
certainly isn't the first time it has come up.  I have however made my
argument. I also tried to help solve the problem. If we aren't
interested in a solution, oh well. It doesn't make my life any harder.


Sincerely,

Joshua D. Drake


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] A smaller default postgresql.conf

[Joshua Drake]

On Tue, 19 Aug 2008 17:03:48 -0400
Tom Lane [EMAIL PROTECTED] wrote:

 Alvaro Herrera [EMAIL PROTECTED] writes:
  Peter Eisentraut wrote:
  I can see that argument, but I think we can quite simply solve it
  if we provide a plain-text version of the configuration chapter of
  the documentation.
 
  Hmm, let me suggest providing it as a manpage for postgresql.conf,
  i.e., you run man postgresql.conf and it gives you this manpage
  documenting every option.
 
 Seems a bit Unix-centric, but +1 for it on Unix machines anyway.
 Is there any near equivalent on Windows?

Yes there are Windows Help files. I would imagine the installer would
deal with that. Magnus would obviously know better than I.

Sincerely,

Joshua D. Drake

 
   regards, tom lane
 


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] A smaller default postgresql.conf

[Joshua Drake]

On Tue, 19 Aug 2008 23:32:34 -0400
Tom Lane [EMAIL PROTECTED] wrote:

 Bruce Momjian [EMAIL PROTECTED] writes:
  On idea is for postgresql.conf to merely include other files:
  include 'sharedmem.conf'
  include 'compat.conf'
  ...
 
 That would definitely add complexity ... what would it buy in return?

I am not arguing for this but if we went down that route it does buy us
the ability to compartmentalize the entire conf.. so you have:

memory_settings.conf
logging.conf
maintenance.conf

It is a bit of misdirection as people will open one conf to find a
bunch of pointers to others. 

Another option would be to break up the conf like the above but do not
include any of them in the main postgresql.conf (which is how I would
argue it should be done). Thus if you want to modify logging, you
include it in the postgresql.conf but you make your adjustments in
logging.conf. 

Sincerely,

Joshua D. Drake


 
   regards, tom lane
 


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] A smaller default postgresql.conf

[Joshua Drake]

On Wed, 20 Aug 2008 00:10:35 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:

  Another option would be to break up the conf like the above but do
  not include any of them in the main postgresql.conf (which is how I
  would argue it should be done). Thus if you want to modify logging,
  you include it in the postgresql.conf but you make your
  adjustments in logging.conf. 
 
 The problem then is that they modify the logging.conf file and then
 wonder why the change doesn't take effect.

Well we have that problem already :)

Joshua D. Drake 


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] PostgreSQL Conference: West - Call for Papers

[Joshua Drake]

The second annual PostgreSQL Conference: West is being held on October
10th through October 12th 2008 in the The Native American Student 
Community Center at Portland State University. 

We are currently accepting papers and you can submit your talks here:

http://www.postgresqlconference.org/west08/talk_submission/

We have already seen submissions on Tsearch2 as well as pgTap. Do you
have something you would like to share about PostgreSQL? Now is the
time!

This year West will be providing its proceeds to the Postgresql.us.

Joshua D. Drake


-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] How can I have 2 completely seperated databases in

[Joshua Drake]

Hello,

Depending on your needs and transaction load per database you can easily 
run 30 databases on a machine with 2 Gig of RAM. You will of course have 
to use initdb for each cluster and change the tcp port for each cluster 
but it works just fine.

Sincerely,

Joshua D. Drake



[EMAIL PROTECTED] wrote:
Thank you very much for your reply.

Yes, that's true. But it seems not a good idea if I have many databases
and I want them totally seperated with each other.
What's your opinion? Thanks.

--Hong Ge

Quoting Rod Taylor [EMAIL PROTECTED]:


On Wed, 2004-02-11 at 16:36, [EMAIL PROTECTED] wrote:

Hi, all

What should I do if I want to have 2 completely seperated databases
in

PostgreSQL? I want each database to have its own data, log and
everything needed to access that database. I don't want them to
share

anything. Has anyone done this before? Or,
could anyone give me some clue of how to do this?
You will need to initdb 2 locations and start 2 instances on separate
ports.




---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

begin:vcard
fn:Joshua Drake
n:Drake;Joshua
org:Command Prompt, Inc.
adr:;;P.O. Box 215;Cascade Locks;OR;97014;US
email;internet:[EMAIL PROTECTED]
title:Consultant
tel;work:503-667-4564
tel;fax:503-210-0334
note:Home of Mammoth PostgreSQL, and PostgreSQL Replicator.
x-mozilla-html:FALSE
url:http://www.commandprompt.com/
version:2.1
end:vcard


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