The problem is that I need not 3 rows but 136 rows. So "id=" is not
really an option. Tried putting each condition in brackets - but that
did not help either.
But you are right in that it looks like the NULL values are the problem.
Leaving that condition out both windows and linux server retur
On 29/04/13 19:09, Igor Neyman wrote:
>
>> -Original Message-
>> From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-
>> ow...@postgresql.org] On Behalf Of Lutz Fischer
>> Sent: Monday, April 29, 2013 1:52 PM
>> To: pgsql-general@postgresql.org
>> Subject: [GENERAL] Windows query
On 30/04/13 11:58, Lutz Fischer wrote:
> On 29/04/13 19:09, Igor Neyman wrote:
>>> -Original Message-
>>> From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-
>>> ow...@postgresql.org] On Behalf Of Lutz Fischer
>>> Sent: Monday, April 29, 2013 1:52 PM
>>> To: pgsql-general@postgr
> >
>
> Seems like REINDEX INDEX rescored; did the trick.
> Any idea how to find out whether a index is corrupted?
>
> --
> Lutz Fischer
> lfisc...@staffmail.ed.ac.uk
> +44 131 6517057
>
>
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC0
> -Original Message-
> From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-
> ow...@postgresql.org] On Behalf Of Igor Neyman
> Sent: Tuesday, April 30, 2013 9:30 AM
> To: Lutz Fischer; pgsql-general@postgresql.org
> Cc: Aaron Abreu
> Subject: Re: [GENERAL] Windows query weird r
v9.0.1 on linux
thedb=# select
||bicolumn||,
coalesce(permitted_values,'is_null'),
case permitted_values when NULL then 'null' else ||permitted_values||
end
from bi_constraints limit 2;
?column?| coalesce| case
+---+
On 30/04/13 14:49, Igor Neyman wrote:
>
>> -Original Message-
>> From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-
>> ow...@postgresql.org] On Behalf Of Igor Neyman
>> Sent: Tuesday, April 30, 2013 9:30 AM
>> To: Lutz Fischer; pgsql-general@postgresql.org
>> Cc: Aaron Abreu
>>
"Gauthier, Dave" writes:
> thedb=# select
> ||bicolumn||,
> coalesce(permitted_values,'is_null'),
> case permitted_values when NULL then 'null' else
> ||permitted_values|| end
>from bi_constraints limit 2;
That's equivalent to "case when permitted_values = NULL then ...
I'm currently working on a project porting an application from RedHat
Linux on Intel onto IBM zLinux. Our application requires PostgreSQL at
version 9.n, so the PostgreSQL binaries have been built using the
standard build tools from source. Everything appears run correctly.
However as part of p
Hi All,
As I'll soon be looking at migrating some of our debian servers onto the new
stable release, I've started doing a bit of basic pgbench testing.
Initially I've seen a little performance regression with higher concurrent
clients when going from the 2.6.32 kernel to 3.2.14 (select on
>
> From: Glyn Astill
>To: "pgsql-general@postgresql.org"
>Sent: Tuesday, 30 April 2013, 16:58
>Subject: [GENERAL] Newer kernels and CFS scheduler again
>
>Hi All,
>
>
>As I'll soon be looking at migrating some of our debian servers onto the new
>stable release,
On 04/30/2013 10:58 AM, Glyn Astill wrote:
kernel.sched_min_granularity_ns=900
kernel.sched_wakeup_granularity_ns=1200
I'll keep this in mind and do some testing when I get a chance. I think
I tried tweaking these and didn't get much of a return compared to the
migration cost, but th
On Tue, Apr 30, 2013 at 8:28 AM, Andrew Hastie wrote:
> I'm currently working on a project porting an application from RedHat
> Linux on Intel onto IBM zLinux. Our application requires PostgreSQL at
> version 9.n, so the PostgreSQL binaries have been built using the standard
> build tools from so
On Apr 27, 2013, at 10:40 AM, Yang Zhang wrote:
> My question really boils down to: if we're interested in using COW
> snapshotting (a common feature of modern filesystems and hosting
> environments), would we necessarily need to ensure the data and
> pg_xlog are on the same snapshotted volume? I
On Tue, Apr 30, 2013 at 12:26 PM, Jeff Janes wrote:
> On Tue, Apr 30, 2013 at 8:28 AM, Andrew Hastie wrote:
>>
>> I'm currently working on a project porting an application from RedHat
>> Linux on Intel onto IBM zLinux. Our application requires PostgreSQL at
>> version 9.n, so the PostgreSQL binar
Hi Tom,
>> There's nothing obviously wrong with that, which means the issue is in
something you didn't show us. Care to assemble a self-contained example?
<<
Unfortunately, it happens erratically and very, very rarely so I can't give
you something that will fail. I expected an occasional failure
On Apr 30, 2013, at 4:00 PM, "Carlo Stonebanks"
wrote:
> Hi Tom,
>
>>> There's nothing obviously wrong with that, which means the issue is in
> something you didn't show us. Care to assemble a self-contained example?
> <<
>
> Unfortunately, it happens erratically and very, very rarely so I c
"Carlo Stonebanks" writes:
> The only way I can see this happening is that an
> acache_mdx_logic_address_validation sneaks in before the insert and after
> the NOT EXISTS... SELECT. And for that to occur, the client must be mistaken
> and something else MUST be running and inserting into
> acache_
I would intuit that it's fine, but I just want to make sure there are
no gotchas from a recovery point of view:
If I were to lose my temp tablespace upon system crash, would this
prevent proper crash recovery?
Also, if I were to omit the temp tablespace from the base backup,
would that prevent pr
On 2013.04.30 4:55 PM, Yang Zhang wrote:
I would intuit that it's fine, but I just want to make sure there are
no gotchas from a recovery point of view:
If I were to lose my temp tablespace upon system crash, would this
prevent proper crash recovery?
Also, if I were to omit the temp tablespace
That is unfortunate. Good thing I asked, I guess. Do you have a
pointer to said blog post?
On Tue, Apr 30, 2013 at 5:31 PM, Darren Duncan wrote:
> On 2013.04.30 4:55 PM, Yang Zhang wrote:
>>
>> I would intuit that it's fine, but I just want to make sure there are
>> no gotchas from a recovery p
2013/5/1 Yang Zhang :
> On Tue, Apr 30, 2013 at 5:31 PM, Darren Duncan
> wrote:
>> On 2013.04.30 4:55 PM, Yang Zhang wrote:
>>>
>>> I would intuit that it's fine, but I just want to make sure there are
>>> no gotchas from a recovery point of view:
>>>
>>> If I were to lose my temp tablespace upo
On Tue, Apr 30, 2013 at 7:14 PM, Ian Lawrence Barwick wrote:
> 2013/5/1 Yang Zhang :
>
>> On Tue, Apr 30, 2013 at 5:31 PM, Darren Duncan
>> wrote:
>>> On 2013.04.30 4:55 PM, Yang Zhang wrote:
I would intuit that it's fine, but I just want to make sure there are
no gotchas from a r
When extracting DDL from a database, I note that the SQL for views is
extracted as a single line, not with the line spacing and indenting it was
created with. DbAdmin reformats the view, but other tools like DbVisualizer
have SQL formatting rules that don't reformat nicely - a lot of extra
parenthe
I should add that I am extracting DDL with "pg_dump -s", and the output of
\dv+ is nicely formatted without the extra parenthesis seen in the pg_dump
output.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Unformatted-view-DDL-in-pg-dump-tp5753856p5753858.html
Sent from
On 2013.04.30 7:14 PM, Ian Lawrence Barwick wrote:
2013/5/1 Yang Zhang :
On Tue, Apr 30, 2013 at 5:31 PM, Darren Duncan wrote:
On 2013.04.30 4:55 PM, Yang Zhang wrote:
I would intuit that it's fine, but I just want to make sure there are
no gotchas from a recovery point of view:
If I were
Ian Lawrence Barwick writes:
> 2013/5/1 Yang Zhang :
>> That is unfortunate. Good thing I asked, I guess. Do you have a
>> pointer to said blog post?
> I think this is the post in question:
> http://thebuild.com/blog/2013/03/10/you-cannot-recover-from-the-loss-of-a-tablespace/
Appears to be sh
Hi
I want to keep one slave node along with our production master server, but
that slave node only accept all the DML except Delete queries.
Primary purpose of this slave node is to keep all the data inserted to the
primary database and no need to delete any data from that.
Anybody know how to
Is there anyone knows about this question made by Alain if its possible to work
with PostgreSQL with tuxedo, someone could help me.
BR
Ramiro Arraya
Mediation Architect
Mobile (BO): +591 70305291
skype: ramiro.arraya
[cid:image001.png@01CE4585.88D79600]
www.TrilogySoftwareBolivia.co
On 01/05/13 12:36, Yang Zhang wrote:
> On Tue, Apr 30, 2013 at 7:21 PM, Julian Glass
> wrote:
>> On 01/05/13 09:55, Yang Zhang wrote:
>>> I would intuit that it's fine, but I just want to make sure there are
>>> no gotchas from a recovery point of view:
>>>
>>> If I were to lose my temp tablespac
On Tue, Apr 30, 2013 at 8:13 PM, Tom Lane wrote:
> Ian Lawrence Barwick writes:
>> 2013/5/1 Yang Zhang :
>>> That is unfortunate. Good thing I asked, I guess. Do you have a
>>> pointer to said blog post?
>
>> I think this is the post in question:
>> http://thebuild.com/blog/2013/03/10/you-canno
On Tue, Apr 30, 2013 at 8:13 PM, Tom Lane wrote:
> Ian Lawrence Barwick writes:
>> 2013/5/1 Yang Zhang :
>>> That is unfortunate. Good thing I asked, I guess. Do you have a
>>> pointer to said blog post?
>
>> I think this is the post in question:
>> http://thebuild.com/blog/2013/03/10/you-canno
You know what I think Postgres needs? Its an official way to declare a
tablespace in a special way that marks the whole tablespace as being
temporary/volatile, so that whenever the server starts/recovers, it assumes this
tablespace doesn't exist or may not exist and can reinitialize it without
On Tue, Apr 30, 2013 at 11:14 PM, Yang Zhang wrote:
> On Tue, Apr 30, 2013 at 8:13 PM, Tom Lane wrote:
>> Ian Lawrence Barwick writes:
>>> I think this is the post in question:
>>> http://thebuild.com/blog/2013/03/10/you-cannot-recover-from-the-loss-of-a-tablespace/
>>
>> Appears to be sheer bla
34 matches
Mail list logo
