On Thu, Jul 21, 2005 at 02:38:51PM +1000, Jamie Deppeler wrote:
I am doing it right
/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
How are you determining that no user is being created? What are
you doing and what's the exact error message?
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
I guess the next obvious question is why do you think there isn't a
user? What is the error message ?
Dave
On 21-Jul-05, at 12:38 AM, Jamie Deppeler wrote:
I am doing it right
/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
Thomas F. O'Connell wrote:
Do you already have a postgres
Hi, All
I am preparing to enhance the pg_resetlog to support recover corrupted pg_control data from WAL. I had finised the code now and testing it, but before I bring it out for patch review, I want to discuss some issues here to get some advice.
The functionality of reset the xlog is the same
Thomas F. OConnell said:
Do you already have a postgres user on the system? And do you mean
that initdb is not creating a postgres user in the database?
Presumably, if run as the user that will own the server process, it
should create that user in the database as well.
Andrew Dunstan wrote:
2. initdb will only create one user, as specified by -U and defaulting to
the name of the user running initdb. Thus it will only ever create a user
called postgres if '-U postgres' is specified, or
if -U is not used and the user running initdb is called postgres.
I cant contribute with any
technical advice, but as a user I had to resort to using pg_resetxlog few times.
I wonder if it is possible to make it more
user-friendly. It was never clear to me whether it was sufficient to run it
without any arguments, and if not what these
arguments should
pgman wrote:
Marc G. Fournier wrote:
On Thu, 21 Jul 2005, Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
#define DAYS_PER_YEAR 365.25
#define MONTHS_PER_YEAR 12
#define DAYS_PER_MONTH 30
#define HOURS_PER_DAY 24
Considering that only
I've been looking into fixing the --enable-thread-safety option on
Windows.
At the moment, we have some simple pthread emulation that may be used in
libpq if --enable-thread-safety is used. The Makefile is slightly
broken,
however this should be easy to fix (properly) for someone more
proficient
yuanjia lee [EMAIL PROTECTED] writes:
The algorithm of searching the WAL is like this:
1. Read name of the segment files from xlog directory, and put all of
their name into an one way list, the list is descending according to the time
line, xlog id, segement id. (Athough I use only the
On Thu, Jul 21, 2005 at 09:39:38 -0400,
Bruce Momjian pgman@candle.pha.pa.us wrote:
I have added this comment above the DAYS_PER_MONTH macro:
+ /*
+ *DAYS_PER_MONTH is very imprecise. The more accurate value is
+ *365.25/12 = 30.4375, or '30 days 10:30:00'.
Bruno Wolff III [EMAIL PROTECTED] writes:
On Thu, Jul 21, 2005 at 09:39:38 -0400,
Bruce Momjian pgman@candle.pha.pa.us wrote:
Let me add that we could actually do this in many places now because we
are already converting to 'time' in those places. Is this a TODO?
Shouldn't you be using
Another problem with this patch is the search-and-replace substitution
of SECS_PER_MINUTE for 60, when in point of fact there are two
different meanings of 60 in this context. For instance, this
code has no problem:
! int Log_RotationAge = 24 * 60;
but this code looks like it
Am Donnerstag, den 21.07.2005, 10:48 -0400 schrieb Tom Lane:
Another problem with this patch is the search-and-replace substitution
of SECS_PER_MINUTE for 60, when in point of fact there are two
different meanings of 60 in this context. For instance, this
code has no problem:
! int
Bruno Wolff III wrote:
On Thu, Jul 21, 2005 at 09:39:38 -0400,
Bruce Momjian pgman@candle.pha.pa.us wrote:
I have added this comment above the DAYS_PER_MONTH macro:
+ /*
+ *DAYS_PER_MONTH is very imprecise. The more accurate value is
+ *365.25/12 = 30.4375,
Tino Wildenhain wrote:
Am Donnerstag, den 21.07.2005, 10:48 -0400 schrieb Tom Lane:
Another problem with this patch is the search-and-replace substitution
of SECS_PER_MINUTE for 60, when in point of fact there are two
different meanings of 60 in this context. For instance, this
code has
Tom,
Josh, I see that all of those runs seem to be using wal_buffers = 8.
Have you tried materially increasing wal_buffers (say to 100 or 1000)
and/or experimenting with different wal_sync_method options since we
fixed the bufmgrlock problem? I am wondering if the real issue is
WAL buffer
People,
So, overall, I see no reason to change that feature.
Me neither. If people are concerned about WAL on-disk size, they can reduce
the number of segments.In my experience, anyway, high segment numbers
don't provide any benefit unless you have a dedicated WAL disk.
--
Josh Berkus
Tom Lane wrote:
Another problem with this patch is the search-and-replace substitution
of SECS_PER_MINUTE for 60, when in point of fact there are two
different meanings of 60 in this context. For instance, this
code has no problem:
! int Log_RotationAge = 24 * 60;
but
Simon,
Also, it would be a good time to suggest some way for making
EXPLAIN script-friendly. Like return data as a computer program
convenient table?
I'm already trying to kludge this in Perl. It would help automated testing
considerably if explain analyze could be output as
Thomas F. O'Connell wrote:
I'm switching the aftermath of this thread -- http://
archives.postgresql.org/pgsql-general/2005-07/msg00501.php -- to -
hackers since it raised issues of potential concern to developers.
At various points in the thread, Tom Lane said the following:
I have an
Bruce Momjian pgman@candle.pha.pa.us writes:
BTW, if you actually wanted to improve readability, defining a
SECS_PER_YEAR value and replacing the various occurrences of
36525 * 864 with it would help.
IIRC the number of seconds in a year is far from a constant.
Yes, I added a
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
After rereading SQL99 4.31, I don't think there is any need to
distinguish CURRENT_USER from CURRENT_ROLE, mainly because our
implementation does not distinguish users from
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
It's possible for CURRENT_ROLE to be null according to the spec; if you
like we could implement that as returning what the current outer-level
SET ROLE value is (which would then make it semantically more like
In round figures:
Since there are 365.2422 days per tropical year, there are 31556926
seconds per year (give or take leap seconds).
Ref:
http://www.grc.nasa.gov/WWW/K-12/Numbers/Math/Mathematical_Thinking/cale
ndar_calculations.htm
So 31557600 seems to be off by quite a bit.
-Original
Greg Stark wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
BTW, if you actually wanted to improve readability, defining a
SECS_PER_YEAR value and replacing the various occurrences of
36525 * 864 with it would help.
IIRC the number of seconds in a year is far from a
I wrote:
... the implication of that is that you cannot drop any of
your login ID's privileges by doing SET ROLE, which surely is not
the intended behavior (else you might as well not have SET ROLE at all;
the only possible use of SET ROLE is to *restrict* your privileges,
since any role you
Stephen Frost [EMAIL PROTECTED] writes:
Perhaps the specification isn't but I'm pretty sure other
implementations follow the SET ROLE - current authorization
identifier (and thus dropping other rights granted to the CURRENT_USER).
My current reading of 4.31 is that SET ROLE *doesn't* drop
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
Sorry about the existing applications, but this does go directly against
the SQL2003 specification.
The spec isn't sufficiently well-designed in this area to make me
willing to insert security holes into
* Tom Lane ([EMAIL PROTECTED]) wrote:
What this says is that when a role A is a member of another role B, A
automatically has all of B's privileges. But when a user U is a member
of role R, U does *not* have R's privileges automatically. What he has
is the right to do SET ROLE R, after which
On 7/21/05, Josh Berkus josh@agliodbs.com wrote:
Also, it would be a good time to suggest some way for making
EXPLAIN script-friendly. Like return data as a computer program
convenient table?
I'm already trying to kludge this in Perl. It would help automated testing
considerably if
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
Perhaps the specification isn't but I'm pretty sure other
implementations follow the SET ROLE - current authorization
identifier (and thus dropping other rights granted to the CURRENT_USER).
My current reading
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
My current reading of 4.31 is that SET ROLE *doesn't* drop rights, which
means we need to rethink all of this. However, on this point:
Yeah, it seems to add them. Honestly, my recollection from working on
Oracle
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
Perhaps the specification isn't but I'm pretty sure other
implementations follow the SET ROLE - current authorization
identifier (and thus dropping other rights granted to the CURRENT_USER).
My current reading
* Tom Lane ([EMAIL PROTECTED]) wrote:
Yeah, let's take a look. This wouldn't be the first part of the spec
we've come across that is mostly honored in the breach...
Oracle appears to mostly follow it, except there's an implicit
'SET ROLE all;', at least in the instance I'm looking at. I'm
* Stephen Frost ([EMAIL PROTECTED]) wrote:
Doing this doesn't seem entirely unreasonable but we don't currently
have a way of handling 'SET ROLE none;'. We'd need to make some changes
but I think we could handle it, and correctly handle a specific
'SET ROLE role', which under Oracle does
Folks,
No doubt several/many of you are planning on attending OSCON 2005. The
PostgreSQL community will have a large, commercial booth in the exhibit
hall at OSCON this year, sponsored by SRA and CommandPrompt. And we need
you to help staff it.
Based on last year, I expect that many of us
Bruno Wolff III wrote:
Shouldn't you be using 365.2425/12 (30.436875) for the number of days per
month?
Well, ISO 8601 prefers 30 to some weird fraction when they
define the term month; and uses a different term calendar
month for the exact number of days in a known month.
They make a
Stephen Frost [EMAIL PROTECTED] writes:
To support having certain roles turned on and certain roles turned off
would be some additional effort. I think we'd need a list of
'ENABLED_ROLES' and then correct recursion based off of that list
instead of just starting from a single point like we do
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
To support having certain roles turned on and certain roles turned off
would be some additional effort. I think we'd need a list of
'ENABLED_ROLES' and then correct recursion based off of that list
instead of
My guess is that is this commit that is causing the problem:
revision 1.110
date: 2005/06/15 00:34:08; author: momjian; state: Exp; lines: +48
-40
This patch makes it possible to use the full set of timezones when doing
AT TIME ZONE, and not just the shorlist
On Jul 21, 2005, at 1:22 PM, Bruce Momjian wrote:
Thomas F. O'Connell wrote:
I'm switching the aftermath of this thread -- http://
archives.postgresql.org/pgsql-general/2005-07/msg00501.php -- to -
hackers since it raised issues of potential concern to developers.
At various points in the
Kevin McArthur wrote:
There appear to be several bugs in the at time zone patch recently applied.
show timezone;
TimeZone
--
UTC
(1 row)
select now();
now
---
2005-07-20 23:38:57.981128+00
(1 row)
*** WORKS
Dann Corbit wrote:
In round figures:
Since there are 365.2422 days per tropical year, there are 31556926
seconds per year (give or take leap seconds).
Ref:
http://www.grc.nasa.gov/WWW/K-12/Numbers/Math/Mathematical_Thinking/cale
ndar_calculations.htm
So 31557600 seems to be off by
43 matches
Mail list logo
