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.
--
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 |
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: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: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: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:
> ... 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
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
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
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
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
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
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
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
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
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
> >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
> >
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):
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
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
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
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
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
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
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
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
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
>> 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
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
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
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
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.
For chan
>> >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
>
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
>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 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
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
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
52 matches
Mail list logo
