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 vers
Dear Tom,
> > The standard "EVERY" is fine for postgres, the issue is only with
> > ANY/SOME. Do you think that bool_and should be proposed anyway for
> > homogeneity with bool_or?
>
> I think EVERY is actively misleading, because it does *not* imply that
> every input is TRUE. The spec says the
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 so
>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 brin
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 timez
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 time
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
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 par
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 wha
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 ind
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 int
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.
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 exten
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
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
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 shou
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: Michae
>> >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
>
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 chan
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'
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, tha
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
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 s
>> 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 goe
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
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 use
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
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 t
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, ma
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 looki
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, ass
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
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
> >
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_listen
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 Acce
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 registr
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.
Th
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 ...
r
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
n
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 a
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 w
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 nonremovab
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 si
At 02:33 PM 3/05/2004, Tom Lane wrote:
Could
you dig a little deeper and see where the problem really is?
I thought I had 8-(.
The result of a 'select * from pg_locks where not granted' was a bunch of
locks on the pg_listener relation, and no others. Only one process had a
lock on that relation,
Philip Warner <[EMAIL PROTECTED]> writes:
> At 02:33 PM 3/05/2004, Tom Lane wrote:
>> Could you dig a little deeper and see where the problem really is?
> I thought I had 8-(.
> The result of a 'select * from pg_locks where not granted' was a bunch of
> locks on the pg_listener relation, and no
At 02:54 PM 3/05/2004, Tom Lane wrote:
I don't believe any of this.
mail=# select * from pg_locks where not granted;
relation | database | transaction | pid |mode | granted
--+--+-+---+-+-
16414 |17149 |
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.
--
52 matches
Mail list logo
