> > > It will be sufficient if DB will not use all 2^32 XIDs
> > > without shutdown.
> >
> > I liked the xid wraparound idea, won't that be sufficient here too ?
> > I don't like the idea to reuse a xid sooner than absolutely necessary.
>
> We need it to reduce pg_log size requirements.
Yes,
Tom Lane wrote:
>
> "Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> >> That'll be true in any case, unless we refuse to start up at all upon
> >> detecting xlog corruption (which doesn't seem like the way to fly).
> >> Not sure what we can do about that.
>
> > What I would refuse in the event of
"Mikheev, Vadim" wrote:
>
> > >> What I was thinking about in that last paragraph was manual
> > >> analysis and recovery. I don't think it's a good idea for automatic
> > >> system startup to skip over gaps in the log.
> >
> > > But if we'll not try to read after gap then after restart
> > > syst
Maybe there should be an error message like :
"PostgreSQL has detected severe xlog corruption. Please fix this with
pg_recover (or similar) manually before restarting the database"?
Guess I'm suggesting a separate xlog recovery tool for "bad cases" of
xlog corruption, so decisions can by manual
Hi Guys,
I'd just like to point out that for most secure installations, X is
removed from servers as part of the "remove all software which isn't
absolutely needed."
I know of Solaris machines which perform as servers with a total of 19
OS packages installed, and then precompiled binaries of the
contrib/pg_resetxlog is checked in. It's not really complete for the
interesting cases (ie, recovery from damaged files) but it does handle
the simple case of upgrading from 7.1beta5 to current sources.
To use: see contrib/pg_resetxlog/README.pg_resetxlog.
regards, tom l
> >> That'll be true in any case, unless we refuse to start up at all upon
> >> detecting xlog corruption (which doesn't seem like the way to fly).
> >> Not sure what we can do about that.
> > What I would refuse in the event of log corruption is continuing
> > normal database operations.
> Hmm.
On Tue, 13 Mar 2001, Alfred Perlstein wrote:
[..]
> Linux does not filesystem-sync file-backed writable mmap pages on a
> regular basis.
Very intersting. I'm not sure that is necessarily the case in
2.4, though -- my understanding is that the new all-singing,
all-dancing page cache makes very l
* Thomas Swan <[EMAIL PROTECTED]> [010313 13:37] wrote:
>
> >On reciept of the info signal, the backends collaborate to piece
> >together a status file. The status file is given a temporay name.
> >When complete the status file is rename(2)'d over a well known
> >file.
>
> Reporting to files, p
>On reciept of the info signal, the backends collaborate to piece
>together a status file. The status file is given a temporay name.
>When complete the status file is rename(2)'d over a well known
>file.
Reporting to files, particularly well known ones, could lead to race
conditions.
All in a
* Matthew Kirkwood <[EMAIL PROTECTED]> [010313 13:12] wrote:
> On Tue, 13 Mar 2001, Ken Hirsch wrote:
>
> > > mlock() guarantees that the locked address space is in memory. This
> > > doesn't imply that updates are not written to the backing file.
> >
> > I've wondered about this myself. It _is
On Tue, 13 Mar 2001, Ken Hirsch wrote:
> > mlock() guarantees that the locked address space is in memory. This
> > doesn't imply that updates are not written to the backing file.
>
> I've wondered about this myself. It _is_ true on Linux that mlock
> prevents writes to the backing store,
I don
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Seems like overkill to me. We could have the postmaster use SIGQUIT for
> db shutdown and leave SIGKILL for admin shutdown of individual backends.
Wrong... at least not with the current definitions of those signals!
regards, to
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > The connection was terminated.
> > And make the postmaster print out
> > The system is shutting down.
> > before it sends out the SIGTERM's.
>
> Unfortunately the postmaster is in no position to send any message to
> the individual client
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The connection was terminated.
> And make the postmaster print out
> The system is shutting down.
> before it sends out the SIGTERM's.
Unfortunately the postmaster is in no position to send any message to
the individual clients.
Maybe we
Giles Lean <[EMAIL PROTECTED]> wrote:
> > When you mmap, you don't use write() ! mlock actualy locks page in
> > memory and as long as the page is locked the OS doesn't attempt to
> > store the dirty page. It is intended also for security app to
> > ensure that sensitive data are not written to
> "tl" == Tom Lane <[EMAIL PROTECTED]> writes:
ecm> ERROR: lo_tell: invalid large object descriptor (0)
tl> Are you remembering to wrap this sequence in a transaction block
tl> (begin/end)? LO descriptors are only valid till end of
tl> transaction.
that was it, thanks. The code use
Bruce Momjian writes:
> Can somone improve the wording?
>
> The system is shutting down.
>
> when the backend receives a SIGTERM. Seems we need some wording that
> can apply to db shutdown and individual backend termination by
> administrators.
The connection was terminated.
And
The Hermit Hacker writes:
> if this is the case, can we look at applying that patch tonight, give ppl
> till Friday to test and put out a RC1 depending on the results?
This should probably be called beta6, given that there is a lot of new
code in it.
--
Peter Eisentraut [EMAIL PROTECTED]
Can somone improve the wording?
The system is shutting down.
when the backend receives a SIGTERM. Seems we need some wording that
can apply to db shutdown and individual backend termination by
administrators.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAI
> > What I would refuse in the event of log corruption is continuing
> > normal database operations.
>
> Hmm. We could do that if we had some notion of a read-only operating
> mode, perhaps. But we don't have one now and I don't want to add it
> for 7.1. Can we agree to look at this more for 7
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> That'll be true in any case, unless we refuse to start up at all upon
>> detecting xlog corruption (which doesn't seem like the way to fly).
>> Not sure what we can do about that.
> What I would refuse in the event of log corruption is continuing
>
> > It will be sufficient if DB will not use all 2^32 XIDs
> > without shutdown.
>
> I liked the xid wraparound idea, won't that be sufficient here too ?
> I don't like the idea to reuse a xid sooner than absolutely necessary.
We need it to reduce pg_log size requirements.
> This would complic
> >> What I was thinking about in that last paragraph was manual
> >> analysis and recovery. I don't think it's a good idea for automatic
> >> system startup to skip over gaps in the log.
>
> > But if we'll not try to read after gap then after restart
> > system will not notice gap and valid re
> As long as I'm about to change the xlog page headers, I have another
> little idea. Wouldn't it be a good idea to allow three backup pages
> per xlog record, not only two? It seems like three pages would be
> a natural requirement for logging operations like index page splits.
On index splits
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> What I was thinking about in that last paragraph was manual
>> analysis and recovery. I don't think it's a good idea for automatic
>> system startup to skip over gaps in the log.
> But if we'll not try to read after gap then after restart system wi
> >> xlog.c's ReadRecord formerly contained code that would zero
> >> out the rest of the log segment (and delete the next log segment,
> >> if any) upon detecting a missing or corrupted xlog record.
> >> I removed that code because I considered it horribly dangerous
> >> where it was. If there i
As long as I'm about to change the xlog page headers, I have another
little idea. Wouldn't it be a good idea to allow three backup pages
per xlog record, not only two? It seems like three pages would be
a natural requirement for logging operations like index page splits.
We could support as man
Giles Lean <[EMAIL PROTECTED]> wrote:
> > When you mmap, you don't use write() ! mlock actualy locks page in
> > memory and as long as the page is locked the OS doesn't attempt to
> > store the dirty page. It is intended also for security app to
> > ensure that sensitive data are not written to
Tom is there new wording we can agree on?
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Not sure. My admin tool is more proof of concept at this point. I
> > think ultimately we will need to allow administrators to such individual
> > backend terminations.
>
> I hope the tool is set up to e
On Tue, 13 Mar 2001, Thomas Lockhart wrote:
> > did anyone from here follow the discussion about postgresql on
> > smp machines on the linux kernel malinglist in the last days?
> > (just as an info)
>
> I didn't. Do you have a synopsis or references?
The thread starts here:
http://www.mail-arc
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> That doesn't seem like a good idea --- once we fail to read an XLOG
>> record, it's probably best to stop there rather than continue on.
>> I think we want to try for a consistent recovery to a past point in
>> time (ie, wherever the xlog gap is) not
> > > StartUpID counts database startups and so has timestamp characteristics.
> > > Actually, idea is to use SUI in future to allow reusing XIDs after startup:
>seeing
> > > old SUI in data pages we'll know that all transaction on this page was committed
> > > "long ago" (ie visible from MVCC P
> Hard to say. 'ps' gives some great information about cpu/memory usage
> that may be hard/costly to put in shared memory. One idea should be to
> issue periodic 'ps/kill' commands though a telnet/ssh pipe to the
> remote machine, or just to the remote X display option.
>
> Of course, getrusage
> > StartUpID counts database startups and so has timestamp characteristics.
> > Actually, idea is to use SUI in future to allow reusing XIDs after startup: seeing
> > old SUI in data pages we'll know that all transaction on this page was committed
> > "long ago" (ie visible from MVCC POV). This r
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > My idea is that they can telnet into the server machine and do remote-X
> > with the application. Just set the DISPLAY variable and it should work.
>
> Remote X pretty well sucks in the real world. Aside from speed issues
> there is the little pro
> > Anyway I like idea of StartUpID in page headers - this will help
>
> Can you please describe StartUpID for me ?
> Ideal would be a stamp that has the last (smallest open) XID, or something else
> that has more or less timestamp characteristics (without the actual need of
>wallclock)
> in r
> > > Anyway I like idea of StartUpID in page headers - this will help
> >
> > Can you please describe StartUpID for me ?
> > Ideal would be a stamp that has the last (smallest open) XID, or something else
> > that has more or less timestamp characteristics (without the actual need of
>wallcl
> Denis Perchine <[EMAIL PROTECTED]> writes:
> >>> Small question... Will it work in console? Or it will be X only?
> >>
> >> It will be tck/tk, so I guess X only.
>
> > That's bad.
>
> tcl/tk is cross-platform; there's no reason that a tcl-coded
> performance monitor client couldn't run on Win
Denis Perchine <[EMAIL PROTECTED]> writes:
>>> Small question... Will it work in console? Or it will be X only?
>>
>> It will be tck/tk, so I guess X only.
> That's bad.
tcl/tk is cross-platform; there's no reason that a tcl-coded
performance monitor client couldn't run on Windows or Mac.
The
Bruce Momjian <[EMAIL PROTECTED]> writes:
> My idea is that they can telnet into the server machine and do remote-X
> with the application. Just set the DISPLAY variable and it should work.
Remote X pretty well sucks in the real world. Aside from speed issues
there is the little problem of fire
[ Charset KOI8-R unsupported, converting... ]
> > > Small question... Will it work in console? Or it will be X only?
> >
> > It will be tck/tk, so I guess X only.
>
> That's bad. Cause it will be unuseful for people having databases far away...
> Like me... :-((( Another point is that it is a lit
Eric Marsden <[EMAIL PROTECTED]> writes:
> lo_open returns 0 as a file descriptor. However, following up with one
> of the other lo functions which take descriptor arguments (such as
> lo_write or lo_tell) fails with
>ERROR: lo_tell: invalid large object descriptor (0)
Are you remembering t
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > After further research, I remembered that we used to have "DB_MIN
> > check" in configure back to 6.4.2:
> > I don't know wht it was removed,
>
> Hmm. Digging in the CVS logs shows that it was removed by Bruce in
> configure.in version 1.262, 1999/0
> I don't want to look a gift horse in the mouth, but it seems to me that the
> performance monitor should wait until the now-famous query tree redesign
> which will allow for sets from functions. I realize that the shared memory
> requirements might be a bit large, but somehow Oracle accomplis
Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> My idea is that they can telnet into the server machine and do remote-X
> with the application. Just set the DISPLAY variable and it should work.
>
Well, actually you would want to tunnel your X session through ssh if
security of the database serv
> At 13:34 12/03/01 -0800, Alfred Perlstein wrote:
> >Is it possible
> >to have a spinlock over it so that an external utility can take a snapshot
> >of it with the spinlock held?
>
> I'd suggest that locking the stats area might be a bad idea; there is only
> one writer for each backend-specific
> did anyone from here follow the discussion about postgresql on
> smp machines on the linux kernel malinglist in the last days?
> (just as an info)
I didn't. Do you have a synopsis or references?
- Thomas
---(end of broadcast)--
On Monday 12 March 2001 03:24, Eric Marsden wrote:
> I am trying to debug my socket-level interface to the backend, which
> implements the 6.4 protocol. It works for general queries, but I have
> a problem with large objects.
>
> lo_create and lo_unlink seem to work OK; I get an oid which looks ok
> Denis Perchine <[EMAIL PROTECTED]> writes:
>
> > > > Small question... Will it work in console? Or it will be X only?
> > >
> > > It will be tck/tk, so I guess X only.
> >
> > That's bad. Cause it will be unuseful for people having databases far away...
> > Like me... :-((( Another point is th
* Philip Warner <[EMAIL PROTECTED]> [010313 06:42] wrote:
> >
> >This ought to always give a consistant snapshot of the file to
> >whomever opens it.
> >
>
> I think Tom has previously stated that there are technical reasons not to
> do IO in signal handlers, and I have philosophical problems wit
>
>This ought to always give a consistant snapshot of the file to
>whomever opens it.
>
I think Tom has previously stated that there are technical reasons not to
do IO in signal handlers, and I have philosophical problems with
performance monitors that ask 50 backends to do file IO. I really do t
> > It will be tck/tk, so I guess X only.
>
> Good point. A typical DB server -- where is performance important --
> has install Xwin?
>
> BTW, I hate Oracle 8.x.x because has X+java based installer, but some
> my servers hasn't monitor and keyboard let alone to Xwin.
>
> What implement per
> >
> >This ought to always give a consistant snapshot of the file to
> >whomever opens it.
> >
>
> I think Tom has previously stated that there are technical reasons not to
> do IO in signal handlers, and I have philosophical problems with
> performance monitors that ask 50 backends to do file I
Tom Lane <[EMAIL PROTECTED]> wrote:
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>> I have tested PostgreSQL with 2-4 CPU linux boxes. In summary, 2 CPU
>> was a big win, but 4 was not. I'm not sure where the bottle neck is
>> though.
> Our not-very-good implementation of spin locking (using select
> > I think Tom has previously stated that there are technical reasons not to
> > do IO in signal handlers, and I have philosophical problems with
> > performance monitors that ask 50 backends to do file IO. I really do think
> > shared memory is TWTG.
>
> I wasn't really suggesting any of those
* Philip Warner <[EMAIL PROTECTED]> [010312 18:56] wrote:
> At 13:34 12/03/01 -0800, Alfred Perlstein wrote:
> >Is it possible
> >to have a spinlock over it so that an external utility can take a snapshot
> >of it with the spinlock held?
>
> I'd suggest that locking the stats area might be a bad
I am trying to debug my socket-level interface to the backend, which
implements the 6.4 protocol. It works for general queries, but I have
a problem with large objects.
lo_create and lo_unlink seem to work OK; I get an oid which looks ok
and there is a corresponding xinv??? file in the base/ dire
On Fri, Mar 09, 2001 at 03:48:33PM -0500, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Well, SQL defines these. Do we want to make our own list? However,
> > numeric codes also have the advantage that some hierarchy is possible.
> > E.g., the "22" in "2200G" is actually the
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Not sure. My admin tool is more proof of concept at this point. I
> think ultimately we will need to allow administrators to such individual
> backend terminations.
I hope the tool is set up to encourage them to try something safer
(ie, CANCEL QUERY)
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Not sure. My admin tool is more proof of concept at this point. I
> > think ultimately we will need to allow administrators to such individual
> > backend terminations.
>
> I hope the tool is set up to encourage them to try something safer
> (ie,
At 18:41 12/03/01 -0500, Tom Lane wrote:
>
>UPDATE pg_class SET reltriggers =
> (SELECT count(*) FROM pg_trigger where pg_class.oid = tgrelid)
>WHERE relname = 'Table';
>
Fixed & done...
Philip Warner|
At 00:32 14/03/01 +1100, Philip Warner wrote:
>
>Are there plans to make 'createdb' support template0 before 7.1? If so,
>I'll amend backup.sgml...
>
Just looked into CVS, and support seems to be there...
Philip Warner
Are there plans to make 'createdb' support template0 before 7.1? If so,
I'll amend backup.sgml...
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498)
I have completed version 0.1 of pgtop, a PostgreSQL session monitor.
Screenshot attached.
I show the currently running query by using gdb to attach to a running
backend. The backend must have debug symbols and the 'postgres' binary
must be in the current patch. I check for both of these in the
> When you mmap, you don't use write() ! mlock actualy locks page in
> memory and as long as the page is locked the OS doesn't attempt to
> store the dirty page. It is intended also for security app to
> ensure that sensitive data are not written to unsecure storage
> (hdd). It is definition of
Tom Lane wrote:
> I am not sure we can/should use gettext (possible license problems?),
> but certainly something like this could be cooked up.
http://citrus.bsdclub.org/index-en.html
I'm not sure of the current status of the code.
Regards,
Giles
---(end of broadcas
On Tue, Mar 13, 2001 at 07:18:36AM -0500, D'Arcy J.M. Cain wrote:
> The logical operators '&', '|', '<<' and '>>' as documented on the page
> http://www.postgresql.org/devel-corner/docs/postgres/functions.html don't
> appear to work as advertised.
>
> darcy=# SELECT 91 & 15;
> ERROR: Unable to i
Denis Perchine <[EMAIL PROTECTED]> writes:
> > > Small question... Will it work in console? Or it will be X only?
> >
> > It will be tck/tk, so I guess X only.
>
> That's bad. Cause it will be unuseful for people having databases far away...
> Like me... :-((( Another point is that it is a littl
The logical operators '&', '|', '<<' and '>>' as documented on the page
http://www.postgresql.org/devel-corner/docs/postgres/functions.html don't
appear to work as advertised.
darcy=# SELECT 91 & 15;
ERROR: Unable to identify an operator '&' for types 'int4' and 'int4'
You will have to r
I don't want to look a gift horse in the mouth, but it seems to me that the
performance monitor should wait until the now-famous query tree redesign
which will allow for sets from functions. I realize that the shared memory
requirements might be a bit large, but somehow Oracle accomplishes this
On Tue, 13 Mar 2001, Tom Lane wrote:
> > I was told the same a long ago about FreeBSD. How much can we count on
> > this undocumented sync() feature?
>
> Sounds quite unreliable to me. Unless there's some interlock ...
> like, say, the second sync not being able to advance past a buffer
> page
> Anyway I like idea of StartUpID in page headers - this will help
Can you please describe StartUpID for me ?
Ideal would be a stamp that has the last (smallest open) XID, or something else
that has more or less timestamp characteristics (without the actual need of wallclock)
in regard to the
> > Small question... Will it work in console? Or it will be X only?
>
> It will be tck/tk, so I guess X only.
That's bad. Cause it will be unuseful for people having databases far away...
Like me... :-((( Another point is that it is a little bit strange to have
X-Window on machine with database
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > After further research, I remembered that we used to have "DB_MIN
> > check" in configure back to 6.4.2:
> > I don't know wht it was removed,
>
> Hmm. Digging in the CVS logs shows that it was removed by Bruce in
> configure.in version 1.262, 1999/0
On Fri, Mar 09, 2001 at 01:54:40PM +1100, Pam Withnall wrote:
> hi,
> I an using postgresql-7.1beta4 and am trying to use the large text fields.
> I have heard of TOAST. There is little documentation.
> I found one section about creating a data type,
> then creating two functions to convert th
76 matches
Mail list logo
