What about just calling the new database postgres by default?
For true newbies, the first thing that happens if you try just
running psql with no arguments is that you discover there's no
database named postgres. For most first-time users, I suspect the
postgres user is the super-user and
Pavel Stehule wrote:
DECLARE excpt EXCEPTION [= 'SQLSTATE']
What would this default to? (i.e. if no '= SQLSTATE' is specified)
Rules:
o User can specify SQLSTATE only from class 'U1'
o Default values for SQLSTATE usr excpt are from class 'U0'
Can you elaborate on what you mean?
o
Tom,
(I assume this *is* CVS tip, or near to it? The recent CRC32 and
omit-the-hole changes should affect the costs of this quite a bit.)
It was a recent build. When was CRC32 checked in?
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of
Andrew,
If people don't monitor the buildfarm then it isn't serving its purpose
of catching these things quickly.
Related to that , Spikesource has started their automated tests (which
currently include JDBC, php and phpPgAdmin as well as PostgreSQL). They have
a web services interface; I
Thomas,
What about just calling the new database postgres by default?
Hey, works for me. A great idea really.
H except ... on BSD platforms, due to history with Ports, the
superuser is pgsql. Fortunately, the BSDs only account for a small
minority of new users, so we could just
Josh Berkus josh@agliodbs.com writes:
(I assume this *is* CVS tip, or near to it? The recent CRC32 and
omit-the-hole changes should affect the costs of this quite a bit.)
It was a recent build. When was CRC32 checked in?
The latest omit-the-hole change went in 2005-06-06 16:22 (EDT), so
Josh Berkus wrote:
Andrew,
If people don't monitor the buildfarm then it isn't serving its purpose
of catching these things quickly.
Related to that , Spikesource has started their automated tests (which
currently include JDBC, php and phpPgAdmin as well as PostgreSQL). They
Tom Lane wrote:
Hm, notice that the processor utilization doesn't actually drop all that
much, so it seems it's not fundamentally an I/O storm kind of issue.
If I read the chart on the bottom of Josh's links correctly,
it looks to me like
the fast one is spending 50% CPU in user and 30% CPU
-Original Message-
From: [EMAIL PROTECTED] on behalf of Andreas Pflug
Sent: Sun 6/19/2005 12:23 AM
To: Tom Lane
Cc: Robert Treat; Magnus Hagander; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [PATCHES] default database creation with initdb
This contradicts my intention to have
Tom Lane wrote:
Josh Berkus josh@agliodbs.com writes:
(I assume this *is* CVS tip, or near to it? The recent CRC32 and
omit-the-hole changes should affect the costs of this quite a bit.)
It was a recent build. When was CRC32 checked in?
The latest omit-the-hole change went in
Oleg Bartunov wrote:
On Wed, 15 Jun 2005, Stefan Kaltenbrunner wrote:
Teodor Sigaev wrote:
btree manages to avoid calling the index support functions during WAL
restore --- can't you do the same? Perhaps you need to be including
more information in the initial xlog records, so that the
Andrew,
Er, who?
www.spikesource.com. Also see my announcement to this list last Thursday.
What are they testing and how? How often?
Regression tests on PostgreSQL, their own php tests on phpPgAdmin, and
standard JDBC test on pgJDBC.
Tests are based on when there have been submissions to
Josh Berkus wrote:
I am expecting that for the most part people will want the lists of
state changes, rather than the lists of all builds or failures. Will
Spikesource tests track state changes?
They'd like to. CVS makes this kind of challenging.They'd be happy to
have
Dave Page wrote:
Whether or not users should write to the default db is another issue
altogether, and one that I'd rather not see causing this idea to be
rejected or get delayed past freeze.
+1
If 'default' is writeable, then
so what if users use it? It won't stop pgAdmin from working,
Andrew Dunstan wrote:
all: every build status received
failures: every non-OK build status received
all_changes: every time status changes
green_changes: every time status changes to/from OK
The digest mailing lists for these notifications are now alive.
Corresponding subscription
Josh Berkus josh@agliodbs.com writes:
What about just calling the new database postgres by default?
Hey, works for me. A great idea really.
Yeah, that seems like a pretty good compromise to me too. I was
thinking last night that we'd end up with documentation statements
like you connect to
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
FYI: we now have at least 4 machines(otter,kingfisher,lionfish,corgi) on
the buildfarm crashing during testing of GIST-related things in contrib.
I'm seeing some problems on Mac OS X, too. The tsearch regression test
crashed ... which we may not
I wrote:
I'm seeing some problems on Mac OS X, too. The tsearch regression test
crashed ... which we may not care about much since tsearch is presumably
going away ... but after that, the postmaster failed to restart:
I tried it again to check that it was reproducible. The tsearch test
Andreas Pflug [EMAIL PROTECTED] writes:
Can't tell whether I could find time for reviewing the docs the next
days (more interesting for feature freeze is having fixed the
implementation anyway).
Of the sixty-odd files that mention template1 in current CVS, only about
half are documentation.
19 matches
Mail list logo
