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 b
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)
>
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 th
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
* 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
> > in
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
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
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 wi
* 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 ', which under Oracle does appe
* 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 g
* 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 curre
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
>
* 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 curre
On 7/21/05, Josh Berkus 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 explain a
* 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 wh
* 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 int
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
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 rol
Greg Stark wrote:
>
> Bruce Momjian 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 co
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 Me
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 lik
* 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 distinguis
Bruce Momjian 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 commen
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 h
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 tab-d
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
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,
> 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 buff
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
Bruno Wolff III wrote:
> On Thu, Jul 21, 2005 at 09:39:38 -0400,
> Bruce Momjian 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 d
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:
>
> !
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 lik
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> On Thu, Jul 21, 2005 at 09:39:38 -0400,
> Bruce Momjian 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 365.2425/12 (30.
On Thu, Jul 21, 2005 at 09:39:38 -0400,
Bruce Momjian 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'. Right now we only
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 onl
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
w
pgman wrote:
> Marc G. Fournier wrote:
> > On Thu, 21 Jul 2005, Tom Lane wrote:
> >
> > > Bruce Momjian 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
> > >>>
> > >>
I can’t 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
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.
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.
>
> http://www.postgr
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 us
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
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/~mfuh
43 matches
Mail list logo
