Tom Lane wrote:
> Bruce Momjian writes:
> > o everyone agrees the current meaning of bgwriter_percent is
> >useless (percent of dirty buffers)
>
> Oh?
>
> It's not useless by any means; it's a perfectly reasonable and useful
> definition that happens to be expensive to implement. O
On Sat, 2005-01-01 at 14:10 -0500, Tom Lane wrote:
Korry <[EMAIL PROTECTED]> writes:
> It seems you can’t trap every condition listed in errocodes-
> appendix.html; in particular, you can’t trap SUCCESSFUL_COMPLETION, any
> of the conditions listed in the WARNING category, or any of the
> con
On Sat, 2005-01-01 at 18:55, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I think the proposal sounds safe, though I worry about performance.
>
> There is no performance loss; we are just changing the order in which
> we acquire two locks. If there were some risk of blocking for
On Sat, 2005-01-01 at 17:47, Simon Riggs wrote:
> On Sat, 2005-01-01 at 17:01, Bruce Momjian wrote:
> > Simon Riggs wrote:
> >
> > > Well, I think we're saying: its not in 8.0 now, and we take our time to
> > > consider patches for 8.1 and accept the situation that the parameter
> > > names/meani
On Sat, Jan 01, 2005 at 12:09:05 -0500,
[EMAIL PROTECTED] wrote:
> One of my testers asked me if there is a function in psql that is
> equivalent to a session log - something that will write out commands sent
> to the server and the results written to a file while still displaying the
> results o
Korry <[EMAIL PROTECTED]> writes:
> It seems you can’t trap every condition listed in errocodes-
> appendix.html; in particular, you can’t trap SUCCESSFUL_COMPLETION, any
> of the conditions listed in the WARNING category, or any of the
> conditions listed in the NO DATA category. (At least throug
Simon Riggs <[EMAIL PROTECTED]> writes:
> I think the proposal sounds safe, though I worry about performance.
There is no performance loss; we are just changing the order in which
we acquire two locks. If there were some risk of blocking for a
measurable time while holding the BufMgrLock, then th
On Sat, Jan 01, 2005 at 10:04:57AM -0500, Korry wrote:
> It seems you can???t trap every condition listed in errocodes-
> appendix.html; in particular, you can't trap SUCCESSFUL_COMPLETION, any
> of the conditions listed in the WARNING category, or any of the
> conditions listed in the NO DATA cat
Bruce Momjian writes:
> o everyone agrees the current meaning of bgwriter_percent is
> useless (percent of dirty buffers)
Oh?
It's not useless by any means; it's a perfectly reasonable and useful
definition that happens to be expensive to implement. One of the
questions that is
One of my testers asked me if there is a function in psql that is
equivalent to a session log - something that will write out commands sent
to the server and the results written to a file while still displaying the
results on screen.
I can't find anything like this, but I think I can put it togeth
On Sat, 2005-01-01 at 17:01, Bruce Momjian wrote:
> Simon Riggs wrote:
>
> > Well, I think we're saying: its not in 8.0 now, and we take our time to
> > consider patches for 8.1 and accept the situation that the parameter
> > names/meaning will change in next release.
>
> I have no problem doing
Simon Riggs wrote:
> On Sat, 2005-01-01 at 06:20, Bruce Momjian wrote:
> > This change isn't going to make it for RC3, and it probably not
> > something we want to rush.
>
> OK. Thank you.
>
> > I think there are a few issues involved:
> >
> > o everyone agrees the current meaning of bgwrit
On Sat, 2005-01-01 at 00:42, Tom Lane wrote:
> I wrote:
> > A possible fix for this is to reorder the operations in FlushBuffer
> > so that we share-lock the buffer before releasing BufMgrLock ... but
> > I'm not sure that doesn't introduce other deadlock risks.
>
> That's too simplistic, since at
On Sat, 2005-01-01 at 06:20, Bruce Momjian wrote:
> This change isn't going to make it for RC3, and it probably not
> something we want to rush.
OK. Thank you.
> I think there are a few issues involved:
>
> o everyone agrees the current meaning of bgwriter_percent is
> useless (p
I am using the following sytex to handle exceptions in
plpgsql (I am using postgres 8 rc1)
some code
EXCEPTION
WHEN NO_DATA THEN
RAISE NOTICE 'NO DATA';
WHEN OTHERS THEN
RAISE NOTICE 'An exception occurred';
RETURN emp_rec;
and i receive the f
I think that the documentation as well as the code itself are the
specifications of postgresql.
Regards,
Jeff Davis
On Mon, 2004-12-27 at 18:02 -0800, Benjamin Arai wrote:
> Where can I obtain a spec for postgresql, so I can start looking at the
> code?
>
> Benjamin
> [EMAIL PROTECTED]
16 matches
Mail list logo
