On Mon, 1 Oct 2007 12:38:07 +1000
"Brendan Jurd" <[EMAIL PROTECTED]> wrote:
> On 10/1/07, Islam Hegazy <[EMAIL PROTECTED]> wrote:
> > I am a graduate student in the University of Calgary. I want to add some new
> > operators to PostgreSQL to perform some specific tasks in a project I am
> > working
Why the Fun_ABC1 is created and Fun_ABC12 is raising the following
error, while run through psql, ( I Could create both the functions from
PgAdmin III query )
ERROR: invalid byte sequence for encoding "UTF8": 0x93
HINT: This error can also happen if the byte sequence does not match
the enco
On Sun, Sep 30, 2007 at 11:30:35PM -0400, Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
> >This morning's ecpg patch certainly seems to have been snake-bit.
> >Although the Windows gcc buildfarm members seem happy, the MSVC ones
> >are all failing with
> >
> >Linking...
> > Creating libra
On Sun, Sep 30, 2007 at 11:46:00PM -0400, Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > It is building with thread.c but it should not be unless I am misreading
> > the Makefile. The makefile processing in Project.pm doesn't look nearly
> > powerful enough to handle this:
>
>
On Fri, Sep 28, 2007 at 10:43:17PM +0200, Hannes Eder wrote:
> Hi,
>
> Starting from version VC7 msvc supports __FUNCTION__, so I think this
> could be enabled in pg_config.h.win32, see attached diff.
Applied, thanks.
//Magnus
---(end of broadcast)--
Hello,
I am having problems of productivity with IDE that I am using. Exists some
IDE that recommended to develop postgresql?
I am thankful,
--
Pedro Belmino.
On 9/22/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> Please try that experiment with all three configurations on both
> versions:
> * autovacuum off
> * autovacuum on, autovacuum_vacuum_cost_delay = 0
> * autovacuum on, autovacuum_vacuum_cost_delay = 20
I've finally found some
On 10/1/07, Pedro Belmino <[EMAIL PROTECTED]> wrote:
> Hello,
> I am having problems of productivity with IDE that I am using. Exists some
> IDE that recommended to develop postgresql?
Hello Pedro,
You are probably looking for a tool like pgAdmin (http://www.pgadmin.org) or
PhpPgAdmin (http://php
Guillaume Smet wrote:
> On 9/22/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Please try that experiment with all three configurations on both
>> versions:
>> * autovacuum off
>> * autovacuum on, autovacuum_vacuum_cost_delay = 0
>> * autovacuum on, autovacuum_vacuum_cost_delay
On Oct 1, 2007, at 10:27 , Adrian Maier wrote:
On 10/1/07, Pedro Belmino <[EMAIL PROTECTED]> wrote:
Hello,
I am having problems of productivity with IDE that I am using.
Exists some
IDE that recommended to develop postgresql?
Hello Pedro,
You are probably looking for a tool like pgAdmin
On 10/1/07, Guillaume Smet <[EMAIL PROTECTED]> wrote:
> * 8.3devel freshly compiled *
> - autovacuum off: 14m39
> - autovacuum on, delay 0: 15m32
> - autovacuum on, delay 20: 51m37 (the box is idle during a large
> amount of this time) - default configuration of 8.3devel
I made a few more tests w
Le lundi 01 octobre 2007, Michael Glaesemann a écrit :
> That may be what he means. Unfortunately "develop PostgreSQL" can be
> taken both ways.
>
> In case he's working on internals, I believe Emacs is used by a
> number of PostgreSQL hackers. And as for developing PostgreSQL-backed
> applications
Tom Lane wrote:
> I tried this program on Mac OS X 10.4.10 (the current release) and found
> out that what that OS mostly returns is the encoding portion of the
> locale name, for instance
FWIW I tried this program here, and I get
C ... ANSI_X3.4-1968 - NO MATCH
POSIX
Tom,
Maybe we need to actively discourage people from running Postgres
against NFS-mounted data directories. Shane Kerr's paper cited above
mentions some other rather scary properties, including O_EXCL file
creation not really working properly.
Wouldn't you be describing a Linux-specific issu
"Stefan Kaltenbrunner" <[EMAIL PROTECTED]> writes:
> some additional datapoints:
>
> autovacuum on, delay 20: 8h 40min
> autovacuum on, delay 0: 4h 23min
I realize this isn't directly addressing the problem but perhaps part of the
solution would be to start advocating the use of pg_restore -1 ?
Josh Berkus <[EMAIL PROTECTED]> writes:
>> Maybe we need to actively discourage people from running Postgres
>> against NFS-mounted data directories.
> It's hard to reconcile this with the real-world performance of
> PostgreSQL on NFS, which is happening all over the place. Most notably,
> Joe
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> FWIW I tried this program here, and I get
> C ... ANSI_X3.4-1968 - NO MATCH
> POSIX ... ANSI_X3.4-1968 - NO MATCH
> Note the funny name. Trying initdb with LC_ALL=C correctly uses
> SQL_ASCII (I saw the special
Thanks for this information. It was really helpful.
Another problem that is facing me is altering existing functions. For
example, what if I want to change the execution of the SUM function to work
as follows:
select sum(a)
from mytable w(5);
which means to sum only 5 records or records that
Gregory Stark <[EMAIL PROTECTED]> writes:
> I realize this isn't directly addressing the problem but perhaps part of the
> solution would be to start advocating the use of pg_restore -1 ? That would
> solve the problem for the narrow case of pg_restore.
Well, that would do as a quick workaround, a
Gregory Stark wrote:
> "Stefan Kaltenbrunner" <[EMAIL PROTECTED]> writes:
>
>> some additional datapoints:
>>
>> autovacuum on, delay 20: 8h 40min
>> autovacuum on, delay 0: 4h 23min
>
>
> I realize this isn't directly addressing the problem but perhaps part of the
> solution would be to start a
Islam Hegazy wrote:
Thanks for this information. It was really helpful.
Another problem that is facing me is altering existing functions. For
example, what if I want to change the execution of the SUM function to
work as follows:
select sum(a)
from mytable w(5);
which means to sum only 5
On 10/1/07, Michael Glaesemann <[EMAIL PROTECTED]> wrote:
>
> > Hello Pedro,
> >
> > You are probably looking for a tool like pgAdmin (http://
> > www.pgadmin.org) or
> > PhpPgAdmin (http://phppgadmin.sourceforge.net). There are also some
> > commercial applications : http://www.postgresql.org/do
If you are talking about working on the code (internals), I find eclipse
works very well for working on PostgreSQL.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Pedro Belmino
Sent: Monday, October 01, 2007 6:42 AM
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] IDE
Hel
On Mon, 2007-10-01 at 10:13 -0700, Josh Berkus wrote:
> > Maybe we need to actively discourage people from running Postgres
> > against NFS-mounted data directories. Shane Kerr's paper cited above
> > mentions some other rather scary properties, including O_EXCL file
> > creation not really worki
On Mon, 2007-10-01 at 19:36 +0100, Simon Riggs wrote:
> > I *do* think it's an accurate statement that if you're going to use
> > Postgres, or any other OLTP database, on NFS you'd better have access to
> > a NAS expert. But to say that it's a bad idea even if you have expert
> > help is proba
As discussed on -hackers, I'm trying to get rid of some redundant code
by creating a widely useful set of functions to convert between text
and C string in the backend.
The new extern functions, declared in include/utils/builtins.h and
defined in backend/utils/adt/varlena.c, are:
char * text_cstr
Heikki Linnakangas escribió:
> In my opinion, CREATE INDEX shouldn't need to wait for autovacuum to
> finish, regardless of who issued it. This is like priority inversion;
> the autovacuum is not urgent, and runs slowly to avoid disturbing
> others. But if it keeps the higher priority CREATE INDEX
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> This is an interesting idea, but I think it's attacking the wrong
> problem. To me, the problem here is that an ANALYZE should not block
> CREATE INDEX or certain forms of ALTER TABLE.
I doubt that that will work; in particular I'm pretty dubious that
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
This is an interesting idea, but I think it's attacking the wrong
problem. To me, the problem here is that an ANALYZE should not block
CREATE INDEX or certain forms of ALTER TABLE.
I doubt that that will work; in particular I'
Matthew T. O'Connor escribió:
> Tom Lane wrote:
>> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>>
>>> This is an interesting idea, but I think it's attacking the wrong
>>> problem. To me, the problem here is that an ANALYZE should not block
>>> CREATE INDEX or certain forms of ALTER TABLE.
>>
>>
On Mon, 2007-10-01 at 16:50 -0400, Alvaro Herrera wrote:
> > Can CREATE INDEX and ANALYZE be made to run concurrently?
>
> I don't see why not (except for the fact that both try to update
> reltuples and relpages AFAIR, so we would need to be careful about
> that).
This seems like the most desir
Simon Riggs <[EMAIL PROTECTED]> writes:
> We should not allow VACUUM to be concurrent with either CREATE INDEX or
> ANALYZE, but then thats not the problem here anyway.
I can't believe anyone is short-sighted enough to think that.
The problem here is that autovac takes locks that block foreground
Tom Lane escribió:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > We should not allow VACUUM to be concurrent with either CREATE INDEX or
> > ANALYZE, but then thats not the problem here anyway.
>
> I can't believe anyone is short-sighted enough to think that.
>
> The problem here is that autovac
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
>> Use BIO functions to avoid passing FILE * pointers to OpenSSL functions.
> Several buildfarm machines are failing:
http://www.openssl.org/docs/crypto/ERR_set_mark.html
says
ERR_set_mark() and ERR_pop_to_m
Tom Lane wrote:
If you insist on crafting a solution that only fixes this problem for
pg_restore's narrow usage, you'll be back revisiting it before beta1
has been out a month.
I don't know much about what is involved in crafting these solutions,
but it seems we're close to beta and probably
Simon Riggs <[EMAIL PROTECTED]> writes:
> http://blogs.netapp.com/dave/2007/08/oracle-optimize.html
Not a whole lot of technical content there, but pretty interesting
nonetheless. I *think* that the issues we're seeing are largely in the
NFS client-side kernel code, so bypassing that stack as Ora
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> So you say we should make any job that needs an exclusive lock on a
> table to be able to cancel a running autovac job?
I think we're going to be seeing complaints of this form until we do that.
The only reason this particular discussion is about pg_res
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> I don't know much about what is involved in crafting these solutions,
> but it seems we're close to beta and probably don't want to make drastic
> changes to anything. As such it seems to me that solving the problem
> for analyze is a nice pie
[ on further thought ]
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
>> ... solving the problem
>> for analyze is a nice piece of low-hanging fruit that solves an
>> immediate problem that has been reported.
Actually, if you wanted a low-hanging solution to that, it would
probably be to rev
Tom Lane escribió:
> [ on further thought ]
>
> "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> >> ... solving the problem
> >> for analyze is a nice piece of low-hanging fruit that solves an
> >> immediate problem that has been reported.
>
> Actually, if you wanted a low-hanging solution t
Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > http://blogs.netapp.com/dave/2007/08/oracle-optimize.html
>
> Not a whole lot of technical content there, but pretty interesting
> nonetheless. I *think* that the issues we're seeing are largely in the
> NFS client-side kernel code, so
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> How about getting ShareUpdateExclusiveLock on manual analyze and plain
> AccessShareLock on autovacuum-induced analyze?
Wouldn't fix the original problem because those two lock types don't
conflict; hence might as well keep the behavior simple.
I wrote:
> http://www.openssl.org/docs/crypto/ERR_set_mark.html
> says
> ERR_set_mark() and ERR_pop_to_mark() were added in OpenSSL 0.9.8.
> Ooops. Back to the drawing board.
To get the buildfarm going again, I applied a patch that turns these
calls into no-ops if the local OpenSSL hasn't got th
dugong (icc on ia64) has been failing the contrib installcheck consistently
since 6 days ago with errors like:
ERROR: could not fsync segment 0 of relation 1663/40960/41403: No such file or
directory
I checked a cvs diff between the two timestamps and that's precisely when the
self-adjusting b
"Gregory Stark" <[EMAIL PROTECTED]> writes:
> dugong (icc on ia64) has been failing the contrib installcheck consistently
> since 6 days ago with errors like:
>
> ERROR: could not fsync segment 0 of relation 1663/40960/41403: No such file
> or directory
>
> I checked a cvs diff between the two t
Gregory Stark <[EMAIL PROTECTED]> writes:
> dugong (icc on ia64) has been failing the contrib installcheck consistently
> since 6 days ago with errors like:
> ERROR: could not fsync segment 0 of relation 1663/40960/41403: No such file
> or directory
Yeah, I already asked Sergey about this but I
Gregory Stark <[EMAIL PROTECTED]> writes:
> And given the consistency and the fact that the other icc machines
> didn't show the same problems it sounds like it's something about that
> machine, not a software problem.
Well, we haven't *got* any other icc-on-ia64 machines AFAICS, so it
could easil
On Tue, 2 Oct 2007, Gregory Stark wrote:
> (we don't seem to have a recent icc ia32 build farm member).
Sorry about that, my buildfarm member (mongoose) is down with hardware
problems, and probably will be for the forseeable future. For some
reason, it suddenly decided to stop recognizing its RA
> > http://www.openssl.org/docs/crypto/ERR_set_mark.html
> > says
> > ERR_set_mark() and ERR_pop_to_mark() were added in OpenSSL 0.9.8.
>
> > Ooops. Back to the drawing board.
>
> To get the buildfarm going again, I applied a patch that turns these
> calls into no-ops if the local OpenSSL hasn't
> > http://www.openssl.org/docs/crypto/ERR_set_mark.html
> > says
> > ERR_set_mark() and ERR_pop_to_mark() were added in OpenSSL 0.9.8.
>
> > Ooops. Back to the drawing board.
>
> To get the buildfarm going again, I applied a patch that turns these
> calls into no-ops if the local OpenSSL hasn't
50 matches
Mail list logo