Re: [BUGS] BUG #8288: 9.3.0Beta2 - Windows Installer bug #7738 still open
On Tue, Jul 9, 2013 at 1:44 PM, wrote: > The following bug has been logged on the website: > > Bug reference: 8288 > Logged by: Thomas Gauss > Email address: tga...@wolfsysteme.de > PostgreSQL version: Unsupported/Unknown > Operating system: Windows 7 64bit > Description: > > Having data directory on drive d:\database\data-9.3 it takes about 45 > minutes to initialise cluster. Most of the time icacls is run by the > installer, seems like bug#7738 is still active in 9.3.0b2's installer. iirc, we eventually came to the conclusion that in some (unknown) circumstances, icacls will recursively examine ACLs, even though it's not updating them. We're currently looking into alternative ways to ensure the permissions needed to write to the data directory are correct. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8290: broken/unexpected locking behavior
pg noob escribió: > Alvaro, > > Is there a PostgreSQL bug number that I could refer to for this problem? #8290 ? -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8290: broken/unexpected locking behavior
Alvaro, Is there a PostgreSQL bug number that I could refer to for this problem? Thank you. On Tue, Jul 9, 2013 at 4:53 PM, Alvaro Herrera wrote: > Jamey Poirier escribió: > > > > Thank you Alvaro. Yes, this explains it. > > It doesn't help to fix it but at least I know now that it's a known > "feature". > > I'll have to see about coming up with a work-around as we likely won't > get to 9.3 anytime soon. > > Perhaps you can use FOR SHARE instead of FOR UPDATE in the first > connection, for instance .. > > -- > Álvaro Herrerahttp://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services >
[BUGS] BUG #8292: Error en Una Función llamada desde NetBeans
The following bug has been logged on the website:
Bug reference: 8292
Logged by: Renzo Carranza
Email address: renzo_...@hotmail.com
PostgreSQL version: 9.2.3
Operating system: Windows
Description:
Este es mi error "malformed function or procedure escape syntax at offset
6"
Estas son mis funciones con las que hago la transacción en Java NetBeans
CREATE OR REPLACE FUNCTION fu_ingresaralquiler()
RETURNS integer AS
$BODY$
DECLARE
lalquilercodigo integer;
BEGIN
INSERT INTO alquiler(vigencia)
VALUES (true::boolean);
lalquilercodigo = CURRVAL('alquiler_codigo_seq');
return lalquilercodigo;
END;
$BODY$
LANGUAGE 'plpgsql'
CREATE OR REPLACE FUNCTION fu_insertardetallealquiler( pnumero integer,
pnombres character varying, papellidos character varying, pcodigohabitacion
integer)
RETURNS void AS
$BODY$
BEGIN
insert into detallealquiler( numero, nombres, apellidos,
codigohabitacion)
values((select codigo from alquiler order by codigo desc limit
1)::integer,pcodigoalquiler::integer, pnumero::integer, pnombres,
papellidos, pcodigohabitacion::integer);
END;
$BODY$
LANGUAGE plpgsql;
Este es mi código en NetBeans para llamar a la función:
public void registrar(TipoHabitacion tipos) throws Exception {
List parsTipo = new ArrayList();
parsTipo.add(new Parametro("", 0));
parsTipo.add(new Parametro("", 0));
parsTipo.add(new Parametro("", 0));
/*parsTipo.add(new Parametro("", tipos.getNombre()));
* parsTipo.add(new Parametro("", tipos.getPrecio()));
* parsTipo.add(new Parametro("", tipos.getCantidad()));*/
try {
this.Conectar(true);
parsTipo.get(0).setValor(
tipos.getNombre());
parsTipo.get(1).setValor(tipos.getPrecio());
parsTipo.get(2).setValor( (int)tipos.getCantidad()) ;
this.EjecutarProcedimiento(
"{call fu_insertartipo(?, ?, ?)}",
parsTipo);
this.Conectar(false);
} catch (Exception e) {
this.Cerrar(false);
JOptionPane.showMessageDialog(null, e);
} finally {
parsTipo.clear();
parsTipo = null;
}
}
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #8293: There are no methods to convert json scalar text to text in v9.3 beta2
The following bug has been logged on the website: Bug reference: 8293 Logged by: Yaroslav Potapov Email address: jaroslav.pota...@gmail.com PostgreSQL version: Unsupported/Unknown Operating system: All Description: SELECT '"a\"b"'::json::text returns text: '"a\"b"' , but it must return 'a"b' in my opinion. Thank you. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Unable to handle error in plperl
Dear all,
I have a situation. I am unable to pass control back to the function
once it hit the "undefined_column" error code.
I am not sure there's a way to return '123' instead exit from the function.
Here is my code
CREATE OR REPLACE FUNCTION foo() RETURNS text as $$
my $sql = "";
my $status = "";
my $r = "";
$sql = 'SELECT non_exist_column from a_table limit 1';
eval { spi_exec_query($sql);};
if ($@) {
$status = 'invalid: '.$@;
elog(ERROR, $status);
return '123';
} else {
$status = 'valid';
}
return $status;
$$ LANGUAGE plperl;
When I run it
select foo();
ERROR: invalid: column "non_exist_column" does not exist at line 6.
CONTEXT: PL/Perl function "foo"
When I select from the valid column
CREATE OR REPLACE FUNCTION foo() RETURNS text as $$
my $sql = "";
my $status = "";
my $r = "";
$sql = 'SELECT exist_column from a_table limit 1';
eval { spi_exec_query($sql);};
if ($@) {
$status = 'invalid: '.$@;
elog(ERROR, $status);
return '123';
} else {
$status = 'valid';
}
return $status;
$$ LANGUAGE plperl;
When I run it
select foo();
foo
--
valid
(1 row)
--
Best regards,
Alex Lai
OMI SIPS DBA ADNET Systems , Inc.
7515 Mission Drive,
Suite A100 Lanham, MD 20706
301-352-4657 (phone)
301-352-0437 (fax)
m...@sesda3.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8291: postgres_fdw does not re-read USER MAPING after change.
--On 9. Juli 2013 22:05:20 + lal...@fhcrc.org wrote: I have found that if you change the password in the USER MAPPING, that postgres_fdw will not use it unless the current password fails or you close and re-open your postgres connection. I found this while testing to see if the USER MAPPING's supports MD5 passwords and they appeared to until the next day when I found that they no longer worked because I had closed and re-opened my connection. Hmm i don't think that's a bug. It's because the postgres_fdw caches the connection within your local session, reusing it for any subsequent foreign table access. The second error that I found is in the documentation of ALTER USER MAPPING. It incorrectly says how to update a users password. It could be misread, i agree. Attached is a small doc patch to address this against HEAD. -- Thanks Bernd user_mapping_doc.patch Description: Binary data -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8291: postgres_fdw does not re-read USER MAPING after change.
I realized that postgres_fdw is caching the connection, but when you have existing items that use the same USER MAPPING and do not cache it such as dblink you get inconsistency in implementation and this should be avoided. Lloyd -Original Message- From: Bernd Helmle [mailto:maili...@oopsware.de] Sent: Wednesday, July 10, 2013 3:34 PM To: Albin, Lloyd P; pgsql-bugs@postgresql.org Subject: Re: [BUGS] BUG #8291: postgres_fdw does not re-read USER MAPING after change. --On 9. Juli 2013 22:05:20 + lal...@fhcrc.org wrote: > I have found that if you change the password in the USER MAPPING, that > postgres_fdw will not use it unless the current password fails or you > close and re-open your postgres connection. I found this while testing > to see if the USER MAPPING's supports MD5 passwords and they appeared > to until the next day when I found that they no longer worked because > I had closed and re-opened my connection. > Hmm i don't think that's a bug. It's because the postgres_fdw caches the connection within your local session, reusing it for any subsequent foreign table access. > > The second error that I found is in the documentation of ALTER USER > MAPPING. It incorrectly says how to update a users password. > > It could be misread, i agree. Attached is a small doc patch to address this against HEAD. -- Thanks Bernd -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
