Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> >>> It would also be handy if users could see their own queries while the
> >>> rest remain blank.
> >>
> >> Seems reasonable offhand ...
>
> > Here's the patch to make this happen. The first is against 7.2.4, the
> > second is against
Kevin Brown <[EMAIL PROTECTED]> writes:
>>> It would also be handy if users could see their own queries while the
>>> rest remain blank.
>>
>> Seems reasonable offhand ...
> Here's the patch to make this happen. The first is against 7.2.4, the
> second is against CVS tip.
You forgot documentati
Will get that fixed this aft (just spent the past 24hrs recovering from a
RAID controller going south, need sleep *sigh*) ... I'm the one that put
those great (and useless) descriptions in, sorry :)
On Thu, 6 Mar 2003, Christopher Kings-Lynne wrote:
> Hi,
>
> I tried to go buy a shirt off the pg
'K, that's what I ended up doing ... the server crashed *really* hard, but
I had a backup from 24hrs previous that I used to do restores ... I kinda
figured that I was lost :(
But, the files available are/where ...
venus# ls -lt
total 1168
-rw--- 1 pgsql pgsql 81920 Mar 6 19:50 0168
-rw
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> FATAL 2: open of /usr/local/pgsql/5432/pg_clog/06F6 failed: No such file or
> directory
> The RAID controller went on our server today ... is it safe to just
> 'touch' the files, or is this a 'restore from backup and deal with the
> losses' sort o
Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
[...]
> > It would also be handy if users could see their own queries while the
> > rest remain blank. That would require changing
> > pg_stat_get_backend_activity() so that it returns a value if the user
> > is the superuser or if the us
Any way to recover?
FATAL 2: open of /usr/local/pgsql/5432/pg_clog/06F6 failed: No such file or directory
The RAID controller went on our server today ... is it safe to just
'touch' the files, or is this a 'restore from backup and deal with the
losses' sort of thing? :(
> The optimizer does not think that "pbx_date = CURRENT_DATE" satisfies the
> partial index's WHERE condition. I don't see any really good way around
> this; to improve matters there'd need to be some concept of a plan that
> is only good for a limited time.
It's the same as the slight issue I ha
> Was this resolved. Christopher, do you have a reproducible case?
Oh sorry, I answered the wrong question!
Yes, I resolved it by reinstalling my DBD perl stuff.
I still have the problem of left over constraint triggers, but they do look
like they're broken, so it's not an adddepend problem...
> Was this resolved. Christopher, do you have a reproducible case?
It wasn't resolved, in fact I'd forgotten about it :)
I do have a reproducible case (our live server), however it seems like it's
basically a case of an invalid set of triggers. I really need to manually
remove some of the trigg
> > As I said in the previlus mails, open()+_commit() does the
> > right job with the transaction log files. So probably I think
> > I should stick with open()+_commit() approach for ordinary
> > table/index files too.
>
> Oh, I didn't see that message. So it's either:
>
> open() + _commit()
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> So I imagine, if this is done fully with changes in the protocol layer,
> then certain commands like "get table schema in XML" would have to exist
> in the protocol, which doesn't seem right. Also, the XML output isn't a
> sibling of the current text/
Tom Lane writes:
> This is also a good time to stop and ask whether the frontend/backend
> protocol needs to change to support this. Not having read the spec,
> I have no idea what the low-level transport needs are for XML output,
> but I suspect our present protocol is not it ...
The spec defin
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
> > Taking it a bit further...
>
> There are (at least) two distinct problems involved here. One is
> getting plpgsql to deal correctly with rowtypes that include dropped
> columns. The other is getting it to react when someone alters a ta
The platypus model he has has an external PSU. The external PSU can be
easily plugged into an UPS. Thus if the main system is shut down as long
as the UPS lives and/or there is power otherwise to the external PSU, the
card will keep the data.
--On Thursday, March 06, 2003 11:16 PM +0200 Hannu
mlw kirjutas K, 05.03.2003 kell 22:05:
> The idea of a RAM disk based database and reliable storage are in
> complete opposition. Forget it.
I read from his post that the Platypus RAM disk _is_ his reliable
storage, just with some peculiar characteristics, like big transfer
speeds and uniform sup
Hannu Krosing kirjutas T, 04.03.2003 kell 22:57:
> Chris Sutton kirjutas T, 04.03.2003 kell 17:03:
> > Hello,
> >
> > I need some insight on the best way to use a RAM drive in a Postgresql
> > installation. Here is our situation and current setup:
> >
> > Postgresql 7.2.1
> > Dual PIII 800
> >
UnsubscribeMSN 8 helps ELIMINATE E-MAIL VIRUSES. Get 2 months FREE*.
Merlin Moncure wrote:
-Original Message-
From: mlw [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 05, 2003 3:47 PM
To: [EMAIL PROTECTED]
Subject: [HACKERS] Aggregate "rollup"
I had written a piece of code about two years ago that used the
aggregate feature of PostgreSQL to create an ar
> -Original Message-
> From: mlw [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 05, 2003 3:47 PM
> To: [EMAIL PROTECTED]
> Subject: [HACKERS] Aggregate "rollup"
>
> I had written a piece of code about two years ago that used the
> aggregate feature of PostgreSQL to create an array of i
Rod Taylor <[EMAIL PROTECTED]> writes:
> On Thu, 2003-03-06 at 11:49, Tom Lane wrote:
>> The implementation I've had in mind for autovacuum would rely on FSM not
>> the pg_stats daemon.
> FSM as I understand it gets it information from vacuum, and has an space
> marker removed when an insert uses
On Thu, 2003-03-06 at 11:49, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > Not if we expect pg_autovacuum to be able to work. It *needs* this
> > information.
>
> Why?
>
> The implementation I've had in mind for autovacuum would rely on FSM not
> the pg_stats daemon.
FSM as I unde
Rod Taylor <[EMAIL PROTECTED]> writes:
> Not if we expect pg_autovacuum to be able to work. It *needs* this
> information.
Why?
The implementation I've had in mind for autovacuum would rely on FSM not
the pg_stats daemon.
regards, tom lane
---(end
On Thu, 2003-03-06 at 11:43, Rod Taylor wrote:
> Not if we expect pg_autovacuum to be able to work [ by default ]
I don't regard that as a very high priority at this stage of the game:
since I think pg_avd should be in contrib/ for the next release at the
very least, I don't think anyone capable o
On Thu, 2003-03-06 at 09:16, Rod Taylor wrote:
> Anyway, the basic proposal would be to change the on / off flags for row
> & block level into a 'stats delay'. A large number would be off, 0
> would have the same properties as today. Default to be determined (but
> 1 second seems to be plenty).
On Thu, 2003-03-06 at 11:40, Neil Conway wrote:
> On Thu, 2003-03-06 at 09:16, Rod Taylor wrote:
> > Anyway, the basic proposal would be to change the on / off flags for row
> > & block level into a 'stats delay'. A large number would be off, 0
> > would have the same properties as today. Default
My experience with windows backend work is that you have to turn off all
buffering and implement your own write cache of sorts. Flushing is not
the only reason: heavy buffering of files (the default behavior) also
tends to thrash the server, because the cache does not always release
memory properl
I can comment on this --- adding a feature isn't zero cost. There is
maintenance, but the larger cost is of users wading through features to
figure out if they need it or not. We don't want to bloat ourselves to
the point PostgreSQL becomes harder to use.
Let's face it, you have to understand a
[EMAIL PROTECTED] wrote:
How about putting a README file in that directory as well, giving out
the same warnings and contact information that appears upon install?
Thanks Greg, excellent suggestion.
Just added it to my personal ToDo list.
:)
Regards and best wishes,
Justin Clift
- --
Greg S
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> I really should fix this rowtype problem for 7.3.3 - here's hoping I find
> some time...
I think it'll be too large and risky a change to put into 7.3.* in any
case. Maybe you'll find some brilliant, obviously-correct solution ---
but I'm be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I think for processing-oriented output, the system described in the
> SQL/XML standard draft is the way to go. Considering the people who wrote
> it, it's probably pulled from, or bound to appear in, a major commercial
> database.
Do you have a l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I'm open to suggestions for making a more visible way for people to know
> how to contact us, if needed.
How about putting a README file in that directory as well, giving out
the same warnings and contact information that appears upon install?
> > Are you asking the way how to open files in the buffer
> > manager? If so, basically PostgreSQL uses open() with flags
> > (O_RDWR | PG_BINARY, 0600).
>
> I cannot find it now, but I'm sure I read that FlushFileBuffers() has no
> effect unless the file was opened with CreateFile() with the
>
On Thu, 2003-03-06 at 09:58, Bruce Momjian wrote:
> Was this resolved. Christopher, do you have a reproducible case?
I've not been able to reproduce it, nor have I had a similar complaint.
I think it's a system configuration issue or somekind. Otherwise there
would have been many many more comp
> Agreed, but I still keep thinking that despite some peoples
> claims that Windows ain't up to it, DB2, SQL and Exchange
> Server as well a probably others that don't use raw
> partitions have got over this problem, so therefore we should
> be able to. Admittedly Microsoft have a bit of an adv
Was this resolved. Christopher, do you have a reproducible case?
---
Rod Taylor wrote:
-- Start of PGP signed section.
> > I worked around it by checking to see if it equalled '' as
> > well as ''. I also have hea
> -Original Message-
> From: Tatsuo Ishii [mailto:[EMAIL PROTECTED]
> Sent: 06 March 2003 14:00
> To: Dave Page
> Cc: [EMAIL PROTECTED]
> Subject: Re: [HACKERS] Win32 Powerfail testing
>
>
> > > Sorry, but it does not help. The page says we could use
> > > FlushFileBuffers() to sync th
Peter Eisentraut wrote:
Justin Clift writes:
>
Yep, that's the first "Proof of Concept" build, and it *prominently* has
a message at the start of the installation that says to email me with
any problems about it.
Maybe a so-called "Proof of Concept" build could be put into an area on
the FTP server
On Thu, 2003-03-06 at 01:13, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > [ optimizing for small frequent queries ]
>
> What if the client doesn't come back with another query for awhile?
Yup.. Thats why I said you basically lose 1 seconds worth of stats (or
rather can't count on
> > Sorry, but it does not help. The page says we could use
> > FlushFileBuffers() to sync the kernel buffer to the
> > disk. Unfortunately, it requires a file descriptor to flush
> > for its argument. Thus it could not be a replacement of
> > sync(). Actually I have modified the buffer manager s
Justin Clift writes:
> Yep, that's the first "Proof of Concept" build, and it *prominently* has
> a message at the start of the installation that says to email me with
> any problems about it.
Maybe a so-called "Proof of Concept" build could be put into an area on
the FTP server that conveys that
> -Original Message-
> From: Tatsuo Ishii [mailto:[EMAIL PROTECTED]
> Sent: 05 March 2003 13:49
> To: Dave Page
> Cc: [EMAIL PROTECTED]
> Subject: Re: [HACKERS] Win32 Powerfail testing
>
>
> > > So far we found interesting facts. Our Win32 port passes his
> > > test in most cases. Howe
Hi everyone,
Just received notification the server hosting the postgresql.org
websites suffered a catastrophic failure a few hours ago.
The admin guys are working to fix it, but it could take at least another
8 hours (no guarantee's here).
No more detailed info at present, but will keep everyo
> -Original Message-
> From: Kevin Brown [mailto:[EMAIL PROTECTED]
> Sent: 06 March 2003 04:37
> To: [EMAIL PROTECTED]
> Subject: Re: [HACKERS] Win32 Powerfail testing
>
>
> Tatsuo Ishii wrote:
> > Sorry, but it does not help. The page says we could use
> > FlushFileBuffers() to sync t
> It would be an interesting comparison for you to roll the file
> descriptor tracking changes into the Unix side of the tree and use
> fsync() or fdatasync() in place of FlushFileBuffers() on the Unix side
> (you'd have to remove or disable the code that does a sync() of
> course). If the end res
>
> Given the repeatedly-asked-for functionalities (like error codes)
> for which the stopper has been the long-threatened protocol revision,
> I'd think it might be boring, but would hardly be thankless. Heck, I'd
> expect a few whoops of joy around the lists.
>
Yes. Error codes would be great.
Christopher Kings-Lynne wrote:
Feels like we've been isolating a whole bunch of bugs in 7.3.2 recently,
some of which are causing crashes out in the real world.
Wondering when we feel it'd be good to start assembling a 7.3.3? I'm
thinking in about two weeks or so, to give a bit more time to catch
47 matches
Mail list logo
