Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Is it OK to commit the change before 7.1 release ?
> > I want to do it before forgetting this issue.
>
> If that fixes the problem for you, then commit it. I was waiting to
> hear back whether you still saw a crash or not...
>
I
> I like this approach. One of the nice things about Oracle is that
> they have an error manual. All Oracle errors have an associated
> number. You can look up that number in the error manual to find a
> paragraph giving details and workarounds. Admittedly, sometimes the
> further details are
In case anyone cares, there is a bug in pg_dump in 7.0.3 when using the bit
fields.
eg: (This is a dump)
INSERT INTO "menu_plans" VALUES (7,'B''1''');
INSERT INTO "menu_plans" VALUES (6,'B''1''');
INSERT INTO "menu_plans" VALUES (8,'B''1''');
I think what's happening is
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Is it OK to commit the change before 7.1 release ?
> I want to do it before forgetting this issue.
If that fixes the problem for you, then commit it. I was waiting to
hear back whether you still saw a crash or not...
regards, t
> So what is the proper columns ? Or let me rephrase, what will your DBA be
> able to monitor using the performance monitor ?
>
> Query stats, IO stats, cache hit/miss ratios ?
For starters, it will be more of a wrapper around ps. In the future, I
hope to add more features.
--
Bruce Momji
Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> Seems we will find out when people complain my performance monitor
> doesn't show the proper columns. :-)
>
So what is the proper columns ? Or let me rephrase, what will your DBA be
able to monitor using the performance monitor ?
Query stats, IO
On Thu, Mar 08, 2001 at 09:00:09PM -0500, Tom Lane wrote:
> [EMAIL PROTECTED] (Nathan Myers) writes:
> > Similar approaches have been tried frequently, and even enshrined
> > in standards (e.g. POSIX catgets), but have almost always proven too
> > cumbersome. The problem is that keeping programs
I Inoue wrote:
>
> Tom Lane wrote:
> >
> > Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > > [ backtrace snipped ]
> >
> > Hmm, this is definitely not operating as intended: LockWaitCancel is
> > getting interrupted, because ProcessInterrupts may be called when it's
> > trying to acquire the lockman
> On Thu, Mar 08, 2001 at 11:49:50PM +0100, Peter Eisentraut wrote:
>> I really feel that translated error messages need to happen soon.
Agreed.
[EMAIL PROTECTED] (Nathan Myers) writes:
> Similar approaches have been tried frequently, and even enshrined
> in standards (e.g. POSIX catgets), but
On Thu, Mar 08, 2001 at 11:49:50PM +0100, Peter Eisentraut wrote:
> I really feel that translated error messages need to happen soon.
> Managing translated message catalogs can be done easily with available
> APIs. However, translatable messages really require an error code
> mechanism (otherwise
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>
> > I've suggested a couple of times that since we include install-sh in our
> > distro anyway, it's pointless and unnecessarily risky to go looking for
> > a platform-supplied install program. However, I could never quite get
>
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Let the actual method of allocating error codes be irrelevant for now,
> although the ones in the SQL standard are certainly to be considered for a
> start. Essentially, instead of writing
>
> elog(ERROR, "disaster struck");
>
> you'd write
>
Tom Lane writes:
> I've suggested a couple of times that since we include install-sh in our
> distro anyway, it's pointless and unnecessarily risky to go looking for
> a platform-supplied install program. However, I could never quite get
> anyone else to see the reasoning. Now that I have this
[EMAIL PROTECTED] (Nathan Myers) writes:
> On Thu, Mar 08, 2001 at 04:06:16PM -0500, Tom Lane wrote:
>> I think it'd be a good idea to change the code so that SIGQUIT is the
>> per-backend quickdie() signal, not SIGUSR1, to bring the postmaster and
>> backend signals back into some semblance of ag
I really feel that translated error messages need to happen soon.
Managing translated message catalogs can be done easily with available
APIs. However, translatable messages really require an error code
mechanism (otherwise it's completely impossible for programs to interpret
error messages relia
Tom Lane writes:
> I think it'd be a good idea to change the code so that SIGQUIT is the
> per-backend quickdie() signal, not SIGUSR1, to bring the postmaster and
> backend signals back into some semblance of agreement.
I think we agreed on this already when someone wanted to use a signal for
sy
I don't believe that UnixWare will take the PS change without having
ROOT.
LER
> Original Message <<
On 3/8/01, 3:54:31 PM, Peter Eisentraut <[EMAIL PROTECTED]> wrote regarding
Re: [HACKERS] Performance monitor :
> Tom Lane writes:
> > How many of our suppo
> Tom Lane writes:
>
> > How many of our supported platforms actually have working ps-status
> > code? (This is an honest question: I don't know.)
>
> BeOS, DG/UX, and Cygwin don't have support code, the rest *should* work.
Seems we will find out when people complain my performance monitor
doe
Greetings,
Sorry about all the posts lately, but things seems to be running *really*
slow on my database. I have two tables, both are identical and one is used
to hold entries older than a certain date, i.e. the history table. I use
this query to move the old records from one to the other.
Tom Lane writes:
> How many of our supported platforms actually have working ps-status
> code? (This is an honest question: I don't know.)
BeOS, DG/UX, and Cygwin don't have support code, the rest *should* work.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
---
On Thu, Mar 08, 2001 at 04:06:16PM -0500, Tom Lane wrote:
> To implement the idea of performing a checkpoint after every so many
> XLOG megabytes (as well as after every so many seconds), I need to pick
> an additional signal number for the postmaster to accept. Seems like
> the most appropriate
To implement the idea of performing a checkpoint after every so many
XLOG megabytes (as well as after every so many seconds), I need to pick
an additional signal number for the postmaster to accept. Seems like
the most appropriate choice for this is SIGUSR1, which isn't currently
being used at th
On Thu, Mar 08, 2001 at 02:43:54PM -0500, Matthew Hagerty wrote:
> Richard,
>
> Thanks for the response, I guess I should have included a little more
> information. The table contains 3.5 million rows. The indexes were
> created after the data was imported into the table and I had just run
>
Matthew Hagerty <[EMAIL PROTECTED]> writes:
> The query where the time_stamp < '03-01-2000' does not return any rows, the
> 04-01-2000 date does return rows. When I disable seqscan the query is
> almost instant, but with it on, it takes about 3 or 4 minutes. Why can't
> the query planner use
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> However, while sitting here looking at it I can't help wondering whether
>> the checkpoint process shouldn't have responded to the SIGTERM that the
>> postmaster sent it when the other backend crashed.
>>
>> Is it really such a good idea for the che
> Bruce Momjian writes:
> ...
> > The problem I see with the shared memory idea is that some of the
> > information needed may be quite large. For example, query strings can
> > be very long. Do we just allocate 512 bytes and clip off the rest. And
> > as I add more info, I need more shared
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> Even with true fdatasync it's not obviously good for performance - it takes
> too long time to write 16Mb files and fills OS buffer cache with trash-:(
True. But at least the write is (hopefully) being done at a
non-performance-critical time.
> Pro
> Other than what we've discussed, do you have any
> comments/objections to my proposed patch?
> I've been holding off committing it so that you have
> time to review it...
Sorry - I'm heading to meet Marc, Thomas & Geoff right now,
will try to comment asap.
Vadim
---(e
Richard,
Thanks for the response, I guess I should have included a little more
information. The table contains 3.5 million rows. The indexes were
created after the data was imported into the table and I had just run
vacuum and vacuum analyze on the database before trying the queries and
sen
> Eventually the checkpoint process will time out the spinlock and abort
> (but please note that this is true only because I insisted --- Vadim
> wanted to have infinite timeouts on the WAL spinlocks. I think this is
> good evidence that that's a bad idea).
I disagree - this is evidence of bug in
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> No, but I want a system that's not brittle. You seem to be content to
>> design a system that is reliable as long as the WAL log is OK
>> but loses the entire database unrecoverably as soon as one bit goes bad
>> in the log.
> I don't see how absen
> > It seems that you want guarantee more than me, Tom -:)
>
> No, but I want a system that's not brittle. You seem to be content to
> design a system that is reliable as long as the WAL log is OK
> but loses the entire database unrecoverably as soon as one bit goes bad
> in the log.
I don't se
Greetings,
I have a real simple table with a timestamp field. The timestamp field has
an index on it. But, the index does not seem to be taken into account for
selects that return rows:
pglog=# explain select time_stamp from history_entries where time_stamp <
'03-01-2000';
NOTICE: QUERY PL
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> > But we need it regardless --- if you didn't want a fully-allocated WAL
> > file, why'd you bother with the original seek-and-write-1-byte code?
>
> I considered this mostly as hint for OS about how log file should be
> allocated (to decrease fragm
Bruce Momjian writes:
...
> The problem I see with the shared memory idea is that some of the
> information needed may be quite large. For example, query strings can
> be very long. Do we just allocate 512 bytes and clip off the rest. And
> as I add more info, I need more shared memory per
I am currently looking at a frozen system: a backend crashed during XLOG
write (which I was deliberately provoking, via running it out of disk
space), and now the postmaster is unable to recover because it's waiting
around for a checkpoint process that it had launched milliseconds before
the crash
> > I see that seek+write was changed to write-s in XLogFileInit
> > (that was induced by subj, right?), but what about problem
> > itself?
>
> > BTW, were performance tests run after seek+write --> write-s
> > change?
>
> That change was for safety, not for performance. It might be a
> perform
> On Wed, Mar 07, 2001 at 10:06:38PM -0500, Bruce Momjian wrote:
> > > I think Bruce wants per-backend data, and this approach would seem to only
> > > get the data for the current backend.
> > >
> > > Also, I really don't like the proposal to write files to /tmp. If we want a
> > > perf tool, t
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Are you sure about 'ps' stuff portability?
>
> > I am not going to do a huge amount with the actual ps columns, except
> > allow you to sort on them. I will do most on the ps status display we
> > use as the command line in ps.
>
> ... which in i
> > Was the following bug already fixed ?
>
> Dunno. I've changed the WAL ReadRecord code so that it fails soft (no
> Asserts or elog(STOP)s) for all failure cases, so the particular crash
> mode exhibited here should be gone. But I'm not sure why the code
> appears to be trying to open the wro
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> And how well will that approach work if the last checkpoint record
>> got written near the start of a log segment file, and then the
>> checkpointer discarded all your prior log segments because "you don't
>> need those anymore"? If the checkpoint r
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Are you sure about 'ps' stuff portability?
> I am not going to do a huge amount with the actual ps columns, except
> allow you to sort on them. I will do most on the ps status display we
> use as the command line in ps.
... which in itself is not nec
Samuel Sieb <[EMAIL PROTECTED]> writes:
> On Tue, Mar 06, 2001 at 12:46:24PM -0800, Nathan Myers wrote:
> >
> > On Linux, /usr/src/linux/include is meaningless for anything in userland;
> > it's meant only for building the kernel and kernel modules. That Red Hat
> > tends to expose it to user
> > > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > > The only problem is that we would no longer have control over which
> > > > pages made it to disk. The OS would perhaps write pages as we modified
> > > > them. Not sure how important that is.
> > >
> > > Unfortunately, this alone is a *fa
"Vadim Mikheev" <[EMAIL PROTECTED]> writes:
> I see that seek+write was changed to write-s in XLogFileInit
> (that was induced by subj, right?), but what about problem
> itself?
> BTW, were performance tests run after seek+write --> write-s
> change?
That change was for safety, not for performan
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Was the following bug already fixed ?
Dunno. I've changed the WAL ReadRecord code so that it fails soft (no
Asserts or elog(STOP)s) for all failure cases, so the particular crash
mode exhibited here should be gone. But I'm not sure why the code
appear
Gavin Sherry <[EMAIL PROTECTED]> writes:
> I've been looking through the memory management system today.
> When a request is made for a memory memory chunk larger than
> ALLOC_CHUNK_LIMIT, AllocSetAlloc() uses malloc() to give the request its
> own block. The result is tested by AllocSetAlloc() t
Karel,
On Thu, 8 Mar 2001, Karel Zak wrote:
> On Thu, Mar 08, 2001 at 10:28:50PM +1100, Gavin Sherry wrote:
> > Hi guys,
> >
> > I've been looking through the memory management system today.
> >
> > When a request is made for a memory memory chunk larger than
> > ALLOC_CHUNK_LIMIT, AllocSetAll
Jarom Hagen <[EMAIL PROTECTED]> writes:
> Yes, we have an evil COBOL compiler from MicroFocus that put that install
> script there. I was really confused why postgres wanted a COBOL system. :-)
I've suggested a couple of times that since we include install-sh in our
distro anyway, it's pointless
On Thu, Mar 08, 2001 at 10:28:50PM +1100, Gavin Sherry wrote:
> Hi guys,
>
> I've been looking through the memory management system today.
>
> When a request is made for a memory memory chunk larger than
> ALLOC_CHUNK_LIMIT, AllocSetAlloc() uses malloc() to give the request its
> own block. The
> Was the following bug already fixed ?
I was going to ask same Q.
I see that seek+write was changed to write-s in XLogFileInit
(that was induced by subj, right?), but what about problem
itself?
> > DEBUG: redo starts at (0, 21075520)
> > The Data Base System is starting up
> > DEBUG: open(log
What do we debate?
I never told that we shouldn't worry about current WAL disability to restart.
And WAL already correctly works in situation of "failing to write a couple of disk
blocks when the system crashes".
My statement at first place that "WAL can't help in the event of disk errors"
was to
Hi!
I am student of system engineering and I carried out a work with
PostgreSQL in which I should implement inclusion dependencies using
rules.
During the development of this work, I met with a problem that I solved
adding the Postgres the possibility to disable (deactivate) a rule
temporarily.
Hi guys,
I've been looking through the memory management system today.
When a request is made for a memory memory chunk larger than
ALLOC_CHUNK_LIMIT, AllocSetAlloc() uses malloc() to give the request its
own block. The result is tested by AllocSetAlloc() to see if the memory
was allocated.
Irr
On Wed, Mar 07, 2001 at 10:06:38PM -0500, Bruce Momjian wrote:
> > I think Bruce wants per-backend data, and this approach would seem to only
> > get the data for the current backend.
> >
> > Also, I really don't like the proposal to write files to /tmp. If we want a
> > perf tool, then we need
On Thu, 8 Mar 2001, Martin Devera wrote:
> > > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Unfortunately, this alone is a *fatal* objection. See nearby
> > > discussions about WAL behavior: we must be able to control the relative
> > > timing of WAL write/flush and data page writes.
> >
> >
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > The only problem is that we would no longer have control over which
> > > pages made it to disk. The OS would perhaps write pages as we modified
> > > them. Not sure how important that is.
> >
> > Unfortunately, this alone is a *fatal* objecti
57 matches
Mail list logo
