I think that that unwritable postgresql.conf file had probably been
hanging around in your data directory for some time. It was not causing
any particular problem until we decided we ought to fsync everything in
the data directory after a crash. So this is indeed the same case
Christoph
2015-05-22 18:36 GMT+02:00 Piotr Gasidło qua...@barbara.eu.org:
2015-05-22 6:55 GMT+02:00 Fujii Masao masao.fu...@gmail.com:
This problem happens when WAL record is stored in separate two WAL files
and
there is no valid latter WAL file in the standby. In your case, the
former file
is
Hello,
I am porting my application from Oracle to PostgreSQL.
We are using BULK COLLECT functionality of oracle.
How can i change the 'BULK COLLECT' fetch of the data from the cursor to
make if compatible for pg/plsql?
A small example is as below (This is just an example and the query is much
On 05/25/2015 07:24 AM, Medhavi Mahansaria wrote:
Hello,
I am porting my application from Oracle to PostgreSQL.
We are using BULK COLLECT functionality of oracle.
How can i change the 'BULK COLLECT' fetch of the data from the cursor to make
if compatible for pg/plsql?
A small example is as
2015-05-25 11:30 GMT+02:00 Guillaume Lelarge guilla...@lelarge.info:
I currently have wal_keep_segments set to 0.
Setting this to higher value will help? As I understand: master won't
delete segment and could stream it to slave on request - so it will
help.
It definitely helps, but the
It seems you are fetching from a table then sequentially inserting each
record to another table.
In PostgreSQL, you could use cursors in PL/pgSQL (
http://www.postgresql.org/docs/9.4/interactive/plpgsql-cursors.html;).
Alternatively you may write a single query which selects from the table and
On 05/25/2015 05:24 AM, Medhavi Mahansaria wrote:
Hello,
I am porting my application from Oracle to PostgreSQL.
We are using BULK COLLECT functionality of oracle.
How can i change the 'BULK COLLECT' fetch of the data from the cursor to
make if compatible for pg/plsql?
See here:
On 05/25/2015 07:17 AM, Piotr Gasidło wrote:
Hello,
I've moved from Linux to FreeBSD. I've used uuid-ossp. Now I need to
aply patch to make it work under FreeBSD. This is rather dirty hack.
So I need to replace it once and for all with uuid-freebsd module. But
because in my database I use uuid
Hello,
I've moved from Linux to FreeBSD. I've used uuid-ossp. Now I need to
aply patch to make it work under FreeBSD. This is rather dirty hack.
So I need to replace it once and for all with uuid-freebsd module. But
because in my database I use uuid type and uuid_* functions is not
easy:
On May 25, 2015 04:17:32 PM Piotr Gasidło wrote:
test_uuid=# drop extension uuid-ossp;
ERROR: cannot drop extension uuid-ossp because other
objects depend on it
DETAIL: default for table test column id depends on function
uuid_generate_v4() HINT: Use DROP ... CASCADE to drop the
dependent
On 2015-05-22 09:41:57 -0400, Melvin Davidson wrote:
I'd like to share those queries with the community, as I know there must be
others out there with the same problem.
/* useless_indexes.sql */
SELECT
idstat.schemaname AS schema,
idstat.relname AS table_name,
2015-05-25 15:15 GMT+02:00 Piotr Gasidło qua...@barbara.eu.org:
2015-05-25 11:30 GMT+02:00 Guillaume Lelarge guilla...@lelarge.info:
I currently have wal_keep_segments set to 0.
Setting this to higher value will help? As I understand: master won't
delete segment and could stream it to
I'm not sure why you are using pg_stat_user_indexes. My original query
below uses pg_stat_all_indexes and the schema names are joined and it
does work.
SELECT n.nspname as schema,
i.relname as table,
i.indexrelname as index,
i.idx_scan,
i.idx_tup_read,
Thank for your patience :-)
- About using PgAdmin, anecdotal problems or not, I did the whole tests again
in plain postgresql.
- About running queries once or not, Bill and Francisco both pointed out
somehow that I should run each query multiple times to get appropriate
statistics. I did it
On 2015-05-25 12:25:01 -0400, Melvin Davidson wrote:
I'm not sure why you are using pg_stat_user_indexes.
Because you did. I didn't change that.
My original query below
uses pg_stat_all_indexes and the schema names are joined and it does work.
I'm not sure what you mean by original, but
Should the same password, stored in MD5, be the same across different DBs?
If I did either:
create user SomeUser encrypted password 'SomePassword';
alter user SomeUser encrypted password 'SomePassword';
On multiple machines, should the MD5 be the same?
using
select rolname,
On 05/25/2015 01:41 PM, Francisco Reyes wrote:
Should the same password, stored in MD5, be the same across different DBs?
If I did either:
create user SomeUser encrypted password 'SomePassword';
alter user SomeUser encrypted password 'SomePassword';
On multiple machines, should the MD5 be the
On 2015-05-25 17:58, Adrian Klaver wrote:
On 05/25/2015 01:41 PM, Francisco Reyes wrote:
On multiple machines, should the MD5 be the same?
using
select rolname, rolpassword,rolcanlogin from pg_catalog.pg_authid where
rolname = 'SomeUser';
Should the MD5 be the same?
I understood that is
On 2015-05-25 17:58, Adrian Klaver wrote:
On 05/25/2015 01:41 PM, Francisco Reyes wrote:
On multiple machines, should the MD5 be the same?
using
select rolname, rolpassword,rolcanlogin from pg_catalog.pg_authid where
rolname = 'SomeUser';
Should the MD5 be the same?
I understood that is
On 05/25/2015 08:41 PM, Yves Dorfsman wrote:
On 2015-05-25 17:58, Adrian Klaver wrote:
On 05/25/2015 01:41 PM, Francisco Reyes wrote:
On multiple machines, should the MD5 be the same?
using
select rolname, rolpassword,rolcanlogin from pg_catalog.pg_authid where
rolname = 'SomeUser';
Should
20 matches
Mail list logo
