Log Message:
Directory /cvsroot/pgrecovery/alpha/src added to the repository
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Log Message:
Directory /cvsroot/pgrecovery/alpha added to the repository
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On Tue, 2008-06-10 at 07:29 +0200, Gabriele Bartolini wrote:
> It's October 17 and 18 in Prato, Italy. We are finalising the setup
> from an administrative point of view.
Perfect. Let me book my flight, then :)
Regards,
--
Devrim GÜNDÜZ , RHCE
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/
The attached WIP patch improves the LAZY VACUUM by limiting or
avoiding the second heap scan. This not only saves considerable time
in VACUUM, but also reduces the double-writes of vacuumed blocks. If
the second heap scan is considerably limited, that should also save
CPU usage and reduce WAL log writing.
With HOT, the first heap scan prunes and defrags every page in the
heap. That truncates all the dead tuples to their DEAD line pointers
and releases all the free space in the page. The second scan only
removes these DEAD line pointers and records the free space in the
FSM. The free space in fact does not change from the first pass. But
to do so, it again calls RepairPageFragmentation on each page, dirties
the page and calls log_heap_clean() again on the page. This clearly
looks like too much work for a small gain.
As this patch stands, the first phase of vacuum prunes the heap pages
as usual. But it marks the DEAD line pointers as DEAD_RECLAIMED to
signal that the index pointers to these line pointers are being
removed, if certain conditions are satisfied. Other backend when
prunes a page, also reclaims DEAD_RECLAIMED line pointers by marking
them UNUSED. We need some additional logic to do this in a safe way:
- An additional boolean pg_class attribute (relvac_inprogress) is used
to track the status of vacuum on a relation. If the attribute is true,
either vacuum is in progress on the relation or the last vacuum did
not complete successfully.
When VACUUM starts, it sets relvac_inprogress to true. The transaction
is committed and a new transaction is started so that all other
backends can see the change. We also note down the transactions which
may already have the table open. VACUUM then starts the first heap
scan. It prunes the page, but it can start marking the DEAD line
pointers as DEAD_RECLAIMED only after it knows that all other backends
can see that VACUUM is in progress on the target relation. Otherwise
there is a danger that backends might reclaim DEAD line pointers
before their index pointers are removed and that would lead to index
corruption. We do that by periodic conditional waits on the noted
transactions ids. Once all old transactions are gone, VACUUM sets the
second scan limit to the current block number and starts marking
subsequent DEAD line pointers as DEAD_RECLAIMED.
In most of the cases where the old transactions quickly go away, and
for large tables, the second scan will be very limited. In the worst
case, we might incur the overhead of conditional waits without any
success.
TODO:
- We can potentially update FSM at the end of first pass. This is not
a significant issue if the second scan is very limited. But if we do
this, we need to handle the truncate case properly.
- As the patch stands, we check of old transactions at every block
iteration. This might not be acceptable for the cases where there are
long running transactions. We probably need some exponential gap here.
- As the patch stands, the heap_page_prune handles reclaiming the
DEAD_RECLAIMED line pointers since it already has ability to WAL log
similar changes. We don't do any extra work to trigger pruning though
(except than setting page_prune_xid). May be we should trigger pruning
if we got a line pointer bloat in a page too.
Please let me know comments/suggestions and any other improvements.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
Devrim GÜNDÜZ ha scritto:
> Did I miss any thread? Did we decide about the EU conference date?
> I want to make my travel plans ;)
Fair enough. :)
It's October 17 and 18 in Prato, Italy. We are finalising the setup from
an administrative point of view. Thanks.
Ciao,
Gabriele
--
Gabriele Bartolini: Open source programmer and data architect
Current Location: Prato, Tuscany, Italy
Associazione Italian PostgreSQL Users Group: www.itpug.org
gabriele.bartolini@gmail.com | www.gabrielebartolini.it
"If I had been born ugly, you would never have heard of Pelé", George Best
http://www.linkedin.com/in/gbartolini
--
Sent via pgeu-general mailing list (pgeu-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgeu-general
On Mon, Jun 9, 2008 at 10:17 PM, Tommy Cheng <csckcac@gmail.com> wrote:Again, there is no auto index creation for foriegn keys. However if
> you are right. I double checked. So, is there any way to turn off auto index
> creation for the parent? (the best is changing postgresql database setting)
> I am using postgres (PostgreSQL) 8.1.9 on CentOS 5 x86_64
>
you declared the column unique or its the pkey (ala unique) (As Scott
said) then there will an index.
No you cant turn it off because its how postgres enforces uniqueness
see http://www.postgresql.org/docs/8.1/interactive/index-unique-checks.html
for more
My guess, use the name of the index to try to distinguish. Auto
generated ones will always be in the form:
pkey: <table_name>_pkey(num)
unique: <table_name>_<column_name>_key(num)
tengo un programa que hice alguna vez que se conecta a un odbc que
escoja y ejecuta la sentencia (o script) sql que le diga...
probe con psqlODBC versiones 08_00 hasta 08_03 (solo las ultimas
versiones de cada una) con 08_00 no pude conectar (no es gran
sorpresa), pero de ahi en adelante se conecto y con todos pude
consultar una vista sin problema... probe con 8.3 en windows (bueno en
realidad es 8.4devel pero es del 18 de mayo asi que supongo que no es
mucha la variacion)
revisando el post original veo que no solo se añade la columna "ctid"
sino tambien un ORDER BY, me parece que hay algo que no nos estan
contando
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Guayaquil - Ecuador
Cel. (593) 87171157
--
TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo
Again, there is no auto index creation for foriegn keys. However if
you declared the column unique or its the pkey (ala unique) (As Scott
said) then there will an index.
No you cant turn it off because its how postgres enforces uniqueness
see http://www.postgresql.org/docs/8.1/interactive/index-unique-checks.html
for more
My guess, use the name of the index to try to distinguish. Auto
generated ones will always be in the form:
pkey: <table_name>_pkey(num)
unique: <table_name>_<column_name>_key(num)
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
I want to make my travel plans ;)
--
Devrim GÜNDÜZ , RHCE
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/
internally is table functions implemenation identical with SRF.
Semantically is far - user's doesn't specify return type (what is from
PostgreSQL), but specifies return table, what is more natural. What
more - for users is transparent chaotic joice betwen "SETOF RECORD"
for multicolumns sets and "SETOF type".
Pavel
> -Neil
>
>
>
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
> Sourceforge?
They gave up on us years ago :-(
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
a) current syntax is strange for beginers (and I am sure - isn't nice)
- look to mailing lists. I belive so ansi syntax is better.
b) it's needed for well SQL/PSM support. With table functions and
RETURN QUERY we are neer standard.
>
> (It's also worth asking where the import is coming from. Who implements
> the spec syntax anyway? DB2 maybe, but when was the last time we heard
> from anyone trying to migrate from DB2 to PG?)
>
lot of smaller new databases respect ANSI SQL 200x well - not only db2
> 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
er, because it doesn't work otherwise?
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
There is no auto index creation for child relationships, only for theOn Mon, Jun 9, 2008 at 8:48 PM, Tommy Cheng <csckcac@gmail.com> wrote:
> Hi admins,
> I would like to turn off the auto index for child table's foreign key. It
> is because i want to read the information_schema for table, column, index,
> unique and so on after creating the database. How to turn off the auto
> behavior? Or Is there a way to distinguish between auto one and user created
> index?
parent (unique index for primary key etc)
This can be solved by my proposal, but I just don't know how it would
apply to something like GIN, for instance. It could replace the unique
constraint for BTree, but I'm not sure it would perform as well. It's
not that my proposal is GiST-specific, it's just that is the only use
case I can think of that is an improvement.
> 2. It involves the index AM reaching into the heap, which is at the
> least a serious failure of modularity.
We need to reach into the heap for visibility information, if we're to
implement any constraints at all. Also, we have to test against values
being inserted by other concurrent transactions, and those values can
be variable in size. What other mechanism do we have to share those
variable-sized values among several backends?
> 3. There's no way to implement a deferred uniqueness check, nor even to
> handle the within-statement conflict problem.
This is the big one.
> Now admittedly I don't have a solution that addresses these objections
> (much less one that does it without losing any performance) but I'm
> hesitant to see us building new features in this area without any idea
> how we will fix these things --- especially #3, which is a SQL-spec
> violation as well as a frequent user complaint. I'd like to have at
> least a design plan for fixing these things, so we know whether we are
> painting ourselves (further) into a corner.
I'll see if I can come up with something. I agree that's an important
problem to solve. Does anyone know how other DBMSs do this? I found this
thread from the TODO:
http://archives.postgresql.org/pgsql-hackers/2006-09/msg01458.php
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
There is no auto index creation for child relationships, only for the
parent (unique index for primary key etc)
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
---Michael Brewer
mbrewer@gmail.com
--
Sent via pgus-board mailing list (pgus-board@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgus-board
> It also means we only have elections once every two years and once every
> two years only ~ 50% of the board is being replaced.
Correction:
After the initial term of the founders, we would have elections every 12
months but it would only effect ~ 50% of the board.
Sincerely,
Joshua D. Drake
--
Sent via pgus-board mailing list (pgus-board@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgus-board
> Selena, Michael and I are currently discussing all components of the
> comments we receive. We stopped on Friday and are set to take it up
> again this week.
Is there a particular reason why you're not discussing anything on this list?
I thought that PGUS was supposed to be a *community* association.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
--
Sent via pgus-general mailing list (pgus-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgus-general
In terms of archive compression, I have archive log compression which
will be found in http://pgfoundry.org/projects/pglesslog/
This feature is also included in NTT's synchronized log shipping
replication presented in the last PGCon.
2008/6/10 Greg Smith <gsmith@gregsmith.com>:
> On Mon, 9 Jun 2008, Tom Lane wrote:
>
>> It should also be pointed out that the whole thing becomes uninteresting
>> if we get real-time log shipping implemented. So I see absolutely no
>> point in spending time integrating pg_clearxlogtail now.
>
> There are remote replication scenarios over a WAN (mainly aimed at disaster
> recovery) that want to keep a fairly updated database without putting too
> much traffic over the link. People in that category really want zeroed
> tail+compressed archives, but probably not the extra overhead that comes
> with shipping smaller packets in a real-time implementation.
>
> --
> * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
------
Koichi Suzuki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Basicamente la imagen se almacena en :
byte[] imageBytes;
y se lee / graba utilizando los metodos de ResultSet getBytes y
updateBytes
Saludos,
Diego.
--
TIP 4: No hagas 'kill -9' a postmaster
---Michael Brewer
mbrewer@gmail.com
--
Sent via pgus-board mailing list (pgus-board@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgus-board
> It should also be pointed out that the whole thing becomes uninteresting
> if we get real-time log shipping implemented. So I see absolutely no
> point in spending time integrating pg_clearxlogtail now.
There are remote replication scenarios over a WAN (mainly aimed at
disaster recovery) that want to keep a fairly updated database without
putting too much traffic over the link. People in that category really
want zeroed tail+compressed archives, but probably not the extra overhead
that comes with shipping smaller packets in a real-time implementation.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
In functin exec_simple_query(), why we run a simple query wrapped in a portal.
For instance:
version 8.3.0 ,postgres.c, Line 908
/*
* Create unnamed portal to run the query or queries in. If there
* already is one, silently drop it.
*/
portal = CreatePortal("", true, true);
......
In other words, what's the benifit we use a portal to run a simple query?
Thanks for your help! :)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> (It's also worth asking where the import is coming from. Who implements
> the spec syntax anyway? DB2 maybe, but when was the last time we heard
> from anyone trying to migrate from DB2 to PG?)
Sourceforge?
--
Alvaro Herrera
http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
> I'm not necessarily opposed to this, but I wonder if we really need
> *more* syntax variants for declaring set-returning functions.
I've been saying right along that we don't. The proposed patch adds
no measurable new functionality; its only reason to live is standards
compliance, and I'm not convinced that's worth the confusion. Our
implementation of functions is (and always will be) far enough away
from the standard that notational issues like this are hardly the top
of the problem list for someone wishing to import a spec-compliant
function.
(It's also worth asking where the import is coming from. Who implements
the spec syntax anyway? DB2 maybe, but when was the last time we heard
from anyone trying to migrate from DB2 to PG?)
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
The archiver doesn't know any more about where the end-of-data is than
the archive_command does. Moreover, the archiver doesn't know whether
the archive_command cares. I think the separate module is a fine
solution.
It should also be pointed out that the whole thing becomes uninteresting
if we get real-time log shipping implemented. So I see absolutely no
point in spending time integrating pg_clearxlogtail now.
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
> For the slave to not interfere with the master at all, we would need to
> delay application of WAL files on each slave until visibility on that
> slave allows the WAL to be applied, but in that case we would have
> long-running transactions delay data visibility of all slave sessions.
Right, but you could segregate out long-running queries to one slave
server that could be further behind than the others.
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
> Agreed. I realize why we are not zeroing those bytes (for performance),
> but can't we have the archiver zero those bytes before calling the
> 'archive_command'?
Perhaps make the zeroing user-settable.
--
Alvaro Herrera
http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Agreed. I realize why we are not zeroing those bytes (for performance),
but can't we have the archiver zero those bytes before calling the
'archive_command'?
--
Bruce Momjian <bruce@momjian.us>
EnterpriseDB
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I'm not entirely sure whether I like the results better than what
we have. Opinions anyone? There are some cases where it seems
clearly better, eg the sequence.out changes, but in a lot of others
it doesn't seem much better.
One particular case of interest is in truncate.out, where the
table-at-a-time implementation of DROP TABLE is clearly exposed
by the fact that you get multiple NOTICEs. I wonder if it would
be worth refactoring the code so that a multiple-object DROP is
implemented via performMultipleDeletions(). This would have more
than just cosmetic advantages: it would no longer matter what
order you listed the tables in. But the refactoring required looks
bigger and more tedious than I want to tackle right now.
I also want to note that we've historically had the code report
auto-cascade drops as DEBUG2 messages. I tried to merge those reports
into the main one but it was a complete mess :-( because the client and
server-log messages might have different numbers of entries depending on
their log-level settings. Almost the first case I tried favored me with
NOTICE: drop cascades to 0 other object(s)
DETAIL:
reported to the client (with the server log of course saying something
different). So I gave up and left that behavior separate.
Comments? Should we do this, or leave things alone?
regards, tom lane
The simplest solution I can come up with is:
Election in October 08 for four two year terms
Board members who are elected in October 08 take their seat at the
Annual meeting.
Annual meeting takes place in March.
Founders also have two year terms.
Which means:
Founders are up for re-election October 2010 with their seats being
replaced or renewed March 2010
The four new members are up for re-election October 2011 because they
don't take their seats until March 2009.
It also means we only have elections once every two years and once every
two years only ~ 50% of the board is being replaced.
Further, officers keep their seats for the length of their term. If they
are re-elected, board elects new officers (which of course may be the
same people).
I see this as the simplest and most effective solution. I know that we
think one year terms are good but I really don't agree. I do think 3
year terms are probably too long (which is what SPI has) but a year goes
by really fast and I would like to think that we are going to have long
term projects to have to follow up on etc...
Sincerely,
Joshua D. Drake
--
Sent via pgus-board mailing list (pgus-board@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgus-board
For the slave to not interfere with the master at all, we would need to
delay application of WAL files on each slave until visibility on that
slave allows the WAL to be applied, but in that case we would have
long-running transactions delay data visibility of all slave sessions.
--
Bruce Momjian <bruce@momjian.us>
EnterpriseDB
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I think this is related to this TODO item:
* Allow XML to accept more liberal DOCTYPE specifications
http://archives.postgresql.org/pgsql-general/2008-02/msg00347.php
--
Bruce Momjian <bruce@momjian.us>
EnterpriseDB
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
JoshB,
Selena, Michael and I are currently discussing all components of the
comments we receive. We stopped on Friday and are set to take it up
again this week.
> I'm wondering if it's actually realistic to launch PGUS if we can't even
> get it together to get the bylaws finalized. Starting another PostgreSQL
> NPO which will be inactive due to lack of volunteer time is not a good way
> for any of us to contribute.
That is certainly a valid concern but I don't think it applies here as
everyone is working very hard. It would be helpful to everyone involved
if you would stop making assumptions about a situation.
Sincerely,
Joshua D. Drake
--
Sent via pgus-general mailing list (pgus-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgus-general
On Mon, Jun 9, 2008 at 6:02 PM, Josh Berkus <josh@agliodbs.com> wrote:
> Most of us know from SPI and previous attempts at PostgreSQL incorporation
> that running an NPO requires a pretty significant time commitment. Yet,
> the bylaws thread and the pgus web site have languished without any
> regular attention from the three of you because you're busy with your
> jobs.
It isn't accurate to say that it is languishing. Sure, the blog hasn't
been updated, but to be honest, most non-profits don't even have
blogs! Not a fair measure.
There's been a lot of work, it has not been published on the -general list.
Over the next week, JD, Michael and I can weigh in here on changes to
the bylaws being made right now, that have incorporated the feedback
we've gotten from you and others.
I will post my opinions this evening. JD may beat me to it, so I
won't say that I'll 'kick things off' :)
-selena
--
Selena Deckelmann
United States PostgreSQL Association - http://www.postgresql.us
PDXPUG - http://pugs.postgresql.org/pdx
Me - http://www.chesnok.com/daily
--
Sent via pgus-general mailing list (pgus-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgus-general
Most of us know from SPI and previous attempts at PostgreSQL incorporation
that running an NPO requires a pretty significant time commitment. Yet,
the bylaws thread and the pgus web site have languished without any
regular attention from the three of you because you're busy with your
jobs.
I'm wondering if it's actually realistic to launch PGUS if we can't even
get it together to get the bylaws finalized. Starting another PostgreSQL
NPO which will be inactive due to lack of volunteer time is not a good way
for any of us to contribute.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
--
Sent via pgus-general mailing list (pgus-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgus-general
> I'm not sure exactly what you have in mind when you say "kludge".
Well, there are at least three things not to like about the btree UNIQUE
implementation:
1. It's btree-specific and can't be shared by other index AMs that might
wish to implement constraints.
2. It involves the index AM reaching into the heap, which is at the
least a serious failure of modularity.
3. There's no way to implement a deferred uniqueness check, nor even to
handle the within-statement conflict problem.
It looks to me like the same knocks can be laid on your proposal.
Now admittedly I don't have a solution that addresses these objections
(much less one that does it without losing any performance) but I'm
hesitant to see us building new features in this area without any idea
how we will fix these things --- especially #3, which is a SQL-spec
violation as well as a frequent user complaint. I'd like to have at
least a design plan for fixing these things, so we know whether we are
painting ourselves (further) into a corner.
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
Don't forget adding a blank line between quoted text and your reply;
that is helpful too.
--
Bruce Momjian <bruce@momjian.us>
EnterpriseDB
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
I am :) you already brought up a direct database pull. We can just
change that to:
A cron that creates an ATOM file from a direct database pull.
Joshua D. Drake
>
--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www
> Only really interested if someone puts together an ATOM feed of the
> news.
You're aware of the limitations of Gforge. Be realistic.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www
I'm not necessarily opposed to this, but I wonder if we really need
*more* syntax variants for declaring set-returning functions. The
existing patchwork of features is confusing enough as it is...
-Neil
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
# connections for all the pcs on the subnet
#
# TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD
host all all 192.168.148.0 255.255.255.0
host all all 192.168.159.0 255.255.255.0
try adding the method to the end of these lines.
# METHOD can be "trust", "reject", "md5", "crypt", "password", "gss",
"sspi",
# "krb5", "ident", "pam" or "ldap". Note that "password" sends passwords
# in clear text; "md5" is preferred since it sends encrypted passwords.
--
Shane Ambler
pgSQL (at) Sheeky (dot) Biz
Get Sheeky @ http://Sheeky.Biz
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
> Maybe we say that you can defer the check, but after a while autovacuum
> runs it for you if you haven't done so. It would certainly be useful to
> run the VALIDATE part as a background task with vacuum wait enabled.
It would be useful if there was anywhere to report the error to, or an
action that could be taken automatically.
--
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
Only really interested if someone puts together an ATOM feed of the
news.
Joshua D. Drake
--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www
Modified Files:
--------------
pgsql/doc/src/sgml:
Makefile (r1.105 -> r1.106)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/Makefile?r1=1.105&r2=1.106)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Yup --- something's trying to use memory that's already been freed.
The particular case is evidently a field containing a type OID.
You might be able to get a clue where the problem is by getting a gdb
stack trace back from errfinish(), but this sort of kills my optimism
that the 7.0-era problem is gone ...
regards, tom lane
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Well, they *must* be in separate transactions if we are to avoid holding
an AccessExclusiveLock while we perform the check. Plus the whole idea
is to perform the second part at some other non-critical time, though we
all agree that never performing the check at all is foolhardy.
Maybe we say that you can defer the check, but after a while autovacuum
runs it for you if you haven't done so. It would certainly be useful to
run the VALIDATE part as a background task with vacuum wait enabled.
> Another benefit that could arise from this is that the hypothetical
> VALIDATE CONSTRAINT step could validate more than one constraint at a
> time, possibly processing all the constraints with a single table scan.
Good thought, though not as useful for FK checks.
--
Simon Riggs
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
> Speak to the statisticians. Our sample size is calculated using the same
> theory behind polls which sample 600 people to learn what 250 million
> people are going to do on election day. You do NOT need (significantly)
> larger samples for larger populations.
Your analogy is bad. For elections, the voters have only a few choices.
In a 300 million row table, there could be 300 million different values,
and the histogram becomes less accurate for every order of magnitude
smaller than 300 million it is.
> Also, our estimates for n_distinct are very unreliable. The math behind
> sampling for statistics just doesn't work the same way for properties
> like n_distinct. For that Josh is right, we *would* need a sample size
> proportional to the whole data set which would practically require us to
> scan the whole table (and have a technique for summarizing the results
> in a nearly constant sized data structure).
Actually, a number of papers have shown block-based algorithms which can
arrive a reasonably confident (between 50% and 250% of accurate) estimates
based on scanning only 5% of *blocks*. Simon did some work on this a
couple years ago, but he and I had difficultly convincing -hackers that a
genuine problem existed.
You're correct that we'd need to change pg_statistic, though. For one
thing, we need to separate the sample size from the histogram size.
Also, we seem to be getting pretty far away from the original GUC
discussion.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I can't really comment on the technical aspects of your proposal, but
yes, please, windowing functions would be great to have even if not
fully implemented.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
Yes, but that provides no help at all outside of pg_dump. Being able
to add a FK with NO CHECK would be tremendously useful outside of
pg_dump. Actually, in the interest of stating the problem and not the
solution, what we need is a way to add FKs that doesn't lock
everything up to perform the key checks. Perhaps there is some semi-
safe way that the constraint could be added and the checks done in
the background...
As for the footgun aspect, are we the enterprise-class OSS database
or the one that caters itself to noobs that will go out of their way
to make life hard on themselves? I'm all in favor of not adding
footguns that don't have value, but this one holds a lot of value for
anyone trying to maintain a large database in a 24/7 environment. To
put this in perspective, the amount of revenue we would loose from
adding just one FK to one of our larger tables would more than cover
paying someone to develop this feature.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
How about using "definition lists"?
//Magnus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Modified Files:
--------------
pgsnap/pgsnap:
ChangeLog (r1.57 -> r1.58)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgsnap/pgsnap/pgsnap/ChangeLog.diff?r1=1.57&r2=1.58)
pgsnap/pgsnap/template:
header.template.html (r1.7 -> r1.8)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgsnap/pgsnap/pgsnap/template/header.template.html.diff?r1=1.7&r2=1.8)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Former discussions are here:
http://archives.postgresql.org/pgsql-hackers/2004-11/msg01093.php
http://archives.postgresql.org/pgsql-hackers/2007-01/msg00861.php
How it works and examples:
SELECT dept, empno,
RANK() OVER(PARTITION BY dept ORDER BY age) as age_rank,
RANK() OVER(PARTITION BY dept ORDER BY salary) as salary_rank,
SUM(salary) OVER(PARTITION BY dept ORDER BY age) as run_total
FROM employees ORDER BY 1, 3, 4;
dept empno age_rank salary_rank run_total
ENG 2 1 2 40000
ENG 1 2 1 90000
QA 3 1 2 30000
QA 4 2 1 65000
(ref.: http://www.gavinsherry.org/talks/window_talk.pdf)
My current idea and concept:
- add "window function" and treat it specially such like aggregate
function and setof function.
- some features may be dropped at the first release, considering to
support them later.
- to formulate and to let it work properly are primary, performance
optimization is secondary.
From my survey around web and list archive, the points are:
- what is "window function" rank(), rank_dense(), lead() and others?
First of all, we should define the window function such like
aggregate function. In my opinion, there are two types of functions in
OVER () call context. One of them is aggregate, and the other is
window (ranking) function. Sum() in a query like
SELECT empno, sum(salary) OVER (PARTITION BY depno) FROM empsalary;
is obviously aggregate function. This type of function can be used as
it is now. Only executer will change its behavior.
Current pgsql feature sets lack window function like rank(). This
type of function must 1) have a context such as SETOF functions, 2)
return values until executor says "DONE", rather than function itself
says "DONE" as in SETOF function, and 3) know about other tuples
(mainly ORDER BY clause), as rank() doesn't take any arguments but
knows the ranking boundary. I suppose that pgsql have new function
system for these types called "window function".
Once we can define window function, users have extensibility to this
type of function.
- do we really need FRAME clause?
From my survey, Oracle and DB2 have FRAME clause
SELECT empno, sum(salary) OVER (ORDER BY empno ROWS BETWEEN
UNBOUNDED PRECEDING AND CURRENT ROW) FROM empsalary;
while MS SQL Server doesn't (note that the literal from "ROWS" to
"CURRENT ROW" is called FRAME clause). To implement FRAME clause is
much more complicated than only PARTITION and ORDER clause support
because we need random access to result tuples. Though we will be
expected to support FAME clause in long-term, for the first release it
might be able to be put off. Even though rank() doesn't support FRAME
clause (only PARTITION and ORDER) it is so useful, more than now at
least.
- execution order
In SQL:2003, the execution order is defined as
where -> group by -> having -> (windowing) * N -> order by (outer,
currently existing one)
where windowing is
partition by -> order by -> (framing) * N
But Oracle seems that it has another order
(windowing) * N -> where -> group by ... and so on.
which is better for us? With Oracle's one you can say
SELECT empno, rank() OVER (PARTITION BY depno ORDER BY saraly) AS
topsalary FROM empsalary
WHERE topsaraly < 3
to get the top 3 people taking heighest salary. In the SQL standard,
you should the nest query.
I insist the first (standard) one is better because we may want use
the result of normal aggregate in OVER clause.
- plan and node
Currently in my mind the execution strategy could be:
1. Where & GroupBy & Having
|
2. SortBy partitionClause, orderByClause
|
3. Window
foreach partition:
if not there_is_frame():
aggvalue = null
foreach row in partition:
aggvalue = agg_trans_func(aggvalue)
aggvalue = agg_final_func(aggvalue)
foreach row in partition:
if has frame clause:
aggvalue = null
frame = make_frame()
foreach row_in_frame:
aggvalue = aggregate_trans_func(aggvalue)
aggvalue = aggregate_final_func(aggvalue)
set aggvalue to row
val = window_func()
set val to row
goto 2. if another window remained
|
4. SortBy ORDER BY clause (outer) & Limit
|
5. Output
This pseudo code is quite simple and stupid. We may optimize it by
splitting tasks with MergeJoin, etc. or think about process 2. that
collect same PARTITION clauses to reduce sort operation. Or to use
Hash Agg to create PARTITION. But let's be stupid at first.
Optimization is secondary.
References:
description by Stefan DeBloch
http://wwwdvs.informatik.uni-kl.de/courses/NEDM/WS0607/Vorlesungsunterlagen/NEDM.Chapter.06.Windows_and_Query_Functions_in_SQL.pdf
via Wikipedia[Select (SQL)] http://en.wikipedia.org/wiki/Select_(SQL)
BTW, what about Bizgres now?
I appreciate for any comments and dis -:)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tags:
----
REL0_3_STABLE
Modified Files:
--------------
pgsnap/pgsnap:
ChangeLog (r1.33.2.10 -> r1.33.2.11)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgsnap/pgsnap/pgsnap/ChangeLog.diff?r1=1.33.2.10&r2=1.33.2.11)
pgsnap/pgsnap/template:
header.template.html (r1.5.2.1 -> r1.5.2.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgsnap/pgsnap/pgsnap/template/header.template.html.diff?r1=1.5.2.1&r2=1.5.2.2)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
this is the problem I am facing.
I have PG 8.3 running on a KUBUNTU installation running on a virtual
machine. From inside the virtual machine I can use PGADMIN to manage PG
but when I try to connect from the xp machine I have this error: "Error
connecting to the server:FATAL: missing or erroneous pg_hba.conf file" .
I set the permission in the pg_hba.conf on the server.
The machine talk each oher, I can ping and use telnet on the 5432 port.
The log on the server does not report any problem.
Ideas?
--
Dr. Simone Gadenz
via P. Togliatti 69, 50051
Castelfiorentino (FI)
+39 339 6053660
*INFORMATIVA PRIVACY (ex D.lgs. 196/03)*
Le inormazioni contenute in questo documento e nei relativi allegato
possono essere riservate e sono destinate esclusivamente alla persona
od alla Società indicata come destinatario.
La diffusione e la distribuzione del presente documento a soggetti
diversi da quelli indicati, od in genere qualsivoglia utilizzo illecito
dei dati ivi contenuti, e proibita sia ai sensi dell'art. 616 del
Codice Penale che dal D.Lgs 196/03 in materia di protezione dei dati
personali (Privacy).
Se avete ricevuto per errore questo documento siete pregati di
distruggerlo e di comunicarcelo prontamente tramite e-mail o fax.
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
> The function above updates the rows between the ids start_id and
> end_id. I have a quad core procesor so i run two separate connections
> to the database: select populate_test_data(5000,1) and another select
> populate_test_data(5000,2). In this case each function runs on one
> core doing the inserts in parallel, but when i try to run select
> select_unprocessed(1,5001) and from another connection select
> select_unprocessed(5001, 10001), one of the processes locks the table
> so the other one has to wait until the table is unlocked. Each
> process updates different parts of the table. Is there a way to do
> the updates in parallel on multiple cores?
>
Wait until the other is done or wait until it has done what it needs to?
If it appears to not update the records I would look at the id ranges
you are passing. You insert 5000 rows with the first function then you
tell the update function to update row id's 1 to 50001 - have you reset
the sequence for the id column? or do you drop and create the table
before each test? My guess is no updates appear to happen as the id's
entered by the serial type are larger than 10000.
Also you update with processed='n' - is that what you want? Is that the
only column you look at to see that it is done?
Transactions would be the only cause of the problem you describe. I am
guessing that you use bigger numbers than 5000 in your tests and the
examples above use overlapping id's. If the first updates row 5001 early
then the second may need to wait until it commits to update it again.
This can work the other way 5001 is updated by the second locking it
until it finishes and the first waits until the second commits to update
it again.
With 5000 rows I wouldn't expect to see a time difference.
Without an order by in the select the rows can be returned and updated
in any order.
--
Shane Ambler
pgSQL (at) Sheeky (dot) Biz
Get Sheeky @ http://Sheeky.Biz
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
Tags:
----
REL8_3_STABLE
Modified Files:
--------------
pginst/package:
README.TXT (r1.7.2.2 -> r1.7.2.3)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pginstaller/pginst/package/README.TXT.diff?r1=1.7.2.2&r2=1.7.2.3)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Declare el array a si :
prueba numeric[][];
pretendo cargar le datos mediante dos variable que voy aumentando :
prueba[x][y] := variable_numeric
y luego quiero retornar el array :
return tabla;
y como llamar a esta función y retornar el array a otra
__________ Information from ESET NOD32 Antivirus, version of virus signature
database 3167 (20080609) __________
The message was checked by ESET NOD32 Antivirus.
--
TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo
Yes it is.
Cheers
Tino :-)
I found no more use cases for text results after libpqtypes started to
take shape, eventhough libpqtypes supports all data types in text &
binary excluding arrays and composites. Because of this, adding a text
parser for arrays and composites felt like a lot of work for a little
gain. libpqtypes is really designed to be a binary interface. The text
support offered allows existing applications to use the new interface
with results generated by PQexec(), meaning you can use PQgetf w/o
having to change code to use PQputf().
If you take another glance at libpqtypes, you may see that result format
decisions are pretty well abstracted and there really is no need for
text results anymore (okay, I'll catagorize that as an opinion).
> I also am not particularly enamoured of the libpqtypes way of doing
> things, which feels rather foreign to me.
Not sure we can fix this issue. We made every attempt to keep things
familiar ... printf/scanf style. It's a new approach for libpq but an
old one for C hacks.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> Il est tout à fait étonnant que je multiplie par 3 le temps pour le
> premier SELECT entre les tests 2 et 3 (la seule différence entre les
> deux est la config où j'ai passé les checkpoint_segments de 3 à 30).
>
> On remarque que le temps d'exécution de l'UPDATE ne varie presque
pas,
> sauf sur les tests 8 et 9 (particularité de ces tests, un
> effective_cache_size passé de 128 Mo, valeur par défaut, à 1 Go)
>
> Le test intéressant est le 8.
>
> Différence de config entre test 7 et test 8 :
> * passage de shared_buffers de 50 Mo à 1 Go
> * passage de effective_cache_size de 128 Mo à 1 Go
>
> Différence de config entre test 8 et test 9 :
> * passage de shared_buffers de 1 Go à 50 Mo
> * passage de effective_cache_size de 1 Go à 1,3 Go
>
>
> Différence entre votre config et la mienne :
> * passage de shared_buffers de 32 Mo à 1 Go
> * passage de wal_buffers de 64 Ko à 1 Mo
> * passage de checkpoint_segments de 3 à 30
> * passage de checkpoint_timeout de 5min à 15 min
> * passage de effective_cache de 128 Mo à 1 Go
Les gros paramètres ayant étés modifiés étant shared_buffers et
effective_cache_size, avec de telles valeurs il faut une
machine ayant au moins 3gigas de mémoire.
Je viens donc ce matin de faire deux tests sur un serveur
avec une base Postgresql , et les paramètres:
--- Parametres Postgresql:
--- shared_buffers = 1024MB
--- checkpoint_segments = 30
--- wal_buffers = 1024kB
--- autovacuum = off
--- effective_cache_size = 1024MB
---
--- Parametres Systeme Linux:
--- memoire: 4GB
---
---
--- Remarque: le file-systeme de la base de donnees est duplique par
--- drdb de linux-ha sur une seconde machine via un
--- lien 1giga prive.
Et j'obtiens en secondes:
UPDATE ANALYZE CHECKPOINT SELECT
test1: 1086 191 119 111
test2: 1310 223 136 701
Pour le test1, j'avais arrêté toute autre activite a la base
Postgresql.
Pour le test2, j'ai rétabli l'alimentation d'autres tables.
En surveillant l'activite du processus 'postgres: writer process',
et en utilisant une commande 'iostat -k 60 60' on voit qu'il y a
beaucoup d'activité d'écriture disque durant le select, et celui-ci
ne termine que vers la fin d'activité du bgwriter.
==================================================================
Remarque: j'ai fais le test suivant sur le PC
bureautique à coté , en pensant amméliorer les temps de selects
grace à une attente de 10 minutes avant le select:
--- Parametres Postgresql:
--- shared_buffers = 128MB
--- checkpoint_segments = 3
--- wal_buffers = 64kB
--- autovacuum = on
--- effective_cache_size = 128MB
---
--- Parametres Systeme Linux:
--- memoire: 1,8 gigas
1) UPDATE de 51872 lignes en 512 secondes
2) analyse verbose en 22 secondes
3) CHECKPOINT en 7 secondes
4) \!iostat -k 60 10
5) select 0 lignes, en 431 secondes
sur la machine, je n'ai pas d'autre activités en dehors de
mon test. On voit avec la commande 'iostat' que le processus
bgwriter de Postgresql ne travaille pas, et recommence son
travail lors du select.
J'aurais pensé, qu'il profita du temps libre (durant iostat)
pour mettre à jour les fichiers disque de la base.
Merci, Valérie.
>
--
********************************************************************
* Les points de vue exprimes sont strictement personnels et *
* n'engagent pas la responsabilite de METEO-FRANCE. *
********************************************************************
* Valerie SCHNEIDER Tel : +33 (0)5 61 07 81 91 *
* METEO-FRANCE / DSI/DEV Fax : +33 (0)5 61 07 81 09 *
* 42, avenue G. Coriolis Email : Valerie.Schneider@meteo.fr *
* 31057 TOULOUSE Cedex 1 - FRANCE
*
********************************************************************
--
Sent via pgsql-fr-generale mailing list (pgsql-fr-generale@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-fr-generale
Tags:
----
REL8_3_STABLE
Modified Files:
--------------
pginst:
RELEASE_PROCESS.txt (r1.3 -> r1.3.2.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pginstaller/pginst/RELEASE_PROCESS.txt.diff?r1=1.3&r2=1.3.2.1)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Added Files:
-----------
muninpgplugins:
AUTHORS (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/muninpgplugins/muninpgplugins/AUTHORS?rev=1.1&content-type=text/x-cvsweb-markup)
COPYING (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/muninpgplugins/muninpgplugins/COPYING?rev=1.1&content-type=text/x-cvsweb-markup)
ChangeLog (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/muninpgplugins/muninpgplugins/ChangeLog?rev=1.1&content-type=text/x-cvsweb-markup)
INSTALL (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/muninpgplugins/muninpgplugins/INSTALL?rev=1.1&content-type=text/x-cvsweb-markup)
README (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/muninpgplugins/muninpgplugins/README?rev=1.1&content-type=text/x-cvsweb-markup)
TODO (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/muninpgplugins/muninpgplugins/TODO?rev=1.1&content-type=text/x-cvsweb-markup)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Statement stmt1 = conn.createStatement();
stmt1.execute(
"CREATE OR REPLACE FUNCTION volcadoDatos() RETURNS void AS $$"+
"DECLARE "+
" fila RECORD;"+
"BEGIN"+
" SELECT dblink_connect('dbname = bd_donde_copiar user = usuario password = 111111);"+
" FOR fila IN SELECT * FROM " + miTabla + " WHERE codigo= '" + cod+ "' LOOP"+
" SELECT dblink_exec('INSERT INTO "+ miTabla +" VALUES(fila)');"+
" END LOOP;"+
" SELECT dblink_disconnect();"+
"END;"+
"$$ LANGUAGE plpgsql;");
stmt1.close();
Tags:
----
REL8_2_STABLE
Modified Files:
--------------
pginst/package:
README.TXT (r1.4.2.8 -> r1.4.2.9)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pginstaller/pginst/package/README.TXT.diff?r1=1.4.2.8&r2=1.4.2.9)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Greenplum sponsored my efforts to include Partitioning and Sort
improvements into 8.1 and 8.2 respectively, and have contributed at
least 3 other patches that the community has rejected (for whatever
reason). IMHO, Bizgres was really their way of showing that useful work
had been done, but I agree it is out of date now in many respects
because and only because it hasn't been updated since 8.1.
--
Simon Riggs
PostgreSQL Training, Services and Support
--
Sent via pgsql-advocacy mailing list (pgsql-advocacy@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-advocacy
I found 512 damaged bytes on the 29th 8k page of the pg_type's datafile
($PGDATA/base/16390/1247), it was overwritten by text from some log(?!).
When I had dropped the whole 8k page (dd of=/tmp/head count=29 bs=8192,
dd of=/tmp/tail skip=30 bs=8192, then cat /tmp/head /tmp/tail), the
pg_dumpall utility was able to dump the DB instance then.
I compared schemas (pg_dumpall -s), fortunately only several empty, not
used tables were affected.
Then I imported the dump, and now the DB instance seems to work properly,
also the pg_dumps, vacuum anylysis.
Best regards,
Filip Krska
--
ComSTAR spol. s r. o.
Třebohostická 14
100 31 Praha 10
HotLine (pev.): 274 016 000
HotLine (mob.): 777 343 857
On Fri, 6 Jun 2008, Alvaro Herrera wrote:
> Filip Krška wrote:
>> Hello,
>>
>> we have (maybe due to temporary Disk Array HW failure, which occurred on
>> the same day the pg_dump started to complain - array is now successfully
>> rebuilt) problem with consistency of pg_catalog.pg_type table.
>
> Did you solve this problem?
>
> --
> Alvaro Herrera
http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>
> --
> Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-admin
>
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Or we could sidestep the issue by not running autoconf, but
search-replace the version strings in configure directly with the perl
script.
--
Heikki Linnakangas
EnterpriseDB
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
postgres=# help
You are using psql, the command-line interface to PostgreSQL.
\? for psql help
\h or \help for SQL help
\g or ";" to execute a query
\q to quit psql
\copyright to view the copyright
postgres=#
New output:
postgres=# help
You are using psql, the command-line interface to PostgreSQL.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit
postgres=#
The newlines in the previous text were inconsistent with psql error
message style elsewhere, aside from being distracting. The advice on
commands to enter next was also just emitted, without actually telling
the user that these are possible inputs. Essentially the text was a
regression from the text we've always used in the startup banner, so I
just re-instituted the old text.
-Neil, doing his best to suppress his aesthetic objection to having
"help" be valid psql input in the first place
