Re: [GENERAL] what database schema version management system to use?

On Fri, Apr 08, 2016 at 09:09:22AM -0500, Merlin Moncure wrote: > I rolled my own in bash. It wasn't that difficult. The basic tactic is to: > > *) separate .sql that can be re-applied (views, functions, scratch tables, > etc) from .sql that can't be re-applied (create table, index,

Re: [GENERAL] max_stack_depth problem though query is substantially smaller

"Bannert Matthias" writes: > Thanks for your reply. I do think it is rather a postgres than an R issue, > here's why: > a) R simply puts an SQL string together. What Charles had posted was an > excerpt of that string. > Basically we have 1.7 MB of that string. Everything

[GENERAL] pg_upgrade with an extension name change

I'm attempting to upgrade a database from 9.2 to 9.5 using pg_upgrade. The 9.2 database has the "orafunc" extension installed, which appears to have changed names to "orafce". pg_upgrade complains that it can't find "orafunc" on 9.5, which is true. Is there a standard way of handling this

Re: [GENERAL] max_stack_depth problem though query is substantially smaller

Thanks for your reply. I do think it is rather a postgres than an R issue, here's why: a) R simply puts an SQL string together. What Charles had posted was an excerpt of that string. Basically we have 1.7 MB of that string. Everything else is equal just the hstore contains 40K key value

Re: [GENERAL] pg_upgrade error regarding hstore operator

Thanks for the reply Tom. template1 is definitely empty and does not contain any hstore objects. I did a little debugging and placed the below SQL before and after the hstore creation in the file produced by the pg_dump and determined that these operator objects only become present immediately

Re: [GENERAL] Bypassing NULL elements in row_to_json function

It looks like json_strip_nulls() may be what I need, I'm currently on 9.3, which doesn't have that function but may be in a position to upgrade to 9.5 this summer. I think the apps that would be receiving the data can deal with any resulting 'holes' in the data set by just setting them to null.

Re: [GENERAL] recover from this error

On Fri, Apr 8, 2016 at 11:44 AM, Scott Ribe wrote: > Alright, check kernel version, but what else, dump & restore? > > ERROR: unexpected data beyond EOF in block 1 of relation base/16388/35954 > HINT: This has been seen to occur with buggy kernels; consider

Re: [GENERAL] Postgresql 9.3.4 file system compatibility

On 4/8/2016 7:20 AM, Scott Mead wrote: I'm not sure if that link exists, the general rule is In g if it's POSIX, it'll work. You'll find that most PostgreSQL-ers have strong opinions and preferences in regards to filesystems. Personally, I know that XFS will work, it's not *my* preference,

Re: [GENERAL] Transitioning to a SQL db

On 04/08/2016 08:04 AM, Karl O. Pinc wrote: Hi Tim, As arranged I am cc-ing the pgsql-general list in the hope they will assist. Your posts to the list may be delayed for moderation, I can't say. It could be helpful if you subscribed to the list, but it is relatively high traffic and I know

Re: [GENERAL] Bypassing NULL elements in row_to_json function

On 04/08/2016 08:31 AM, Michael Nolan wrote: I'm looking at the possibility of using JSON as a data exchange format with some apps running on both PCs and Macs. . The table I would be exporting has a lot of NULL values in it. Is there any way to skip the NULL values in the row_to_json

Re: [GENERAL] Bypassing NULL elements in row_to_json function

On Fri, Apr 8, 2016 at 8:53 AM, Raymond O'Donnell wrote: > On 08/04/2016 16:31, Michael Nolan wrote: > > I'm looking at the possibility of using JSON as a data exchange format > > with some apps running on both PCs and Macs. . > > > > The table I would be exporting has a lot of

Re: [GENERAL] Bypassing NULL elements in row_to_json function

On 08/04/2016 16:31, Michael Nolan wrote: > I'm looking at the possibility of using JSON as a data exchange format > with some apps running on both PCs and Macs. . > > The table I would be exporting has a lot of NULL values in it. Is > there any way to skip the NULL values in the row_to_json

[GENERAL] recover from this error

Alright, check kernel version, but what else, dump & restore? ERROR: unexpected data beyond EOF in block 1 of relation base/16388/35954 HINT: This has been seen to occur with buggy kernels; consider updating your system. -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/

[GENERAL] Bypassing NULL elements in row_to_json function

I'm looking at the possibility of using JSON as a data exchange format with some apps running on both PCs and Macs. . The table I would be exporting has a lot of NULL values in it. Is there any way to skip the NULL values in the row_to_json function and include only the fields that are

Re: [GENERAL] Transitioning to a SQL db

Hi Tim, As arranged I am cc-ing the pgsql-general list in the hope they will assist. Your posts to the list may be delayed for moderation, I can't say. It could be helpful if you subscribed to the list, but it is relatively high traffic and I know you have extremely limited and expensive

Re: [GENERAL] max_stack_depth problem though query is substantially smaller

"Charles Clavadetscher" writes: > When R processes the daily time serie we get a stack size exceeded error, followed by the hint to increase the max_stack_depth. Postgres doesn't generally allocate large values on the stack, and I doubt that R does either. Almost

Re: [GENERAL] Postgresql 9.3.4 file system compatibility

On Fri, Apr 8, 2016 at 9:16 AM, Marllius wrote: > thank you, but i need a link in official postgresql documentation > I'm not sure if that link exists, the general rule is In g if it's POSIX, it'll work. You'll find that most PostgreSQL-ers have strong opinions and

Re: [GENERAL] what database schema version management system to use?

On Wed, Apr 6, 2016 at 5:55 AM, Alexey Bashtanov wrote: > Hi all, > > I am searching for a proper database schema version management system. > > My criteria are the following: > 0) Open-source, supports postgresql > 1) Uses psql to execute changesets (to have no problems with

Re: [GENERAL] Postgresql 9.3.4 file system compatibility

thank you, but i need a link in official postgresql documentation OCFS2 = oracle cluster file system 2 2016-04-08 10:00 GMT-03:00 Bob Lunney : > XFS absolutely does. Its well supported on Redhat and CentOS 6.x and > 7.x. Highly recommended. > > Don’t know about OCFS2. > >

Re: [GENERAL] Postgresql 9.3.4 file system compatibility

XFS absolutely does. Its well supported on Redhat and CentOS 6.x and 7.x. Highly recommended. Don’t know about OCFS2. Bob Lunney Lead Data Architect MeetMe, Inc. > On Apr 8, 2016, at 8:56 AM, Marllius wrote: > > Hi guys! > > The OCFS2 and XFS have compatibility with

[GENERAL] Postgresql 9.3.4 file system compatibility

Hi guys! The OCFS2 and XFS have compatibility with postgresql 9.3.4? I was looking the documentation but i not found it.

Re: [GENERAL] max_stack_depth problem though query is substantially smaller

Charles Clavadetscher wrote: > We have a process in R which reads statistical raw data from a table and > computes time series values > from them. > The time series values are in a hstore field with the date as the key and the > value as the value. > The process writes the computed value into a

Re: [GENERAL] Please let me know the latest PostgreSQL version available on Solaris 11?

On 08/04/2016 11:50, M Tarkeshwar Rao wrote: > Hi all, > > > > Please let me know the latest PostgreSQL version available on Solaris 11? > > > > Which PostgreSQL version will be supported on Solaris 11.x version and > when the same will be available ?

[GENERAL] Please let me know the latest PostgreSQL version available on Solaris 11?

Hi all, Please let me know the latest PostgreSQL version available on Solaris 11? Which PostgreSQL version will be supported on Solaris 11.x version and when the same will be available ? Regards Tarkeshwar

[GENERAL] max_stack_depth problem though query is substantially smaller

Hello We have a process in R which reads statistical raw data from a table and computes time series values from them. The time series values are in a hstore field with the date as the key and the value as the value. The process writes the computed value into a temporary table and locks the

[GENERAL] Shipping big WAL archives to hot standby

I'm looking to extend my PostgreSQL 9.4 master with a few slaves in hot standby read-only for load balancing. The idea would be to update the slaves only at defined times (once every 24/48 hours) to avoid migration issues with the application server code and also because the "freshness" of

Re: [GENERAL] Trying to understand page structures in PG

Rakesh Kumar wrote: >> Every row has two system columns associated with it: xmin and xmax >> >> xmin is the transaction ID that created the row, while xmax is >> the transaction ID that removed the row. >> >> So when an update takes place, xmax of the original row and xmin >> of the new row are

Re: [GENERAL] Trying to understand page structures in PG

Jeff Janes wrote: >> I am curious because of "while xmax is the transaction ID that >> *removed* the row". > > "marked for removal" would be more accurate. If the row were actually > physically removed, it would no longer have a xmax to set. Yes, thanks for the clarification. I was thinking