On Thu, 04 Sep 2003, Tom Lane wrote:
> Ben Grimm <[EMAIL PROTECTED]> writes:
> > I haven't tried the 7.4 beta, so it may be fixed there - but in
> > 7.3.4, pg_dumpall doesn't output global database ACL's.
>
> This is fixed for 7.4.
Is there a patch to
On Mon, 08 Sep 2003, Tom Lane wrote:
> Ben Grimm <[EMAIL PROTECTED]> writes:
> > On Thu, 04 Sep 2003, Tom Lane wrote:
> >> Ben Grimm <[EMAIL PROTECTED]> writes:
> >>> I haven't tried the 7.4 beta, so it may be fixed there - but in
> >>
users
that own the schemas.
On Thu, 04 Sep 2003, Ben Grimm wrote:
> I haven't tried the 7.4 beta, so it may be fixed there - but in
> 7.3.4, pg_dumpall doesn't generate the commands to create schemas
> in the right order. This bug may have been reported before, but
> I saw
I haven't tried the 7.4 beta, so it may be fixed there - but in
7.3.4, pg_dumpall doesn't generate the commands to create schemas
in the right order. This bug may have been reported before, but
I saw no response to it in the lists.
Try this in a fresh database after an initdb:
template1=# cr
I haven't tried the 7.4 beta, so it may be fixed there - but in
7.3.4, pg_dumpall doesn't output global database ACL's. Try this
in a fresh database after an initdb:
template1=# create user test nocreatedb nocreateuser;
CREATE USER
template1=# create database testdb;
CREATE DATABASE
template1=#
On Fri, 15 Mar 2002, Tom Lane wrote:
> "'Ben Grimm'" <[EMAIL PROTECTED]> writes:
> > When these bugs are fixed there is still the issue of bug #3 that I
> > came across. The one that I work around by resetting log_cnt to 0 when a
> > backend in
On Fri, 15 Mar 2002, Vadim Mikheev wrote:
> > But sequences should not be under transaction control. Can you
> > safely rollback a sequence? No! The only way to ensure that would
> ...
> > Placing a restriction on an application that says it must treat the values
> > returned from a sequence a
On Thu, 14 Mar 2002, Mikheev, Vadim wrote:
> And it's not. But behaviour of application *must* be
> conditional on was transaction committed or not.
>
> What's the problem for application that need nextval() for
> external (out-of-database) purposes to use sequence values
> only after transactio
On Thu, 14 Mar 2002, Tom Lane wrote:
>
> If you do a SELECT nextval() and then use the returned value externally
> *without waiting for a commit acknowledgement*, then I think you are
> risking trouble; there's no guarantee that the WAL record (if one is
> needed) has hit disk yet, and so a crash
On Wed, 13 Mar 2002, Tom Lane wrote:
>
> I don't think that can work. AFAICT what your patch does is to ensure
> a WAL record is written by the first nextval() in any given backend
> session.
That's exactly what it does, yes. It forces the WAL record to be
written at least once. I think th
On Wed, 13 Mar 2002, Tom Lane wrote:
>
> Accordingly, I'm thinking that we must remove the SEQ_LOG_VALS
> functionality and force one-WAL-record-per-nextval operation.
>
> Vadim, do you see another way? This was a cool idea and I hate
> to throw it away...
>
It seems like you just need to ens
11 matches
Mail list logo
