The following bug has been logged online:
Bug reference: 1761
Logged by: Jack
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8
Operating system: wxp
Description:missing files
Details:
Wellcome
On Compiling code with PSQLTable1 component a have error message :
mark reid wrote:
I've been using pg_autovacuum for a while, and for the most part it's
been great. There's one case in my system where it won't run on a
particular type of table, even though the table apparently needs it.
I have a table called "properties" that has key->value pairs. Usually
> > It appears that the timestamp 'epoch' is being interpreted as
> > relative to the local timezone, rather than being an absolute time.
>
> This is correct for timestamp ... you want timestamp with time zone.
Sorry, but that's dumb (IMHO). The unix epoch is not relative to the
local timezone.
Hi,
We have a problems with postgresSQL 7.1.3 that suddenly all databases
don't work, and it logged the following message,
pq_recvbuf: unexpected EOF on client connection
pq_recvbuf: unexpected EOF on client connection
Smart Shutdown request at Fri Jul 8 09:19:47 2005
DEBUG: shutting down
DE
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> mark reid wrote:
>> What I believe is happening is that the main table doesn't meet the
>> minimum activity level for pg_autovacuum based on size / update
>> frequency, but the toast table would, though it isn't specifically
>> checked by pg_au
Thanh Q Lam wrote:
Hi,
We have a problems with postgresSQL 7.1.3 that suddenly all databases
don't work, and it logged the following message,
I'm sure you know that's an old version, but I'll recommend upgrading
anyway.
pq_recvbuf: unexpected EOF on client connection
pq_recvbuf: unexpecte
Jack wrote:
Bug reference: 1761
Wellcome
On Compiling code with PSQLTable1 component a have error message :
I'm not sure there is any such component bundled with PostgreSQL - did
you get it from somwhere else?
PostgreSQL erroc code : (1)
syntax error at or on "FROM" at character 314
Thanks Richard! I finally got it work. It was caused byethe PGDATA
environment variable. I fixed it the .cshrc and reran initdd, then
everything's back to normal.
Yes, our current postgres is very old and I'm setting up 7.4.8 on
another box.
Thanks again,
Thanh
Richard Huxton wrote:
Tom Lane wrote:
I think Mark is probably on to something. The activity in the toast
table will show as deletes *in the toast table* ... and that activity
fails to show at all in the pg_stat_activity view, because it shows
only plain relations! So unless autovacuum is ignoring the stats views
a
> Tom Lane wrote:
> >The first of these would be easiest but it seems quite likely to break
> >applications (eg, if unmodified, autovacuum would probably try to issue
> >vacuums against toast tables). And the last seems to be confusing.
> >So I think I favor adding columns.
Hmm. With integrated
Mark Reid <[EMAIL PROTECTED]> writes:
> I think the issue is that a single update to the main table causes a
> whole bunch of updates to the toast table. So in my case (with the
> vacuum output attached previously), a thousand updates to the main table
> entails tens of thousands of updates to
"Matthew T. O'Connor" writes:
> Shouldn't the update to the toast table just be considered an update to
> table t1? The fact that there is an underlying toast table is an
> implementation detail that I don't think should show up in the stats system.
At the level of the stats system, though, y
Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> The first of these would be easiest but it seems quite likely to break
>>> applications (eg, if unmodified, autovacuum would probably try to issue
>>> vacuums against toast tables). And the last seems to be confusing.
>>> So I think
Tom Lane wrote:
"Matthew T. O'Connor" writes:
Shouldn't the update to the toast table just be considered an update to
table t1? The fact that there is an underlying toast table is an
implementation detail that I don't think should show up in the stats system.
At the level of the s
"Matthew T. O'Connor" writes:
> Tom Lane wrote:
>> In particular, I think people would like to be able to use the stats
>> views to see how much toast-related I/O is going on, and not have that
>> smushed together with main-table I/O.
> Fair enough, but how are you planning to display the data,
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Hmm. With integrated autovacuum, we could set something up to issue
vacuums separately to TOAST tables and the main table. It'd probably be
a tad easier if the toast stats are separate from the main table; and an
autovac of the main table not necessar
On Fri, Jul 08, 2005 at 01:29:03PM -0400, Tom Lane wrote:
> "Matthew T. O'Connor" writes:
> > Tom Lane wrote:
> >> In particular, I think people would like to be able to use the stats
> >> views to see how much toast-related I/O is going on, and not have that
> >> smushed together with main-table
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Fri, Jul 08, 2005 at 01:29:03PM -0400, Tom Lane wrote:
>> The main bit of additional logic that might be needed is an awareness
>> that firing a VACUUM on a main table will implicitly fire one on its
>> toast table, and so you'd not want to go and iss
Tom Lane wrote:
I'm having some second thoughts about allowing VACUUM on a toast table
independently of its parent table --- it's a bit scary to be messing
with the toast table when we have no lock at all on the parent. It
might work OK, but I'm not sure I want to take the risk. If we simply
e
On Fri, Jul 08, 2005 at 02:35:14PM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > On Fri, Jul 08, 2005 at 01:29:03PM -0400, Tom Lane wrote:
> >> The main bit of additional logic that might be needed is an awareness
> >> that firing a VACUUM on a main table will implicitly f
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Another issue altogether is the stat system. I don't know if it stores
> info about toast tables.
Yes, it does --- you can pull out the info, even, if you use the stats
access functions directly. It's just that the views filter on relkind =
'r'.
> No
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Note that it doesn't matter that it doesn't show up in the pg_stat
views, because we don't use those; rather we access the hash tables
directly.
Ah, but this is only true in the integrated version no? The contrib
version sure
22 matches
Mail list logo
