Bruce wrote:
> > I was never all that happy with the WAL chapter, since, as you say,
it
> > doesn't seem to be a first-class user-level feature. I'd be happy
to
> > integrate it into another chapter, but I'm not sure where.
>
> Sure, I am looking for suggestions. My relabeling at least fixes
tha
> Merlin Moncure wrote:
> > I was looking for some good documentation resources on dealing with
> > database concurrency issues online and I stumbled across this gem
from
> > Microsoft:
> >
> >
http://msdn.microsoft.com/library/default.asp?url=/library/en-
I was looking for some good documentation resources on dealing with
database concurrency issues online and I stumbled across this gem from
Microsoft:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/h
tml/concurev4M.asp
In it is a kind of 'best practices' in dealing with var
Bruce Momijan wrote:
> Merlin Moncure wrote:
> > The PostgreSQL FAQ currently suggests using dynamic SQL as a
workaround
> > for the table OID caching problem of temp tables in pg/pgsql
functions.
> > While this is ok, it fails to suggest that besides the initial
> > cr
The PostgreSQL FAQ currently suggests using dynamic SQL as a workaround
for the table OID caching problem of temp tables in pg/pgsql functions.
While this is ok, it fails to suggest that besides the initial
create/drop statements, every statement that touches the table must also
be dynamic.
With 8
I have to ask this...why is 'allballs' accepted as a literal for time?
I checked the dictionary and wikipedia and couldn't find a reason why.
Merlin
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
> Merlin Moncure wrote:
> > Second,
> > Is there a reason why user level locks are completely undocumented?
> > AFAICT, There is no mention of them in anywhere in the docs,
> > particularly 12.4, which describes methods for application managed
> > concurrency. The
I've been knocking around a bit with user level locks and I have a few
suggestions/questions:
First, the pg_locks view lists user level locks but doesn't really say
much about them. For example, for traditional locks we get the xid but
for user locks we don't really get anything useful. I looked
> >> execution of PostgreSQL by a user with administrative permissions
is
> >> not permitted.
> >> The server must be started under an unprivileged user ID to prevent
> >> possible system security compromise. See the documentation for
> >> more information on how to properly start the server.
> >>
