Friday, July 11, 2008

Re: [torontopug] Next meeting planning

On Wed, 25 Jun 2008, Steve Singer wrote:

So it's a little over 2 weeks to the next meeting and this thread sort of
died.

Have any other speakers/topics come forward?
Have we decided what we want the lineup to be?
Should I start preparing a short talk on any of the below topics, if so
which one?

>
> I should be able to handle a 20 minute presentation on any of:
>
> -Replication options
> -GIS/Postgis (geared at newbies, I'm no expert)
> -Pl/Proxy
>


--
Sent via torontopug mailing list (torontopug@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/torontopug

Re: [pgadmin-hackers] Support of INHERIT in existing tables (8.2+ releases)

On Fri, Jul 11, 2008 at 11:30 PM, Guillaume Lelarge
<guillaume@lelarge.info> wrote:
>
> (btw, I'm following ebay's Mac Mini list to get one soon).

:-)

Make sure you don't get anything older than OS X 10.4 (Tiger). No real
need to spend extra to get Leopard though (unless you want to).


--
Dave Page
EnterpriseDB UK:

http://www.enterprisedb.com

--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [HACKERS] Vacuuming leaked temp tables (once again)

On Sat, Jul 12, 2008 at 12:41 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>
> On Fri, 2008-07-11 at 17:26 -0400, Tom Lane wrote:
>> Simon Riggs <simon@2ndquadrant.com> writes:
>> > So it would seem that we need a way of handling temp tables that doesn't
>> > rely on catalog entries at all.
>>
>> That's a complete non-starter; I need go no farther than to point out
>> that it would break clients that expect to see their temp tables
>> reflected in pg_class and so forth.
>
> What does the SQL Standard say about the Information Schema I wonder/

Many apps were written long before we had one. Not too mention that it
doesn't provide anything like all the info that PostgreSQL-specific
tool (though not necessarily user apps) would likely need.

--
Dave Page
EnterpriseDB UK:

http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [SQL] PERSISTANT PREPARE (another point of view)

At 04:31 PM 7/11/2008, pgsql-sql-owner@postgresql.org wrote:
>Date: Fri, 11 Jul 2008 23:31:03 +0000
>From: Milan Oparnica <milan.opa@hotmail.com>
>To: <pgsql-sql@postgresql.org>
>Subject: PERSISTANT PREPARE (another point of view)
>Message-ID: <BLU109-W5078B5ABDE57D183AA6695F8900@phx.gbl>
>[snip]
>What could we gain by introducing a kind of global prepared statement
>area, is SIMPLICITY of DB DEVELOPMENT AND MAINTENANCE.
>
>Here is our point of view:
>[snip]
>Now, instead of preparing statements on each connection request (and
>we use around 900 prepared statements), why couldn't we simply prepare
>these statements ONCE and keep them in some global storage for future
>everyday usage.

Hi,

What's wrong with using complex views, stored procedures, functions and
maybe even custom data types to accomplish what you want here? It seems
like you could build a lot of "prepared statements" using these tools,
providing your application layer developers with a consistent set of
interfaces to obtain data that are not tied to the data tables
themselves. And allowing them to insert/update/manage tables via
structured interfaces as well.

Am I missing something?

Best,

Steve


--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql

Re: [GENERAL] Default fill factor for tables?

On Fri, 2008-07-11 at 15:25 -0600, Scott Marlowe wrote:
> On Fri, Jul 11, 2008 at 3:24 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> >
> > On Fri, 2008-07-11 at 14:51 -0600, Scott Marlowe wrote:
> >
> >> I would kindly disagree. I'm looking at a project where HOT updates
> >> are going to be a real performance enhancement, but I'll have to
> >> create a hundred or so tables ALL with fillfactor tacked on the end.
> >
> > You clearly think that adjusting fillfactor helps in all cases with HOT.
> > I disagree with that, else would have pushed earlier for exactly what
> > you suggest. In fact, I've has this exact discussion previously.
>
> How odd, because that's clearly NOT what I said. In fact I used the
> single "a" to describe the project I was looking at where having a
> default table fill factor of < 100 would be very useful. OTOH, I have
> stats databases that have only insert and drop child tables that would
> not benefit from < 100 fill factor. For a heavily updated database,
> where most of the updates will NOT be on indexed columns, as the ONE
> project I'm looking at, a default fill factor would be quite a time
> saver.

I apologise if my phrasing sounded confrontational.

For specific workloads, tuning of particular tables can be effective,

I have not heard of evidence that setting fillfactor < 100 helps as an
across-the-board tuning measure on longer-term tests of performance.
Theoretically, it makes little sense, but current theory is not always
right. Until we have even hear-say evidence of benefit, introducing a
parameter would be inadvisable, IMHO. I will change that view in an
instant, with reasonable evidence.

--
Simon Riggs

www.2ndQuadrant.com

PostgreSQL Training, Services and Support


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [HACKERS] posix advises ...

"Abhijit Menon-Sen" <ams@oryx.com> writes:

> Hi Zoltán.
>
> I was reading through your posix_fadvise patch,

Actually Zoltan's patch was based on an earlier patch from me. The sections
you're highlighting here are from my original patch.

> and I wanted to ask about this change in particular:
>
>> --- a/src/backend/executor/nodeIndexscan.c
>> +++ b/src/backend/executor/nodeIndexscan.c
>> @@ -290,7 +290,7 @@ ExecIndexEvalArrayKeys(ExprContext *econtext,
>> /* We want to keep the arrays in per-tuple memory */
>> oldContext = MemoryContextSwitchTo(econtext->ecxt_per_tuple_memory);
>>
>> - for (j = 0; j < numArrayKeys; j++)
>> + for (j = numArrayKeys-1; j >= 0; j--)

> Why is this loop reversed? (I could have missed some discussion about
> this, I just wanted to make sure it was intentional.)

There was some discussion about this change and in fact if you look at CVS
HEAD you'll find it already applied. It probably doesn't make a big difference
at least in most cases but it seems more sensible to increment the least
significant key elements first since that maximizes the chances of fetching
index keys from the same index pages or nearby pages. Incrementing the most
significant index keys would maximize the distance we're jumpin around in the
index tree.

> But I'm not convinced that this GUC is well-advised; at least, it needs
> some advice about how to determine a sensible size for the parameter
> (and maybe a better name). But is it really necessary at all?

I'm not sure which version of my patch Zoltan's was based on. The later
versions of mine had a GUC named effective_spindle_count which I think is
nicely abstracted away from the implementation details. We do need something
like that because we have no way to determine how wide a raid stripe Postgres
is sitting on and the optimal read-ahead depends on that.

The alternative would be to measure the bandwith with various amounts of
read-ahead. But I fear that would be quite hard on a production system with
the amount of noise from other i/o. It's hard enough on an idle machine with
synthetic benchmarks.

--
Gregory Stark
EnterpriseDB

http://www.enterprisedb.com

Ask me about EnterpriseDB's Slony Replication support!

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [pgadmin-support] pgAdmin v1.8.4 editing binary data in 'view data'

On Fri, Jul 11, 2008 at 10:06 PM, Will Langford <unfies@gmail.com> wrote:
> Is there a way to re-enable the editing of binary data in 1.8.4 ?
>
> We were running old versions of pgAdmin (pre v1.6.0), and actively
> used the View Data option on tables to edit the binary data within a
> couple tables. Binary Data entries were typically pretty small, under
> 512 bytes most of the time.
>
> We've upgraded to 1.8.4 and noted that all the binary data columns are
> now just <binary data> and can't be edited.

No - it was disabled because it was very far from safe.

--
Dave Page
EnterpriseDB UK:

http://www.enterprisedb.com

--
Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

Re: [HACKERS] PATCH: CITEXT 2.0 v3

On Jul 11, 2008, at 16:45, Tom Lane wrote:

> Not sure about a memory leak, but this code is clearly wrong if
> str_tolower results in a change of physical string length (clearly
> possible in Turkish, for instance, and probably in some other
> locales too). You need to do strlen's on the lowercased strings.

Ah, great point. Thanks.

Anyone else got an idea on the memory leak?

Best,

David

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PATCH: CITEXT 2.0 v3

"David E. Wheeler" <david@kineticode.com> writes:
> lcstr = str_tolower(VARDATA_ANY(left), VARSIZE_ANY_EXHDR(left));
> rcstr = str_tolower(VARDATA_ANY(right), VARSIZE_ANY_EXHDR(right));

> result = varstr_cmp(
> lcstr,
> VARSIZE_ANY_EXHDR(left),
> rcstr,
> VARSIZE_ANY_EXHDR(right)
> );

Not sure about a memory leak, but this code is clearly wrong if
str_tolower results in a change of physical string length (clearly
possible in Turkish, for instance, and probably in some other
locales too). You need to do strlen's on the lowercased strings.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [SQL] PERSISTANT PREPARE (another point of view)

Milan Oparnica <milan.opa@hotmail.com> writes:
> [ much snipped ]
> What could we gain by introducing a kind of global prepared statement area, is SIMPLICITY of DB DEVELOPMENT AND MAINTENANCE.
> The idea is: LETS SEPARATE SQL STATEMENTS FROM APPLICATION CODE.

Most people around this project think that the best way to do that is to
push as much logic as you can into server-side stored procedures. That
gives you every advantage that a persistent-prepared-statement feature
would offer, and more besides:

* you can push procedural logic, as well as SQL, out of the application

* you can improve performance by reducing the number of network round
trips needed to accomplish a multi-SQL-statement task

regards, tom lane

--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql

Re: [HACKERS] Vacuuming leaked temp tables (once again)

On Fri, 2008-07-11 at 17:26 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > So it would seem that we need a way of handling temp tables that doesn't
> > rely on catalog entries at all.
>
> That's a complete non-starter; I need go no farther than to point out
> that it would break clients that expect to see their temp tables
> reflected in pg_class and so forth.

What does the SQL Standard say about the Information Schema I wonder/

> There's been some idle musing in the past about causing pg_class and
> friends to have inheritance-child tables that are "temp", both in the
> sense of being backend-local and of not having guaranteed storage,
> and arranging to store the rows needed for a backend's temp tables
> in there. There's still a long way to go to make that happen, but
> at least it would be reasonably transparent on the client side.

OK, very cool if we could make it work. I realised it would have to
apply all the way through to pg_statistic.

Brain dump a little more, while we're on the subject? This aspect is
something I've not spent any time on yet, so even a few rungs up the
ladder will help lots. Thanks.

--
Simon Riggs

www.2ndQuadrant.com

PostgreSQL Training, Services and Support


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[SQL] PERSISTANT PREPARE (another point of view)

Hi,

We are new to Postgre, actually we are migrating from MICROSOFT DBMS technologies to...hopefully Postgre.
Our company is involved in ERP business software in Serbia and region, currently counting over 200 clients. Some of them have DB's over 4GB in size.

Reason for posting is implementation of PREPARE statements.
I've read a thread "# PREPARE and stuff PFC" on pgsql-performance 2007-06 list and I do agree that it would not gain performance issues.

What could we gain by introducing a kind of global prepared statement area, is SIMPLICITY of DB DEVELOPMENT AND MAINTENANCE.

Here is our point of view:

We have an application layer running over db layer. Application layer consists of classes and interfaces and db layer contains data and various data manipulation structures.
Application layer calls SQL statements expecting some datasets as results (inventory list for instance). What it doesn't care about is HOW is query built (sorting, conditions, etc.) as long as it returns EXPECTED columns. Application simplly calls EXECUTE <statement> (<param1>,<param2>...). Developers working application layer do not interfere with developers working on DB and queries. Plus MOST queries can be written to be reusable in various situations !!!

The idea is: LETS SEPARATE SQL STATEMENTS FROM APPLICATION CODE.

This way, we can introduce fine tuning to each of our clients without having to recompile our application. We can also work on improvements of queries performance and complexity without recompile of the application layer.

Since one company has one set of rules PREPARED statements apply to every client connected to that database.

Now, instead of preparing statements on each connection request (and we use around 900 prepared statements), why couldn't we simply prepare these statements ONCE and keep them in some global storage for future everyday usage.

We use this approach for forms & reports creation where Crystal Report engine creates outlined report based on static prepared statement.

This approach is probably not suitable for large db systems with tons of data, but is very efficient in 90% of small and medium business size databases.

Please consider this issue when planning your WISH LIST or hopefully To-do-task-list.

Ill be glad to here comments on this topic as well.

Milan Oparnica
MELANY SOFWARE TEAM


Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! Try it!

Re: [HACKERS] [PATCHES] GIN improvements

> I've committed the multicolumn one with minor revisions (fix some poor
> English in docs and comments, add regression-test coverage). Do you
Thank you very much.

> need more review of fast_insert yet? It looked like a number of people
> commented on it already.
I should modify it to support/synchronize with multicolumn GIN - both patches
touch the same pieces of code, and I didn't make a single patch to simplify review.

--
Teodor Sigaev E-mail: teodor@sigaev.ru
WWW: http://www.sigaev.ru/

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [pgsql-es-ayuda] pg_dump y pg_restore

Mas que las consultas, el problema es mas con los DELETE, UPDATE  e INSERTS, ya que el postgres.conf es un espejo de lo que esta en produccion


Miguel Beltran R. wrote:
el EXPLAIN lo que hace es decir como se ejecuta la consulta, si esta usando los indices por ejemplo en la consulta te puede salir INDEX SCAN o SEQUENCE SCAN.  Para tu caso, las consultas que haces en tus dos equipos deben arrojar los mismos resultados; si son diferentes es que las configuraciones de postgres.conf estab diferentes  El 11/07/08, Oscar Argueta <oscar.argueta@transtel.com.gt> escribió:   
El  'EXPLAIN' me ayuda tambien a los tiempos de restauracion de las bases de datos?  Saludos    Miguel Beltran R. wrote: Te falto mandar el correo a la lista     
 Un manual que encontre ahorita en   
español donde dan un poco de ejemplo     
2001.encuentrolinux.cl/documentacion/PostgreSQL.pdf.gz  para   
mas busca en el historial de la lista     
 http://www.google.com.mx/search?q=explain+site%3Aarchives.postgresql.org%2Fpgsql-es-ayuda&ie=utf-8&oe=utf-8&aq=t&rls=com.frontmotion:es-AR:unofficial&client=firefox-a  El   
día 11 de julio de 2008 12:07, Oscar Argueta     
<oscar.argueta@transtel.com.gt> escribió:    
Gracias Miguel, fijate que por la poca experiencia del mantenimiento a base     
de datos,, lo que he estado realizando rudimentariamente, es que en la   
noche     
cuando el servicio no estan exigible, hago dump a la base , luego drop   
y de     
ultimo createdb, restore para que los procesos corran tal y como en el   
host     
de pruebas. Con anterioridad habia realizado un VACUUM pero lo que   
provoco     
fue que se me desintegraran los datos, la razon la desconozco, ahora   
mi     
pregunta es el EXPLAIN/ANALYZE que servicio realiza o que tipo   
de     
mantenimiento realiza.  Att.  Miguel Beltran R. wrote:  usa un explain (o   
es explain analyze?) para ver como se ejecuta casa     
consulta  El día 11 de   
julio de 2008 10:16, Oscar Argueta     
<oscar.argueta@transtel.com.gt> escribió:   Tenga   
el Mejor de los dias     
 Podria alguien explicarme por que cuando hago   
'pg_dump' a una base que esta     
en produccion y luego la restauro (con   
'pg_restore') en otro host que es     
para pruebas, los procedimientos corren   
mas rapido que en produccion.     
 Saludos --  Oscar Argueta Transtel,   
S.A.     
2386-1231/39     --  Oscar Argueta Transtel, S.A. 2386-1231/39    
    
-- Oscar Argueta     
Transtel, S.A. 2386-1231/39   
    

--
Oscar Argueta Transtel, S.A. 2386-1231/39

[pgadmin-hackers] Support of INHERIT in existing tables (8.2+ releases)

Index: pgadmin/include/schema/pgTable.h
===================================================================
--- pgadmin/include/schema/pgTable.h (revision 7393)
+++ pgadmin/include/schema/pgTable.h (working copy)
@@ -72,6 +72,7 @@
long GetInheritedTableCount() { if (inheritedTableCount < 0) UpdateInheritance(); return inheritedTableCount; }
wxString GetInheritedTables() { GetInheritedTableCount(); return inheritedTables; }
wxString GetQuotedInheritedTables() { GetInheritedTableCount(); return quotedInheritedTables; }
+ wxArrayString GetInheritedTablesOidList() { GetInheritedTableCount(); return inheritedTablesOidList; }
wxArrayString GetQuotedInheritedTablesList() { GetInheritedTableCount(); return quotedInheritedTablesList; }
wxString GetCoveringIndex(ctlTree *browser, const wxString &collist);
pgCollection *GetColumnCollection(ctlTree *browser);
@@ -124,7 +125,7 @@
long inheritedTableCount;
wxString quotedInheritedTables, inheritedTables, primaryKey, quotedPrimaryKey,
primaryKeyName, primaryKeyColNumbers, tablespace;
- wxArrayString quotedInheritedTablesList;
+ wxArrayString quotedInheritedTablesList, inheritedTablesOidList;
slSet *replicationSet;
OID tablespaceOid;
};
Index: pgadmin/include/dlg/dlgTable.h
===================================================================
--- pgadmin/include/dlg/dlgTable.h (revision 7393)
+++ pgadmin/include/dlg/dlgTable.h (working copy)
@@ -56,7 +56,7 @@
wxString GetItemConstraintType(ctlListView *list, long pos);
bool hasPK;

- wxArrayString previousColumns, previousConstraints;
+ wxArrayString previousColumns, previousConstraints, previousTables;
wxArrayString tableOids, inheritedTableOids;
wxTreeItemId columnsItem, constraintsItem;

Index: pgadmin/schema/pgTable.cpp
===================================================================
--- pgadmin/schema/pgTable.cpp (revision 7393)
+++ pgadmin/schema/pgTable.cpp (working copy)
@@ -511,7 +511,7 @@
{
// not checked so far
pgSet *props=ExecuteSet(
- wxT("SELECT c.relname , nspname\n")
+ wxT("SELECT c.oid, c.relname , nspname\n")
wxT(" FROM pg_inherits i\n")
wxT(" JOIN pg_class c ON c.oid = i.inhparent\n")
wxT(" JOIN pg_namespace n ON n.oid=c.relnamespace\n")
@@ -533,6 +533,7 @@
+ qtIdent(props->GetVal(wxT("relname")));
quotedInheritedTablesList.Add(GetQuotedSchemaPrefix(props->GetVal(wxT("nspname")))
+ qtIdent(props->GetVal(wxT("relname"))));
+ inheritedTablesOidList.Add(props->GetVal(wxT("oid")));
props->MoveNext();
inheritedTableCount++;
}
Index: pgadmin/dlg/dlgTable.cpp
===================================================================
--- pgadmin/dlg/dlgTable.cpp (revision 7393)
+++ pgadmin/dlg/dlgTable.cpp (working copy)
@@ -157,14 +157,19 @@
if (table->GetTablespaceOid() != 0)
cbTablespace->SetKey(table->GetTablespaceOid());

+ inheritedTableOids=table->GetInheritedTablesOidList();
+
wxArrayString qitl=table->GetQuotedInheritedTablesList();
size_t i;
for (i=0 ; i < qitl.GetCount() ; i++)
+ {
+ previousTables.Add(qitl.Item(i));
lbTables->Append(qitl.Item(i));
+ }

- btnAddTable->Disable();
- lbTables->Disable();
- cbTables->Disable();
+ btnAddTable->Enable(connection->BackendMinimumVersion(8, 2));
+ lbTables->Enable(connection->BackendMinimumVersion(8, 2));
+ cbTables->Enable(connection->BackendMinimumVersion(8, 2));
chkHasOids->Enable(table->GetHasOids() && connection->BackendMinimumVersion(8, 0));
cbTablespace->Enable(connection->BackendMinimumVersion(7, 5));

@@ -278,11 +283,30 @@
// create mode
btnChangeCol->Hide();

+ // Add the default tablespace
+ cbTablespace->Insert(_("<default tablespace>"), 0, (void *)0);
+ cbTablespace->SetSelection(0);
+ }
+
+ if (connection->BackendMinimumVersion(8,2) || !table)
+ {
wxString systemRestriction;
if (!settings->GetShowSystemObjects())
systemRestriction =
wxT(" AND ") + connection->SystemNamespaceRestriction(wxT("n.nspname"));
-
+
+ if (table)
+ {
+ wxString oids = table->GetOidStr();
+ int i;
+ for (i=0 ; i < (int)inheritedTableOids.GetCount() ; i++)
+ {
+ oids += wxT(", ") + inheritedTableOids.Item(i);
+ }
+ if (oids.Length() > 0)
+ systemRestriction += wxT(" AND c.oid NOT IN (") + oids + wxT(")");
+ }
+
pgSet *set=connection->ExecuteSet(
wxT("SELECT c.oid, c.relname , nspname\n")
wxT(" FROM pg_class c\n")
@@ -302,10 +326,6 @@
}
delete set;
}
-
- // Add the default tablespace
- cbTablespace->Insert(_("<default tablespace>"), 0, (void *)0);
- cbTablespace->SetSelection(0);
}

FillConstraint();
@@ -511,7 +531,7 @@
wxArrayString tmpDef=previousColumns;
wxString tmpsql;

- // Build a tmeporary list of ADD COLUMNs, and fixup the list to remove
+ // Build a temporary list of ADD COLUMNs, and fixup the list to remove
for (pos=0; pos < lstColumns->GetItemCount() ; pos++)
{
definition = lstColumns->GetText(pos, 3);
@@ -555,10 +575,34 @@
AppendNameChange(sql);
AppendOwnerChange(sql, wxT("TABLE ") + tabname);

+ tmpDef=previousTables;
+ tmpsql.Empty();
+
+ // Build a temporary list of INHERIT tables, and fixup the list to remove
+ for (pos = 0 ; pos < (int)lbTables->GetCount() ; pos++)
+ {
+ definition = lbTables->GetString(pos);
+ index = tmpDef.Index(definition);
+ if (index < 0)
+ tmpsql += wxT("ALTER TABLE ") + table->GetQuotedFullIdentifier()
+ + wxT(" INHERIT ") + qtIdent(definition) + wxT(";\n");
+ else
+ tmpDef.RemoveAt(index);
+ }
+
+ for (index = 0 ; index < (int)tmpDef.GetCount() ; index++)
+ {
+ definition = tmpDef.Item(index);
+ sql += wxT("ALTER TABLE ") + table->GetQuotedFullIdentifier()
+ + wxT(" NO INHERIT ") + qtIdent(definition) + wxT(";\n");
+ }
+ // Add the ADD COLUMNs...
+ sql += tmpsql;
+
tmpDef=previousConstraints;
tmpsql.Empty();

- // Build a tmeporary list of ADD CONSTRAINTs, and fixup the list to remove
+ // Build a temporary list of ADD CONSTRAINTs, and fixup the list to remove
for (pos=0; pos < lstConstraints->GetItemCount() ; pos++)
{
wxString conname= qtIdent(lstConstraints->GetItemText(pos));
Hi,

I don't know if you have read this page
(http://www.postgresonline.com/journal/index.php?/archives/59-How-to-Inherit,-Unherit-and-Merge-Inherit.html)
but it complains on the lack of inherit support for existing tables.

So, here is a patch to add support on adding inherited tables on already
existing tables. The feature is available since PostgreSQL 8.2 release.

Tested on Linux. It works fine there. I didn't check Win32 platform
because I didn't change any xrc files :) Didn't check on Mac OS X either
cause I don't have one (btw, I'm following ebay's Mac Mini list to get
one soon).

Regards.


--
Guillaume.

http://www.postgresqlfr.org

http://dalibo.com

Re: [pgsql-es-ayuda] pg_dump y pg_restore

el EXPLAIN lo que hace es decir como se ejecuta la consulta, si esta
usando los indices por ejemplo en la consulta te puede salir INDEX
SCAN o SEQUENCE SCAN.

Para tu caso, las consultas que haces en tus dos equipos deben arrojar
los mismos resultados; si son diferentes es que las configuraciones de
postgres.conf estab diferentes

El 11/07/08, Oscar Argueta <oscar.argueta@transtel.com.gt> escribió:
> El 'EXPLAIN' me ayuda tambien a los tiempos de restauracion de las bases de
> datos?
>
> Saludos
>
>
>
> Miguel Beltran R. wrote:
> Te falto mandar el correo a la lista

Un manual que encontre ahorita en
> español donde dan un poco de
> ejemplo
2001.encuentrolinux.cl/documentacion/PostgreSQL.pdf.gz

para
> mas busca en el historial de la
> lista

http://www.google.com.mx/search?q=explain+site%3Aarchives.postgresql.org%2Fpgsql-es-ayuda&ie=utf-8&oe=utf-8&aq=t&rls=com.frontmotion:es-AR:unofficial&client=firefox-a

El
> día 11 de julio de 2008 12:07, Oscar
> Argueta
<oscar.argueta@transtel.com.gt> escribió:

> Gracias Miguel, fijate que por la poca experiencia del mantenimiento a
> base
de datos,, lo que he estado realizando rudimentariamente, es que en la
> noche
cuando el servicio no estan exigible, hago dump a la base , luego drop
> y de
ultimo createdb, restore para que los procesos corran tal y como en el
> host
de pruebas. Con anterioridad habia realizado un VACUUM pero lo que
> provoco
fue que se me desintegraran los datos, la razon la desconozco, ahora
> mi
pregunta es el EXPLAIN/ANALYZE que servicio realiza o que tipo
> de
mantenimiento realiza.

Att.

Miguel Beltran R. wrote:

usa un explain (o
> es explain analyze?) para ver como se ejecuta casa
consulta

El día 11 de
> julio de 2008 10:16, Oscar
> Argueta
<oscar.argueta@transtel.com.gt> escribió:


Tenga
> el Mejor de los dias

Podria alguien explicarme por que cuando hago
> 'pg_dump' a una base que esta
en produccion y luego la restauro (con
> 'pg_restore') en otro host que es
para pruebas, los procedimientos corren
> mas rapido que en produccion.

Saludos
--

Oscar Argueta
Transtel,
> S.A.
2386-1231/39


--

Oscar Argueta
Transtel, S.A.
2386-1231/39

>


>
> --
> Oscar Argueta
Transtel, S.A.
2386-1231/39
>


--
________________________________________
Lo bueno de vivir un dia mas
es saber que nos queda un dia menos de vida
--
TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda

Re: [pgsql-es-ayuda] Herencia?

Arturo Munive escribió en mayo de 2007:

> osea en conclusión
> hasta ahora la herencia en postgresql solo abarca el hecho
> de 'heredar' los campos de una tabla en sus hijas
> mas no el hecho de tratar un registro de la tabla hija como si fuese
> un registro de la tabla padre, o hacer polimorfismo
>
> es decir si tengo una función
> f1(p padre)
>
> no puedo
> select f1(h);
>
> donde h sea un registro del tipo de la tabla hija.
>
>
> estoy en lo cierto??
>
> por curiosidad piensan dar soporte a eso en algún momento...

Efectivamente, como ya has observado, no puedes hacer eso :-) Y además,
no hay nadie trabajando en hacerlo funcionar que yo sepa. Es un
problema que existe desde hace años pero es bastante difícil y no ha
habido la motivación suficiente.

--
Alvaro Herrera

http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda

Re: [INTERFACES] connecting with libpq interface

Tom Lane wrote:

> Or you could
> tell the postmaster to use /var/run/postgresql --- there's a
> configuration parameter for that somewhere, IIRC.

In conninfo string, you add "host=/tmp"

--
Alvaro Herrera

http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

--
Sent via pgsql-interfaces mailing list (pgsql-interfaces@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-interfaces

Re: [PERFORM] How many updates and inserts

Have a look at the pg_stat_user_tables table.

On Fri, 11 Jul 2008, Campbell, Lance wrote:

> PostgreSQL: 8.2
>
> How can I identify how many inserts and updates are being done in a
> given time frame for a database?
>
>
>
> Thanks,
>
>
>
>
>
> Lance Campbell
>
> Project Manager/Software Architect
>
> Web Services at Public Affairs
>
> University of Illinois
>
> 217.333.0382
>
> http://webservices.uiuc.edu
>
> My e-mail address has changed to lance@illinois.edu
>
>
>
>

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] REINDEX/SELECT deadlock?

Tom Lane wrote:
> Karl Wright <kwright@metacarta.com> writes:
>
>>I just noticed what looks like a deadlock situation on postgresql
>>8.2.4.
>
>
> Did you look into pg_locks to see what locks those transactions have and
> are waiting for?
>
> regards, tom lane

No. Unlike a typical transaction-based deadlock, I did not see a deadlock error come back - it just
seemed to wait indefinitely instead. So I'm not even sure anything will show up in the pg_locks
table. In any case, it will have to happen again before I can spelunk more, since I had to reset
everything because the system was dead and it was needed by others.

Karl


--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [INTERFACES] connecting with libpq interface

Vincent Predoehl <vpredoehl@phoenixwebgroup.com> writes:
> On Jul 11, 2008, at 3:05 PM, Tom Lane wrote:
>>> could not connect to server: No such file or directory
>>> Is the server running locally and accepting
>>> connections on Unix domain socket "/var/run/
>>> postgresql/.s.PGSQL.5432"?
>>
>> What I'd wonder is whether the postmaster is using that socket
>> location
>> or not. The more common location is /tmp/.s.PGSQL.5432. You might
>> have
>> a problem with having a copy of libpq that has a different default
>> socket path compiled into it than the postmaster does.

> Do you know where can I find that in the source code? I used the
> 8.3.3 source from postgresql.org.

The postgresql.org sources will most certainly default to using /tmp.
What I suspect now is that you have a postmaster that you built from
source, and it's using /tmp (did you look for the socket file to
verify?), but your client program is linking to an Ubuntu-supplied
version of libpq.so that has a nonstandard socket location built in.
You'll need to fool with ldconfig or local equivalent to get the
dynamic linker to select the right copy of libpq.so. Or you could
tell the postmaster to use /var/run/postgresql --- there's a
configuration parameter for that somewhere, IIRC.

regards, tom lane

--
Sent via pgsql-interfaces mailing list (pgsql-interfaces@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-interfaces

Re: [HACKERS] PATCH: CITEXT 2.0 v3

On Jul 11, 2008, at 13:02, Zdenek Kotala wrote:

>> Thank you, Zdenek. Have you had a chance to try citext yet? Or did
>> you just read the source?
>
> I tested version two on Solaris/SPARC and Sun studio compiler. I
> checked last version only quickly (comparing your changes).

Thanks.

I just updated my performance test script (attached) by increasing the
number of rows tested by an order of magnitude. So now it creates
1,000,000 rows, queries them, adds indexes, and then queries them
again. Unfortunately, CITEXT seems to have a memory leak somewhere,
because when I index the CITEXT column, it fails with "ERROR: out of
memory". So obviously something's not getting cleaned up. Here's the
btree indexing function:

Datum
citext_cmp(PG_FUNCTION_ARGS)
{
text *left = PG_GETARG_TEXT_PP(0);
text *right = PG_GETARG_TEXT_PP(1);
int32 result;

result = citextcmp(left, right);

PG_FREE_IF_COPY(left, 0);
PG_FREE_IF_COPY(right, 1);

PG_RETURN_INT32(result);
}

And here's citextcmp():

citextcmp (text *left, text *right)
{
char *lcstr, *rcstr;
int result;

lcstr = str_tolower(VARDATA_ANY(left), VARSIZE_ANY_EXHDR(left));
rcstr = str_tolower(VARDATA_ANY(right), VARSIZE_ANY_EXHDR(right));

result = varstr_cmp(
lcstr,
VARSIZE_ANY_EXHDR(left),
rcstr,
VARSIZE_ANY_EXHDR(right)
);

pfree(lcstr);
pfree(rcstr);
return result;
}

Can anyone see where I'm failing to free up memory? Might it be in
some other function?

Thanks!

David

Re: [GENERAL] recovery do not finish

On Fri, 2008-07-11 at 16:53 -0400, Alvaro Herrera wrote:
> Benedek Laszlo wrote:
> > Hello,
> >
> > I have a serious problem with a production database.
> > We had a no disk space left on device problem, and postgres did not stop, so it was killed ( kill -9 )
> > we made free space and reboot, but postgres not start properly.
> > We have waited for more than 2 hours, but psql still says that the system is starting up.
> > ( Db size is about 20 gb )
> > the os is Ubuntu 4.0.3-1ubuntu5
> > postgres is 8.1.4

2 hours is a long time for a crash recovery. What does the log say?

> There are known bugs in the recovery code; IIRC some of them may cause
> the recovery to hang.

Just to clarify: There are no known bugs in recovery code at the highest
maintenance release level in any version of PostgreSQL after 8.0 on
Linux, possibly before that also. So upgrade, yes, very soon.

--
Simon Riggs

www.2ndQuadrant.com

PostgreSQL Training, Services and Support


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[PERFORM] How many updates and inserts

PostgreSQL: 8.2

How can I identify how many inserts and updates are being done in a given time frame for a database?

 

Thanks,

 

 

Lance Campbell

Project Manager/Software Architect

Web Services at Public Affairs

University of Illinois

217.333.0382

http://webservices.uiuc.edu

My e-mail address has changed to lance@illinois.edu

 

Re: [HACKERS] Vacuuming leaked temp tables (once again)

Simon Riggs <simon@2ndquadrant.com> writes:
> So it would seem that we need a way of handling temp tables that doesn't
> rely on catalog entries at all.

That's a complete non-starter; I need go no farther than to point out
that it would break clients that expect to see their temp tables
reflected in pg_class and so forth.

There's been some idle musing in the past about causing pg_class and
friends to have inheritance-child tables that are "temp", both in the
sense of being backend-local and of not having guaranteed storage,
and arranging to store the rows needed for a backend's temp tables
in there. There's still a long way to go to make that happen, but
at least it would be reasonably transparent on the client side.

> Are we also at risk from very long lived sessions that use temp tables?

Yeah, one of the bigger problems with it is that no one else could
even see whether a backend's temp table was at risk of wraparound
(or even before actual wraparound, in need of freezing because pg_clog
is supposed to be truncated). Possibly a backend could advertise a
min frozen xid for its temp tables in the PGPROC array.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[PERFORM] How many inserts am I doing

PostgreSQL: 8.2

How can you identify how many inserts are being done in a given time frame for a database?

 

Thanks,

 

Lance Campbell

Project Manager/Software Architect

Web Services at Public Affairs

University of Illinois

217.333.0382

http://webservices.uiuc.edu

My e-mail address has changed to lance@illinois.edu

 

Re: [GENERAL] Default fill factor for tables?

On Fri, Jul 11, 2008 at 3:24 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>
> On Fri, 2008-07-11 at 14:51 -0600, Scott Marlowe wrote:
>
>> I would kindly disagree. I'm looking at a project where HOT updates
>> are going to be a real performance enhancement, but I'll have to
>> create a hundred or so tables ALL with fillfactor tacked on the end.
>
> You clearly think that adjusting fillfactor helps in all cases with HOT.
> I disagree with that, else would have pushed earlier for exactly what
> you suggest. In fact, I've has this exact discussion previously.

How odd, because that's clearly NOT what I said. In fact I used the
single "a" to describe the project I was looking at where having a
default table fill factor of < 100 would be very useful. OTOH, I have
stats databases that have only insert and drop child tables that would
not benefit from < 100 fill factor. For a heavily updated database,
where most of the updates will NOT be on indexed columns, as the ONE
project I'm looking at, a default fill factor would be quite a time
saver.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Default fill factor for tables?

On Fri, 2008-07-11 at 14:51 -0600, Scott Marlowe wrote:

> I would kindly disagree. I'm looking at a project where HOT updates
> are going to be a real performance enhancement, but I'll have to
> create a hundred or so tables ALL with fillfactor tacked on the end.

You clearly think that adjusting fillfactor helps in all cases with HOT.
I disagree with that, else would have pushed earlier for exactly what
you suggest. In fact, I've has this exact discussion previously.

--
Simon Riggs

www.2ndQuadrant.com

PostgreSQL Training, Services and Support


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [pgsql-es-ayuda] ERROR EN COMPILACION FUNCTION

2008/7/11 Fabio Arias <fharias@gmail.com>:
> Tambien como hago para ejecutarla desde PHP gracias! :D

Para ejecutar la función,

* SELECT FROM ANULAR_APUESTA(parametros...);

Y desde PHP:

* Usas pg_connect para conectarte a la DB;
* Usas pg_query para realizar el query;
* Usas pg_fetch_row, pg_fetch_assoc o equivalente para levantar los
resultados...

Espero te ayude, acá esta la info posta sobre php:

www.php.net

Saludos,

Juan
--
TIP 2: puedes desuscribirte de todas las listas simultáneamente
(envía "unregister TuDirecciónDeCorreo" a majordomo@postgresql.org)

Re: [HACKERS] Vacuuming leaked temp tables (once again)

On Fri, 2008-06-27 at 12:43 -0400, Tom Lane wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> >> The only solution proposed in that thread was to auto-delete temp
> >> tables at postmaster restart; which I opposed on the grounds that
> >> throwing away data right after a crash was a terrible idea from a
> >> forensic standpoint.
>
> > Why not just rename the files out of the way, and nuke the entries from
> > the catalog?
>
> It's usually tough to make any sense of the contents of a table if you
> don't have the catalog entries. Anyway, that approach would put the
> onus on the admin to clean things up eventually, which isn't all that
> appealing.

We need to learn to live without the catalog entries anyway.

In Hot Standby mode, creating a temp table would cause a write to the
catalog, which would then fail. If we want to allow creating temp tables
in Hot Standby mode then we must prevent them from inserting and then
later deleting them from the catalog.

So it would seem that we need a way of handling temp tables that doesn't
rely on catalog entries at all.

My proposal would be that we identify all temp table names by the xid
that first creates them (and their name...). In memory we would keep
track of which files go with which tablenames, so we can still locate
them easily. If we lose that context we can always see which files are
in need of vacuum using that xid.

Are we also at risk from very long lived sessions that use temp tables?
Do we need to put in a check for sessions to vacuum old temp tables that
are still valid?

I'm happy to work on this if a solution to all of the above emerges.

--
Simon Riggs

www.2ndQuadrant.com

PostgreSQL Training, Services and Support


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [GENERAL] How do I tell if a vacuum is currently running?

William Garrison wrote:
> If the autovacuum is running, will that show somewhere? I know there is
> a command to see currently running queries (not in front of me right
> now) but will that show vacuums or any other maintenance operations that
> might be running?

Yes, autovacuum appears in pg_stat_activity.

--
Alvaro Herrera

http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [PATCHES] GIN improvements

Teodor Sigaev <teodor@sigaev.ru> writes:
> http://www.sigaev.ru/misc/fast_insert_gin-0.7.gz
> http://www.sigaev.ru/misc/multicolumn_gin-0.3.gz

I've committed the multicolumn one with minor revisions (fix some poor
English in docs and comments, add regression-test coverage). Do you
need more review of fast_insert yet? It looked like a number of people
commented on it already.

regards, tom lane

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

[COMMITTERS] pgsql: Multi-column GIN indexes.

Log Message:
-----------
Multi-column GIN indexes. Teodor Sigaev

Modified Files:
--------------
pgsql/doc/src/sgml:
indices.sgml (r1.73 -> r1.74)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/indices.sgml?r1=1.73&r2=1.74)
pgsql/doc/src/sgml/ref:
create_index.sgml (r1.67 -> r1.68)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/ref/create_index.sgml?r1=1.67&r2=1.68)
pgsql/src/backend/access/gin:
ginbulk.c (r1.12 -> r1.13)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/gin/ginbulk.c?r1=1.12&r2=1.13)
ginentrypage.c (r1.16 -> r1.17)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/gin/ginentrypage.c?r1=1.16&r2=1.17)
ginget.c (r1.17 -> r1.18)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/gin/ginget.c?r1=1.17&r2=1.18)
gininsert.c (r1.13 -> r1.14)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/gin/gininsert.c?r1=1.13&r2=1.14)
ginscan.c (r1.16 -> r1.17)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/gin/ginscan.c?r1=1.16&r2=1.17)
ginutil.c (r1.15 -> r1.16)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/gin/ginutil.c?r1=1.15&r2=1.16)
ginvacuum.c (r1.20 -> r1.21)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/gin/ginvacuum.c?r1=1.20&r2=1.21)
ginxlog.c (r1.14 -> r1.15)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/gin/ginxlog.c?r1=1.14&r2=1.15)
pgsql/src/include/access:
gin.h (r1.22 -> r1.23)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/access/gin.h?r1=1.22&r2=1.23)
pgsql/src/include/catalog:
catversion.h (r1.465 -> r1.466)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/catversion.h?r1=1.465&r2=1.466)
pg_am.h (r1.56 -> r1.57)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/pg_am.h?r1=1.56&r2=1.57)
pgsql/src/test/regress/expected:
create_index.out (r1.28 -> r1.29)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/create_index.out?r1=1.28&r2=1.29)
pgsql/src/test/regress/sql:
create_index.sql (r1.24 -> r1.25)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/create_index.sql?r1=1.24&r2=1.25)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[pgadmin-support] pgAdmin v1.8.4 editing binary data in 'view data'

Is there a way to re-enable the editing of binary data in 1.8.4 ?

We were running old versions of pgAdmin (pre v1.6.0), and actively
used the View Data option on tables to edit the binary data within a
couple tables. Binary Data entries were typically pretty small, under
512 bytes most of the time.

We've upgraded to 1.8.4 and noted that all the binary data columns are
now just <binary data> and can't be edited.

Postgres versions 8.0, 8.2.4, and 8.3.3 are in use as backends.
pgAdmin III running on Windows 2000 systems.

-Will

--
Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

Re: [HACKERS] [WIP] collation support revisited (phase 1)

Zdenek Kotala escribió:

> The example is when you have translation data (vocabulary) in database.
> But the reason is that ANSI specify (chapter 4.2) charset as a part of
> string descriptor. See below:
>
> — The length or maximum length in characters of the character string type.
> — The catalog name, schema name, and character set name of the character
> set of the character string type.
> — The catalog name, schema name, and collation name of the collation of
> the character string type.

We already support multiple charsets, and are able to do conversions
between them. The set of charsets is hardcoded and it's hard to make a
case that a user needs to create new ones. I concur with Martijn's
suggestion -- there's no need for this to appear in a system catalog.

Perhaps it could be argued that we need to be able to specify the
charset a given string is in -- currently all strings are in the server
encoding (charset) which is fixed at initdb time. Making the system
support multiple server encodings would be a major undertaking in itself
and I'm not sure that there's a point.

--
Alvaro Herrera

http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[BUGS] Olá

Olá, preciso instalar o postgres 8.1.4 no windows server 2008 com active directory instalado, pode me ajudar ? Não estou conseguindo instalar, dá erro, acho que é por causa do AD.
 
Atenciosamente,
Marcos Fabrício Corso
Analista de Sistemas Júnior
JM Informática
Fone : (41)  3076-0896
Fax : (41)  3352-2688
marcoscorso@terra.com.br
www.informaticajm.com.br
 

Re: [GENERAL] Default fill factor for tables?

> Roberts, Jon escribió:
>
> > Why would you set the fillfactor to anything other than 100 for a
> > PostgreSQL table?
>
> To favor HOT updates.
>
> --

I can find very little information on hot updates but I found this: http://archives.postgresql.org/pgsql-patches/2006-11/msg00059.php

It states, "This design optimizies the updates when none of the index columns are modified and length of the tuple remains the same after update."

How can a row's length change? I think it must mean the size (in bytes) of the row remains the same.

If this is the constraint, then I still don't see the benefit. If the size can vary, I can see the benefit because the new column value may be larger than the old value thus needing the space.

Why isn't the hot update documented in these locations?
http://www.postgresql.org/docs/8.3/interactive/sql-createtable.html
http://www.postgresql.org/docs/8.3/interactive/sql-update.html
http://www.postgresql.org/docs/8.3/interactive/sql-altertable.html

Jon


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] recovery do not finish

Benedek Laszlo wrote:
> Hello,
>
> I have a serious problem with a production database.
> We had a no disk space left on device problem, and postgres did not stop, so it was killed ( kill -9 )
> we made free space and reboot, but postgres not start properly.
> We have waited for more than 2 hours, but psql still says that the system is starting up.
> ( Db size is about 20 gb )
> the os is Ubuntu 4.0.3-1ubuntu5
> postgres is 8.1.4

There are known bugs in the recovery code; IIRC some of them may cause
the recovery to hang. Update to 8.1.13 and try again.

--
Alvaro Herrera

http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Default fill factor for tables?

On Fri, Jul 11, 2008 at 2:10 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>
> On Fri, 2008-07-11 at 12:52 -0600, Scott Marlowe wrote:
>> On Fri, Jul 11, 2008 at 12:12 PM, Richard Broersma
>> <richard.broersma@gmail.com> wrote:
>> > On Fri, Jul 11, 2008 at 10:27 AM, Scott Marlowe <scott.marlowe@gmail.com> wrote:
>> >
>> >> Is there any way to set a different default fill factor?
>> >
>> > ALTER TABLE Yourtable
>> > SET ( FILLFACTOR = 50 );
>>
>> Hehe. I know how to do that. I mean the default fill factor for a
>> database / user for tables / indexes.. Like setting search_path for a
>> user.
>
> I think the reasoning was/is that setting it away from the default is
> only sensible in certain table-specific cases, so such a setting would
> more likely result in a general drop in performance.

I would kindly disagree. I'm looking at a project where HOT updates
are going to be a real performance enhancement, but I'll have to
create a hundred or so tables ALL with fillfactor tacked on the end.

Imagine dumping a db, setting the new target DB to default fill
factors and then reloading all the data from the dump. No need to
edit the dump file or a schema dump etc... I could definitely see a
lot of use cases for a default fill factor.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [pgsql-es-ayuda] ERROR EN COMPILACION FUNCTION

Tambien como hago para ejecutarla desde PHP gracias! :D


El día 11 de julio de 2008 15:49, Fabio Arias <fharias@gmail.com> escribió:
Muy buenas tardes muchachos ya logre compilar la FUNCTIOn y crearla pero no se como la puede ejecutar, alguno de uds me puede ayudar???

2008/7/11 Fabio Arias <fharias@gmail.com>:

Muy buenos dias muchachos, estoy empezando con la creacion de funciones y tengo este error y no se por que es?

Si me pueden dar una mano para mejorarlo les agradecere mucho....

=== psql 1 ===
psql:129: ERROR:  syntax error at end of input
LINEA 1: SELECT

########################################################################
CREATE FUNCTION ANULAR_APUESTA(IDTRANSACCION INTEGER, COLILLA VARCHAR, ACEPTACION_AEL VARCHAR, IDUSUARIO_REG VARCHAR) RETURNS INTEGER AS $$
DECLARE
    USUARIO "TSO"."USUARIO"%ROWTYPE;
    CUENTAUSUARIO "TSO"."CUENTA"%ROWTYPE;
    DISTRIBUIDOR "TSO"."CLIENTE"%ROWTYPE;
    CUENTADISTRIBUIDOR "TSO"."CUENTA"%ROWTYPE;
    PUNTODEVENTA "TSO"."CLIENTE"%ROWTYPE;
    TRANSACCION "TSO"."TRANSACCION"%ROWTYPE;
    SALDOFINAL NUMERIC(10,2);
    SALDOCOMISION NUMERIC(10,2);
    COMISIONPRODUCTODIS "TSO"."COMISION"%ROWTYPE;
    COMISIONPRODUCTOPDV "TSO"."COMISION"%ROWTYPE;
    COMISION NUMERIC(10,2);
    VALORCOMISION NUMERIC(10,2);
    IDTRANSACCION_ANULACION INTEGER;
    IDNOVEDAD INTEGER;
BEGIN
    -- CONSULTAR TRANSACCION
    SELECT * INTO TRANSACCION FROM "TSO"."TRANSACCION" WHERE "TRAN_ID"=IDTRANSACCION;
    IF NOT FOUND THEN
        RAISE EXCEPTION 'NO EXISTE TRANSACCION %',IDTRANSACCION;
        RETURN;
    END IF;
    -- BUSCAR USUARIO DE TRANSACCION
    SELECT * INTO USUARIO FROM "TSO"."USUARIO" WHERE "USUA_ID"=TRANSACCION."USUA_ID";
    IF NOT FOUND THEN
        RAISE EXCEPTION 'NO EXISTE USUARIO DE TRANSACCION %',IDTRANSACCION;
        RETURN;
    END IF;
    SELECT * INTO CUENTAUSUARIO FROM "TSO"."CUENTA" WHERE USUARIO."CUEN_ID";
    IF NOT FOUND THEN
        RAISE EXCEPTION 'NO EXISTE CUENTA PARA USUARIO %',USUARIO."USUA_ID";
        RETURN;
    END IF;
    SELECT * INTO PUNTODEVENTA FROM "TSO"."CLIENTE" WHERE "CLIE_ID"=USUARIO."CLIE_ID";
    IF NOT FOUND THEN
        RAISE EXCEPTION 'NO EXISTE PUNTO DE VENTA PARA USUARIO %',USUARIO."USUA_ID";
        RETURN;
    END IF;
    SELECT * INTO DISTRIBUIDOR FROM "TSO"."CLIENTE" WHERE "CLIE_ID"=PUNTODEVENTA."CLIE_PADRE";
    IF NOT FOUND THEN
        RAISE EXCEPTION 'NO EXISTE DISTRIBUIDOR PARA PUNTO DE VENTA %',PUNTODEVENTA."CLIE_ID";
        RETURN;
    END IF;
    SELECT * INTO CUENTADISTRIBUIDOR FROM "TSO"."CUENTA" WHERE "CUEN_ID"=DISTRIBUIDOR."CUEN_ID";
    IF NOT FOUND THEN
        RAISE EXCEPTION 'NO EXISTE CUENTA PARA DISTRIBUIDOR %',DISTRIBUIDOR."CLIE_ID";
        RETURN;
    END IF;
   
    -- INSERTAR MOVIMIENTO DE REVERSO DE VENTA
    SALDOFINAL := CUENTAUSUARIO."CUEN_SALDO"+TRANSACCION."TRAN_VALOR";
   
    INSERT INTO "TSO"."MOVIMIENTOSCUENTA" (
    "CUEN_ID","TRAN_ID","TIMC_ID","MOCU_FECHAMOVIMIENTO",
    "MOCU_SOBREGIROACTUAL", "MOCU_SALDOACTUAL",
    "MOCU_SOBREGIRO","MOCU_SALDO", "MOCU_REGISTRADOPOR", "MOCU_VALOR")
    VALUES(
    CUENTAUSUARIO."CUEN_ID",IDTRANSACCION,13,now(),
    0,SALDOFINAL,
    CUENTAUSUARIO."CUEN_SOBREGIRO",CUENTAUSUARIO."CUEN_SALDO",IDUSUARIO_REG,TRANSACCION."TRAN_VALOR");

    -- ACTUALIZAR EL SALDO DEL USUARIO
    UPDATE "TSO"."CUENTA" SET "CUEN_SALDO"="CUEN_SALDO"+TRANSACCION."TRAN_VALOR"
    WHERE "CUEN_ID"=CUENTAUSUARIO."CUEN_ID";

    -- BUSCAR COMISION LINEAL PDV
    SELECT * INTO COMISIONPRODUCTOPDV FROM "TSO"."COMISION" WHERE
    "USUA_ID"=USUARIO."USUA_ID" AND "PROD_ID"=TRANSACCION."PROD_ID"
    AND "TICO_ID"=2;
    IF NOT FOUND THEN
        COMISION := 0;
    ELSE
        COMISION := COMISIONPRODUCTOPDV."COMI_VALOR";
    END IF;
    VALORCOMISION := TRANSACCION."TRAN_VALOR"*(COMISION/100);
    SALDOCOMISION := SALDOFINAL;
    SALDOFINAL := SALDOFINAL-VALORCOMISION;
    -- INSERTAR MOVIMIENTO DE REVERSO DE COMISION
    INSERT INTO "TSO"."MOVIMIENTOSCUENTA" (
    "CUEN_ID","TRAN_ID","TIMC_ID","MOCU_FECHAMOVIMIENTO",
    "MOCU_SOBREGIROACTUAL", "MOCU_SALDOACTUAL",
    "MOCU_SOBREGIRO","MOCU_SALDO", "MOCU_REGISTRADOPOR", "MOCU_VALOR")
    VALUES(
    CUENTAUSUARIO."CUEN_ID",IDTRANSACCION,14,now(),
    0,SALDOFINAL,
    CUENTAUSUARIO."CUEN_SOBREGIRO",SALDOCOMISION,IDUSUARIO_REG,VALORCOMISION);
    -- ACTUALIZAR EL SALDO DEL USUARIO
    UPDATE "TSO"."CUENTA" SET "CUEN_SALDO"="CUEN_SALDO"-VALORCOMISION
    WHERE "CUEN_ID"=CUENTAUSUARIO."CUEN_ID";

    -- BUSCAR COMISION LINEAL DIS
    SELECT * INTO COMISIONPRODUCTODIS FROM "TSO"."COMISION" WHERE
    "CLIE_ID"=DISTRIBUIDOR."CLIE_ID" AND "PROD_ID"=TRANSACCION."PROD_ID"
    AND "TICO_ID"=3;
    IF NOT FOUND THEN
        COMISION := 0;
    ELSE
        COMISION := COMISIONPRODUCTODIS."COMI_VALOR";
    END IF;
    VALORCOMISION := TRANSACCION."TRAN_VALOR"*(COMISION/100);
    SALDOFINAL := CUENTADISTRIBUIDOR."CUEN_SALDO"-VALORCOMISION;
    -- INSERTAR REVERSO COMISION DE DISTRIBUIDOR
    INSERT INTO "TSO"."MOVIMIENTOSCUENTA" (
    "CUEN_ID","TRAN_ID","TIMC_ID","MOCU_FECHAMOVIMIENTO",
    "MOCU_SOBREGIROACTUAL", "MOCU_SALDOACTUAL",
    "MOCU_SOBREGIRO","MOCU_SALDO", "MOCU_REGISTRADOPOR", "MOCU_VALOR")
    VALUES(
    CUENTADISTRIBUIDOR."CUEN_ID",IDTRANSACCION,15,now(),
    0,SALDOFINAL,
    CUENTADISTRIBUIDOR."CUEN_SOBREGIRO",CUENTADISTRIBUIDOR."CUEN_SALDO",IDUSUARIO_REG,VALORCOMISION);
    -- ACTUALIZAR SALDO DE DISTRIBUIDOR
    UPDATE "TSO"."CUENTA" SET "CUEN_SALDO"="CUEN_SALDO"-VALORCOMISION
    WHERE "CUEN_ID"=CUENTADISTRIBUIDOR."CUEN_ID";
    --- TERMINADO EL ANULADO
    --- CREAR TRANSACCION DE ANULACION
    INSERT INTO "TSO"."TRANSACCION" (
    "TITR_ID", "PROD_ID", "USUA_ID", "TRAN_FECHA", "TRAN_VALOR", "TRAN_ESTADO", "TRAN_REGISTRADOPOR")
    VALUES (32, 2, IDUSUARIO_REG, now(), TRANSACCION."TRAN_VALOR", '1', IDUSUARIO_REG);
    SELECT currval('"TSO"."TRANSACCION_TRAN_ID_seq"') INTO IDTRANSACCION_ANULACION;

    -- INSERTAR NOVEDAD DE TRANSACCION
    INSERT INTO "TSO"."NOVEDADTRANSACCION"(
    "NOVE_ID", "TRAN_ID", "NOTR_IDTRANSACCION", "NOTR_OBSERVACION", "NOTR_REGISTRADOPOR")
    VALUES (5, IDTRANSACCIONANULACION, IDTRANSACCION, ACEPTACION_AEL, IDUSUARIO_REG);
    SELECT currval('"TSO"."NOVEDADTRANSACCION_NOTR_ID_seq"') INTO IDNOVEDAD;
    RETURN IDNOVEDAD;
END;
$$ LANGUAGE plpgsql;
########################################################################

--
Fabio Hernando Arias Vera
Cel. 314 411 7776



--
Fabio Hernando Arias Vera
Cel. 314 411 7776



--
Fabio Hernando Arias Vera
Cel. 314 411 7776

Re: [pgsql-es-ayuda] ERROR EN COMPILACION FUNCTION

Muy buenas tardes muchachos ya logre compilar la FUNCTIOn y crearla pero no se como la puede ejecutar, alguno de uds me puede ayudar???

2008/7/11 Fabio Arias <fharias@gmail.com>:
Muy buenos dias muchachos, estoy empezando con la creacion de funciones y tengo este error y no se por que es?

Si me pueden dar una mano para mejorarlo les agradecere mucho....

=== psql 1 ===
psql:129: ERROR:  syntax error at end of input
LINEA 1: SELECT

########################################################################
CREATE FUNCTION ANULAR_APUESTA(IDTRANSACCION INTEGER, COLILLA VARCHAR, ACEPTACION_AEL VARCHAR, IDUSUARIO_REG VARCHAR) RETURNS INTEGER AS $$
DECLARE
    USUARIO "TSO"."USUARIO"%ROWTYPE;
    CUENTAUSUARIO "TSO"."CUENTA"%ROWTYPE;
    DISTRIBUIDOR "TSO"."CLIENTE"%ROWTYPE;
    CUENTADISTRIBUIDOR "TSO"."CUENTA"%ROWTYPE;
    PUNTODEVENTA "TSO"."CLIENTE"%ROWTYPE;
    TRANSACCION "TSO"."TRANSACCION"%ROWTYPE;
    SALDOFINAL NUMERIC(10,2);
    SALDOCOMISION NUMERIC(10,2);
    COMISIONPRODUCTODIS "TSO"."COMISION"%ROWTYPE;
    COMISIONPRODUCTOPDV "TSO"."COMISION"%ROWTYPE;
    COMISION NUMERIC(10,2);
    VALORCOMISION NUMERIC(10,2);
    IDTRANSACCION_ANULACION INTEGER;
    IDNOVEDAD INTEGER;
BEGIN
    -- CONSULTAR TRANSACCION
    SELECT * INTO TRANSACCION FROM "TSO"."TRANSACCION" WHERE "TRAN_ID"=IDTRANSACCION;
    IF NOT FOUND THEN
        RAISE EXCEPTION 'NO EXISTE TRANSACCION %',IDTRANSACCION;
        RETURN;
    END IF;
    -- BUSCAR USUARIO DE TRANSACCION
    SELECT * INTO USUARIO FROM "TSO"."USUARIO" WHERE "USUA_ID"=TRANSACCION."USUA_ID";
    IF NOT FOUND THEN
        RAISE EXCEPTION 'NO EXISTE USUARIO DE TRANSACCION %',IDTRANSACCION;
        RETURN;
    END IF;
    SELECT * INTO CUENTAUSUARIO FROM "TSO"."CUENTA" WHERE USUARIO."CUEN_ID";
    IF NOT FOUND THEN
        RAISE EXCEPTION 'NO EXISTE CUENTA PARA USUARIO %',USUARIO."USUA_ID";
        RETURN;
    END IF;
    SELECT * INTO PUNTODEVENTA FROM "TSO"."CLIENTE" WHERE "CLIE_ID"=USUARIO."CLIE_ID";
    IF NOT FOUND THEN
        RAISE EXCEPTION 'NO EXISTE PUNTO DE VENTA PARA USUARIO %',USUARIO."USUA_ID";
        RETURN;
    END IF;
    SELECT * INTO DISTRIBUIDOR FROM "TSO"."CLIENTE" WHERE "CLIE_ID"=PUNTODEVENTA."CLIE_PADRE";
    IF NOT FOUND THEN
        RAISE EXCEPTION 'NO EXISTE DISTRIBUIDOR PARA PUNTO DE VENTA %',PUNTODEVENTA."CLIE_ID";
        RETURN;
    END IF;
    SELECT * INTO CUENTADISTRIBUIDOR FROM "TSO"."CUENTA" WHERE "CUEN_ID"=DISTRIBUIDOR."CUEN_ID";
    IF NOT FOUND THEN
        RAISE EXCEPTION 'NO EXISTE CUENTA PARA DISTRIBUIDOR %',DISTRIBUIDOR."CLIE_ID";
        RETURN;
    END IF;
   
    -- INSERTAR MOVIMIENTO DE REVERSO DE VENTA
    SALDOFINAL := CUENTAUSUARIO."CUEN_SALDO"+TRANSACCION."TRAN_VALOR";
   
    INSERT INTO "TSO"."MOVIMIENTOSCUENTA" (
    "CUEN_ID","TRAN_ID","TIMC_ID","MOCU_FECHAMOVIMIENTO",
    "MOCU_SOBREGIROACTUAL", "MOCU_SALDOACTUAL",
    "MOCU_SOBREGIRO","MOCU_SALDO", "MOCU_REGISTRADOPOR", "MOCU_VALOR")
    VALUES(
    CUENTAUSUARIO."CUEN_ID",IDTRANSACCION,13,now(),
    0,SALDOFINAL,
    CUENTAUSUARIO."CUEN_SOBREGIRO",CUENTAUSUARIO."CUEN_SALDO",IDUSUARIO_REG,TRANSACCION."TRAN_VALOR");

    -- ACTUALIZAR EL SALDO DEL USUARIO
    UPDATE "TSO"."CUENTA" SET "CUEN_SALDO"="CUEN_SALDO"+TRANSACCION."TRAN_VALOR"
    WHERE "CUEN_ID"=CUENTAUSUARIO."CUEN_ID";

    -- BUSCAR COMISION LINEAL PDV
    SELECT * INTO COMISIONPRODUCTOPDV FROM "TSO"."COMISION" WHERE
    "USUA_ID"=USUARIO."USUA_ID" AND "PROD_ID"=TRANSACCION."PROD_ID"
    AND "TICO_ID"=2;
    IF NOT FOUND THEN
        COMISION := 0;
    ELSE
        COMISION := COMISIONPRODUCTOPDV."COMI_VALOR";
    END IF;
    VALORCOMISION := TRANSACCION."TRAN_VALOR"*(COMISION/100);
    SALDOCOMISION := SALDOFINAL;
    SALDOFINAL := SALDOFINAL-VALORCOMISION;
    -- INSERTAR MOVIMIENTO DE REVERSO DE COMISION
    INSERT INTO "TSO"."MOVIMIENTOSCUENTA" (
    "CUEN_ID","TRAN_ID","TIMC_ID","MOCU_FECHAMOVIMIENTO",
    "MOCU_SOBREGIROACTUAL", "MOCU_SALDOACTUAL",
    "MOCU_SOBREGIRO","MOCU_SALDO", "MOCU_REGISTRADOPOR", "MOCU_VALOR")
    VALUES(
    CUENTAUSUARIO."CUEN_ID",IDTRANSACCION,14,now(),
    0,SALDOFINAL,
    CUENTAUSUARIO."CUEN_SOBREGIRO",SALDOCOMISION,IDUSUARIO_REG,VALORCOMISION);
    -- ACTUALIZAR EL SALDO DEL USUARIO
    UPDATE "TSO"."CUENTA" SET "CUEN_SALDO"="CUEN_SALDO"-VALORCOMISION
    WHERE "CUEN_ID"=CUENTAUSUARIO."CUEN_ID";

    -- BUSCAR COMISION LINEAL DIS
    SELECT * INTO COMISIONPRODUCTODIS FROM "TSO"."COMISION" WHERE
    "CLIE_ID"=DISTRIBUIDOR."CLIE_ID" AND "PROD_ID"=TRANSACCION."PROD_ID"
    AND "TICO_ID"=3;
    IF NOT FOUND THEN
        COMISION := 0;
    ELSE
        COMISION := COMISIONPRODUCTODIS."COMI_VALOR";
    END IF;
    VALORCOMISION := TRANSACCION."TRAN_VALOR"*(COMISION/100);
    SALDOFINAL := CUENTADISTRIBUIDOR."CUEN_SALDO"-VALORCOMISION;
    -- INSERTAR REVERSO COMISION DE DISTRIBUIDOR
    INSERT INTO "TSO"."MOVIMIENTOSCUENTA" (
    "CUEN_ID","TRAN_ID","TIMC_ID","MOCU_FECHAMOVIMIENTO",
    "MOCU_SOBREGIROACTUAL", "MOCU_SALDOACTUAL",
    "MOCU_SOBREGIRO","MOCU_SALDO", "MOCU_REGISTRADOPOR", "MOCU_VALOR")
    VALUES(
    CUENTADISTRIBUIDOR."CUEN_ID",IDTRANSACCION,15,now(),
    0,SALDOFINAL,
    CUENTADISTRIBUIDOR."CUEN_SOBREGIRO",CUENTADISTRIBUIDOR."CUEN_SALDO",IDUSUARIO_REG,VALORCOMISION);
    -- ACTUALIZAR SALDO DE DISTRIBUIDOR
    UPDATE "TSO"."CUENTA" SET "CUEN_SALDO"="CUEN_SALDO"-VALORCOMISION
    WHERE "CUEN_ID"=CUENTADISTRIBUIDOR."CUEN_ID";
    --- TERMINADO EL ANULADO
    --- CREAR TRANSACCION DE ANULACION
    INSERT INTO "TSO"."TRANSACCION" (
    "TITR_ID", "PROD_ID", "USUA_ID", "TRAN_FECHA", "TRAN_VALOR", "TRAN_ESTADO", "TRAN_REGISTRADOPOR")
    VALUES (32, 2, IDUSUARIO_REG, now(), TRANSACCION."TRAN_VALOR", '1', IDUSUARIO_REG);
    SELECT currval('"TSO"."TRANSACCION_TRAN_ID_seq"') INTO IDTRANSACCION_ANULACION;

    -- INSERTAR NOVEDAD DE TRANSACCION
    INSERT INTO "TSO"."NOVEDADTRANSACCION"(
    "NOVE_ID", "TRAN_ID", "NOTR_IDTRANSACCION", "NOTR_OBSERVACION", "NOTR_REGISTRADOPOR")
    VALUES (5, IDTRANSACCIONANULACION, IDTRANSACCION, ACEPTACION_AEL, IDUSUARIO_REG);
    SELECT currval('"TSO"."NOVEDADTRANSACCION_NOTR_ID_seq"') INTO IDNOVEDAD;
    RETURN IDNOVEDAD;
END;
$$ LANGUAGE plpgsql;
########################################################################

--
Fabio Hernando Arias Vera
Cel. 314 411 7776



--
Fabio Hernando Arias Vera
Cel. 314 411 7776

[HACKERS] Change of site

I'm getting many Delivery Failures on list postings.

I think this is because my emails are now coming from a different
domain. I've changed this because it's used as the basis for permalinks.

So if you have me set in your spam filter White List then you'll need to
reset it. Thanks and sorry for the noise.

--
Simon Riggs

www.2ndQuadrant.com

PostgreSQL Training, Services and Support


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [GENERAL] Default fill factor for tables?

Roberts, Jon escribió:

> Why would you set the fillfactor to anything other than 100 for a
> PostgreSQL table?

To favor HOT updates.

--
Alvaro Herrera

http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [pgsql-es-ayuda] pg_dump y pg_restore

Oscar Argueta wrote:
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
> <title></title>
> </head>
> <body text="#000000" bgcolor="#ffffff">
> Ahora para los tiempos de restauracion de las bases, el VACUUM tambien
> ayuda a que sea mas optimo?<br>

No

--
Alvaro Herrera

http://www.flickr.com/photos/alvherre/
"[PostgreSQL] is a great group; in my opinion it is THE best open source
development communities in existence anywhere." (Lamar Owen)
--
TIP 2: puedes desuscribirte de todas las listas simult�neamente
(env�a "unregister TuDirecci�nDeCorreo" a majordomo@postgresql.org)

[GENERAL] recovery do not finish

Hello,

I have a serious problem with a production database.
We had a no disk space left on device problem, and postgres did not stop, so it was killed ( kill -9 )
we made free space and reboot, but postgres not start properly.
We have waited for more than 2 hours, but psql still says that the system is starting up.
( Db size is about 20 gb )
the os is Ubuntu 4.0.3-1ubuntu5
postgres is 8.1.4


pg_controldata says the following :
pg_control version number:            812
Catalog version number:               200510211
Database system identifier:           5006307211022564835
Database cluster state:               in recovery
pg_control last modified:             Fri 11 Jul 2008 09:38:54 PM CEST
Current log file ID:                  48
Next log file segment:                205
Latest checkpoint location:           30/C6AECCAC
Prior checkpoint location:            30/C693404C
Latest checkpoint's REDO location:    30/C6AE62A8
Latest checkpoint's UNDO location:    0/0
Latest checkpoint's TimeLineID:       1
Latest checkpoint's NextXID:          1441774700
Latest checkpoint's NextOID:          25908
Latest checkpoint's NextMultiXactId:  1
Latest checkpoint's NextMultiOffset:  0
Time of latest checkpoint:            Fri 11 Jul 2008 05:22:49 PM CEST
Maximum data alignment:               4
Database block size:                  8192
Blocks per segment of large relation: 131072
Bytes per WAL segment:                16777216
Maximum length of identifiers:        64
Maximum columns in an index:          32
Date/time type storage:               64-bit integers
Maximum length of locale name:        128
LC_COLLATE:                           en_US.UTF-8
LC_CTYPE:                             en_US.UTF-8

In the log file we have the following lines :
DEBUG:  TZ "W-SU" scores 0: at 1074121200 2004-01-15 02:00:00 std versus 2004-01-15 00:00:00 std
DEBUG:  TZ "Zulu" scores 0: at 1074121200 2004-01-14 23:00:00 std versus 2004-01-15 00:00:00 std
LOG:  could not load root certificate file "root.crt": No SSL error reported
DETAIL:  Will not verify client certificates.
DEBUG:  invoking IpcMemoryCreate(size=10461184)
DEBUG:  max_safe_fds = 984, usable_fds = 1000, already_open = 6
LOG:  database system was interrupted while in recovery at 2008-07-11 19:08:09 CEST
HINT:  This probably means that some data is corrupted and you will have to use the last backup for recovery.
LOG:  checkpoint record is at 30/C6AECCAC
LOG:  redo record is at 30/C6AE62A8; undo record is at 0/0; shutdown FALSE
LOG:  next transaction ID: 1441774700; next OID: 25908
LOG:  next MultiXactId: 1; next MultiXactOffset: 0
LOG:  database system was not properly shut down; automatic recovery in progress
LOG:  redo starts at 30/C6AE62A8
LOG:  connection received: host=[local]
LOG:  incomplete startup packet
DEBUG:  proc_exit(0)
DEBUG:  shmem_exit(0)
DEBUG:  exit(0)
DEBUG:  forked new backend, pid=3760 socket=7
DEBUG:  reaping dead processes
DEBUG:  server process (PID 3760) exited with exit code 0
LOG:  connection received: host=[local]
DEBUG:  forked new backend, pid=3763 socket=7
FATAL:  the database system is starting up
DEBUG:  proc_exit(0)
DEBUG:  shmem_exit(0)
DEBUG:  exit(0)
DEBUG:  reaping dead processes
DEBUG:  server process (PID 3763) exited with exit code 0
LOG:  connection received: host=[local]
FATAL:  the database system is starting up
DEBUG:  proc_exit(0)
DEBUG:  shmem_exit(0)
DEBUG:  exit(0)
DEBUG:  forked new backend, pid=3766 socket=7
DEBUG:  reaping dead processes
DEBUG:  server process (PID 3766) exited with exit code 0
LOG:  connection received: host=[local]
FATAL:  the database system is starting up
DEBUG:  proc_exit(0)
DEBUG:  shmem_exit(0)
DEBUG:  exit(0)

Any help is appreciated


________________________________________________________
VÁSÁROLNA? SEGÍTÜNK! Igényeljen hitelkártyát online és élvezze Ön is a vásárlás szabadságát!