Re: [GENERAL] PQprepare in PostgreSQL 7.4 (lack of SAVEPOINTs)
lol Seriosly, this customer issues resulted in improvement of the way our driver prepares statements. Keeping the map of prepared statements names is actually faster than using Savepoints (less roundtrips to server). I found that DECLARE ... CURSOR FOR ... cannot be prepared. Basically I'm looking for a way to prepare a complex query and then use cursor for reading tuples. Is this possible? This works: PREPARE abcd AS SELECT * FROM test; EXECUTE abcd; This does not work: PREPARE sdsdsd AS DECLARE csr1 CURSOR FOR SELECT * FROM test; This does not work (after prepared the query): DECLARE csr1 CURSOR FOR EXECUTE abcd; Thank you! Konstantin On Wed, Jun 23, 2010 at 9:41 PM, Tom Lane wrote: > Scott Marlowe writes: > > On Wed, Jun 23, 2010 at 10:55 PM, Konstantin Izmailov > wrote: > >> The company is not willing to upgrade from 7.4 to a later version due to > >> risk. > > > The risk of upgrading is less than the risk of staying on an > > unsupported version of pgsql. The company that won't upgrade is > > making a poorly informed decision. > > Indeed. Point out to them that 7.4 is going to be unsupported after the > end of this month: > http://wiki.postgresql.org/wiki/PostgreSQL_Release_Support_Policy > > If they don't have a plan to get off of 7.4 within the pretty near > future, they're fools. > >regards, tom lane >
[GENERAL] How to log query parameters instead of variables with log_min_duration_statement
Hi,
I am logging long queries with log_min_duration_statement but would like to see
the parameters for parameterized queries. Eg...
Jun 28 10:21:49 dbs1 postgres[20866]: [2-1] LOG: duration: 6625.543 ms
execute PRSTMT1405204512-1371060978/PORTAL1405204512-1371060978: SELECT COUNT(*)
Jun 28 10:21:49 dbs1 postgres[20866]: [2-2]FROM "XYZ123" AS "T0"
Jun 28 10:21:49 dbs1 postgres[20866]: [2-3]WHERE ("T0"."Id" = $1)
I'd like to log or find out what $1 was from the postgresql server side, not
the application side. Is this possible?
Best Regards,
Max Williams
Re: [GENERAL] How to log query parameters instead of variables with log_min_duration_statement
On Mon, Jun 28, 2010 at 5:29 AM, Max Williams wrote: > Hi, > > I am logging long queries with log_min_duration_statement but would like to > see the parameters for parameterized queries. Eg… > Consider increasing log level. I think you need to go to "debug" at least. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Enabling all backup options
I installed EnterpriseDB PostgreSQL Plus Standard Server R2 and I want to enable each and every feature related to recovery. I want to enable WAL and other features so that at the time of disaster, my database recovery is guaranteed. How to proceed? Regards, Rohit Prakash. _ The latest in fashion and style in MSN Lifestyle http://lifestyle.in.msn.com/
Re: [GENERAL] Enabling all backup options
On Mon, Jun 28, 2010 at 13:43, RP Khare wrote: > I installed EnterpriseDB PostgreSQL Plus Standard Server R2 and I want to > enable each and every feature related to recovery. I want to enable WAL and > other features so that at the time of disaster, my database recovery is > guaranteed. If you're using PostgreSQL Plus, you should be contacting EnterpriseDB, or use their forums, for support. While it's mostly PostgreSQL, it is bundled with a number of other products, so "each and every feature" may mean something else there. If you're only talking about the features also included in PostgreSQL, you should start by reading the chapters at http://www.postgresql.org/docs/8.4/static/backup.html. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Looking for a PostGre SQL Trainer, Bangalore
Hello, I am looking for a PostGre SQL trainer who can do a training program for a client of mine in Bangalore. If interested please send me a mail. Regards, Ravi 9686554646 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Looking for a PostGre SQL Trainer, Bangalore
Ravi Kariparmbil - Epistiuum Solutios, 28.06.2010 14:40: Hello, I am looking for a PostGre SQL trainer who can do a training program for a client of mine in Bangalore. I think this if off-topic here And you should learn how to write the name correctly :) Writing PostGre is like writing MerCed, PoRsch, ToYot, MicroSof, OrAcl or BangAlor Thomas -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] How to log query parameters instead of variables with log_min_duration_statement
Max Williams writes: > I am logging long queries with log_min_duration_statement but would like to > see the parameters for parameterized queries. Eg... You need a more recent version of Postgres. The versions that can do that at all (8.2 and up) will do it automatically. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] convert accented character to base character
I want to convert accented characters to the according base character, e.g. "Ü"
or "Ú" to "U".
Is there a way to do this with pgsql functions?
postgres=# select convert('Ü', 'UTF8', 'SQL_ASCII');
convert
--
\303\234
did not work as I had hoped.
Any help would be appreciated -
Cheers, Joachim
Re: [GENERAL] How to log query parameters instead of variables with log_min_duration_statement
I'm running 8.4.4 so you are saying this should work? I don't really want to go to debug level logging, tried it for 5 mins and it just logs too much! Max -Original Message- From: Tom Lane [mailto:t...@sss.pgh.pa.us] Sent: 28 June 2010 15:28 To: Max Williams Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] How to log query parameters instead of variables with log_min_duration_statement Max Williams writes: > I am logging long queries with log_min_duration_statement but would like to > see the parameters for parameterized queries. Eg... You need a more recent version of Postgres. The versions that can do that at all (8.2 and up) will do it automatically. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] convert accented character to base character
On 28 June 2010 16:22, Neubert Joachim wrote:
> I want to convert accented characters to the according base character, e.g.
> "Ü" or "Ú" to "U".
>
>
>
> Is there a way to do this with pgsql functions?
>
>
>
>
>
> postgres=# select convert('Ü', 'UTF8', 'SQL_ASCII');
>
> convert
>
> --
>
> \303\234
>
>
>
> did not work as I had hoped.
>
>
>
> Any help would be appreciated -
>
>
>
> Cheers, Joachim
There's a function called unaccent coming in PostgreSQL 9.0:
http://www.postgresql.org/docs/9.0/static/unaccent.html
But in the meantime, you could try this:
CREATE OR REPLACE FUNCTION unaccent_string(text) RETURNS text AS $$
DECLARE
input_string text := $1;
BEGIN
input_string := translate(input_string,
'âãäåāăąÁÂÃÄÅĀĂĄèééêëēĕėęěĒĔĖĘĚìíîïìĩīĭÌÍÎÏÌĨĪĬóôõöōŏőÒÓÔÕÖŌŎŐùúûüũūŭůÙÚÛÜŨŪŬŮ',
'aaaeeeooo');
return input_string;
END;
$$ LANGUAGE plpgsql;
Then you can do:
select unaccent_string('Ü');
Someone else may have a better suggestion though.
Regards
Thom
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] convert accented character to base character
On 06/28/10 8:22 AM, Neubert Joachim wrote: I want to convert accented characters to the according base character, e.g. "Ü" or "Ú" to "U". Is there a way to do this with pgsql functions? translate(somestring, 'ÙÚÛÜŨŪŬŮŰŲùúûüũūŭůűų', 'UUuu') of course, expand those with all the other characters you want translated. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] postgres user password: Log on failure
Hello, I'm on Windows XP with postgresql 8.4 installed by postgresql-8.4.4-1-windows. exe with essentially default settings (only the path to the data dir was changed from default). I realized that sometimes (not always!) the server cannot start when I reboot my machine (I get error messages on the line of "Log on failure: Only an unprivileged user can start the server"; Error 1063; Error 1069). It appears that the postgres user sometimes tries to log on with a wrong password (or no password?) so that I have to go to Control Panel -> Administrative Tools -> Services -> PostgreSQL -> Properties and retype the correct password. I would like to ask... - Why does this happen? (I have installed postgresql a few times on different machines and this is the first time I see this behavior) - Why is the postgres password wrong/missing sometimes but not every time I reboot? Many thanks for any explanation (Hopefully others will benefit from it... I spent quite some time to find out out to fix this "log on failure"). Dario -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] convert accented character to base character
On 28 June 2010 16:33, Thom Brown wrote:
> On 28 June 2010 16:22, Neubert Joachim wrote:
>> I want to convert accented characters to the according base character, e.g.
>> "Ü" or "Ú" to "U".
>>
>>
>>
>> Is there a way to do this with pgsql functions?
>>
>>
>>
>>
>>
>> postgres=# select convert('Ü', 'UTF8', 'SQL_ASCII');
>>
>> convert
>>
>> --
>>
>> \303\234
>>
>>
>>
>> did not work as I had hoped.
>>
>>
>>
>> Any help would be appreciated -
>>
>>
>>
>> Cheers, Joachim
>
> There's a function called unaccent coming in PostgreSQL 9.0:
> http://www.postgresql.org/docs/9.0/static/unaccent.html
>
> But in the meantime, you could try this:
>
> CREATE OR REPLACE FUNCTION unaccent_string(text) RETURNS text AS $$
> DECLARE
> input_string text := $1;
> BEGIN
>
> input_string := translate(input_string,
> 'âãäåāăąÁÂÃÄÅĀĂĄèééêëēĕėęěĒĔĖĘĚìíîïìĩīĭÌÍÎÏÌĨĪĬóôõöōŏőÒÓÔÕÖŌŎŐùúûüũūŭůÙÚÛÜŨŪŬŮ',
> 'aaaeeeooo');
That should actually be
'aaaeeEooo');
>
> return input_string;
> END;
> $$ LANGUAGE plpgsql;
>
> Then you can do:
>
> select unaccent_string('Ü');
>
> Someone else may have a better suggestion though.
>
> Regards
>
> Thom
>
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] convert accented character to base character
On 28/06/10 17:22, Neubert Joachim wrote:
I want to convert accented characters to the according base character,
e.g. "Ü" or "Ú" to "U".
I have the following:
CREATE OR REPLACE FUNCTION unaccent(TEXT) RETURNS TEXT AS
$$
use Text::Unaccent;
return unac_string('UTF8', $_[0]);
$$ LANGUAGE plperlu IMMUTABLE STRICT;
On debian you need the following package:
libtext-unaccent-perl
Kind regards,
Mathieu
Re: [GENERAL] PQprepare in PostgreSQL 7.4 (lack of SAVEPOINTs)
Looks like other people were asking similar question, but there is no answer: http://forums.devshed.com/postgresql-help-21/combine-prepare-and-declare-cursor-437562.html On Mon, Jun 28, 2010 at 1:00 AM, Konstantin Izmailov wrote: > lol > > Seriosly, this customer issues resulted in improvement of the way our > driver prepares statements. Keeping the map of prepared statements names is > actually faster than using Savepoints (less roundtrips to server). > > I found that DECLARE ... CURSOR FOR ... cannot be prepared. Basically I'm > looking for a way to prepare a complex query and then use cursor for reading > tuples. Is this possible? > This works: PREPARE abcd AS SELECT * FROM test; EXECUTE abcd; > This does not work: PREPARE sdsdsd AS DECLARE csr1 CURSOR FOR SELECT * FROM > test; > This does not work (after prepared the query): DECLARE csr1 CURSOR FOR > EXECUTE abcd; > > Thank you! > Konstantin > On Wed, Jun 23, 2010 at 9:41 PM, Tom Lane wrote: > >> Scott Marlowe writes: >> > On Wed, Jun 23, 2010 at 10:55 PM, Konstantin Izmailov >> wrote: >> >> The company is not willing to upgrade from 7.4 to a later version due >> to >> >> risk. >> >> > The risk of upgrading is less than the risk of staying on an >> > unsupported version of pgsql. The company that won't upgrade is >> > making a poorly informed decision. >> >> Indeed. Point out to them that 7.4 is going to be unsupported after the >> end of this month: >> http://wiki.postgresql.org/wiki/PostgreSQL_Release_Support_Policy >> >> If they don't have a plan to get off of 7.4 within the pretty near >> future, they're fools. >> >>regards, tom lane >> > >
Re: [GENERAL] How to log query parameters instead of variables with log_min_duration_statement
Max Williams writes: > I'm running 8.4.4 so you are saying this should work? Works for me, just as described here: http://archives.postgresql.org/pgsql-committers/2006-09/msg00152.php regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Is full-row updates slower than single-value updates
Hello everyone, My question is like the subject, is it much slower to update all columns values than just a single column? Generated update queries from ORM:s generally have the following format: update foo set a = 1, b = 2, c = 3, where id = 1234; So each column is touched which, I suspect, is much slower than just updating a single column because more indexes has to be rebuilt and so on. EXPLAIN ANALYZE does not give any hints and claims that both queries are equally fast. Maybe someone can guide me to documentation which explains how to estimate how costly row-level updates are? -- mvh Björn -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] EDB editions
On 06/26/2010 01:32 AM, RP Khare wrote: Hi, What is the difference between PGSQL provided by www.postgresql.org and www.enterprisedb.com? EnterpriseDB offers three variants: 1. Simple PostgreSQL 2. Standard Server, and 3. Advanced Server I want to migrate my production MySQL database to PostgreSQL. If I go for EnterpriseDB editions, is there any chance that those editions get discontinued later. I can see that PostgreSQL Plus edition is also free. Can I later migrate PostgreSQL plus database to community PostgreSQL? Just my 0.02, but I would consider EnterpriseDB if: 1. You need contract support for PostgreSQL whether due to technical needs that extend beyond what the mailing lists can provide or because there are organizational requirements to have such support on-call. 2. You need some of the features that EnterpriseDB adds to PostgreSQL - especially Oracle compatibility. 3. You find compelling added features in EnterpriseDB. If you use some of the added features in the EnterpriseDB variants you might find it more difficult to switch to vanilla PostgreSQL. If you start with vanilla PostgreSQL and then decide you want to move to EnterpriseDB, I doubt you will encounter much trouble. Any project or company *can* disappear or get discontinued. For open-source projects this can happen when the developers drift away or are all employed by a single company which falls on hard-times. PostgreSQL shines in this area because the core-developers are scattered around the world and employed by a diverse group of companies including EnterpriseDB who have vested interests in ensuring PostgreSQL's viability. Cheers, Steve -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PQprepare in PostgreSQL 7.4 (lack of SAVEPOINTs)
I have figured it out and everything works wonderfully!!!
Here is test code that allows preparing a query with cursor using libpq
library:
PGconn* conn = PQconnectdb("host=localhost dbname=postgres user=postgres
password=12345 port=5432");
PGresult* res = ::PQexec(conn, "START TRANSACTION", 0, 0); // need
transaction scope for the cursor
res = ::PQprepare(conn, "abcd", "DECLARE cur1 CURSOR FOR SELECT * FROM test",
0, NULL);
res = ::PQexecPrepared(conn, "abcd", 0, 0, 0, 0, 0, 0);
res = ::PQexec(conn, "FETCH FORWARD 100 FROM cur1", 0, 0);
int cColumns = PQnfields(res);
int cRows = PQntuples(res);
for (int field_num = 0; field_num < cColumns; field_num++)
{
char* szName = PQfname(res, field_num);
int nColumnSize = PQfsize(res, field_num);
Oid nType = PQftype(res, field_num);
int nMod = PQfmod(res, field_num);
}
res = ::PQexec(conn, "ABORT", 0, 0);
On Mon, Jun 28, 2010 at 9:11 AM, Konstantin Izmailov wrote:
> Looks like other people were asking similar question, but there is no
> answer:
> http://forums.devshed.com/postgresql-help-21/combine-prepare-and-declare-cursor-437562.html
>
> On Mon, Jun 28, 2010 at 1:00 AM, Konstantin Izmailov
> wrote:
>
>> lol
>>
>> Seriosly, this customer issues resulted in improvement of the way our
>> driver prepares statements. Keeping the map of prepared statements names is
>> actually faster than using Savepoints (less roundtrips to server).
>>
>> I found that DECLARE ... CURSOR FOR ... cannot be prepared. Basically I'm
>> looking for a way to prepare a complex query and then use cursor for reading
>> tuples. Is this possible?
>> This works: PREPARE abcd AS SELECT * FROM test; EXECUTE abcd;
>> This does not work: PREPARE sdsdsd AS DECLARE csr1 CURSOR FOR SELECT *
>> FROM test;
>> This does not work (after prepared the query): DECLARE csr1 CURSOR FOR
>> EXECUTE abcd;
>>
>> Thank you!
>> Konstantin
>> On Wed, Jun 23, 2010 at 9:41 PM, Tom Lane wrote:
>>
>>> Scott Marlowe writes:
>>> > On Wed, Jun 23, 2010 at 10:55 PM, Konstantin Izmailov <
>>> pgf...@gmail.com> wrote:
>>> >> The company is not willing to upgrade from 7.4 to a later version due
>>> to
>>> >> risk.
>>>
>>> > The risk of upgrading is less than the risk of staying on an
>>> > unsupported version of pgsql. The company that won't upgrade is
>>> > making a poorly informed decision.
>>>
>>> Indeed. Point out to them that 7.4 is going to be unsupported after the
>>> end of this month:
>>> http://wiki.postgresql.org/wiki/PostgreSQL_Release_Support_Policy
>>>
>>> If they don't have a plan to get off of 7.4 within the pretty near
>>> future, they're fools.
>>>
>>>regards, tom lane
>>>
>>
>>
>
Re: [GENERAL] Is full-row updates slower than single-value updates
Hello 2010/6/28 Björn Lindqvist : > Hello everyone, > > My question is like the subject, is it much slower to update all > columns values than just a single column? Generated update queries > from ORM:s generally have the following format: > > update foo set a = 1, b = 2, c = 3, where id = 1234; > > So each column is touched which, I suspect, is much slower than just > updating a single column because more indexes has to be rebuilt and so > on. EXPLAIN ANALYZE does not give any hints and claims that both > queries are equally fast. Maybe someone can guide me to documentation > which explains how to estimate how costly row-level updates are? > it depends. Pg create a new version of complete row for every update, so isn't important if you update one or all columns. But there are exception - TOAST columns. If you update any TOAST column, then UPDATE is significally slower, so - if you don't need to update these columns, then don't do it. Regards Pavel > -- > mvh Björn > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general > -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Is full-row updates slower than single-value updates
Pavel Stehule writes: > 2010/6/28 Björn Lindqvist : >> My question is like the subject, is it much slower to update all >> columns values than just a single column? Generated update queries >> from ORM:s generally have the following format: >> >> update foo set a = 1, b = 2, c = 3, where id = 1234; > it depends. Pg create a new version of complete row for every update, > so isn't important if you update one or all columns. But there are > exception - TOAST columns. If you update any TOAST column, then UPDATE > is significally slower, so - if you don't need to update these > columns, then don't do it. It's worth noting that updates like update foo set a = a, b = b, c = something where ... are pretty much equivalent in cost to update foo set c = something where ... ie, explicitly assigning a column its old value doesn't add anything to the cost, not even for toasted columns. (In fact, the planner inserts such assignments if you didn't request them, because that's necessary in order to form the complete new tuple value.) I'm not sure if that's true in other DBMSes but it's true in PG. But assigning a new value to a column costs something, even if it happens to be equal to the previous value. The cost is mainly in parsing and converting the supplied value, and that's something that every DBMS is going to be paying regardless of any optimizations it might have later. I hope your ORM is not really stupid enough to do explicit assignments to columns it knows already have that value --- if it is, you need a less stupid ORM. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] weird initdb output
I wrote a script that creates a new database from an existing backup. Works great on my machine. Another user tries to use it and sees the following output from initdb: could not change directory to "/root" The files belonging to this database system will be owned by user "postgres". This user must also own the server process. . . Why is it trying to change directory to /root??? Running as the postgres user. Any assistance would be appreciated. -- Until later, Geoffrey "I predict future happiness for America if they can prevent the government from wasting the labors of the people under the pretense of taking care of them." - Thomas Jefferson -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] weird initdb output
On 06/28/10 11:41 AM, Geoffrey wrote: I wrote a script that creates a new database from an existing backup. Works great on my machine. Another user tries to use it and sees the following output from initdb: could not change directory to "/root" The files belonging to this database system will be owned by user "postgres". This user must also own the server process. . . Why is it trying to change directory to /root??? Running as the postgres user. Any assistance would be appreciated. maybe he did an "su postgres" and not a "su - postgres" ? the latter does the equiv of a login, while the first only changes hte effective user. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] weird initdb output
Geoffrey writes: > I wrote a script that creates a new database from an existing backup. > Works great on my machine. Another user tries to use it and sees the > following output from initdb: > could not change directory to "/root" > The files belonging to this database system will be owned by user > "postgres". > This user must also own the server process. > . > . > Why is it trying to change directory to /root??? IIRC, part of the startup process involves chdir'ing to where the initdb executable is and then chdir'ing back to whatever directory had been current when you called initdb. I speculate the other guy was root and did "su postgres" not "su - postgres", so his cwd was still root's home directory. This might be harmless as long as you gave an absolute path for PGDATA to initdb, but I'd still recommend using su - not just su. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Vamos fazer esta operação
Sr.George Kevin Islamic Development Bnak Ouagadougou, Burkina Faso ( www.isdb.org) Tel: +226 70 54 98 80 Caro amigo, Por favor, eu quero que você leia esta carta com muita atenção e peço desculpa por trazer esta mensagem em sua caixa de correio, sem qualquer introdução formal devido à urgência e confidencial desta questão e sei que esta mensagem chegue até nós como uma surpresa, Por favor, isso não é uma piada e eu não gosto de você brincar com ele. Antes de os E.U. guerra do Iraque e do nosso cliente Sr.Hatem Kamil Abdul Fatah, que era um homem de negócios e também um fornecedor de petróleo para a República de Burkina Faso feito um depósito numeradas fixada para 18 meses do calendário, com um valor total de quinze milhões de dólares dos Estados Unidos ($ 15 000.000 million ) , apenas em nosso banco. Depois, vários avisos de vencimento foi enviada a ele, mesmo durante a guerra que começou em 2003. Novamente, após a guerra outra notificação foi enviada e ainda nenhuma resposta veio dele. Mais tarde descobrir que o cliente falecido, juntamente com toda sua família (esposa e filhos) morreram na explosão de uma bomba que atingiu sua casa. Após uma investigação mais aprofundada, também foi descoberto que o cliente final não declarar o seu parente mais próximo em seus documentos oficiais, incluindo a papelada de seu depósito bancário. E ele também me confidenciou que a última vez que esteve no meu escritório que ninguém, exceto eu sabia de seu depósito em nosso banco, assim que eu preciso de sua ajuda urgente para transferir o montante de (US $ 15 000 000) milhões de dólares em sua conta bancária no 14 dias úteis bancários. O que mais me incomoda é que, de acordo com as leis de um país Burkinabe não pode sair e reivindicar este fund.I não quero o dinheiro para ir para a nossa tesouraria do Banco como um fundo abandonado. Portanto, esta é a razão pela qual entrei em contato com você para que nosso banco vai liberar este dinheiro para você como o parente mais próximo ao cliente falecido. Por favor, eu gostaria de manter esta proposta como altamente secreto e eliminá-lo se você não está interessado. Após a recepção da vossa resposta e indicação de sua capacidade, eu lhe darei mais detalhes sobre como o negócio será executado e também a nota que você terá 40% do montante acima referido, se você concorda em lidar com esse negócio comigo enquanto 60% serão para mim. Eu não quero ninguém aqui em nosso banco para saber do meu envolvimento, até você confirmar este fundo em sua conta e pedir-me para vir para a partilha como indicado. Então, depois vou me aposentar do nosso banco e venha para você contry de desembolso acconding à percentagem indicada. Portanto, para permitir a transferência imediata do fundo para você conforme o combinado, você deve aplicar primeiro para o banco de relação ou de parentes próximos do morto, por favor, não entreter um átomo de temor, porque otransação é 100% livre de risco. NB: Como você está ciente de que esta é uma operação internacional, haverá expences pouco durante a transferência para sua conta. Portanto, qualquer dinheiro gasto durante o período de transferência deve ser tomado por nós dois Seja a certeza de que vou prestar todas as informações necessárias que o banco pode exigir de você durante o processo para garantir que tudo corra bem e rápido. Atenciosamente George Kevin
[GENERAL] weird initdb output
I wrote a script that creates a new database from an existing backup. Works great on my machine. Another user tries to use it and sees the following output from initdb: could not change directory to "/root" The files belonging to this database system will be owned by user "postgres". This user must also own the server process. . . Why is it trying to change directory to /root??? Running as the postgres user. Any assistance would be appreciated. -- Geoffrey Myers Myers Consulting Inc. 770.592.1651 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] postgres user password: Log on failure
> -Original Message- > From: dario@libero.it [mailto:dario@libero.it] > Sent: Monday, June 28, 2010 11:41 AM > To: pgsql-general@postgresql.org > Subject: postgres user password: Log on failure > > Hello, > > I'm on Windows XP with postgresql 8.4 installed by > postgresql-8.4.4-1-windows. > exe with essentially default settings (only the path to the > data dir was changed from default). > > I realized that sometimes (not always!) the server cannot > start when I reboot my machine (I get error messages on the > line of "Log on failure: Only an unprivileged user can start > the server"; Error 1063; Error 1069). > > It appears that the postgres user sometimes tries to log on > with a wrong password (or no password?) so that I have to go > to Control Panel -> Administrative Tools -> Services -> > PostgreSQL -> Properties and retype the correct password. > > I would like to ask... > - Why does this happen? (I have installed postgresql a few > times on different machines and this is the first time I see > this behavior) > - Why is the postgres password wrong/missing sometimes but > not every time I reboot? > > Many thanks for any explanation > (Hopefully others will benefit from it... I spent quite some > time to find out out to fix this "log on failure"). > > Dario > > > Does this XP has a policy set up, that requires every login to change it's password every so often (say 30 days, or whatever)? If so, exclude postgres account from this policy. Regards, Igor Neyman -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PG dump and restore
That was it exactly as I just tested the entire process and it all worked fine again. For some reason, I inadvertently replaced the "-Fc" part with a "-c" somewhere along the way. Thanks again! On Fri, Jun 25, 2010 at 5:18 PM, Adrian Klaver wrote: > On Friday 25 June 2010 4:59:17 pm Dennis C wrote: > > OK well the gunzip seemed to "do the trick," but I don't recall before > > having to do anything other than run the pg_restore command. Anyway, > > thanks to everyone for all your help! > > My guess is that previously the dump command was actually: > > /opt/local/lib/postgresql84/bin/pg_dump -Fc -f ./Trading-Access -Z 5 > Trading-Access > > > > > -- > Adrian Klaver > adrian.kla...@gmail.com >
Re: [GENERAL] postgres user password: Log on failure
On 28/06/10 8:58 PM, Igor Neyman wrote: Log on failure: Only an unprivileged user can start > the server"; Error 1063; Error 1069). > Error Message shows that services are getting started with Admin Privileges. Please use unprivileged user(i.e Non admin user) for starting the services. -- Thanks& Regards, Vibhor Kumar. EnterpriseDB Corporation The Enterprise Postgres Company Office: 732-331-1300 Ext-2022 Website: www.enterprisedb.com EnterpriseDB Blog: http://blogs.enterprisedb.com Follow us on Twitter: http://www.twitter.com/enterprisedb -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] weird initdb output
Tom Lane wrote: Geoffrey writes: I wrote a script that creates a new database from an existing backup. Works great on my machine. Another user tries to use it and sees the following output from initdb: could not change directory to "/root" The files belonging to this database system will be owned by user "postgres". This user must also own the server process. . . Why is it trying to change directory to /root??? IIRC, part of the startup process involves chdir'ing to where the initdb executable is and then chdir'ing back to whatever directory had been current when you called initdb. I speculate the other guy was root and did "su postgres" not "su - postgres", so his cwd was still root's home directory. This might be harmless as long as you gave an absolute path for PGDATA to initdb, but I'd still recommend using su - not just su. Appears this was exactly the case. I do specify absolute path for PGDATA, thanks. -- Until later, Geoffrey "I predict future happiness for America if they can prevent the government from wasting the labors of the people under the pretense of taking care of them." - Thomas Jefferson -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] PostgreSQL training
Hello All, I want to take a training course about “PostgreSQL” and have been browsing trough http://www.postgresql.org/about/eventarchive , but I am not sure about the level of training offered as there are disclaimers everywhere. Is there anybody on the list having experience with training offered? If so please share your opinion We are using PostgreSQL for a couple of years now so I am interested in advanced courses, like http://www.postgresql.org/about/event.1092 . Anybody having experience with “Modern Course” they like to share? Greetings, Ingmar -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Single quotes vs. double quotes when setting a pwd and other cmds
A. Kretschmer wrote: > In response to Alexander Farber : > > And identifiers means column names (eventually containing whitespace)? > > Right. > > test=# select 'foo' as "my new column"; > my new column > --- > foo > (1 row) And double-quotes preserve case: test=> select 'foo' as Mine; mine -- foo (1 row) test=> select 'foo' as "Mine"; <-- double-quotes Mine <-- -- foo (1 row) -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] weird initdb output
On Mon, Jun 28, 2010 at 2:11 PM, Geoffrey Myers wrote: > I wrote a script that creates a new database from an existing backup. Works > great on my machine. Another user tries to use it and sees the following > output from initdb: > > could not change directory to "/root" > The files belonging to this database system will be owned by user > "postgres". > This user must also own the server process. > > Why is it trying to change directory to /root??? Running as the postgres > user. Maybe if we could see the script? -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Prepared statement issue in Pgpool-II
Hi, We are using pgool-II version 2.3.2.2 (tomiteboshi)and postgres 8.3.9 and facing the below error while running the select queries in the application side:: ERROR: prepared statement "mdb2_statement_pgsql_71417ca02c1aa9cec1dd2570c46e992e" does not exist STATEMENT: DEALLOCATE PREPARE mdb2_statement_pgsql_71417ca02c1aa9cec1dd2570c46e992e WARNING: archive_mode enabled, yet archive_command is not set In the pgpool.conf file set the "reset_query_list" ='ABORT; RESET ALL; SET SESSION AUTHORIZATION DEFAULT' We also tested on pgpool-II version 2.3.3, result will be same. Please help us to resolve the issue. Regards Raghu
Re: [GENERAL] The case of PostgreSQL on NFS Server
Craig Ringer wrote: > On 24/06/10 12:42, Iwao Shikase wrote: > > > In my environment, Database cluster is in NFS server. > > So you are mounting an nfs file system shared by "localhost" ? > > Why not run PostgreSQL directly on the underlying file system, rather > than via nfs? > > > I guess that, In my environment, the mount options, system synchronously > > and without cache does not need. > > I would still expect to lose some written data if the system crashed or > lost power and nfs write caching was enabled. Because nfs's caching > doesn't guarantee write ordering, this data loss would probably horribly > corrupt your database. > > If you can get your NFS implementation to guarantee write ordering then > it's quite safe to cache. Good luck proving that it's doing the right > thing, though. "Safe" meaning it will not corrupt your database, but you could lose committed transactions after a server crash. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] XML - DOCTYPE element - documentation suggestion
On fre, 2010-06-18 at 02:43 +0800, Craig Ringer wrote: > The xml datatype documentation should probably mention that whole > documents must be loaded with an XMLPARSE(DOCUMENT 'doc_text_here), > they > cannot just be cast from text to xml as happens when you pass an xml > document as text to a parameter during an INSERT. This should probably > appear under "CREATING XML VALUES" in: > > http://www.postgresql.org/docs/current/static/datatype-xml.html > > ... and probably deserves mention in a new "CAVEATS" or "NOTES" > section > too, as it' *will* catch people out even if they R TFM. Done -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Need Some Recent Information on the Differences between Postgres and MySql
Tom Lane wrote: > Dave Page writes: > > Hmm, I think I misread Thom's question. The smgr API used to be far > > more rigidly designed as I understand it, to allow the possibility of > > having different storage engines (for example, maybe one that used raw > > devices). I don't know that any other storage engines were ever > > actually written though. > > There actually were two smgr storage modules in the code we inherited > from Berkeley, and I think there were probably more at one time. But > the smgr interface is *way* lower level than mysql's storage engines; > there is not that much that you can do to affect the behavior of the DB > by replacing an smgr module. I believe what they had in mind originally > was to be able to drive different physical storage devices, using raw > access instead of going through the filesystem. That decision was taken > before everything of interest got unified under the Unix filesystem API. > These days, if you needed to do what they had in mind, you'd be writing > a kernel device driver instead. So smgr is pretty vestigial, and we've > largely broken its API abstraction anyway by doing filesystem access > directly in so many other places. Yes, the second storage manager we had was for WORM drives, or more accurately, stubs were left in our code for WORM drives. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Need Some Recent Information on the Differences between Postgres and MySql
Bruce Momjian writes: > Tom Lane wrote: >> There actually were two smgr storage modules in the code we inherited >> from Berkeley, and I think there were probably more at one time. > Yes, the second storage manager we had was for WORM drives, or more > accurately, stubs were left in our code for WORM drives. No, the other storage manager in the Berkeley sources was for keeping stuff in "hopefully stable" main memory: http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/smgr/Attic/mm.c?rev=1.1;content-type=text%2Fplain Of course that was dead as a doornail after people stopped using magnetic-core main memory. There are references to a WORM storage manager in the Berkeley Postgres papers, but it's not clear to me if they ever wrote one or merely theorized about it. The hint-bit stuff, to take just one example, would never have worked on WORM storage, and yet it's implemented above the smgr API. So it seems kinda unlikely that there was ever a working WORM smgr. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Need xml element constructor given tag, attribute array & children
Hi Everybody, I'm having trouble finding any way to build up XML values from their logical components, e.g. given an XML element tag, an array of attributes in some form, and an xml[] array of children I can't find any SQL function or expression which would construct the XML element. Surely the syntactic sugary XMLPARSE must be calling such a function? Am I missing something or is PostgreSQL missing something? Thanks, _Greg -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Need xml element constructor given tag, attribute array & children
On 29/06/10 09:49, J. Greg Davidson wrote: > Hi Everybody, > > I'm having trouble finding any way to build up > XML values from their logical components, e.g. > given an XML element tag, an array of attributes > in some form, and an xml[] array of children I > can't find any SQL function or expression which > would construct the XML element. Surely the > syntactic sugary XMLPARSE must be calling such > a function? Am I missing something or is > PostgreSQL missing something? The XMLELEMENT pseudo-function will do what you need. http://www.postgresql.org/docs/current/static/functions-xml.html -- Craig Ringer Tech-related writing: http://soapyfrogs.blogspot.com/ -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Prepared statement issue in Pgpool-II
On 28/06/10 11:14 PM, raghu ram wrote: Hi, We are using pgool-II version 2.3.2.2 (tomiteboshi)and postgres 8.3.9 and facing the below error while running the select queries in the application side:: ERROR: prepared statement "mdb2_statement_pgsql_71417ca02c1aa9cec1dd2570c46e992e" does not exist Try with reset_query_list= 'ABORT; DISCARD ALL' -- Thanks& Regards, Vibhor Kumar. EnterpriseDB Corporation The Enterprise Postgres Company Office: 732-331-1300 Ext-2022 Website: www.enterprisedb.com EnterpriseDB Blog: http://blogs.enterprisedb.com Follow us on Twitter: http://www.twitter.com/enterprisedb -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] owner of a database does not own "public" schema?
Hi, I was playing around with schemas and noticed that that the owner of a the database (specified with the CREATE DATABASE command) is not the owner of the database's public schema: (Connect as super user) c:\temp>psql postgres postgres Password for user postgres: psql (8.4.3) Type "help" for help. postgres=# create user foo password 'bar'; CREATE ROLE postgres=# create database foo owner = foo encoding = 'UTF-8'; CREATE DATABASE postgres=# \q c:\>psql foo foo Password for user foo: psql (8.4.3) Type "help" for help. foo=> drop schema public; ERROR: must be owner of schema public foo=> (As you can see, I'm using Postgres 8.4.3 on Windows) I understand that I could grant the necessary privileges to the role after creating the database. I'm just curious why the databse owner is not the owner of the public schema. Regards Thomas -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
