> 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
> Christop
2015-05-22 18:36 GMT+02:00 Piotr Gasidło :
> 2015-05-22 6:55 GMT+02:00 Fujii Masao :
> >
> > 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 00044C4D0090 and the
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 be
2015-05-25 11:30 GMT+02:00 Guillaume Lelarge :
>> 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 issue could sti
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
p
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:
http://www.po
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:
test_uui
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 t
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
depe
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 :
> 2015-05-25 11:30 GMT+02:00 Guillaume Lelarge :
>
> >> 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
> >> h
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,
i.idx
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",
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 fo
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, rolpassword,rolcanlog
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 s
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 under
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 under
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 the
Hi Daniel:
On Mon, May 25, 2015 at 10:03 PM, Daniel Begin wrote:
...
> Even after doing all this, I did not find any improvement in execution times
> between my original fat table and the partitioned version (sometime even
> worst). If partitioning the table has improved significantly queries r
21 matches
Mail list logo
