--
Rob Wultsch
wultsch@gmail.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
The May commitfest is finished. The remaining patches on the queue
are Heikki's map-forks patch, which was WIP not intended to be
committed now; and Merlin and Andrew's libpq hooks patch, which is
still in flux and not ready to commit now.
PgCon 2008 was a smashing success, eh. People hashed things out at
the developer meeting, complete with a Secret Cabal Meeting.
Participants came in from as far as Pune, India.
== PostgreSQL Product News ==
DbWrench Database Design v1.4.7 released.
http://www.dbwrench.com/
MicroOLAP Database Designer for PostgreSQL ver.1.2.4-beta released.
http://microolap.com/products/database/postgresql-designer/download/
Npgsql 2 Beta4 released.
http://pgfoundry.org/projects/npgsql/
The call for papers for OSS 2.0: Leveraging the Open Source Community
for Business is open. Submissions must be in by June 21, 2008.
http://conferenze.dei.polimi.it/oss20
pgtcl 1.7 released.
http://pgfoundry.org/projects/pgtcl/
Playr 0.1 released.
https://area51.myyearbook.com/trac.cgi/wiki/Playr
== PostgreSQL Jobs for May ==
http://archives.postgresql.org/pgsql-jobs/2008-05/threads.php
== PostgreSQL Local ==
The Greek PUG will be putting up a booth at the third Greek FLOSS
conference on May 27-28 at NTUA, Athens.
http://www.postgresql.gr
LAPUG will be meeting May 30, 2008 at Cal Poly
Non-trivial updateable views, from Keith Larson
http://pugs.postgresql.org/node/390
The Call for Papers for PgCon.BR is open. The deadline is May 31, so
get those proposals in.
http://pgcon.postgresql.org.br/chamadas.en.html
PGDay will be in Portland the day before OSCON.
http://pugs.postgresql.org/taxonomy/term/53
Utah Open Source Conference 2008's CfP is open through June 1.
This 2nd annual conference is August 28-30, 2008 in Salt Lake City, UT
http://2008.utosc.com/
PGCon Brazil 2008 will be on September 26-27 at Unicamp in Campinas.
http://pgcon.postgresql.org.br/index.en.html
PGDay.IT 2008 will be October 17 and 18 in Prato.
http://www.pgday.org/it/
== PostgreSQL in the News ==
Planet PostgreSQL: http://www.planetpostgresql.org/
General Bits, Archives and occasional new articles:
http://www.varlena.com/GeneralBits/
PostgreSQL Weekly News is brought to you this week by David Fetter
and Tom Lane.
Submit news and announcements by Sunday at 3:00pm Pacific time.
Please send English language ones to david@fetter.org, German language
to pwn@pgug.de, Italian language to pwn@itpug.org.
== Applied Patches ==
Tom Lane committed:
- Coercion sanity check in ri_HashCompareOp failed to allow for enums,
as per example from Rod Taylor. On reflection the correct test here
is for any polymorphic type, not specifically ANYARRAY as in the
original coding.
- Make to_char()'s localized month/day names depend on LC_TIME, not
LC_MESSAGES. Euler Taveira de Oliveira
- Adjust -Wl,--asneeded test to avoid using the switch if it breaks
libreadline. What we will do for compatibility :-(
- Adjust timestamp regression tests to prevent two low-probability
failure cases. Recent buildfarm experience shows that it is
sometimes possible to execute several SQL commands in less time than
the granularity of Windows' not-very-high-resolution gettimeofday(),
leading to a failure because the tests expect the value of now() to
change and it doesn't. Also, it was recognized some time ago that
the same area of the tests could fail if local midnight passes
between the insertion and the checking of the values for
'yesterday', 'tomorrow', etc. Clean all this up per ideas from
myself and Greg Stark. There remains a window for failure if the
transaction block is entered exactly at local midnight (so that
'now' and 'today' have the same value), but that seems
low-probability enough to live with. Since the point of this change
is mostly to eliminate buildfarm noise, back-patch to all versions
we are still actively testing.
Heikki Linnakangas committed:
- Remove arbitrary 10MB limit on two-phase state file size. It's not
that hard to go beoynd 10MB, as demonstrated by Gavin Sharry's
example of dropping a schema with ~25000 objects. The really bogus
thing about the limit was that it was enforced when a state file
file was read in, not when it was written, so you would end up with
a prepared transaction that you can't commit or abort, and the only
recourse was to shut down the server and remove the file by hand.
Raise the limit to MaxAllocSize, and enforce it also when a state
file is written. We could've removed the limit altogether, but
reading in a file larger than MaxAllocSize would fail anyway because
we read it into a palloc'd buffer. Backpatch down to 8.1, where 2PC
and this issue was introduced.
Bruce Momjian committed:
- Mark TODO as done: "Use LC_TIME for localized weekday/month names."
- In pgsql/src/backend/utils/adt/formatting.c, simplify code now that
to_(upper|lower|initcap) do not modify the passed string.
Michael Meskes committed:
- Synced parser. Made ecpg parser use backend provided keyword list.
Changed whenever test so exit value is 0.
- In pgsql/src/interfaces/ecpg/preproc/Makefile, ecpg_keywords.o also
depends on preproc.h
- Link in keywords file instead of copying it. Use #define/#ifdef
instead of sed to fix include files, this should work on Windows
too.
Magnus Hagander committed:
- Use CRITICAL_SECTION instead of Mutexes for thread-locking in libpq
on Windows, for better performance. Per suggestion from Andrew
Chernow, but not his patch since the underlying code was changed to
deal with return values.
- In pgsql/src/bin/psql/print.c, fix function headers not matching
prototype in header file, per compiler warnings on msvc.
- In pgsql/src/tools/msvc/Mkvcbuild.pm, add include directory required
after the latest changes to the ecpg build. Per red Windows
buildfarm members.
== Rejected Patches (for now) ==
No one was disappointed this week :-)
== Pending Patches ==
Guillaume Lelarge sent in a patch to make psql backward-compatible to
7.4. Bryce Nesbitt followed up with one of his own.
Andrew Chernow sent in another revision of the libpq object hooks
patch.
Greg Sabino Mullane sent in a documentation patch by Kevin L. McBride
explaining LOCK_DEBUG options in detail.
Gregory Stark sent in three revisions of a patch which makes \d+ show
storage options for columns, per discussion with Oleg Bartunov.
Jaime Casanova sent in two versions of a patch to extent GRANT's scope
on sequences.
Heikki Linnakangas sent in another revision of his FSM rewrite patch.
Dickson Guedes sent in a patch in collaboration with Euler Taveira de
Oliveira which makes \d and \d+ on sequences produce more useful
output.
---------------------------(end of broadcast)---------------------------
-To unsubscribe from this list, send an email to:
pgsql-announce-unsubscribe@postgresql.org
>> the patch discussed here [1] that supposedly made the win32 msvc builds use
>> lc_locale properly has flaws.
>
> I think a large part of the confusion that's been evidenced in this
> thread is because you are submitting a "bug report" about a patch that is
> not in fact in 8.3.1 (and is unlikely ever to appear in 8.3.x at all).
> It's unclear what you are really testing: stock 8.3.1? 8.3.1 plus that
> patch? CVS HEAD plus the patch?
it's the 8.3.1 win32 binary coming from postgresql.org i'm using.
i was digging in the mailing list archives for some answers and found
the conversation about the patch which i believed to be included in
8.3.1. sorry for the mess :|
nevertheless the problem/bug exists: changing LC_MESSAGES has no effect
on the windows boxes, while it works on the non-win32 systems. all i
really would like is to get english system messages back on our
non-english win32 servers - like they were pre 8.3.1.
the main reason for this being: the german error messages have non-ascii
special characters in the error text ('»' and '«') which mess with some
of our applications (whereas english messages use '"').
regards,
thomas
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Este problema no te deberia pasar con esos servidores
ni con la configuracion por defecto de postgres, pero
por las dudas lee Thuning.
Pero antes preguntate si tenes un buen modelo de base
de datos y si las vistas estan bien elaboradas.
Una cosita que me llama la atencion es que para evitar
duplicados bloquees las tablas, yo para evitar
duplicados creo claves primarias o unicas.
Atte.
Gabriel Colina
____________________________________________________________________________________
Yahoo! Deportes Beta
¡No te pierdas lo último sobre el torneo clausura 2008! Entérate aquí http://deportes.yahoo.com
--
TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda
Disculpen mi ignorancia sobre este tema, mi dilema es el siguiente,
hasta el momento estaba desarrollando mi primer proyecto con
PostgreSQL y PHP que por suerte termine.
De momento lo fui desarrollando en Windows, ahora se me plantea la
necesidad de probarlo sobre la plataforma Linux (mas precisamente
Debian Etch) y lo que hice fue, instalar PostgreSQL en este SO y
mediante un pg_dump volcar la BD a Linux.
Ahora lo que yo necesitaria o me gustaria, seria no duplicar la base
de datos como hice anteriormente sino poder conectarme a la misma BD
en los dos SO.
Seria como conectarse a una BD de forma remota? Que es lo que deberia
hacer o por donde tendria que empezar a leer?
Desde ya muchas gracias,
Saludos,
Juan
--
TIP 2: puedes desuscribirte de todas las listas simultáneamente
(envía "unregister TuDirecciónDeCorreo" a majordomo@postgresql.org)
Seria como conectarse a una BD de forma remota? Que es lo que deberia
hacer o por donde tendria que empezar a leer?
Desde ya muchas gracias,
Saludos,
Juan
--
TIP 2: puedes desuscribirte de todas las listas simultáneamente
(envía "unregister TuDirecciónDeCorreo" a majordomo@postgresql.org)
Well, the thought of an unstable "dirty read" seems strange, but I get
your point that it isn't the SQL Standard's Read Uncommitted mode.
The use of this is clear though: allowing long running transactions
against unchanging data to not interfere with other activities. It will
also have importance in a Hot Standby mode.
So, even if this isn't Read Uncommitted exactly, it is a transaction
isolation mode that has utility for us and I would like to support it,
well documented and with appropriate cautions.
--
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
I agree to the disagreement ;-).
Reading and editing views is not the most pleasing thing to do
currently. Still, storing the original SQL is not the right thing to do
IMHO - the only viable option I can see is trying to store plain-text
nodes with the parse tree which get reinserted when the parse tree is
converted back into a query.
regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
This seems like a remarkably bad idea. It has no use that I can see for
anything except shooting oneself in the foot.
> The implementation is trivial, namely that the calculation of global
> xmin would ignore Read Uncommitted transactions.
This proposed implementation seems to have very little to do with
what most people would think Read Uncommitted does. In particular it
does not agree with the SQL spec, which says that Read Uncommitted
permits transactions to see the results of as-yet-uncommitted
transactions. As an example, suppose that old transaction T1 reads
a table that always contains exactly one live row, but T2 has modified
that row since T1 started. Per spec what Read Uncommitted means is that
T1 may see the modified version before T2 commits. This would not
implement that behavior, though. What this implementation would mean is
that after T2 commits, we might vacuum away the old version, causing T1
to see *nothing* in the table:
* T1 scans the new row version, doesn't return it because T2 not
yet committed;
* T2 commits;
* VACUUM removes old row version;
* T1 never finds old row version to return.
Even if we thought that supporting Read Uncommitted would be a good
idea, this would be an unacceptably unstable implementation of it.
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
> At this point I can once again access the original data base
> and \l shows it correctly, but \d shows no relations.
Do you see any rows at all in pg_class in that database?
Also, where did /bup/previous/var/lib/pgsql come from? If this was
a filesystem-level backup that was taken while the postmaster was
running, you may have consistency problems in it.
regards, tom lane
--
Sent via pgsql-novice mailing list (pgsql-novice@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-novice
At the moment, a long running SQL Statement can prevent xmin moving
forward, which can result in VACUUM and HOT not being able to remove row
versions effectively. My proposal is that a Read Uncommitted transaction
would not prevent row removal, which then offers no guarantee that the
"correct" answer would be returned. Which is *exactly* what that
transaction isolation level was designed for.
In many cases, an application designer may be able to tell that a
particular query will always return the correct answer. For example, we
may query against data which is known not to change, even though other
data in the same database cluster may be subject to frequent change.
e.g. queries against large insert-only tables.
By allowing the user to select a non-default isolation level we would
allow long running queries to have significantly less disruption on
other operations. Read Uncommitted would imply Read Only status, so
various data change operations would be rejected. No errors would
result, just that some data would be missing from the answer, iff data
had been removed during execution. It might be possible to get a table
does not exist error because non-transactional pg_class updates take
place; transactional pg_class updates would be prevented by
relation-level locking.
I would *not* allow this as an option or default for pg_dump, since this
would almost certainly result in error. No footguns allowed in so
critical a utility.
The implementation is trivial, namely that the calculation of global
xmin would ignore Read Uncommitted transactions.
Read Uncommitted would not be the default, so novice users would be in
no danger. Bear in mind that Read Uncommitted is commonly used in other
database systems, so this feature is already understood and even
expected by many database experts from other backgrounds. Many
PostgreSQL experts would also be able to take advantage of this feature.
Since its part of the SQL Standard this "dirty read" isn't likely to
take anybody by surprise that reads any of (PostgreSQL manual, SQL
Standard, other RDBMS manual).
Comments?
--
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
That's just weird. I tried the same here (also on an x86_64 F-8 box)
and didn't see it happen. Are you using the standard Fedora update
repository?
regards, tom lane
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Should this stuff really go into the SGML documentation, when these
options will certainly never be enabled anywhere except in developers'
private builds? A few lines of comments in pg_config_manual.h seems
a more appropriate solution.
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
In principle, if you subscript TG_ARGV[] with an expression that has
visible side-effects, you could have unexpected behavior here. I think
though that the right fix is to get rid of the special treatment of
TG_ARGV[] and make it a ordinary variable with type text[], instead
of being its very own class of datum. The current implementation has
a lot of other misbehaviors for TG_ARGV[], like not being able to apply
array operations to it.
I agree that worrying about the performance is pointless, considering
the cost of the SPI_prepare_cursor() that we're about to do in the one
place where there could be a use for a get-the-type-only call.
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
Sounds like you need to fix your "support of the postgres wire
protocol" --- in particular you'd better read up on query cancel,
and it would appear you are unable to send a proper error response
either.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
> the patch discussed here [1] that supposedly made the win32 msvc builds use
> lc_locale properly has flaws.
I think a large part of the confusion that's been evidenced in this
thread is because you are submitting a "bug report" about a patch that is
not in fact in 8.3.1 (and is unlikely ever to appear in 8.3.x at all).
It's unclear what you are really testing: stock 8.3.1? 8.3.1 plus that
patch? CVS HEAD plus the patch?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
It appears that the section on configuring ODBC on Windows is not
quite right, at least for Windows XP.
The FAQ says, "For Windows, use the ODBC Administrator in Control
Panel. Here you can add, modify, or delete data sources."
At least on XP, it should say something like "Go to Programs ->
Administrative Tools -> Data Sources and Add the PostgreSQL Unicode
driver."
Thanks to Dan Dascalescu (pidginusr) in IRC for pointing this out :)
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
There remains a window for failure if the transaction block is entered
exactly at local midnight (so that 'now' and 'today' have the same value),
but that seems low-probability enough to live with.
Since the point of this change is mostly to eliminate buildfarm noise,
back-patch to all versions we are still actively testing.
Tags:
----
REL8_1_STABLE
Modified Files:
--------------
pgsql/src/test/regress/expected:
timestamp.out (r1.28 -> r1.28.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/timestamp.out?r1=1.28&r2=1.28.2.1)
timestamptz.out (r1.18 -> r1.18.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/timestamptz.out?r1=1.18&r2=1.18.2.1)
pgsql/src/test/regress/sql:
timestamp.sql (r1.14 -> r1.14.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/timestamp.sql?r1=1.14&r2=1.14.2.1)
timestamptz.sql (r1.7 -> r1.7.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/timestamptz.sql?r1=1.7&r2=1.7.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
There remains a window for failure if the transaction block is entered
exactly at local midnight (so that 'now' and 'today' have the same value),
but that seems low-probability enough to live with.
Since the point of this change is mostly to eliminate buildfarm noise,
back-patch to all versions we are still actively testing.
Tags:
----
REL7_4_STABLE
Modified Files:
--------------
pgsql/src/test/regress/expected:
timestamp.out (r1.25 -> r1.25.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/timestamp.out?r1=1.25&r2=1.25.2.1)
timestamptz.out (r1.13 -> r1.13.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/timestamptz.out?r1=1.13&r2=1.13.2.1)
pgsql/src/test/regress/sql:
timestamp.sql (r1.12 -> r1.12.4.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/timestamp.sql?r1=1.12&r2=1.12.4.1)
timestamptz.sql (r1.4 -> r1.4.4.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/timestamptz.sql?r1=1.4&r2=1.4.4.1)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
There remains a window for failure if the transaction block is entered
exactly at local midnight (so that 'now' and 'today' have the same value),
but that seems low-probability enough to live with.
Since the point of this change is mostly to eliminate buildfarm noise,
back-patch to all versions we are still actively testing.
Tags:
----
REL8_0_STABLE
Modified Files:
--------------
pgsql/src/test/regress/expected:
timestamp.out (r1.27 -> r1.27.4.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/timestamp.out?r1=1.27&r2=1.27.4.1)
timestamptz.out (r1.17 -> r1.17.4.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/timestamptz.out?r1=1.17&r2=1.17.4.1)
pgsql/src/test/regress/sql:
timestamp.sql (r1.13 -> r1.13.4.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/timestamp.sql?r1=1.13&r2=1.13.4.1)
timestamptz.sql (r1.6 -> r1.6.4.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/timestamptz.sql?r1=1.6&r2=1.6.4.1)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
There remains a window for failure if the transaction block is entered
exactly at local midnight (so that 'now' and 'today' have the same value),
but that seems low-probability enough to live with.
Since the point of this change is mostly to eliminate buildfarm noise,
back-patch to all versions we are still actively testing.
Tags:
----
REL8_2_STABLE
Modified Files:
--------------
pgsql/src/test/regress/expected:
timestamp.out (r1.31.2.1 -> r1.31.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/timestamp.out?r1=1.31.2.1&r2=1.31.2.2)
timestamptz.out (r1.21.2.2 -> r1.21.2.3)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/timestamptz.out?r1=1.21.2.2&r2=1.21.2.3)
pgsql/src/test/regress/sql:
timestamp.sql (r1.17 -> r1.17.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/timestamp.sql?r1=1.17&r2=1.17.2.1)
timestamptz.sql (r1.10.2.1 -> r1.10.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/timestamptz.sql?r1=1.10.2.1&r2=1.10.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
There remains a window for failure if the transaction block is entered
exactly at local midnight (so that 'now' and 'today' have the same value),
but that seems low-probability enough to live with.
Since the point of this change is mostly to eliminate buildfarm noise,
back-patch to all versions we are still actively testing.
Tags:
----
REL8_3_STABLE
Modified Files:
--------------
pgsql/src/test/regress/expected:
timestamp.out (r1.35 -> r1.35.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/timestamp.out?r1=1.35&r2=1.35.2.1)
timestamptz.out (r1.28 -> r1.28.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/timestamptz.out?r1=1.28&r2=1.28.2.1)
pgsql/src/test/regress/sql:
timestamp.sql (r1.20 -> r1.20.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/timestamp.sql?r1=1.20&r2=1.20.2.1)
timestamptz.sql (r1.16 -> r1.16.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/timestamptz.sql?r1=1.16&r2=1.16.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
There remains a window for failure if the transaction block is entered
exactly at local midnight (so that 'now' and 'today' have the same value),
but that seems low-probability enough to live with.
Since the point of this change is mostly to eliminate buildfarm noise,
back-patch to all versions we are still actively testing.
Modified Files:
--------------
pgsql/src/test/regress/expected:
timestamp.out (r1.35 -> r1.36)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/timestamp.out?r1=1.35&r2=1.36)
timestamptz.out (r1.29 -> r1.30)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/timestamptz.out?r1=1.29&r2=1.30)
pgsql/src/test/regress/sql:
timestamp.sql (r1.20 -> r1.21)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/timestamp.sql?r1=1.20&r2=1.21)
timestamptz.sql (r1.17 -> r1.18)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/timestamptz.sql?r1=1.17&r2=1.18)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
"For Windows, use the ODBC Administrator in Control Panel. Here you
can add, modify, or delete data sources."
On Windows XP, however, there is no Control Panel applet for ODBC
management. The answer should read:
"Go to Programs -> Administrative Tools -> Data Sources and Add the
PostgreSQL Unicode driver".
Hope this helps,
Dan Dascalescu
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
2.6? How old is that?
> Undefined first referenced
> symbol in file
> gethostbyname ../../src/port/libpgport_srv.a(getaddrinfo_srv.o) (symbol belongs to implicit dependency /usr/lib/libnsl.so.1)
> h_errno ../../src/port/libpgport_srv.a(getaddrinfo_srv.o) (symbol belongs to implicit dependency /usr/lib/libnsl.so.1)
> inet_ntoa ../../src/port/libpgport_srv.a(getaddrinfo_srv.o) (symbol belongs to implicit dependency /usr/lib/libnsl.so.1)
> ld: fatal: Symbol referencing errors. No output written to postgres
Just guessing, but maybe it will help to add -lnsl to LIBS (in
src/Makefile.global) after running configure.
regards, tom lane
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
> BTW what happened to the idea of displaying only user
> functions by default?
It's waiting on me to submit an updated patch, per Heikki's
request. I'll try to get one out this week.
- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200805251718
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iEYEAREDAAYFAkg515sACgkQvJuQZxSWSsjHSACgk2LoV4IHn36VyM2ubbShQGxR
Tl0AoILbyhbHCdcFjjr3+Kps6/2EYoQ+
=p6f6
-----END PGP SIGNATURE-----
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
As promised, the mistakes were mine, and I did not include Asaba-san's
fix. :P
Please find enclosed another patch remedying this problem and
documenting some of what WITH [RECURSIVE] does.
I'm also thinking there should be updates to psql's \h and tab
completion code.
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
few weeks ago I compiled PostgreSQL 8.3.1 on Solaris SPARC 9 without errors or problems. Today I would like to compile it on my old Sparis SPARC 2.6 box, so I've download new gnu software.
make hangs with this message:
gmake[3]: Leaving directory `/mnt/station-3/postgresql-8.3.1/src/timezone'
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -L../../src/port -Wl,-R'/usr/local/pgsql/lib' access/SUBSYS.o bootstrap/SUBSYS.o catalog/SUBSYS.o parser/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o storage/SUBSYS.o tcop/SUBSYS.o tsearch/SUBSYS.o utils/SUBSYS.o ../../src/timezone/SUBSYS.o ../../src/port/libpgport_srv.a -lposix4 -lsocket -ldl -lm -o postgres
Undefined first referenced
symbol in file
gethostbyname ../../src/port/libpgport_srv.a(getaddrinfo_srv.o) (symbol belongs to implicit dependency /usr/lib/libnsl.so.1)
h_errno ../../src/port/libpgport_srv.a(getaddrinfo_srv.o) (symbol belongs to implicit dependency /usr/lib/libnsl.so.1)
inet_ntoa ../../src/port/libpgport_srv.a(getaddrinfo_srv.o) (symbol belongs to implicit dependency /usr/lib/libnsl.so.1)
ld: fatal: Symbol referencing errors. No output written to postgres
collect2: ld returned 1 exit status
gmake[2]: *** [postgres] Error 1
gmake[2]: Leaving directory `/mnt/station-3/postgresql-8.3.1/src/backend'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory `/mnt/station-3/postgresql-8.3.1/src'
gmake: *** [all] Error 2
[station-1] /mnt/station-3/postgresql-8.3.1 |
I downloaded from http://www.sunfreeware.com
make-3.81-sol26-sparc-local.gz
gcc-3.4.6-sol26-sparc-local.gz
zip-2.32-sol26-sparc-local.gz
readline-5.2-sol26-sparc-local.gz
gzip-1.3.12-sol26-sparc-local
Have you got any idea ?
Regards.
Ganimede Dignan.
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
> Hang out on the pgsql-performance mailing list and see what other people
> do - "How do I tune a database for X" comes up pretty regularly, and
> gets good answers, so trolling through the mailing list archive can give
> some very good advice.
>
Aside from the hardware and server options that can be adjusted - the
sql you use can make a big difference to performance as well.
That goes from good table design and index usage through to select
statement structure as well.
The mailing lists are often a good place to get help with selects that
perform slowly.
--
Shane Ambler
pgSQL (at) Sheeky (dot) Biz
Get Sheeky @ http://Sheeky.Biz
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
something like -
pg_dump --data-only --table=myoldhistorytable | psql -h x.x.x.x mynewdb
> The thing is:
> I have a table that acts as a historic for some devices activity.
> Now I've migrated the entire 'shebang' to another server and need to
> update the history table on the new server with data from the old server
> for every different record.
If I get that right the old server has some of the new data (or more
importantly - updates to rows that were transferred) since the transfer
started?
Your best bet would be to pg_dump the data then change the table name at
the start of the file to match a temp table name that can take the old
history and then insert/update from the temp table to the new server
history table.
> As the table on the new server grows exponentially (already nearing 1M
> records) I need to do this asap unless I want the entire thing to take
> forever... (sweat)
>
> Could someone please lend me a hand here?
>
> Already thankful for any insight,
>
--
Shane Ambler
pgSQL (at) Sheeky (dot) Biz
Get Sheeky @ http://Sheeky.Biz
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Now I've migrated the entire 'shebang' to another server and need to
update the history table on the new server with data from the old server
for every different record.
-- Reece Hart, http://harts.net/reece/, GPG:0x25EC91A0 |
If there is any difference at all, the Socket should be faster. It is a
data-stream in the "virtual" file-system.
The loopback needs to create IP-packets. But the optimization might be very
high, so you maybe won't recognize any difference.
--
Sent via pgsql-novice mailing list (pgsql-novice@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-novice
Date: 2008-05-25 20:08:39 +0100 (Sun, 25 May 2008)
New Revision: 7309
Revision summary: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=7309&view=rev
Log:
Ensure that changing an icon image doesn't change the colour back to white. Seems to be a Mac issue
Modified:
trunk/pgadmin3/pgadmin/ctl/ctlTree.cpp
trunk/pgadmin3/pgadmin/include/ctl/ctlTree.h
--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers
How about splitting them up with newlines instead of (or in addition
to) commas?
> >> BTW what happened to the idea of displaying only user functions
> >> by default?
>
> IIRC it was more-or-less agreed to that the 'S' modifier ought to
> work uniformly for all object types the way it does now for tables,
> but there is no patch in the queue.
OK, since I did the whining, I get to prepare a patch. I'll see how
far I can get today. :)
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> I've looked into using PGOPTIONS to set the role, and it doesn't seem to
> be possible because when we're processing the backend command-line
> options we're not yet in a transaction state, so variable.c:assign_role
> will always come back with NULL and you get:
> vardamir:/home/sfrost> PGOPTIONS="-c role=postgres" psql -d networx -h vardamir
> psql: FATAL: invalid value for parameter "role": "postgres"
FWIW, I found by experimentation that ALTER USER ... SET ROLE does work
to cause a SET ROLE at login, though that might be a bit useless for
your purposes --- you'd more or less need a dedicated userid for
pg_dump.
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
Gregory Stark <stark@enterprisedb.com> writes:
> "Yoshiyuki Asaba" <y-asaba@sraoss.co.jp> writes:
>> Recursive query does not consume stack. The server enters an infinite
>> loop without consuming stack. Stack-depth error does not happen.
> We could have a separate guc variable which limits the maximum number of
> levels of recursive iterations. That might be a useful feature for DBAs that
> want to limit their users from issuing an infinite query.
This whole thread seems to be proposing more and more complicated
solutions for what is really a non-problem given Yoshiyuki-san's point.
It's trivial to construct SQL queries that will run for longer than the
MTBF of your hardware --- eg, forget a few join constraints. We've
gotten along fine with nothing but query cancel and statement_timeout
for that, and I've seen no one proposing that we need to "fix it".
We don't disallow you from writing an infinite loop in plpgsql, either.
I think this patch is plenty complicated enough without adding useless
restrictive options.
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
>>
>
> i don't think statement_timeout is a good idea at all.
> it is not deterministic. depending on the load on the server some
> queries will execute while others fail.
> a separate GUC is needed.
I don't think we need to add clutter to GUC for something that exists to
handle the problem at hand. If our real concern is server utilization
based on user or query resources we need to look at an overall solution
for that issue not a one off for a single feature.
Sincerely,
Joshua D. Drake
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
C'est un commentaire très vieux car cela fait au moins 3 ans que le site
www.postgresqlfr.org ne tourne plus sur un processeur Geode. :-)
Aujourd'hui le portail principal de postgresqlfr.org fonctionne sur un bi-pro
3Ghz. La version de drupal que nous utilisons est une 4.7.x, c'est à dire une
antiquité ( la version 6 vient de sortir )
Une très grosse réflexion est en cours au sein de l'asso PGFR pour décider de
l'avenir de la plate-forme. Le constat de départ est que notre version de
drupal est obsolète. Par ailleurs après 5 ans d'existence, la masse d'
information est tout simplement trop grande pour être gérée dans un CMS
unique : les listes de diffusion, le wiki, la planete, la doc, ( probablement
bientôt les forums) tout cela a fini par être hébergé en dehors de drupal.
Je rédigerai un message plus détails sur ce sujet dans quelques jours.
> Quant est-il de Drupal aujourd'hui ?
D'après moi Drupal est un très bon CMS, très modulaire..
Ce qu'on lui reproche c'est d'être extrèmement compliqué. Drupal introduit
tout un tas de concepts ( "taxonomie", "noeud", "livre", etc. ) qu'il faut
bien comprendre pour arriver a exploiter la puissance du logiciel.
Le temps passe. Les administrateurs changent. Les connaissances se perdent.
et si les concepts de base ont été mal transmis, on se retrouve avec une
machine à gaz ingérable en l'espace de 3 ans.
Tout ceci va l'encontre la tendance actuelle qui est de simplifier les
interfaces (KISS !) et faciliter l'écriture pour un maximum de visiteurs des
sites ( l'inénarrable web deux point zéro... ).
Les wikis sont l'illustration parfaite de cette nouvelle tendance.
Drupal , Joomla et consorts sont probablement des softs très puissants mais
il s'avère que la simplicité est souvent plus importante que la puissance.
En tout cas a titre personnel je suis convaincu que l'époque des
gros "CMS-qui-savent-tout-faire" est révolue :-)
> Notamment sur le point de vue performance ?
Il y a deux ans environ on a vécu une augmentation de trafic . On est passsé
de 110 000 à 170 000 pages vues par mois. Ceci a ralenti le site de manière
significative. Après investigation on s'est rendu compte que le serveur
PostgreSQL était bombardé de requêtes et avait du mal à suivre. La solution a
consisté à intercaler un pooler de connexion (pgpool) entre drupal et
postgresql...
> Drupal s'est-il amélioré ?
Aucune idée.
Cédric Villemain a fait quelques recherches sur drupal 6. Peut-être qu'il
pourra en dire plus. :-)
> S'agit-il uniquement d'un problème de performance au moment de la création
du contenu ?
Non. Les données du site sont utilisées à 99,99% en lecture. La création de
contenu n'est pas le soucis premier ;-)
>
> Quels sont les avantages et inconvénients de Drupal par rapport à SPIP,
> très populaire en francophonie ?
Je connais assez bien SPIP et à mon avis c'est une erreur de le considérer
comme un CMS.
SPIP est parfait pour gérer un journal en ligne, c'est à dire
une équipe de rédacteurs , un comité de rélecture, et des droits de réponse en
bas de chaque article.
En dehors de cette organisation bien particulière, SPIP n'a pas beaucoup
d'intérêt.
Toute tentative de transformer SPIP en un CMS généraliste est une perte de
temps. L'échec complet de SPIP-Agora en est la meilleure preuve.
En résumé, Drupal est un bon logiciel mais son coté "couteau-suisse" est passé
de mode. Les wikis sont des outils plus simples, plus conviviaux et plus
ouverts. Dans la pluspart des cas, ils remplacent avantageusement les gros
CMS comme Drupal
bonne journée :)
--
damien clochard
http://dalibo.org | http://dalibo.com
--
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
Jon
> -----Original Message-----
> From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-
> owner@postgresql.org] On Behalf Of Pedro Doria Meunier
> Sent: Sunday, May 25, 2008 6:25 AM
> To: Postgresql Mailing List
> Subject: [GENERAL] Copying data from a table to another database
> Importance: High
>
> Hi all,
>
> This is perhaps a very 'newbie' question but for the life of me, I
can't
> see a way to do it without resorting to programming... (blush)
>
> The thing is:
> I have a table that acts as a historic for some devices activity.
> Now I've migrated the entire 'shebang' to another server and need to
> update the history table on the new server with data from the old
server
> for every different record.
> As the table on the new server grows exponentially (already nearing 1M
> records) I need to do this asap unless I want the entire thing to take
> forever... (sweat)
>
> Could someone please lend me a hand here?
>
> Already thankful for any insight,
>
> --
> Pedro Doria Meunier <pdoria@netmadeira.com>
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
> Not a great idea.
Yeah, you'd certainly have to provide them somewhere, and so this would
just amount to splitting one column into two.
>> BTW what happened to the idea of displaying only user functions by
>> default?
IIRC it was more-or-less agreed to that the 'S' modifier ought to work
uniformly for all object types the way it does now for tables, but there
is no patch in the queue.
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
I want to useit pg_namespace table to create a "sub-schema" that will be used to
group the functions like in Oracle
--
Nabucodonosor Coutinho
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
As far as I'm concerned writing SQL is programming. It's not (usually)
procedural, but neither is Prolog, ML, Haskell, or any other number of
programming languages.
Anyway ... your question doesn't seem to be all that specific, but it
sounds like you've done a database migration where the data from one
table was excluded from the migration. You now wish to copy that table's
contents to the new server as well, merging it with the data in the same
table that's been created since the migration.
If it's just a history table I don't really see what's wrong with doing
a data-only dump of just that table using pg_dump, removing any DELETE
or TRUNCATE statements from the dump script, then running the load
script on the new server. That does assume you reserved space in any
primary key ID sequence in the new table though.
If there are primary key ID conflicts and you don't actually care about
the primary key values you may be able to load the data into a temporary
table then do an INSERT...SELECT that generates new primary keys with
`nextval' / DEFAULT and copies all other fields.
Personally I don't bother putting a primary key on history tables unless
it needs to be accessed by an ORM layer or similar, but I realise lots
of people do.
If all the above completely misses the point then either I've totally
misread your question or you might want to explain it in a bit more detail.
--
Craig Ringer
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Not a great idea. Maybe having the output of \df+ be \x'd would help
more.
> BTW what happened to the idea of displaying only user functions by
> default?
Some of the people who'd approve such a patch have trouble imagining
why the other 99.99%+ of the use base find having the system functions
appear by default to be useless clutter :(
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
En fouillant dans les archives de la liste j'ai trouvé quelques commentaires sur Drupal qui est utilisé pour le site postgresqlfr.org. En voici deux (datant de 2005) :
« Alors pour faire pgfr.org j'ai opté pour Drupal, qui lui est un gros veau bien lent, mais qui est relativement propre question code. »
« Aujourd'hui, Drupal assure vraiment bien, mais est toujours un peu trop lourd pour le processeur Géode que possède l'Open Brick sur lequel tourne le site!! »
Merci d'avance pour tout feedback et réponses aux questions ci-dessous (tout ça parce que avec d'autres, nous sommes en train de choisir un CMS pour construire des sites militants).
Quant est-il de Drupal aujourd'hui ? Notamment sur le point de vue performance ? Drupal s'est-il amélioré ? S'agit-il uniquement d'un problème de performance au moment de la création du contenu ?
Quels sont les avantages et inconvénients de Drupal par rapport à SPIP, très populaire en francophonie ?
Bien à vous,
Francis Leboutte
--
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
Hmm, right. Maybe the problem I have is that we made \df+ so wide so as
to be almost useless by now ...
I think this is mostly caused by the "args" column getting too wide.
Can we remove the OUT params from it?
BTW what happened to the idea of displaying only user functions by
default?
--
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
www.postgresql.org/mailpref/pgsql-es-ayuda
Desmarca la opcion "digest". Necesitas tu clave.
--
Alvaro Herrera
http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
TIP 5: ¿Has leído nuestro extenso FAQ?
> when thinking of REASSIGNED OWNED people tend to think about tables
> rather than about CONNECT rights.
> i would suggest to make DROP ROLE just kill the role unless there is a
> real object depending on it.
> i would not see a permission to be an object. what do you think?
Yes, this might make some sense. (Keep in mind that db CONNECT
privileges were invented after REASSIGN OWNED). Perhaps we could make
exceptions -- in which case it would be good to investigate which
exceptions we need (i.e. for all object types that we support, which
ones we should be caring about and which ones we should ignore).
I'm stuck in Canuckistan for a week still, so I expect your detailed
proposal by when I get back home ;-)
--
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
Gruß
Sven Marcel Buchholz
--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein
