"Benjamin Krajmalnik" <[EMAIL PROTECTED]> writes:
> I was playing around trying to tweak the performance of the database.
> As part of the process, I increased the number of WAL buffers to 32 and
> the checkpoint segments to 16.
> That appears to have been the culprit! I set them back at the same
I’m the author of the O’Reilly book “Backup
& Recovery,” due to be released in Q3 of this year.
Among other things, it has a chapter on backing up
PostgreSQL.
I’m looking for a few PostgreSQL-knowledgeable folks
to provide a technical review of this chapter. Obviously I’d want yo
On Thu, Jul 13, 2006 at 06:01:34PM -0600, Benjamin Krajmalnik wrote:
> Is there a way to determine the name of an object based on the filenode
> number?
Use contrib/oid2name or make queries using pg_database.oid and
pg_class.relfilenode. For example, suppose you have the file
$PGDATA/base/16388/6
The table is vacuumed all the time.
Pg_autovacuum runs.
I started thinking - what did I change right before this happened?
I was playing around trying to tweak the performance of the database.
As part of the process, I increased the number of WAL buffers to 32 and
the checkpoint segments to 16.
T
On 7/13/06, Benjamin Krajmalnik <[EMAIL PROTECTED]> wrote:
I am running PostgreSQL 8.1.4 on windows.
I have a table with the following structure:
CREATE TABLE "public"."tblksaura" (
"ksaurasysid" SERIAL,
"testtime" TIMESTAMP WITHOUT TIME ZONE,
"lasthouralive" DOUBLE PRECISION[],
"last2
I am running
PostgreSQL 8.1.4 on windows.
I have a table with
the following structure:
CREATE TABLE
"public"."tblksaura" ( "ksaurasysid" SERIAL, "testtime"
TIMESTAMP WITHOUT TIME ZONE, "lasthouralive" DOUBLE PRECISION[],
"last24hrsalive" DOUBLE PRECISION[], "last7daysalive"
DOUB
FM <[EMAIL PROTECTED]> writes:
> I'e got a very strange (scary) problem.
> ERROR: could not read block 81235 of relation "pg_largeobject":
> Input/output error
This one is very strongly indicative of a disk hardware problem.
The others look like they could be consequences of catalog corruption
e
Is there a way to determine the name of an object based on the filenode
number?
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
On Wed, 2006-07-12 at 15:04, Alexander Burbello wrote:
> Ok! Its a good tool, but for Production Database I think it is not
> recommended.
> Only using pg_dump for the second backup plain.
> Suppose that you backed up at 6:00am and at 9am happened a crash on the
> server.
> In this case, I would
Ok! Its a good tool, but for Production Database I think it is not
recommended.
Only using pg_dump for the second backup plain.
Suppose that you backed up at 6:00am and at 9am happened a crash on the
server.
In this case, I would lost data between that time, 3 hours of information.
For product
[EMAIL PROTECTED] ("Joshua D. Drake") writes:
> That is why IS NULL can be placed in a unique index because it isn't
> actually there (in the theorectical sense).
In effect, NULL is not actually a value.
--
(reverse (concatenate 'string "gro.mca" "@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/sa
Why is PostgreSQL not enforcing this index? This appears to be a pretty
major a bug? It would seem that you could have a unique index across
columns that might have a null in them.
From:
http://www.postgresql.org/docs/8.1/interactive/indexes-unique.html
Quote:
"When an index is declared un
Hi ,
I am experimenting with PITR aspect of postgres8.0,
and I needed some answers on this subject.
I have following questions :
1)
At time t0, I created a base backup. (got a backup
marker file named as:
0008000200A8.005E61B4.backup)
(assume no previous base backups and recoveries.
On 7/13/06, Chris Hoover <[EMAIL PROTECTED]> wrote:
On this table, I have created a unique index on payer_trn03, payer_trn04,
and expire_timestamp. However, since the expire_timestamp is normally null,
the unique index does not appear to be working. I have been able to enter
two identical rows
The service account is still available (PG 8.1.3 can be started), although the
account doesn't show in the Control Panel, User Accounts. If I search the
system for accounts (when changing the credentials of a service), I do find the
account, but have no way of administering it.
Note: the Postg
PostgreSQL does not consider a NULL value to be an equal value,
therefore it cannot be a duplicate.
If you must have a blank value in a column and need it to be unique,
you'd need to do something like an empty string, or a string/figure your
application will know is a null value that makes sen
Am Donnerstag, 13. Juli 2006 16:40 schrieb Chris Hoover:
> On this table, I have created a unique index on payer_trn03, payer_trn04,
> and expire_timestamp. However, since the expire_timestamp is normally
> null, the unique index does not appear to be working. I have been able to
> enter two iden
On Thu, 13 Jul 2006, Chris Hoover wrote:
> I am having what appears to be a bug with unique indexes on 8.1.3.
>
> I have created a new table.
>
> create table payer_835 (
> payer_id int8 not null default
> nextval('payer_835_payer_id_seq'::regclass) primary key,
> payer_name
On 7/13/06, Hyatt, Gordon <[EMAIL PROTECTED]> wrote:
I've searched the archives and found no helpful info, so I'll ask here.I've successfully installed v8.1.3 on my laptop and was attempting to upgrade it to version 8.1.4 when I ran into the message indicating that the service could not be installe
On 7/13/06, Chris Hoover <[EMAIL PROTECTED]> wrote:
I am having what appears to be a bug with unique indexes on 8.1.3.I have created a new table. create table payer_835 ( payer_id int8 not null default nextval('payer_835_payer_id_seq'::regclass) primary key,
payer_name varchar
On Thu, Jul 13, 2006 at 10:40:43AM -0400, Chris Hoover wrote:
> Why is PostgreSQL not enforcing this index? This appears to be a pretty
> major a bug? It would seem that you could have a unique index across
> columns that might have a null in them.
This comes up frequently due to a misunderstandi
[EMAIL PROTECTED] (adey) writes:
> ...but I can't find pgsql_tmp in my v8.1.4 installation.
>
> Where can I find these temp files please?
They get created on demand, and go away when that demand disappears.
Run a big REINDEX and you'll see them pop into place...
--
output = ("cbbrowne" "@" "ntlu
On Thu, 2006-07-13 at 09:40, Chris Hoover wrote:
> I am having what appears to be a bug with unique indexes on 8.1.3.
>
> I have created a new table.
>
> create table payer_835 (
> payer_id int8 not null default
> nextval('payer_835_payer_id_seq'::regclass) primary key,
> payer_
I am having what appears to be a bug with unique indexes on 8.1.3.I have created a new table. create table payer_835 ( payer_id int8 not null default nextval('payer_835_payer_id_seq'::regclass) primary key,
payer_name varchar(50) not null, payer_trn03 varchar(10) not
I've searched the archives and found no helpful info, so I'll ask here.
I've successfully installed v8.1.3 on my laptop and was attempting to upgrade
it to version 8.1.4 when I ran into the message indicating that the service
could not be installed due to insufficient permissions to install serv
These do exist as the documentation says - I found them in my 8.1.3
install, but only for a couple of databases. Perhaps they're only used
when there has a need to be swapping data to disk?
adey wrote:
The postgresql parameter explanation for work_mem say :-
"Another way to set this value
26 matches
Mail list logo
