[GENERAL] Is BDR support distributed table on slave nodes with ACID and join support.
Hello everyone, We ae working on a application in which we are using posgresql as a database. We are sure that in future it will extend to level that we have to scale it horizontally. We have some tables which are going to be more than 90% of database size. I looked at pg_shard, as per my understanding it is for nosql data, in our case we are going to use postgresql RDBMS features without nosql, pg_shard have lot on limitation as per our case. I looked at postgresql-xl, it looks good as per our requirements, but we have to do a lot of things to make it high availaiblity and it don't have debian packages available for debian. Now I see BDR, it looks good, it have multimasters, we can start with one master and later we can add more master servers to avoid failover. Bellow are my queries:- 1. If start with postgresql 9.4 database, later can I upgrade it to DBR with these already large table, can I distribute these tables or shard them. Do I need to do some extra changes in database or it will be complicate later. 2. how can I distribute some of tables on my slave nodes, if it have any limitations please let me know. 3. if I started with 4 or 5 node cluster with one master and rest of slave nodes, how can I take backup of this distributed database to one of my other server or backup location. Please suggest me what would be the best approch for this. -- Thanks & Regards, Amit Bondwal
[GENERAL] Backup fatal issue
Hi there,
I have some problems in a postgres cluster when I try to execute a backup.
This is the log of entire operation:
LOG: connection received: host=91.121.182.110 port=54957
LOG: connection authorized: user=postgres database=postgres
LOG: statement: BEGIN
LOG: statement: SET application_name TO barman
LOG: statement: SHOW "data_directory"
LOG: connection received: host=91.121.182.110 port=54958
LOG: connection authorized: user=postgres database=postgres
LOG: statement: BEGIN
LOG: statement: SET application_name TO barman
LOG: statement: SELECT name, setting FROM pg_settings WHERE name IN
('config_file', 'hba_file', 'ident_file')
LOG: connection received: host=91.121.182.110 port=54959
LOG: connection authorized: user=postgres database=postgres
LOG: statement: BEGIN
LOG: statement: SET application_name TO barman
LOG: statement: SELECT spcname, oid, pg_tablespace_location(oid) AS
spclocation FROM pg_tablespace WHERE pg_tablespace_location(oid) != ''
LOG: connection received: host=91.121.182.110 port=54960
LOG: connection authorized: user=postgres database=postgres
LOG: statement: BEGIN
LOG: statement: SET application_name TO barman
LOG: statement: select pg_is_in_recovery()
LOG: statement: SELECT xlog_loc, (pg_xlogfile_name_offset(xlog_loc)).*,
now() FROM pg_start_backup('Barman backup redevodb_citrix
20150717T091702',false) as xlog_loc
LOG: connection received: host=91.121.182.110 port=54988
FATAL: semctl(983046, 3, SETVAL, 0) failed: Invalid argument
LOG: server process (PID 1756) exited with exit code 1
LOG: terminating any other active server processes
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back the
current transaction and exit, because another server process exited
abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and
repeat your command.
LOG: all server processes terminated; reinitializing
LOG: could not remove shared memory segment "/PostgreSQL.1804289383": No
such file or directory
LOG: semctl(786432, 0, IPC_RMID, ...) failed: Invalid argument
LOG: semctl(819201, 0, IPC_RMID, ...) failed: Invalid argument
LOG: semctl(851970, 0, IPC_RMID, ...) failed: Invalid argument
LOG: semctl(884739, 0, IPC_RMID, ...) failed: Invalid argument
LOG: semctl(917508, 0, IPC_RMID, ...) failed: Invalid argument
LOG: semctl(950277, 0, IPC_RMID, ...) failed: Invalid argument
LOG: semctl(983046, 0, IPC_RMID, ...) failed: Invalid argument
LOG: semctl(1015815, 0, IPC_RMID, ...) failed: Invalid argument
LOG: database system was interrupted; last known up at 2015-07-17 09:18:10
CEST
LOG: redo starts at 16/9F28
LOG: record with zero length at 16/9F000100
LOG: redo done at 16/9FC8
LOG: MultiXact member wraparound protections are now enabled
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
Can anyone help me to identify and to resolve this inconvenience?
Thanks in advance.
Meph
--
View this message in context:
http://postgresql.nabble.com/Backup-fatal-issue-tp5858258.html
Sent from the PostgreSQL - general mailing list archive at Nabble.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] Is BDR support distributed table on slave nodes with ACID and join support.
1,2,3: You can't shard with BDR. It's only for multimaster (at least for now). Please read the docs. On Fri, Jul 17, 2015 at 9:02 AM, Amit Bondwal wrote: > Hello everyone, > > We ae working on a application in which we are using posgresql as a > database. We are sure that in future it will extend to level that we have > to scale it horizontally. We have some tables which are going to be more > than 90% of database size. > > I looked at pg_shard, as per my understanding it is for nosql data, in our > case we are going to use postgresql RDBMS features without nosql, pg_shard > have lot on limitation as per our case. > > I looked at postgresql-xl, it looks good as per our requirements, but we > have to do a lot of things to make it high availaiblity and it don't have > debian packages available for debian. > > Now I see BDR, it looks good, it have multimasters, we can start with one > master and later we can add more master servers to avoid failover. > Bellow are my queries:- > > 1. If start with postgresql 9.4 database, later can I upgrade it to DBR > with these already large table, can I distribute these tables or shard > them. Do I need to do some extra changes in database or it will be > complicate later. > > 2. how can I distribute some of tables on my slave nodes, if it have any > limitations please let me know. > > 3. if I started with 4 or 5 node cluster with one master and rest of slave > nodes, how can I take backup of this distributed database to one of my > other server or backup location. > > Please suggest me what would be the best approch for this. > > -- > Thanks & Regards, > > Amit Bondwal >
Re: [GENERAL] Is BDR support distributed table on slave nodes with ACID and join support.
On 17 July 2015 at 17:33, Dorian Hoxha wrote: > 1,2,3: You can't shard with BDR. It's only for multimaster (at least for > now). Please read the docs. You can kind-of shard using table partitioning, but the application has to deal with shard integration because there's no cross-node querying. So in practice it's no benefit over a bunch of standalone databases. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- 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 BDR support distributed table on slave nodes with ACID and join support.
On 17 July 2015 at 15:02, Amit Bondwal wrote: > I looked at pg_shard, as per my understanding it is for nosql data, in our > case we are going to use postgresql RDBMS features without nosql, pg_shard > have lot on limitation as per our case. You'll find that _most_ products have a lot of limitations when doing things like horizontal scaling. BDR is no exception either. > 1. If start with postgresql 9.4 database, later can I upgrade it to BDR with > these already large table, can I distribute these tables or shard them. You need a patched PostgreSQL 9.4 if you're going to use BDR because it relies on a bunch of functionality that didn't make it into the 9.4 release. (Some didn't make it into 9.5 either). That patched PostgreSQL can be used like normal PostgreSQL 9.4, but it's not 100% on-disk compatible. You have to do a dump and reload to convert to or from stock community PostgreSQL, you can't pg_upgrade or otherwise convert in-place. You can run normal PostgreSQL applications on a standalone database on the BDR-patched PostgreSQL 9.4 by just not installing the BDR extension in the database. You can then activate BDR later. Be aware, though, that BDR imposes quite a few limitations on what the app can do when it comes to DDL. If you activate BDR later, you might find that things you were expecting to work and that worked fine before stop working. I'd strongly suggest planning to deploy with BDR from the start if you're going to use it at all. > 2. how can I distribute some of tables on my slave nodes, if it have any > limitations please let me know. BDR doesn't support sharding. A table can be on all nodes or - using replication sets - some subset of nodes, but it's the whole table or none of it. You can partition the table and shard the partitions using replication sets, but then each node will only see a subset of the data. There's no transparent cross-node querying. You could try to combine foreign data wrappers and inheritance with partitioning, but by then you're playing database jenga and things will come toppling down very, very hard. > 3. if I started with 4 or 5 node cluster with one master and rest of slave > nodes, how can I take backup of this distributed database to one of my other > server or backup location. pg_dump > Please suggest me what would be the best approch for this. >From your description it sounds like BDR is not particularly suitable for your use case at this time. We're looking at adding sharding down the track, but it's quite a way down the track because there's a fair bit of work on making sure the core functionality is rock solid and easy to manage. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Getting error "IST FATAL: the database system is in recovery mode"
Dear Team, I am getting the below error in my database pg_log file and also I am unable to open the database. "IST FATAL: the database system is in recovery mode" I am using postgresql version 9.1 on Centos 6.6. Kindly suggest why this problem is coming. Regards, Sachin
Re: [GENERAL] Is BDR support distributed table on slave nodes with ACID and join support.
On 17 July 2015 at 19:37, Amit Bondwal wrote: > Thank you very much all of you for quick response and clearing my mind. Please reply to the mailing list, not just to me directly. > One more question, can I run a databse of postgres 9.4 on postgres-XL > cluster? postgres-XL is based on PostgreSQL 9.2, so no. Postgres-XL doesn't "run on" PostgreSQL. It's a modified (forked) version of PostgreSQL. > Or you can advise me any better solution. Not without knowing a lot more about what you're trying to do, what your requirements are, etc. > As per my knowledge partitioning > of a table have some limits in nos. and I can't extend more storage in a > server upto a limit. Yes, that's true, but those limits are quite large, and you may be trying to solve a problem you don't and won't have. This may well be premature optimisation. I can't know without a lot more info. Rather than starting with the solution (horizontal partitioning, sharding) try starting with the problem and requirements, then looking for solutions from there. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- 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 BDR support distributed table on slave nodes with ACID and join support.
Thanks you very much Craig for clearing these facts and sorry for mail sent only to you by mistake. -- Thanks & Regards, Amit Bondwal On Fri, Jul 17, 2015 at 6:19 PM, Craig Ringer wrote: > On 17 July 2015 at 19:37, Amit Bondwal wrote: > > Thank you very much all of you for quick response and clearing my mind. > > Please reply to the mailing list, not just to me directly. > > > One more question, can I run a databse of postgres 9.4 on postgres-XL > > cluster? > > postgres-XL is based on PostgreSQL 9.2, so no. > > Postgres-XL doesn't "run on" PostgreSQL. It's a modified (forked) > version of PostgreSQL. > > > Or you can advise me any better solution. > > Not without knowing a lot more about what you're trying to do, what > your requirements are, etc. > > > As per my knowledge partitioning > > of a table have some limits in nos. and I can't extend more storage in a > > server upto a limit. > > Yes, that's true, but those limits are quite large, and you may be > trying to solve a problem you don't and won't have. > > This may well be premature optimisation. I can't know without a lot more > info. > > Rather than starting with the solution (horizontal partitioning, > sharding) try starting with the problem and requirements, then looking > for solutions from there. > > -- > Craig Ringer http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services >
Re: [GENERAL] Backup fatal issue
I think we need just a little bit more information.
What is the O/S?
What is the PostgreSQL version?
What is the backup command?
Does this always occur with the same command?
Did you need to restarrt PostgreSQL after this started?
On Fri, Jul 17, 2015 at 3:29 AM, mephysto wrote:
> Hi there,
> I have some problems in a postgres cluster when I try to execute a backup.
> This is the log of entire operation:
>
> LOG: connection received: host=91.121.182.110 port=54957
> LOG: connection authorized: user=postgres database=postgres
> LOG: statement: BEGIN
> LOG: statement: SET application_name TO barman
> LOG: statement: SHOW "data_directory"
> LOG: connection received: host=91.121.182.110 port=54958
> LOG: connection authorized: user=postgres database=postgres
> LOG: statement: BEGIN
> LOG: statement: SET application_name TO barman
> LOG: statement: SELECT name, setting FROM pg_settings WHERE name IN
> ('config_file', 'hba_file', 'ident_file')
> LOG: connection received: host=91.121.182.110 port=54959
> LOG: connection authorized: user=postgres database=postgres
> LOG: statement: BEGIN
> LOG: statement: SET application_name TO barman
> LOG: statement: SELECT spcname, oid, pg_tablespace_location(oid) AS
> spclocation FROM pg_tablespace WHERE pg_tablespace_location(oid) != ''
> LOG: connection received: host=91.121.182.110 port=54960
> LOG: connection authorized: user=postgres database=postgres
> LOG: statement: BEGIN
> LOG: statement: SET application_name TO barman
> LOG: statement: select pg_is_in_recovery()
> LOG: statement: SELECT xlog_loc, (pg_xlogfile_name_offset(xlog_loc)).*,
> now() FROM pg_start_backup('Barman backup redevodb_citrix
> 20150717T091702',false) as xlog_loc
> LOG: connection received: host=91.121.182.110 port=54988
> FATAL: semctl(983046, 3, SETVAL, 0) failed: Invalid argument
> LOG: server process (PID 1756) exited with exit code 1
> LOG: terminating any other active server processes
> WARNING: terminating connection because of crash of another server process
> DETAIL: The postmaster has commanded this server process to roll back the
> current transaction and exit, because another server process exited
> abnormally and possibly corrupted shared memory.
> HINT: In a moment you should be able to reconnect to the database and
> repeat your command.
> LOG: all server processes terminated; reinitializing
> LOG: could not remove shared memory segment "/PostgreSQL.1804289383": No
> such file or directory
> LOG: semctl(786432, 0, IPC_RMID, ...) failed: Invalid argument
> LOG: semctl(819201, 0, IPC_RMID, ...) failed: Invalid argument
> LOG: semctl(851970, 0, IPC_RMID, ...) failed: Invalid argument
> LOG: semctl(884739, 0, IPC_RMID, ...) failed: Invalid argument
> LOG: semctl(917508, 0, IPC_RMID, ...) failed: Invalid argument
> LOG: semctl(950277, 0, IPC_RMID, ...) failed: Invalid argument
> LOG: semctl(983046, 0, IPC_RMID, ...) failed: Invalid argument
> LOG: semctl(1015815, 0, IPC_RMID, ...) failed: Invalid argument
> LOG: database system was interrupted; last known up at 2015-07-17 09:18:10
> CEST
> LOG: redo starts at 16/9F28
> LOG: record with zero length at 16/9F000100
> LOG: redo done at 16/9FC8
> LOG: MultiXact member wraparound protections are now enabled
> LOG: database system is ready to accept connections
> LOG: autovacuum launcher started
>
> Can anyone help me to identify and to resolve this inconvenience?
>
> Thanks in advance.
>
> Meph
>
>
>
> --
> View this message in context:
> http://postgresql.nabble.com/Backup-fatal-issue-tp5858258.html
> Sent from the PostgreSQL - general mailing list archive at Nabble.com.
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
--
*Melvin Davidson*
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.
Re: [GENERAL] Getting error "IST FATAL: the database system is in recovery mode"
On Fri, Jul 17, 2015 at 9:47 PM, Sachin Srivastava wrote: > I am getting the below error in my database pg_log file and also I am unable > to open the database. > "IST FATAL: the database system is in recovery mode" > I am using postgresql version 9.1 on Centos 6.6. Kindly suggest why this > problem is coming. You are trying to connect to a system that is performing a crash recovery, meaning that it crashed, and you cannot connect to it, or this is a standby node that is not set up as a read-only hot standby. -- Michael -- 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] Getting error "IST FATAL: the database system is in recovery mode"
On 07/17/2015 05:47 AM, Sachin Srivastava wrote: Dear Team, I am getting the below error in my database pg_log file and also I am unable to open the database. "IST FATAL: the database system is in recovery mode" I am using postgresql version 9.1 on Centos 6.6. Kindly suggest why this problem is coming. More information is needed. Postgres version? Do you have replication set up and if so which server are you trying to connect to? If not then the information that would help would be in the log before the line you show above. So what do you see earlier in the log? Regards, Sachin -- Adrian Klaver adrian.kla...@aklaver.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] Promoting 1 of 2 slaves
Hello, I am getting ready to take my master server out of service today and promote the slave to take it's place. In my current setup I have one master server which ships WAL files to two separate slave servers. My plan is to promote one of those slaves. How do I get the slave that I promoted to start replicating to the other slave the moment I trigger it's promotion? Thanks, -Joseph Kregloh
Re: [GENERAL] Backup fatal issue
Hi Melvin,
I am using Pstgres 9.4.4 in a virtualized Debian Linux 8.0. I do not know
backup command because is launched by BARMAN 1.4.1. I have tried many times
to execute the backup. I have restarted and reinstalled Postgres and I also
rebooted OS many times.
Thanks for your help.
Meph
On 17 July 2015 at 15:12, Melvin Davidson wrote:
> I think we need just a little bit more information.
>
> What is the O/S?
> What is the PostgreSQL version?
> What is the backup command?
> Does this always occur with the same command?
> Did you need to restarrt PostgreSQL after this started?
>
>
>
> On Fri, Jul 17, 2015 at 3:29 AM, mephysto
> wrote:
>
>> Hi there,
>> I have some problems in a postgres cluster when I try to execute a backup.
>> This is the log of entire operation:
>>
>> LOG: connection received: host=91.121.182.110 port=54957
>> LOG: connection authorized: user=postgres database=postgres
>> LOG: statement: BEGIN
>> LOG: statement: SET application_name TO barman
>> LOG: statement: SHOW "data_directory"
>> LOG: connection received: host=91.121.182.110 port=54958
>> LOG: connection authorized: user=postgres database=postgres
>> LOG: statement: BEGIN
>> LOG: statement: SET application_name TO barman
>> LOG: statement: SELECT name, setting FROM pg_settings WHERE name IN
>> ('config_file', 'hba_file', 'ident_file')
>> LOG: connection received: host=91.121.182.110 port=54959
>> LOG: connection authorized: user=postgres database=postgres
>> LOG: statement: BEGIN
>> LOG: statement: SET application_name TO barman
>> LOG: statement: SELECT spcname, oid, pg_tablespace_location(oid) AS
>> spclocation FROM pg_tablespace WHERE pg_tablespace_location(oid) != ''
>> LOG: connection received: host=91.121.182.110 port=54960
>> LOG: connection authorized: user=postgres database=postgres
>> LOG: statement: BEGIN
>> LOG: statement: SET application_name TO barman
>> LOG: statement: select pg_is_in_recovery()
>> LOG: statement: SELECT xlog_loc, (pg_xlogfile_name_offset(xlog_loc)).*,
>> now() FROM pg_start_backup('Barman backup redevodb_citrix
>> 20150717T091702',false) as xlog_loc
>> LOG: connection received: host=91.121.182.110 port=54988
>> FATAL: semctl(983046, 3, SETVAL, 0) failed: Invalid argument
>> LOG: server process (PID 1756) exited with exit code 1
>> LOG: terminating any other active server processes
>> WARNING: terminating connection because of crash of another server
>> process
>> DETAIL: The postmaster has commanded this server process to roll back the
>> current transaction and exit, because another server process exited
>> abnormally and possibly corrupted shared memory.
>> HINT: In a moment you should be able to reconnect to the database and
>> repeat your command.
>> LOG: all server processes terminated; reinitializing
>> LOG: could not remove shared memory segment "/PostgreSQL.1804289383": No
>> such file or directory
>> LOG: semctl(786432, 0, IPC_RMID, ...) failed: Invalid argument
>> LOG: semctl(819201, 0, IPC_RMID, ...) failed: Invalid argument
>> LOG: semctl(851970, 0, IPC_RMID, ...) failed: Invalid argument
>> LOG: semctl(884739, 0, IPC_RMID, ...) failed: Invalid argument
>> LOG: semctl(917508, 0, IPC_RMID, ...) failed: Invalid argument
>> LOG: semctl(950277, 0, IPC_RMID, ...) failed: Invalid argument
>> LOG: semctl(983046, 0, IPC_RMID, ...) failed: Invalid argument
>> LOG: semctl(1015815, 0, IPC_RMID, ...) failed: Invalid argument
>> LOG: database system was interrupted; last known up at 2015-07-17
>> 09:18:10
>> CEST
>> LOG: redo starts at 16/9F28
>> LOG: record with zero length at 16/9F000100
>> LOG: redo done at 16/9FC8
>> LOG: MultiXact member wraparound protections are now enabled
>> LOG: database system is ready to accept connections
>> LOG: autovacuum launcher started
>>
>> Can anyone help me to identify and to resolve this inconvenience?
>>
>> Thanks in advance.
>>
>> Meph
>>
>>
>>
>> --
>> View this message in context:
>> http://postgresql.nabble.com/Backup-fatal-issue-tp5858258.html
>> Sent from the PostgreSQL - general mailing list archive at Nabble.com.
>>
>>
>> --
>> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-general
>>
>
>
>
> --
> *Melvin Davidson*
> I reserve the right to fantasize. Whether or not you
> wish to share my fantasy is entirely up to you.
>
Re: [GENERAL] Backup fatal issue
If this is occurring with Barman, try doing a manual backup.
IE: pg_dump your_database > /tmp/somefile.sql
If that works, then the problem is with Barman or it's configuration.
On Fri, Jul 17, 2015 at 10:07 AM, Mephysto wrote:
> Hi Melvin,
> I am using Pstgres 9.4.4 in a virtualized Debian Linux 8.0. I do not know
> backup command because is launched by BARMAN 1.4.1. I have tried many times
> to execute the backup. I have restarted and reinstalled Postgres and I also
> rebooted OS many times.
>
> Thanks for your help.
>
> Meph
>
> On 17 July 2015 at 15:12, Melvin Davidson wrote:
>
>> I think we need just a little bit more information.
>>
>> What is the O/S?
>> What is the PostgreSQL version?
>> What is the backup command?
>> Does this always occur with the same command?
>> Did you need to restarrt PostgreSQL after this started?
>>
>>
>>
>> On Fri, Jul 17, 2015 at 3:29 AM, mephysto
>> wrote:
>>
>>> Hi there,
>>> I have some problems in a postgres cluster when I try to execute a
>>> backup.
>>> This is the log of entire operation:
>>>
>>> LOG: connection received: host=91.121.182.110 port=54957
>>> LOG: connection authorized: user=postgres database=postgres
>>> LOG: statement: BEGIN
>>> LOG: statement: SET application_name TO barman
>>> LOG: statement: SHOW "data_directory"
>>> LOG: connection received: host=91.121.182.110 port=54958
>>> LOG: connection authorized: user=postgres database=postgres
>>> LOG: statement: BEGIN
>>> LOG: statement: SET application_name TO barman
>>> LOG: statement: SELECT name, setting FROM pg_settings WHERE name IN
>>> ('config_file', 'hba_file', 'ident_file')
>>> LOG: connection received: host=91.121.182.110 port=54959
>>> LOG: connection authorized: user=postgres database=postgres
>>> LOG: statement: BEGIN
>>> LOG: statement: SET application_name TO barman
>>> LOG: statement: SELECT spcname, oid, pg_tablespace_location(oid) AS
>>> spclocation FROM pg_tablespace WHERE pg_tablespace_location(oid) != ''
>>> LOG: connection received: host=91.121.182.110 port=54960
>>> LOG: connection authorized: user=postgres database=postgres
>>> LOG: statement: BEGIN
>>> LOG: statement: SET application_name TO barman
>>> LOG: statement: select pg_is_in_recovery()
>>> LOG: statement: SELECT xlog_loc, (pg_xlogfile_name_offset(xlog_loc)).*,
>>> now() FROM pg_start_backup('Barman backup redevodb_citrix
>>> 20150717T091702',false) as xlog_loc
>>> LOG: connection received: host=91.121.182.110 port=54988
>>> FATAL: semctl(983046, 3, SETVAL, 0) failed: Invalid argument
>>> LOG: server process (PID 1756) exited with exit code 1
>>> LOG: terminating any other active server processes
>>> WARNING: terminating connection because of crash of another server
>>> process
>>> DETAIL: The postmaster has commanded this server process to roll back
>>> the
>>> current transaction and exit, because another server process exited
>>> abnormally and possibly corrupted shared memory.
>>> HINT: In a moment you should be able to reconnect to the database and
>>> repeat your command.
>>> LOG: all server processes terminated; reinitializing
>>> LOG: could not remove shared memory segment "/PostgreSQL.1804289383": No
>>> such file or directory
>>> LOG: semctl(786432, 0, IPC_RMID, ...) failed: Invalid argument
>>> LOG: semctl(819201, 0, IPC_RMID, ...) failed: Invalid argument
>>> LOG: semctl(851970, 0, IPC_RMID, ...) failed: Invalid argument
>>> LOG: semctl(884739, 0, IPC_RMID, ...) failed: Invalid argument
>>> LOG: semctl(917508, 0, IPC_RMID, ...) failed: Invalid argument
>>> LOG: semctl(950277, 0, IPC_RMID, ...) failed: Invalid argument
>>> LOG: semctl(983046, 0, IPC_RMID, ...) failed: Invalid argument
>>> LOG: semctl(1015815, 0, IPC_RMID, ...) failed: Invalid argument
>>> LOG: database system was interrupted; last known up at 2015-07-17
>>> 09:18:10
>>> CEST
>>> LOG: redo starts at 16/9F28
>>> LOG: record with zero length at 16/9F000100
>>> LOG: redo done at 16/9FC8
>>> LOG: MultiXact member wraparound protections are now enabled
>>> LOG: database system is ready to accept connections
>>> LOG: autovacuum launcher started
>>>
>>> Can anyone help me to identify and to resolve this inconvenience?
>>>
>>> Thanks in advance.
>>>
>>> Meph
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://postgresql.nabble.com/Backup-fatal-issue-tp5858258.html
>>> Sent from the PostgreSQL - general mailing list archive at Nabble.com.
>>>
>>>
>>> --
>>> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>>> To make changes to your subscription:
>>> http://www.postgresql.org/mailpref/pgsql-general
>>>
>>
>>
>>
>> --
>> *Melvin Davidson*
>> I reserve the right to fantasize. Whether or not you
>> wish to share my fantasy is entirely up to you.
>>
>
>
--
*Melvin Davidson*
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.
Re: [GENERAL] Backup fatal issue
mephysto writes: > I have some problems in a postgres cluster when I try to execute a backup. > ... > FATAL: semctl(983046, 3, SETVAL, 0) failed: Invalid argument > ... > LOG: could not remove shared memory segment "/PostgreSQL.1804289383": No > such file or directory > LOG: semctl(786432, 0, IPC_RMID, ...) failed: Invalid argument > LOG: semctl(819201, 0, IPC_RMID, ...) failed: Invalid argument > LOG: semctl(851970, 0, IPC_RMID, ...) failed: Invalid argument > LOG: semctl(884739, 0, IPC_RMID, ...) failed: Invalid argument > LOG: semctl(917508, 0, IPC_RMID, ...) failed: Invalid argument > LOG: semctl(950277, 0, IPC_RMID, ...) failed: Invalid argument > LOG: semctl(983046, 0, IPC_RMID, ...) failed: Invalid argument > LOG: semctl(1015815, 0, IPC_RMID, ...) failed: Invalid argument Assuming you didn't manually destroy the shared memory segment and semaphores, the only very likely explanation for this is that another postmaster instance started up, used the same memory and semaphore IDs, and then removed them when it shut down. This should be impossible given the interlocks around shared memory segment creation and use of a data directory; but it's possible to break those interlocks if you try hard enough. I speculate that you've got a postmaster-startup script that unconditionally removes the postmaster.pid lock file before starting the postmaster, and that your backup procedure or some other routine action is invoking that even when there might be a live postmaster already. If so, the answer is simple: get rid of the script's attempt to remove the lock file. And have a word with whoever put it in. *Nothing* except the postmaster's own code should *ever* remove postmaster.pid. 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] conn = PQconnectdb(conninfo);
Hi, Every now and then my program will abort. IAnd this is because: conn = PQconnectdb(conninfo); The error given: *** Error in `./server_prog': malloc(): smallbin double linked list corrupted: 0x092c10a0 *** Any thoughts on why I'm getting this message? Regards, Peter
Re: [GENERAL] conn = PQconnectdb(conninfo);
Peter Kroon writes: > Every now and then my program will abort. > IAnd this is because: conn = PQconnectdb(conninfo); > The error given: > *** Error in `./server_prog': malloc(): smallbin double linked list > corrupted: 0x092c10a0 *** This looks like malloc() complaining because something has corrupted its bookkeeping data, which generally means that something previously wrote past the end of a malloc'd data chunk, or tried to write into an already-freed chunk. The odds are very high that the bug is in your program rather than libpq, though, because no such problems have been found within libpq recently. valgrind is a fairly useful tool for tracking down such issues. 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
