On Thu, 24 Mar 2005, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> >> The hard part is CREATE TABLESPACE, and the reason it's hard is that
> >> someone might possibly want the tablespace to be located at a different
> >> place on the recipient machine than it is on the master. I do
Gavin Sherry <[EMAIL PROTECTED]> writes:
>> The hard part is CREATE TABLESPACE, and the reason it's hard is that
>> someone might possibly want the tablespace to be located at a different
>> place on the recipient machine than it is on the master. I do not see a
>> reasonable way to support that a
Added to TODO:
* Add GUC to issue notice about queries that use unjoined tables
---
Kevin Brown wrote:
> Greg Stark wrote:
> >
> > Kevin Brown <[EMAIL PROTECTED]> writes:
> >
> > > Hence, it makes sense to go ahe
On Wed, 23 Mar 2005, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Tue, 2005-03-22 at 21:42 -0500, Bruce Momjian wrote:
> >> Is this a TODO?
>
> > Yes, it is.
>
> > In my experience, most people create only a single Database, then define
> > their Tablespaces (or change them rar
When you turn on \x mode for query output in psql, it wrecks the output
of \d , etc.
Should we change it so that the \d is unaffected by \x? What about for
other \d commands?
Well, they asked for \x so why is it wrong for us to \x the \d output
like we do now?
Because I have the feeling (back m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
> "Wrecks" to you maybe ... but if someone likes \x display, why wouldn't
> they like it for \d too?
>
> One could argue that the real bug is that the footers in \d don't change
> to look like \x output.
Indeed, it behaves exactly th
On Wednesday March 23 2005 5:14, Mark Kirkwood wrote:
> - decide on a snapshot interval (e.g. 30 seconds)
> - capture pg_stat_activity every interval and save the results
> in a timestamped copy of this view (e.g. add a column
> 'snap_time')
That might serve for some purposes, but log-parsing soun
Tom Lane wrote:
I agree that we aren't MVCC with respect to DDL operations (and for this
purpose CLUSTER is DDL). Trying to become so would open a can of worms
far larger than it's worth, though, IMHO.
I think if we can come up with a reasonable way to handle all the
consequences, it's worth doin
Ed L. wrote:
On Wednesday March 23 2005 4:11, Mark Kirkwood wrote:
Is enabling the various postgresql.conf stats* options and
taking regular snapshots of pg_stat_activity a possible way to
get this?
I don't see how; the duration is the key measurement I'm after,
and I don't believe it is availabl
Tom Lane wrote:
I think last night's discussion makes it crystal-clear why I felt that
this hasn't been sufficiently thought through. Please revert until the
discussion comes to a conclusion.
I applied the patch because I don't think it is very closely related to
the discussion. But if you'd pref
On Wed, Mar 23, 2005 at 01:55:46PM +0900, ITAGAKI Takahiro wrote:
> Hi, Mark.
>
> Mark Wong <[EMAIL PROTECTED]> wrote:
>
> > In light of this thread, have you compared the performance on
> > Linux-2.4?
>
> No, but I'm just testing my patch on Linux-2.4 with a middle-range server.
> I will report
On Wednesday March 23 2005 3:34, Tom Lane wrote:
>
> This is going to fall down on exactly the same objections that
> have been made to putting the log messages themselves into
> tables. The worst one is that a failed transaction would fail
> to make any entry whatsoever. There are also performanc
On Wednesday March 23 2005 4:11, Mark Kirkwood wrote:
> Is enabling the various postgresql.conf stats* options and
> taking regular snapshots of pg_stat_activity a possible way to
> get this?
I don't see how; the duration is the key measurement I'm after,
and I don't believe it is available anywh
Ed L. wrote:
Hackers,
(some snippage...)
Our Problem: We work with 75+ geographically distributed pg
clusters; it is a significant challenge keeping tabs on
performance. We see degradations from rogue applications,
vacuums, dumps, bloating indices, I/O and memory shortages, and
so on. Custom
"Ed L." <[EMAIL PROTECTED]> writes:
> ... We can do
> this by writing programs to periodically parse log files for
> queries and durations, and then centralizing that information
> into a db for analysis, similar to pqa's effort.
That strikes me as exactly what you ought to be doing.
> Suppose
Hackers,
I'd like to pose a problem we are facing (historical query time
profiling) and see if any of you interested backend gurus have
an opinion on the promise or design of a built-in backend
solution (optional built-in historical query time stats), and/or
willingness to consider such a pat
Oleg Bartunov writes:
> is't possible to get timings separately for index anf heap processing,
> like we get separate stats for io ?
gprof?
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe command
On Wed, 23 Mar 2005, Tom Lane wrote:
Oleg Bartunov writes:
is't possible to get timings separately for index anf heap processing,
like we get separate stats for io ?
gprof?
oh, no. I need 2 numbers only :) What's \timing in psql does ?
Or it's just a wrapper to system 'time' ?
Hi there,
is't possible to get timings separately for index anf heap processing,
like we get separate stats for io ?
Regards,
Oleg
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Inst
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> Greg Stark <[EMAIL PROTECTED]> writes:
>>> Though pg_dump works in READ COMMITTED mode doesn't it?
>>
>> Certainly not.
> It works in serializable mode? I guess the only reason we don't see
> "transaction failed" eve
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Though pg_dump works in READ COMMITTED mode doesn't it?
>
> Certainly not.
It works in serializable mode? I guess the only reason we don't see
"transaction failed" ever is because it's not doing any updates?
--
g
strk <[EMAIL PROTECTED]> writes:
> On Wed, Mar 23, 2005 at 01:48:11PM +, Richard Huxton wrote:
>> *What* is giving this error? Something seems to be holding onto a
>> reference to (at a guess) your temporary table. Can you identify what?
> Whatever is called from create temp table ..
"\set V
Greg Stark <[EMAIL PROTECTED]> writes:
> Though pg_dump works in READ COMMITTED mode doesn't it?
Certainly not.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Tue, 2005-03-22 at 21:42 -0500, Bruce Momjian wrote:
>> Is this a TODO?
> Yes, it is.
> In my experience, most people create only a single Database, then define
> their Tablespaces (or change them rarely, if ever). So I've always
> regarded CREATE DATA
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> When you turn on \x mode for query output in psql, it wrecks the output
> of \d , etc.
"Wrecks" to you maybe ... but if someone likes \x display, why wouldn't
they like it for \d too?
One could argue that the real bug is that the footers in \
Christopher Kings-Lynne wrote:
> When you turn on \x mode for query output in psql, it wrecks the output
> of \d , etc.
>
> Should we change it so that the \d is unaffected by \x? What about for
> other \d commands?
Well, they asked for \x so why is it wrong for us to \x the \d output
like we
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It isn't 100% MVCC, I agree. But it works because system catalog
>> lookups are SnapshotNow, and so when another session comes and wants to
>> look at the table it will see the committed new version of the pg_class
>> row pointing at the
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I don't think this has been adequately thought through at all ... but
>> at least make it ExclusiveLock. What is the use-case for allowing
>> SELECT FOR UPDATE in parallel with this?
> Ok, patch applied -- I adjusted it to use Exclusive
On Wed, Mar 23, 2005 at 02:49:53PM +, Richard Huxton wrote:
> strk wrote:
> >On Wed, Mar 23, 2005 at 01:48:11PM +, Richard Huxton wrote:
> >
> >>strk wrote:
> >>
> >>>Hello.
> >>>A memory fault in a trigger left my database
> >>>in a corrupted state:
> >>>
> >>
> >>> - I can't create temp
strk wrote:
On Wed, Mar 23, 2005 at 01:48:11PM +, Richard Huxton wrote:
strk wrote:
Hello.
A memory fault in a trigger left my database
in a corrupted state:
- I can't create temporary tables anymore
(restart/vacuum full don't help)
ERROR: cache lookup failed for r
Tom Lane <[EMAIL PROTECTED]> writes:
> Bruce Momjian writes:
> > In fact, would a truncate during a backup cause the backup to be
> > inconsistent because it wouldn't be a true snapshot of the database at
> > backup start time? Seems so.
>
> No, because pg_dump holds AccessShareLock on every t
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
> > It isn't 100% MVCC, I agree. But it works because system catalog
> > lookups are SnapshotNow, and so when another session comes and wants to
> > look at the table it will see the committed new version of the pg_class
> > row pointing a
Thanks for the explanation. Then, Can I say that PostgreSQL and
Informix are cousins?
On Tue, 22 Mar 2005 17:36:28 -0500, Tom Lane <[EMAIL PROTECTED]> wrote:
> Juan Pablo Espino <[EMAIL PROTECTED]> writes:
> > My question is if the architecture of postgreSQL were inherited of
> > postgres origina
On Wed, Mar 23, 2005 at 01:48:11PM +, Richard Huxton wrote:
> strk wrote:
> >Hello.
> >A memory fault in a trigger left my database
> >in a corrupted state:
> >
>
> > - I can't create temporary tables anymore
> > (restart/vacuum full don't help)
> > ERROR: cache lookup failed
strk wrote:
Hello.
A memory fault in a trigger left my database
in a corrupted state:
- I can't create temporary tables anymore
(restart/vacuum full don't help)
ERROR: cache lookup failed for relation 1250714
*What* is giving this error? Something seems to be holding o
Hello.
A memory fault in a trigger left my database
in a corrupted state:
- A temporary table listed in pg_class
was not accessible with a select
- I could not DROP it
- I deleted the record from pg_class
- I can't create temporary tables anymore
On Wed, 2005-03-23 at 13:07 +, Simon Riggs wrote:
> On Tue, 2005-03-22 at 19:07 -0500, Tom Lane wrote:
> > Oleg Bartunov writes:
> > >> This isn't a problem in normal use of course, but it'd be a serious
> > >> issue for someone engaging in WAL-shipping, if their backup postmaster
> > >> were
On Tue, 2005-03-22 at 19:07 -0500, Tom Lane wrote:
> Oleg Bartunov writes:
> >> This isn't a problem in normal use of course, but it'd be a serious
> >> issue for someone engaging in WAL-shipping, if their backup postmaster
> >> were living at a different absolute path. We probably need to think
> > It would keep the old table around while building the new, then grab
> > an exclusive lock to swap the two.
>
> Lock upgrading is right out.
It would need a whole of new family of "intent" locks, with different rules.
Andreas
---(end of broadcast)
I checked stable branch. no problem now.
Oleg
On Tue, 22 Mar 2005, Tom Lane wrote:
Oleg Bartunov writes:
This isn't a problem in normal use of course, but it'd be a serious
issue for someone engaging in WAL-shipping, if their backup postmaster
were living at a different absolute path. We
On Tue, 2005-03-22 at 21:42 -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > Oleg Bartunov writes:
> > >> This isn't a problem in normal use of course, but it'd be a serious
> > >> issue for someone engaging in WAL-shipping, if their backup postmaster
> > >> were living at a different absolute pa
41 matches
Mail list logo
