"Dan Langille" <[EMAIL PROTECTED]> writes:
> Now that my NZ server is up and running:
> template1=# select now();
> 2003-07-05 12:47:15.444535+12
> That doesn't look backwards to me.
Try EXTRACT(timezone_hour from now());
The timestamp I/O routines are using what I think is the correct sign.
EX
Tom Lane wrote:
1. Does this approach seem like a reasonable solution to our problem
of some machines having unrealistically small kernel limits on shared
memory?
Yes, it does to me.
2. If so, can I get away with applying this post-feature-freeze? I can
argue that it's a bug fix, but perhaps some
Gud day! We are currently having our thesis for our undergarduate course and this involoves the code of PostgreSQL. Basically, our thesis needs a modification of the existing code of the said database. As of now, our University has an existing online registration system which uses Postgre as their
On 3 Jul 2003 at 13:18, Tom Lane wrote:
> Comments?
Now that my NZ server is up and running:
template1=# select now();
now
---
2003-07-05 12:47:15.444535+12
That doesn't look backwards to me. Perhaps I don't understand the
problem. After rereading y
On Fri, 4 Jul 2003, David Blasby wrote:
> > My first guess would be that you're not running in "C" locale
> > on the 7.3 system. I get false on my 7.3.1 system in C locale,
> > but if I compare the two strings in C using en_US for example I
> > seem to get results like the above ('_'<'5' is true
My first guess would be that you're not running in "C" locale
on the 7.3 system. I get false on my 7.3.1 system in C locale,
but if I compare the two strings in C using en_US for example I
seem to get results like the above ('_'<'5' is true).
It turns out our 7.3 database was somehow initd with lo
On Friday 04 July 2003 13:31, Michael Meskes wrote:
> On Fri, Jul 04, 2003 at 03:29:37PM -0400, Tom Lane wrote:
> > 2. If so, can I get away with applying this post-feature-freeze? I can
> > argue that it's a bug fix, but perhaps some will disagree.
>
> I'd say it is a bug fix.
>
> Michael
I'm wi
On Fri, 4 Jul 2003, David Blasby wrote:
> I noticed a change between our 7.2 and 7.3 postgresql database.
>
> On 7.2:
>
> template1=> select '_' < '5';
> ?column?
> --
> f
> (1 row)
>
>
>
> On 7.3:
>
> template1=# select '_' < '5';
> ?column?
> --
> t
> (1 row)
>
>
> Any
I noticed a change between our 7.2 and 7.3 postgresql database.
On 7.2:
template1=> select '_' < '5';
?column?
--
f
(1 row)
On 7.3:
template1=# select '_' < '5';
?column?
--
t
(1 row)
Any reason for this change?
dave
---(end of broadcast)
On Fri, Jul 04, 2003 at 10:49:01AM -0400, Rod Taylor wrote:
> > In my opinion the defaults should be set up for a typical database
> > server machine.
>
> Ok.. thats fair. The first problem would be to define typical for
> current PostgreSQL installations, and typical for non-postgresql
> install
On Fri, Jul 04, 2003 at 03:29:37PM -0400, Tom Lane wrote:
> 2. If so, can I get away with applying this post-feature-freeze? I can
> argue that it's a bug fix, but perhaps some will disagree.
I'd say it is a bug fix.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De
ICQ: 179140304,
The attached patch shows how initdb can dynamically determine reasonable
shared_buffers and max_connections settings that will work on the
current machine. It consists of two trivial adjustments: one rips out
the "PrivateMemory" code, so that a standalone backend will allocate a
shared memory segm
> > I wonder how Postgres handles this situation.
> > (Or power outage, or any hard system fault, at this point)
>
> Theoretically we should be able to recover from this without loss of
> committed data (assuming you were running with fsync on). Is your QA
> person certain that the record in ques
On Fri, Jul 04, 2003 at 11:23:57 -0700,
Joe Conway <[EMAIL PROTECTED]> wrote:
>
> Thanks, Tom. It does at least compile cleanly now. I don't use ecpg, so
> I can't say whether the changes actually work.
I am still seeing the problem in anoncvs, but I seem to remember there being
a lag between
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Yeah, I've been getting that since Wednesday morning (west coast USA
time), and reported it Wednesday evening, but no one else has replied to
that post, so I thought maybe it was somehow related to the othee ecpg
issues being discussed.
I
Joe Conway <[EMAIL PROTECTED]> writes:
> Yeah, I've been getting that since Wednesday morning (west coast USA
> time), and reported it Wednesday evening, but no one else has replied to
> that post, so I thought maybe it was somehow related to the othee ecpg
> issues being discussed.
I've commit
Bruno Wolff III wrote:
I get the following compilation error when making postgres from current CVS:
timestamp.c: In function `tm2timestamp':
timestamp.c:69: warning: implicit declaration of function `elog'
timestamp.c:69: `ERROR' undeclared (first use in this function)
timestamp.c:69: (Each undecla
Michael Brusser <[EMAIL PROTECTED]> writes:
> Apparently we managed to run out of the open file descriptors on the host
> machine.
This is pretty common if you set a large max_connections value while
not doing anything to raise the kernel nfile limit. Postgres will
follow what the kernel tells it
Hi,
I've been using pg_autovacuum for a couple of weeks now, and have noticed one
weird little bug: sometimes the daemon calculates it used a negative amount of
time for the last vacuum it did, and waits no time at all before checking if
it needs to run anything again. Sample output:
2411 All DBs
We ran into problem while load-testing 7.3.2 server.
>From the database log:
FATAL: cannot open /home//postgresql/PG_VERSION:
File table overflow
The QA engineer who ran the test claims that after server was restarted
one record on the database was missing.
We are not sure what exactly happened.
I get the following compilation error when making postgres from current CVS:
timestamp.c: In function `tm2timestamp':
timestamp.c:69: warning: implicit declaration of function `elog'
timestamp.c:69: `ERROR' undeclared (first use in this function)
timestamp.c:69: (Each undeclared identifier is repor
Weiping He <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I think Bruce already fixed this. How old is your CVS pull?
> upgraded this morning, around 2003-07-04 09:29:00 CST or 2003-07-03
> 17:29:00 PST.
> and later I add a
> #include
Yeah, that is the correct fix, and Bruce did fix it on We
Tom Lane wrote:
I think Bruce already fixed this. How old is your CVS pull?
regards, tom lane
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
upgraded this morning, around 2003-07-04 09:29:00 CST or 2003
Well, I doubt what is right way.
tsearch V2 use new names, new function new feature and hasn't compatibility with
old one.
1 tsearch2 and tsearch directory in contrib. tsearch marked as deprecated and
will be removed for 7.5
2 V2 places in contrib as tsearch, old tsearch will be at our site.
It
Moving to -hackers.
> In my opinion the defaults should be set up for a typical database server
> machine.
Ok.. thats fair. The first problem would be to define typical for
current PostgreSQL installations, and typical for non-postgresql
installations (the folks we want to convert).
After that,
Weiping He <[EMAIL PROTECTED]> writes:
> I'm trying to compile pgsql-7.4devl on Solaris8, but got the error
> below:
I think Bruce already fixed this. How old is your CVS pull?
regards, tom lane
---(end of broadcast)--
> So, for upgrading tsearch to V2 you need to do following:
> 1 rename columns or typecast for type txtidx to tsvector, query_txt to tsquery
> 2 rename function txt2txtidx to to_tsvector, ( may be to strip(to_tsvector()),
>now tsvector has information for ranking ), trigger 'tsearch' isn't cha
"Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> ... I would have thought 'terse' would include the error number. Even
> _just_ the error number.
Well, we can talk about that, but remember this is psql's take on what
to display, not anyone else's. IMHO it should be designed for human
readability
Chris,
what if we write, that old tsearch (v1) is deprecated in 7.4 and will be
obsoleted in 7.5 and put tsearch-v1.tar.gz on our site.
Oleg
On Fri, 4 Jul 2003, Teodor Sigaev wrote:
> I think with upgrade X.Y to X.Y+1 version of pgsql you need dump/restore all
> databases, isn't it?
>
>
I think with upgrade X.Y to X.Y+1 version of pgsql you need dump/restore all
databases, isn't it?
So, for upgrading tsearch to V2 you need to do following:
1 rename columns or typecast for type txtidx to tsvector, query_txt to tsquery
2 rename function txt2txtidx to to_tsvector, ( may be to stri
On Thursday 03 July 2003 12:32, A. van Roggen wrote:
> If you ever have read the instruction books for e.g. early VCR
> recorders, translated from the original Japanese to English, you will know
> exactly what I mean. Proper translation is not an easy job, and
> volunteers from another branch of t
It's rumoured that Josh Berkus once said:
> Guys,
>
>> On Fri, Jun 13, 2003 at 10:18:06PM +0100, Dave Page wrote:
>> > Yes, this is expected. Currently the website is not being mirrored
>> > due to it's dependency on a backend database. We are considering
>> > different ways of overcoming this prob
32 matches
Mail list logo
