On Fri, 23 Jan 2004, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom's answer will be undoubtly better ...
>
> Nope, I think you got all the relevant points.
>
> The only thing I'd add after having had more time to think about it is
> that this seems very much like the problem
On Sat, 24 Jan 2004, Satoshi Nagayasu wrote:
> OK.
> I've started working on the PostgreSQL-KNOPPIX English version.
Satoshi ... Robert Bernier just reminded me that we currently have an
English version sitting in our office ... Of course, I don't have it here
with me, but maybe Robert can commen
Steve Atkins wrote:
> (I hope this is -hackers appropriate - feel free to point me elsewhere)
>
> I'm using 7.4.1 as the backend to several applications. Until recently,
> I've been developing solely single-threaded applications.
>
> I just rebuilt postgresql with --enable-thread-safety, to work
Jean-Michel,
> Morphix is an auto-bootable Debian GNU/Linux distribution based on Knoppix.
>
> What makes Morphix different is that the project has several graphical
> installers and wizards in preparation (written in plain C, using GTK-2
> libraries and Glade-2) ... which could possibly be used t
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom's answer will be undoubtly better ...
Nope, I think you got all the relevant points.
The only thing I'd add after having had more time to think about it is
that this seems very much like the problem we noticed recently with
recovery-from-WAL being
Dennis Haney <[EMAIL PROTECTED]> writes:
> But this limited optimization makes me wonder, why the limitation to
> optimizing '='?
In the first place, you wouldn't get any improvement anyway if the
combining operator is not '=' --- if it isn't, then merge and hash join
aren't applicable and so you
Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > Are you interested in real backtraces, any of the old data directory,
> > etc. to debug the problem?
>
> If you could recompile with debug support and get a backtrace from the
> panic, it would be helpful. I suspect what w
Bruce Momjian wrote:
Andrew Dunstan wrote:
Tom Lane said:
Actually, I was expecting you to complain that the s_lock.h coding is
gcc-specific. Which compilers do we need to support on Windows?
AFAIK the only target build environment for Windows right now is MinGW/gcc
If anyone kn
On Fri, Jan 23, 2004 at 04:21:04PM -0500, Tom Lane wrote:
> But the clog access code evidently got confused by being asked to read
> a page that didn't exist in the file. I'm not sure yet how that
> sequence of events occurred, which is why I asked Chris for a stack
> trace.
There was a very sim
Rod Taylor <[EMAIL PROTECTED]> writes:
> Granted, running out of diskspace is a bad idea, but can (has?)
> something be put into place to prevent manual intervention from being
> required in restarting the database?
See subsequent discussion. I do want to modify the code to avoid this
problem in
On Fri, Jan 23, 2004 at 05:58:33PM -0300, Martín Marqués wrote:
> Tom, could you give a small insight on what occurred here, why those 8k of zeros
> fixed it, and what is a "WAL replay"?
If I may ...
- the disk filled up
- Postgres registered something in WAL that required some commit status
(
=?iso-8859-1?b?TWFydO1uIA==?= =?iso-8859-1?b?TWFycXXpcw==?= <[EMAIL PROTECTED]> writes:
> Tom, could you give a small insight on what occurred here, why those
> 8k of zeros fixed it, and what is a "WAL replay"?
I think what happened is that there was insufficient space to write out
a new page of t
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Are you interested in real backtraces, any of the old data directory,
> etc. to debug the problem?
If you could recompile with debug support and get a backtrace from the
panic, it would be helpful. I suspect what we need to do is make the
clo
On Fri, 2004-01-23 at 16:00, Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > Now I can start it up! Thanks!
>
> > What should I do now?
>
> Go home and get some sleep ;-). If the WAL replay succeeded, you're up
> and running, nothing else to do.
Granted, running out o
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 23, 2004 1:01 PM
> To: Christopher Kings-Lynne
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] Disaster!
>
>
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > Now I can start it up! Th
What should I do now?
Go home and get some sleep ;-). If the WAL replay succeeded, you're up
and running, nothing else to do.
Cool, thanks heaps Tom.
Are you interested in real backtraces, any of the old data directory,
etc. to debug the problem?
Obviously it ran out of disk space, but surely
Mensaje citado por Tom Lane <[EMAIL PROTECTED]>:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > Now I can start it up! Thanks!
>
> > What should I do now?
>
> Go home and get some sleep ;-). If the WAL replay succeeded, you're up
> and running, nothing else to do.
Tom, could you gi
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Now I can start it up! Thanks!
> What should I do now?
Go home and get some sleep ;-). If the WAL replay succeeded, you're up
and running, nothing else to do.
regards, tom lane
---(end of bro
Mensaje citado por Christopher Kings-Lynne <[EMAIL PROTECTED]>:
> > I'd suggest extending that file with 8K of zeroes (might need more than
> > that, but probably not).
>
> How do I do that? Sorry - I'm not sure of the quickest way, and I'm
> reading man pages as we speak!
# dd if=/dev/zeros o
I'd suggest extending that file with 8K of zeroes (might need more than
that, but probably not).
OK, I've done
dd if=/dev/zero of=zeros count=16
Then cat zero >> 000D
Now I can start it up! Thanks!
What should I do now?
Chris
---(end of broadcast)
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> I'd suggest extending that file with 8K of zeroes (might need more than
>> that, but probably not).
> How do I do that? Sorry - I'm not sure of the quickest way, and I'm
> reading man pages as we speak!
Something like "dd if=/dev/zero bs=8k
I'd suggest extending that file with 8K of zeroes (might need more than
that, but probably not).
How do I do that? Sorry - I'm not sure of the quickest way, and I'm
reading man pages as we speak!
Thanks Tom,
Chris
---(end of broadcast)---
TIP 4:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> We ran out of disk space on our main server, and now I've freed up
> space, we cannot start postgres!
> Jan 23 12:18:51 canaveral postgres[563]: [7-1] PANIC: could not access
> status of transaction 14286850
> Jan 23 12:18:51 canaveral postg
> -Original Message-
> From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 23, 2004 12:29 PM
> To: PostgreSQL-development
> Cc: Tom Lane
> Subject: [HACKERS] Disaster!
>
>
> We ran out of disk space on our main server, and now I've freed up
> space, we cannot
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> In theory there should be a section at the head of release.sgml
>> mentioning the major changes done-so-far, but for various reasons
>> this hasn't gotten installed in the 7.5 branch yet. (Look at the
>> CVS versions
pg_clog information:
# cd pg_clog
# ls -al
total 3602
drwx-- 2 pgsql pgsql 512 Jan 23 03:49 .
drwx-- 6 pgsql pgsql 512 Jan 23 12:30 ..
-rw--- 1 pgsql pgsql 262144 Jan 18 19:43
-rw--- 1 pgsql pgsql 262144 Jan 18 19:43 0001
-rw--- 1 pgsql pgsql 262144 Ja
We ran out of disk space on our main server, and now I've freed up
space, we cannot start postgres!
Jan 23 12:18:50 canaveral postgres[563]: [2-1] LOG: checkpoint record
is at 2/96500B94
Jan 23 12:18:50 canaveral postgres[563]: [3-1] LOG: redo record is at
2/964BD23C; undo record is at 0/0; s
Tom Lane <[EMAIL PROTECTED]> writes:
> In theory there should be a section at the head of release.sgml
> mentioning the major changes done-so-far, but for various reasons
> this hasn't gotten installed in the 7.5 branch yet. (Look at the
> CVS versions during 7.4 development to see how we did it l
Tom Lane wrote:
Dennis Haney <[EMAIL PROTECTED]> writes:
I saw it as though convert_IN_to_join rewrote the query from
select a.* from tenk1 a where a.unique1 in
(select c.thousand from tenk1 c where c.hundred = 99);
to
select a.* from te
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> If the TODO-list-with-dash isn't the correct place to have looked, is
> there another list of committed changes for the next release?
We tend to rely on the CVS commit logs as the definitive source. You
can pull the info from the CVS server (I use cvs2c
Tom Lane wrote:
> ow <[EMAIL PROTECTED]> writes:
> > Is this all that's planned for 7.5? (based on current TODO list)
>
> If you think the TODO list has *anything* to do with release planning,
> you fundamentally misunderstand the way things are done around here.
>
> The TODO list is a list of th
ow wrote:
> Hi,
>
> Is this all that's planned for 7.5? (based on current TODO list)
>
> -Change factorial to return a numeric (Gavin)
> -COMMENT ON [ CAST | CONVERSION | OPERATOR CLASS | LARGE OBJECT | LANGUAGE ]
> (Christopher)
> -Have psql \dn show only visible temp schemas using current_schem
Hi everyone,
Since yesterday I've noticed the errors bellow on one on the most updated
tables in a database.
This db is vaccumed analyzed every half an hour...
Any idea what could cause it and if I could loose data?
Regards
--
Jan 23 13:32:09 server postgres[2425]: [6] WARNING: Rel sessions_lo
Simon,
thanks for the time to give this further thought.
Simon Riggs wrote:
If we know ahead of time that a large scan is going to have this effect,
why wait for the ARC to play its course, why not take exactly the same
action?
Have large scans call StrategyHint also. (Maybe rename it...?)...of
c
> Jan Wieck wrote:
>
> have you read src/backend/storage/buffer/README of current CVS tip?
>
> The algorithm in the new replacement strategy is an attempt to figure
> that SMALL_TABLE_THRESHOLD automatically. Do you see anything that can
> be improved in that algorithm?
>
Jan,
I've read src/ba
> Jan Wieck wrote:
>
> have you read src/backend/storage/buffer/README of current CVS tip?
> Tom Lane wrote:
>
> Um, did you read the discussion of the ARC buffer management algorithm
> that's already been implemented for 7.5?
>
Tom, Jan,
No, I hadn't read this. Thank you both for your time an
Le Vendredi 23 Janvier 2004 03:08, Satoshi Nagayasu a écrit :
> If you want to install to your hard drive, KNOPPIX installation script
> can help you.
> However, I think "without any installation" is more important for
> newbies.
> Any comments?
Dear Satoshi,
Your Knoppix-based CD-ROM is a great
Dann Corbit wrote:
But for now I suggest that the default prefix on Windows is
C:\Program Files\PostgreSQL
More properly:
%ProgramFiles%\PostgreSQL
Another suggestion: %ProgramFiles%\PGDG\PostgreSQL (or even
%ProgramFiles%\PGDG\PostgreSQL 7.5). Apache2 uses %ProgramFiles%\Apache
Group\Apache2.
N
38 matches
Mail list logo
