On Sun, 2008-05-25 at 20:10 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > At the moment, a long running SQL Statement can prevent xmin moving
> > forward, which can result in VACUUM and HOT not being able to remove row
> > versions effectively. My proposal is that a Read Unc
Merlin Moncure wrote:
On Wed, May 21, 2008 at 4:39 AM, Andreas Pflug
<[EMAIL PROTECTED]> wrote:
Not the whole reason. To get a view definition that is more readable, the
pretty_bool option of pg_get_viewdef already does some newline and indent
formatting. Not the initial formatting, but Good Eno
Simon Riggs <[EMAIL PROTECTED]> writes:
> At the moment, a long running SQL Statement can prevent xmin moving
> forward, which can result in VACUUM and HOT not being able to remove row
> versions effectively. My proposal is that a Read Uncommitted transaction
> would not prevent row removal, which
Currently, PostgreSQL implements the SQL Standard transaction isolation
level of Read Uncommitted as being equivalent to Read Committed. That is
a valid decision, though I wish to propose an alternative.
At the moment, a long running SQL Statement can prevent xmin moving
forward, which can result
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> I don't buy the performance argument unless I see some test results
> demonstrating it; exec_prepare_plan is only called on the first
> invocation of a statement. What kind of side-effects could
> exec_eval_datum call have?
In principle, if you
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> BTW what happened to the idea of displaying only user
> functions by default?
It's waiting on me to submit an updated patch, per Heikki's
request. I'll try to get one out this week.
- --
Greg Sabino Mullane [EMAIL PROTECTED]
PGP Key: 0x14964
On Sat, May 24, 2008 at 05:08:51AM -0700, David Fetter wrote:
> On Sun, May 18, 2008 at 08:51:29PM +0900, Tatsuo Ishii wrote:
> > WITH RECURSIVE patch V0.1
>
> Please find updated patch with bug fixes from Yoshiyuki Asaba and
> Michael Meskes. Any mistakes in it are mine. :)
As promised, the mis
On Sun, May 25, 2008 at 01:39:50PM -0400, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > On Sun, May 25, 2008 at 10:05:10AM -0400, Alvaro Herrera wrote:
> >> Hmm, right. Maybe the problem I have is that we made \df+ so
> >> wide so as to be almost useless by now ...
> >>
> >> I th
Stephen Frost <[EMAIL PROTECTED]> writes:
>> Discussing psql options made me recall an annoying problem that we've
>> run into. There's no way (unless it was added to 8.3 and I missed it,
>> but I don't think so) to tell pg_dump 'switch to this role before
>> doing anything else'. That's very fru
[ catching up on back email ]
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Yoshiyuki Asaba" <[EMAIL PROTECTED]> writes:
>> Recursive query does not consume stack. The server enters an infinite
>> loop without consuming stack. Stack-depth error does not happen.
> We could have a separate guc varia
Hans-Juergen Schoenig wrote:
Gregory Stark wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
i don't think statement_timeout is a good idea at all.
it is not deterministic. depending on the load on the server some
queries will execute while others fail.
a separate GUC is needed.
I
David Fetter <[EMAIL PROTECTED]> writes:
> On Sun, May 25, 2008 at 10:05:10AM -0400, Alvaro Herrera wrote:
>> Hmm, right. Maybe the problem I have is that we made \df+ so wide so as
>> to be almost useless by now ...
>>
>> I think this is mostly caused by the "args" column getting too wide.
>> Ca
I want to start working to implement packages in PostgreSQL and would
like to learn how to change the tables of the catalogue.
I want to useit pg_namespace table to create a "sub-schema" that will be used to
group the functions like in Oracle
--
Nabucodonosor Coutinho
--
Sent via pgsql-hackers
On Sun, May 25, 2008 at 10:05:10AM -0400, Alvaro Herrera wrote:
> Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > Would anyone object to \df displaying a function's volatility? Maybe
> > > limit it to \df+?
> >
> > Huh? \df+ has displayed volatility for a long time, and I do
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Would anyone object to \df displaying a function's volatility? Maybe
> > limit it to \df+?
>
> Huh? \df+ has displayed volatility for a long time, and I don't recall
> any great demand to move it into \df.
Hmm, right. Maybe the p
Hans-Juergen Schoenig wrote:
> when thinking of REASSIGNED OWNED people tend to think about tables
> rather than about CONNECT rights.
> i would suggest to make DROP ROLE just kill the role unless there is a
> real object depending on it.
> i would not see a permission to be an object. what do
Alvaro Herrera wrote:
Hans-Juergen Schoenig wrote:
test=# create role xy LOGIN;
CREATE ROLE
test=# grant connect on database test to xy;
GRANT
test=# drop role xy;
ERROR: role "xy" cannot be dropped because some objects depend on it
DETAIL: access to database test
this is a totally fres
Hans-Juergen Schoenig wrote:
> test=# create role xy LOGIN;
> CREATE ROLE
>
> test=# grant connect on database test to xy;
> GRANT
>
> test=# drop role xy;
> ERROR: role "xy" cannot be dropped because some objects depend on it
> DETAIL: access to database test
>
> this is a totally fresh instanc
Gregory Stark wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Couldn't we just have it pay attention to the existing
max_stack_depth?
Recursive query does not consume stack. The server enters an infinite
loop without consuming stack. Stack-depth error does not happen.
Decibel! wrote:
>For reference, the original query as posted to -performance:
>select * from t1, t2 where t1.id > 158507 and t1.id = t2.id;
>That took > 84 minutes (the query was a bit longer but this is the
>part that made the difference) after a little change the query took
>~1 second:
Jus
20 matches
Mail list logo
