Andrew Dunstan wrote:
Even if we don't do that can we *please* put in something that
detects the error, and tells the user what they will have to do to
fix it? Failing in a situation which we know we can detect and not
telling the user is intolerable, IMNSHO.
Can you try a more recent version
I have added a timezone database to CVS, and enabled it for Win32. This
allows Win32 to pass our pre-1970 regression tests. There are also
plans to enable this code under Unix so we have a standard database for
all installs and so we can query for valid timezone names.
However, this brings up
I have added a timezone database to CVS, and enabled it for
Win32. This
allows Win32 to pass our pre-1970 regression tests. There are also
plans to enable this code under Unix so we have a standard database for
all installs and so we can query for valid timezone names.
However, this brings up
I have been looking at our use of fixed directory specifications in
binaries.
Right now we have libdir (dynamic_library_path) predefined in the
compile, with a GUC to override it. initdb also needs to be able to
find its input files, and that can be overridden by an initdb flag.
Adding the
Magnus Hagander wrote:
I have added a timezone database to CVS, and enabled it for
Win32. This
allows Win32 to pass our pre-1970 regression tests. There are also
plans to enable this code under Unix so we have a standard database for
all installs and so we can query for valid timezone
Christopher Kings-Lynne wrote:
Now, I have to change that relation_expr to qualified_name. However,
this causes shift/reduce errors. (Due to ALTER TABLE relation_expr SET
WITHOUT OIDS.)
Well, seems like what you have to do is leave it as relation_expr
as far as bison is concerned, but
Bruce Momjian wrote:
Also, Win32 installs are going to want to be more directory
independent than Unix.
Why?
Because Win32 can probe for the location of the binary, it seems it
should check to see if it can find libdir and sharedir own its own
and set those GUC values accordingly as part of
Peter Eisentraut wrote:
Bruce Momjian wrote:
Also, Win32 installs are going to want to be more directory
independent than Unix.
Why?
Because when I install Win32 stuff on my machine via an installer, it
says Where do you want the files and puts it in C:\ or C:\Program
Files or whatever I
Peter Eisentraut wrote:
Bruce Momjian wrote:
Also, Win32 installs are going to want to be more directory
independent than Unix.
Why?
Common practice, for one thing. Windows programs are typically
relocatable, and Windows admins regard programs that rely on hardcoded
paths very poorly
Actually, it occurs to me that the SET WITHOUT CLUSTER form CAN recurse.
Should I make it do that, even though the CLUSTER ON form cannot?
I just thought about this. CLUSTER is more of a storage-level
specification, rather than a logical one. Seems it is OK that WITOUTH
CLUSTER not recurse
Christopher Kings-Lynne wrote:
Actually, it occurs to me that the SET WITHOUT CLUSTER form CAN recurse.
Should I make it do that, even though the CLUSTER ON form cannot?
I just thought about this. CLUSTER is more of a storage-level
specification, rather than a logical one. Seems it
Uh, if the CLUSTER doesn't recurse, the WITHOUT shouldn't either, I
think, and throwing an error seems fine to me, even if it isn't the same
wording as a syntax error.
Well, maybe - up to you.
---(end of broadcast)---
TIP 5: Have you checked our
Bruce Momjian wrote:
In other words:
#dynamic_library_path = '$libdir'
could maybe become:
#dynamic_library_path = '/usr/local/pgsql/lib'
Not sure I follow - dynamic_library_path is a colon-separated set of
paths. How will somone using $libdir have that resolved? ISTM we need to
Andrew Dunstan [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
This is just going to open up the possibility of silently finding the
wrong files.
Maybe it could be improved by using more version markers?
AFAICS the sharedir will already be sufficiently checked by means of
initdb's check
I wrote:
AFAICS the sharedir will already be sufficiently checked by means of
initdb's check on the postgres.bki version marker. In some sense, the
sharedir used by initdb is the *right* one for an installation by
definition --- I'm not even convinced that we should allow people to
fool with
Tom Lane wrote:
I wrote:
AFAICS the sharedir will already be sufficiently checked by means of
initdb's check on the postgres.bki version marker. In some sense, the
sharedir used by initdb is the *right* one for an installation by
definition --- I'm not even convinced that we should allow
On Fri, Apr 30, 2004 at 04:48:33PM -0400, Bruce Momjian wrote:
Does ecpg need to use the same timezone database as the backend?
I have to check what you changed. ecpg itself does not use the timezone
database, but some of that code is used in pgtypeslib.
Michael
--
Michael Meskes
Email:
1) How do we set the default local timezone for our
database? The OS
knows the local timezone. How do we set our local timezone
on Win32?
On Unix? (On Unix, there is usually an /etc/localtime file that is
created during install.) Perhaps we can query the current timezone
specification
Michael Meskes wrote:
On Fri, Apr 30, 2004 at 04:48:33PM -0400, Bruce Momjian wrote:
Does ecpg need to use the same timezone database as the backend?
I have to check what you changed. ecpg itself does not use the timezone
database, but some of that code is used in pgtypeslib.
For changes
Bruce Momjian wrote:
Tom Lane wrote:
I wrote:
AFAICS the sharedir will already be sufficiently checked by means of
initdb's check on the postgres.bki version marker. In some sense, the
sharedir used by initdb is the *right* one for an installation by
definition --- I'm not even
Michael Meskes wrote:
On Fri, Apr 30, 2004 at 04:48:33PM -0400, Bruce Momjian wrote:
Does ecpg need to use the same timezone database as the backend?
I have to check what you changed. ecpg itself does not use the timezone
database, but some of that code is used in pgtypeslib.
Yea, that's
Magnus Hagander wrote:
1) How do we set the default local timezone for our
database? The OS
knows the local timezone. How do we set our local timezone
on Win32?
On Unix? (On Unix, there is usually an /etc/localtime file that is
created during install.) Perhaps we can query the
Andrew Dunstan wrote:
Common practice, for one thing. Windows programs are typically
relocatable, and Windows admins regard programs that rely on
hardcoded paths very poorly indeed.
OK, but how can that work in general? How do other programs handle
this? I don't think we should design a
Common practice, for one thing. Windows programs are typically
relocatable, and Windows admins regard programs that rely on
hardcoded paths very poorly indeed.
OK, but how can that work in general? How do other programs handle
this? I don't think we should design a solution that goes
like
Magnus Hagander wrote:
To make it work more cross-platform, replace that registry thing
with postgresql.conf. It's basically the same thing, except the
registry has a hierarchy model.
That only works as long as all the files we want to refer to are used by
the server. But how will psql find
Peter Eisentraut wrote:
Andrew Dunstan wrote:
Common practice, for one thing. Windows programs are typically
relocatable, and Windows admins regard programs that rely on
hardcoded paths very poorly indeed.
OK, but how can that work in general? How do other programs handle
this? I don't
Peter Eisentraut wrote:
Magnus Hagander wrote:
To make it work more cross-platform, replace that registry thing
with postgresql.conf. It's basically the same thing, except the
registry has a hierarchy model.
That only works as long as all the files we want to refer to are used by
the
Christopher Kings-Lynne wrote:
Uh, if the CLUSTER doesn't recurse, the WITHOUT shouldn't either, I
think, and throwing an error seems fine to me, even if it isn't the same
wording as a syntax error.
Well, maybe - up to you.
Well, if we don't recurse on creation, does it make sense to
Bruce Momjian wrote:
Peter Eisentraut wrote:
Magnus Hagander wrote:
To make it work more cross-platform, replace that registry thing
with postgresql.conf. It's basically the same thing, except the
registry has a hierarchy model.
That only works as long as all the files we want to
On Sun, May 02, 2004 at 06:23:30PM -0400, Bruce Momjian wrote:
Christopher Kings-Lynne wrote:
Uh, if the CLUSTER doesn't recurse, the WITHOUT shouldn't either, I
think, and throwing an error seems fine to me, even if it isn't the same
wording as a syntax error.
Well, maybe - up to
Andrew Dunstan wrote:
Binaries can find other binaries the way they do now: look in our own
location, then in the path.
No, we can't look into the path. We have no information that says that
anything useful pertaining to our installation is in the path.
Other files could be found by looking
Peter Eisentraut wrote:
Andrew Dunstan wrote:
Binaries can find other binaries the way they do now: look in our own
location, then in the path.
No, we can't look into the path. We have no information that says that
anything useful pertaining to our installation is in the path.
Well,
Alvaro Herrera wrote:
On Sun, May 02, 2004 at 06:23:30PM -0400, Bruce Momjian wrote:
Christopher Kings-Lynne wrote:
Uh, if the CLUSTER doesn't recurse, the WITHOUT shouldn't either, I
think, and throwing an error seems fine to me, even if it isn't the same
wording as a syntax error.
We are seeing occasional long lockouts from out DB. When I do a 'select *
from pg_locks', I find that everybody is waiting for pg_listener, and that
the lock on pg_listener is currently held by a long-running ANALYZE VERBOSE.
I saw the following in the change logs (not sure if it's relevant):
5) We only had a compiled-in location for /lib in the past for dynamic
loading, and had a GUC variable to override it. initdb always used
/share in a fixed location, but it has a flag to override it. With
/share/timezone, the server now requires the timezone
database to be in
a fixed
Philip Warner [EMAIL PROTECTED] writes:
Does this mean that ANALYZE will take an exclusive lock on pg_listener
until the ANALYZE finishes? Or is there some other cause?
ANALYZE does not take an exclusive lock on anything. However, the
async.c functions want AccessExclusiveLock on pg_listener,
Tom Lane wrote:
Philip Warner [EMAIL PROTECTED] writes:
Does this mean that ANALYZE will take an exclusive lock on pg_listener
until the ANALYZE finishes? Or is there some other cause?
ANALYZE does not take an exclusive lock on anything. However, the
async.c functions want
Andrew Dunstan wrote:
For Win32, we could use the registry. For Unix, we can't use /etc
because we can't be sure we are root. Can we create a dot-file in the
user's home directory during install?
We can't be sure we are Administrator either.
Exactly. IMHO, using the registry is the
At 12:45 PM 3/05/2004, Tom Lane wrote:
Possibly we could reduce the strength of the lock taken by the async.c
functions
If possible, this seems like a great option. We currently have a large
database with several hundred users who get locked out for as much as half
an hour while ANALYZE runs.
Philip Warner [EMAIL PROTECTED] writes:
Would ACCESS SHARE be OK?
Certainly not, since the point of the locks in async.c is that only one
backend should execute those routines at a time. ExclusiveLock might
work okay ... but I still haven't thought hard about it ...
Philip Warner [EMAIL PROTECTED] writes:
If possible, this seems like a great option. We currently have a large
database with several hundred users who get locked out for as much as half
an hour while ANALYZE runs.
If it takes half an hour to ANALYZE pg_listener, I think that ANALYZE is
not
On Sun, 2 May 2004, Bruce Momjian wrote:
Tom Lane wrote:
Philip Warner [EMAIL PROTECTED] writes:
Does this mean that ANALYZE will take an exclusive lock on pg_listener
until the ANALYZE finishes? Or is there some other cause?
ANALYZE does not take an exclusive lock on anything.
At 01:46 PM 3/05/2004, Tom Lane wrote:
If it takes half an hour to ANALYZE pg_listener, I think that ANALYZE is
not your real problem :-(. You need a much more aggressive vacuuming
policy on that table. Maybe a cron job issuing vacuum pg_listener
once a minute would do? And get the size of the
I had lots of trouble posting so you may receive this
more than once. My apologies..
--
Hi,
I know the issue of pre-fork PostgreSQL has been
discussed previously.
Someone mentionned pre-fork can be implemented when
schemas become available
in PostgreSQL because there
Philip Warner [EMAIL PROTECTED] writes:
... for some reason pg_listeners is being locked in ACCESS SHARE the
entire time.
Just vacuuming pg_listener produces:
vacuum verbose pg_listener;
INFO: vacuuming pg_catalog.pg_listener
INFO: pg_listener: found 0 removable, 0 nonremovable row
At 02:21 PM 3/05/2004, Tom Lane wrote:
[blinks...] There's something pretty strange about that. Are you using
LISTEN/NOTIFY at all?
Nope.
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/
Philip Warner [EMAIL PROTECTED] writes:
At 02:21 PM 3/05/2004, Tom Lane wrote:
[blinks...] There's something pretty strange about that. Are you using
LISTEN/NOTIFY at all?
Nope.
In that case there's no reason for anything to be taking any particular
locks on pg_listener; and it's simply
At 02:54 PM 3/05/2004, Tom Lane wrote:
Please dig deeper.
I will log everything I check next time; unfortunately, when it happens,
the priority is on unlocking everything so I have a limited time to play.
So far, killing the ANALYZE has fixed the problem each time.
48 matches
Mail list logo
