[GENERAL] Drop or alter column under load give ERROR #42804 structure of query does not match function result type:

I have a heavily used PostgreSQL 9.3.5 database on CentOS 6. Sometimes I need to add/remove columns, preferably without any service interruptions, but I get temporary errors. I follow the safe operations list from https://www.braintreepayments.com/blog/safe-operations-for-high-volume-postgresql bu

Re: [GENERAL] BDR: no free replication state could be found

On 9 October 2015 at 06:54, Selim Tuvi wrote: > Hi I am testing BDR functionality with Postgres 9.4. I had went through the > bdrdemo example with a 3 node cluster and then tried to set up my own db. > > My "max_replication_slots" is set to 6. After getting removing the bdrdemo > db I am having tr

[GENERAL] BDR: no free replication state could be found

Hi I am testing BDR functionality with Postgres 9.4. I had went through the bdrdemo example with a 3 node cluster and then tried to set up my own db. My "max_replication_slots" is set to 6. After getting removing the bdrdemo db I am having trouble starting up the postgres instance unless I incre

[GENERAL] Version management for extensions

I am facing a scenario where I have different version of an extension, say 1.0 and 2.0, which have some different functionality between them (so not merely a bug fix), so people might want to continue to use 1.0. But changes to the PostgreSQL software between major versions requires changes to the

Re: [GENERAL] Best practices for aggregate table design

Nabble has a "quote" feature - please use it. On Thu, Oct 8, 2015 at 5:00 PM, droberts wrote: > I haven't but wouldn't it be better to wait and just add new columns > if/when > I need to? > ​Its worth keeping in the back of your mind but I tend to think that choosing hstore in order to "be flex

Re: [GENERAL] Best practices for aggregate table design

I haven't but wouldn't it be better to wait and just add new columns if/when I need to? -- View this message in context: http://postgresql.nabble.com/Best-practices-for-aggregate-table-design-tp5868940p5869372.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Se

Re: [GENERAL] blank in query - cannot return results

On Thu, Oct 8, 2015 at 3:54 PM, Emi wrote: > But run: >> select * from table_name where col1 ilike '%Abc,%test%'; -- remove blank >> >> Result is returned. >> > ​It works. WITH vals (v) AS ( VALUES ('Abc, test'::text) ) SELECT * FROM vals WHERE v ILIKE '%Abc, test%'​ If you are expecting a ma

Re: [GENERAL] postgres standby won't start

On 10/08/2015 08:27 AM, Ramalingam, Sankarakumar wrote: Yes it is and Yes I do have the recovery file. I would suggest you and the other folks involved take a look here: http://www.postgresql.org/docs/9.4/interactive/warm-standby.html It will go a long way to explaining what you are seeing a

Re: [GENERAL] blank in query - cannot return results

On 10/08/2015 12:51 PM, Emi wrote: Hello, PostgreSQL 8.3.18 on x86_64-linux-gnu, query: select * from table_name where col1 ='Abc, test'; select * from table_name where col1 ilike '%Abc, test%'; NO result returned. Well without an indication of what the value in col1 is this is not goi

Re: [GENERAL] blank in query - cannot return results

Hello, PostgreSQL 8.3.18 on x86_64-linux-gnu, query: select * from table_name where col1 ='Abc, test'; select * from table_name where col1 ilike '%Abc, test%'; NO result returned. But run: select * from table_name where col1 ilike '%Abc,%test%'; -- remove blank Result is returned.

[GENERAL] blank in query - cannot return results

Hello, PostgreSQL 8.3.18 on x86_64-linux-gnu, query: select * from table_name where col1 ='Abc, test'; select * from table_name where col1 ilike '%Abc, test%'; NO result returned. But run: select * from table_name where col1 ilike '%Abc,%test%'; -- remove blank Result is returned.

Re: [GENERAL] dubious optimization of the function in SELECT INTO target list

Oleksii Kliukin wrote: > Thank you, now it’s clear. I have to say there is no guarantee that > the computation would be useless. Someone might be calling a function > that updates/deletes rows in the SELECT INTO block, being forced to > use SELECT INTO by inability of pl/pgSQL to just discard the

Re: [GENERAL] postgres standby won't start

Yes it is and Yes I do have the recovery file. Here is the scenario. It looks like the logs are not getting shipped over to the standby. After I dragged the WAL files from Primary to Standby and restarted, I see some successful recovery messages with the file names mentioned. Right now the stand

Re: [GENERAL] dubious optimization of the function in SELECT INTO target list

On 10/08/2015 01:57 AM, Oleksii Kliukin wrote: On 06 Oct 2015, at 23:31, Tom Lane mailto:t...@sss.pgh.pa.us>> wrote: Oleksii Kliukin mailto:al...@hintbits.com>> writes: This should work, but I'm interested in finding out why the original statement behaves the way I’ve described. plpgsql's S

Re: [GENERAL] postgres standby won't start

On 10/07/2015 10:01 PM, Ramalingam, Sankarakumar wrote: Hi Adrian, After a few attempts I used the following (without method=stream as it is not working on 9.1) and restored the DB on standby site successfully. The log says it is connecting to primary streaming replication successfully connecte

Re: [GENERAL] Issues with german locale on CentOS 5,6,7

Thomas Kellerer wrote: > I always thought that this is a major shortcoming (if not a bug) in Postgres > that the collation support is left to the OS. > > Because it essentially means that that exactly the same query with exactly > the same data might return a different result if run on d

Re: [GENERAL] Best practices for aggregate table design

On Thu, Oct 8, 2015 at 3:49 AM, wrote: > Is there an advantage of hstore vs. json/jsonb? > Definitely over json because that is not indexable. I'm not seeing an advantage over jsonb unless you want to prevent storing complex data structures.

Re: [GENERAL] dubious optimization of the function in SELECT INTO target list

> On 06 Oct 2015, at 23:31, Tom Lane wrote: > > Oleksii Kliukin writes: >> This should work, but I'm interested in finding out why the original >> statement behaves the way I’ve described. > > plpgsql's SELECT INTO is only capable of storing a single result row, > so it only executes the sta

Re: [GENERAL] dubious optimization of the function in SELECT INTO target list

> On 06 Oct 2015, at 23:11, Adrian Klaver wrote: > > On 10/06/2015 02:00 PM, Oleksii Kliukin wrote: >> >>> On 06 Oct 2015, at 22:50, Adrian Klaver >> > wrote: >>> >>> On 10/06/2015 01:48 PM, Oleksii Kliukin wrote: > On 06 Oct 2015, at 22:40, Adrian K

Re: [GENERAL] Best practices for aggregate table design

Thomas Kellerer writes: > droberts schrieb am 06.10.2015 um 20:53: >> Okay, so is it safe to say I should use loosely use these guidelines when >> deciding whether to model an attribute as a dimension >> (type=[inbound,outbound]) vs. bundling with a measure (total_inbound) ? >> >> If you know th