Hi,
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Group commit is a well-documented technique for improving performance,
>
> The issue here is not "is group commit a good idea in the abstract?".
> It is "is the commit_delay implementation of the idea worth a dime?"
> ... and the evidence we have
On Fri, 1 Jul 2005, Peter Eisentraut wrote:
Tom Lane wrote:
Are the correct tools also installed on cvs.postgresql.org (ie, will
the right things happen when Marc tries to build a tarball)?
I don't see any autoconf installed there, so the wrong thing would
happen either way. :-) But gnu-auto
Heikki Linnakangas wrote:
> On Fri, 1 Jul 2005, Oliver Jowett wrote:
>>
>> That implies it's valid (in fact, normal!) to enlist many different RMs
>> in the same transaction branch. Am I interpreting that correctly?
>
>
> I see. No, I don't think that's the correct interpretation, though now
> th
Tom Lane wrote:
> regression=# \h commit prepared
> Command: COMMIT PREPARED
> Description: commit a transaction that was earlier prepared for two-phase
> commit
>
> Syntax:
> COMMIT PREPARED transaction_id
Ah, I was looking under '\h commit', '\h prepare' etc.
-O
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
A number of buildfarm platforms appear to be failing regression tests
from ordering differences due to the rtree_gist merge.
Fixed, thanks.
BTW, could we get the owner of echidna/herring (I assume these are the
same machine
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> A number of buildfarm platforms appear to be failing regression tests
> from ordering differences due to the rtree_gist merge.
Fixed, thanks.
BTW, could we get the owner of echidna/herring (I assume these are the
same machine) to clean out the bogus /
A number of buildfarm platforms appear to be failing regression tests
from ordering differences due to the rtree_gist merge.
cheers
andrew
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.
On Thu, Jun 30, 2005 at 10:11:56AM -0400, Rod Taylor wrote:
> On Thu, 2005-06-30 at 23:02 +0900, Satoshi Nagayasu wrote:
> > > The TODO item is about counting all temporary files, not sorts in
> > > particular. Or at least that's what I thought it meant.
> >
> > If the DBA have to improve the per
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
>> We probably need to think a bit harder about the meaning of CREATEROLE
>> though. Right now it gives free license not only to create roles but
>> to alter any property of existing roles. This seems appropriate if
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Fabien COELHO <[EMAIL PROTECTED]> writes:
> >> Right, this can be done now.
> > There is the namespace collision issue, and although I might grant a
> > student the privilege to create simple roles, I would not allow them to
> > create new users for a basic
My UnixWare 7.1.4 box started flunking with it's latest run..
See the firefly entry on the buildfarm.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 US
---
Fabien COELHO <[EMAIL PROTECTED]> writes:
>> Right, this can be done now.
> There is the namespace collision issue, and although I might grant a
> student the privilege to create simple roles, I would not allow them to
> create new users for a basic practice;-)
Why not? With the setup Stephen
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The regression test files plpgsql and rangefuncs both create a dup()
> function, and as they are run in parallel this just caused an error for
> me, as attached. This just happened once for me, but it still ought to
> be corrected.
Wups, that's my
* Robert Treat ([EMAIL PROTECTED]) wrote:
> On Friday 01 July 2005 13:07, Stephen Frost wrote:
> However On Friday 01 July 2005 13:02, Stephen Frost wrote:
> > * Bruce Momjian (pgman@candle.pha.pa.us) wrote:
> > > Stupid question, but how do roles relate to our existing "groups"?
> >
> > Uhhh. The
Robert Treat <[EMAIL PROTECTED]> writes:
> Was following this conversation up till now, because these two statement seem
> to contradict each other. Do we really support groups still, are is CREATE
> GROUP now syntactical sugar for some for of CREATE ROLE.
CREATE GROUP and CREATE USER are both
On Friday 01 July 2005 13:07, Stephen Frost wrote:
> * Bruce Momjian (pgman@candle.pha.pa.us) wrote:
> > Thanks, TODO updated. We still support CREATE GROUP? It translates to
> > roles?
>
> Yes,
However On Friday 01 July 2005 13:02, Stephen Frost wrote:
> * Bruce Momjian (pgman@candle.pha.pa.u
Tom Lane wrote:
> Are the correct tools also installed on cvs.postgresql.org (ie, will
> the right things happen when Marc tries to build a tarball)?
I don't see any autoconf installed there, so the wrong thing would
happen either way. :-) But gnu-autoconf-2.59 is in the FreeBSD ports,
if it's
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> On Fri, 1 Jul 2005, Oliver Jowett wrote:
>> PS: noticed in passing: psql's help doesn't seem to know about the 2PC
>> command syntax yet.
> True.
Really?
regression=# \h commit prepared
Command: COMMIT PREPARED
Description: commit a transactio
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> As previously announced I have committed the update to Autoconf 2.59 as
> well as updates of mkinstalldirs, install-sh, as well as config.guess
> and config.sub.
Are the correct tools also installed on cvs.postgresql.org (ie, will the
right things h
As previously announced I have committed the update to Autoconf 2.59 as
well as updates of mkinstalldirs, install-sh, as well as config.guess
and config.sub. This shouldn't have any immediate functional impact,
except that you can now turn off the autom4te.cache directory (using
~/.autom4te.cf
On Fri, 1 Jul 2005, Oliver Jowett wrote:
PS: noticed in passing: psql's help doesn't seem to know about the 2PC
command syntax yet.
True.
Should we add support for it? 2PC is not something you normally do
interactively...
- Heikki
---(end of broadcast)-
Heikki Linnakangas wrote:
> On Fri, 1 Jul 2005, Oliver Jowett wrote:
>
> > PS: noticed in passing: psql's help doesn't seem to know about the 2PC
> > command syntax yet.
>
> True.
>
> Should we add support for it? 2PC is not something you normally do
> interactively...
Yes, we should add psql
The regression test files plpgsql and rangefuncs both create a dup()
function, and as they are run in parallel this just caused an error for
me, as attached. This just happened once for me, but it still ought to
be corrected.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
*** ./
On Fri, 1 Jul 2005, Barry Lind wrote:
I oversimplified a bit. The TM *can* enlist multiple threads of control
(= connection in JTA) to the same transaction branch. That's called
"tightly-coupled threads", and they should then be treated as one
local transaction in the RM. The calls will look lik
On Fri, 1 Jul 2005, Oliver Jowett wrote:
What I'm confused about is, for example, 3.3.1 in the DTP:XA spec:
3.3.1 Registration of Resource Managers
Normally, a TM involves all associated RMs in a transaction branch. (The TMs
set of
RM switches, described in Section 4.3 on page 21 tells the T
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
> Thanks, TODO updated. We still support CREATE GROUP? It translates to
> roles?
Yes, CREATE USER too.
Stephen
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > Stupid question, but how do roles relate to our existing "groups"?
> >
> >
Bruce Momjian writes:
> Stupid question, but how do roles relate to our existing "groups"?
As committed, roles subsume both users and groups: a role that permits
login (rolcanlogin) acts as a user, and a role that has members is a
group. It is possible for the same role to do both things, though
Thanks, TODO updated. We still support CREATE GROUP? It translates to
roles?
---
Tom Lane wrote:
> Bruce Momjian writes:
> > Stupid question, but how do roles relate to our existing "groups"?
>
> As committed, roles subs
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
> Stupid question, but how do roles relate to our existing "groups"?
Uhhh. There are no longer "groups", they've been replaced with roles
(which can have members).
Thanks,
Stephen
signature.asc
Description: Digital signat
>>> branch id: Branch Identifier. Every RM involved in the global
>>> transaction is given a *different* branch id.
>>
>> Hm, I am confused then -- the XA spec definitely talks about
enlisting
>> multiple RMs in a single transaction branch.
>>
>> Can you explain?
>
>I oversimplified a bit. The TM *
Stupid question, but how do roles relate to our existing "groups"?
---
Fabien COELHO wrote:
>
> >> The privilege management is about a catalog, so it better to have it in
> >> the catalog.
> >
> > Permissions are at a numb
Tom Lane wrote:
> You'd have to talk to your kernel provider about that one; we don't
> have any direct control over where or even whether core dumps occur.
Apache used to have (still has?) a way to configure that. I think they
must have done the chdir() in the SIGSEGV handler. Not that I'm
pr
The privilege management is about a catalog, so it better to have it in
the catalog.
Permissions are at a number of levels already: cluster, database,
schema, table. Permissions at different levels hasn't got anything to
do w/ per-catalog roles.
Sorry for not being very clear. I see two "ma
Fabien,
* Fabien COELHO ([EMAIL PROTECTED]) wrote:
> >Please outline exactly what you're really looking for. Let's drop the
> >idea of per-cluster users/groups/roles/whatever and instead consider
> >what specific capabilities you're looking for.
>
> I think from a conceptual point of view that t
Dear Stephen,
Please outline exactly what you're really looking for. Let's drop the
idea of per-cluster users/groups/roles/whatever and instead consider
what specific capabilities you're looking for.
I think from a conceptual point of view that the ability to manage
permissions at the datab
Thanks. Updated.
---
Christopher Kings-Lynne wrote:
> Bruce - this is done:
>
> o Add dumping and restoring of LOB comments
>
> Chris
>
>
> ---(end of broadcast)---
> TIP 5
Neil Conway <[EMAIL PROTECTED]> writes:
> BTW, I notice that some but not all the call sites of ereport(ERROR) in
> PL/PgSQL's gram.y set plpgsql_error_lineno. Is there a reason for this?
Without looking at the code, I think it may be that you only need to set
the variable if you want the error t
Fabien COELHO <[EMAIL PROTECTED]> writes:
> Moreover, a working per-cluster grouping was already
> available.
Only for sufficiently small values of "working". The lack of ability
for groups to contain other groups and for groups to be the direct
owners of objects were both pretty serious restric
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Not ignoring errors is one of the staples of PostgreSQL. What you are
> proposing here sounds entirely like a MySQL design plan. Maybe that is
> newbie-friendly in your mind, but I really doubt that. I agree that we
> do not want to force people
In my application server, one db connection per thread. client may start
a galobal transaction ,immediacy or indirect associate to a lot of app
servers and more and more threads (db connections).
---(end of broadcast)---
TIP 8: explain analyze is
Fabien,
* Fabien COELHO ([EMAIL PROTECTED]) wrote:
> >I really disagree with you here. I feel it makes much more sense to do
> >this in stages, first user/group -> roles, then roles-per-catalog, which
> >means you can then have both per-catalog 'users' and per-catalog
> >'groups', if you want to
Pavel Stehule wrote:
this patch allows optional using label with END and END LOOP. Ending label
has only informational value, but can enhance readability large block and
enhance likeness with Oracle.
<>LOOP
...
...
END LOOP<>;
Attached is a revised version of this patch. Changes / comments
Heikki Linnakangas wrote:
> On Fri, 1 Jul 2005, Oliver Jowett wrote:
>
>> Heikki Linnakangas wrote:
>>
>>> branch id: Branch Identifier. Every RM involved in the global
>>> transaction is given a *different* branch id.
>>
>>
>> Hm, I am confused then -- the XA spec definitely talks about enlisting
On Fri, 1 Jul 2005, Oliver Jowett wrote:
Heikki Linnakangas wrote:
branch id: Branch Identifier. Every RM involved in the global
transaction is given a *different* branch id.
Hm, I am confused then -- the XA spec definitely talks about enlisting
multiple RMs in a single transaction branch.
Tom Lane wrote:
> > I think we could also error out if we cannot create at least one
> > listen socket for each entry in listen_addresses (instead of at
> > least one overall).
>
> No; that will break cases that don't need to break.
Which cases would that be? If you specify a host name and it doe
Dear Stephen,
I still think that removing groups and having per-cluster roles is not a
good idea. The better way would be to keep user/group and add per-catalog
roles. There is an opportunity which is being missed, and that won't show
up later.
I really disagree with you here. I feel it make
> -Original Message-
> From: Dawid Kuroczko [mailto:[EMAIL PROTECTED]
> Sent: 30 June 2005 22:21
> To: Dave Page
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] [PATCHES] Dbsize backend integration
>
> On 6/30/05, Dave Page wrote:
> > > -Original Message-
> > > From: Bru
47 matches
Mail list logo