Hi,
I have attempted to upgrade my Postgres installation this morning from 9.0.1 to
9.2.0 and it failed with an out of memory problem using pg_dumpall to dump the
first database.
So after backing out the change and restarting level 9.0.1, I've done some
basic investigation into the failure of
On Wed, Sep 19, 2012 at 11:15 PM, David Johnston wrote:
> I could maybe see something like the following having some value:
>
> SELECT inverse
> FROM data
> WHERE x<>0 AND inverse > .5
> MACRO inverse (1/x)
>
WITH macros AS (SELECT *,1/x AS inverse FROM data) SELECT inverse FROM
macros WHERE x<>0
On 09/20/2012 05:37 AM, Lucas Clemente Vella wrote:
I am trying to write a generic "upsert" function in PL/pgSQL, in a way
that I can specify the table were I want to insert/update, the columns
whose values I want to specify, and the values to be inserted.
http://www.depesz.com/2012/06/10/why-i
On 09/20/2012 01:01 AM, Ivan Voras wrote:
Hello,
Actually I have sort of two questions rolled into one: when creating
custom data types, there's the option to implement *_send() and *_recv()
functions in addition to *_in() and *_out(); does pg_dump use them for
binary dumps, and, if not, what us
Hi all
I'm wondering if there's any way to convince `to_char` to add a leading
zero to the hours in negative intervals. The current behaviour feels
wrong, in that FMHH24:MM and HH24:MM produce the same output for
negative intervals:
regress=# WITH x(i) AS (VALUES (INTERVAL '9:00'),(INTERV
I am trying to write a generic "upsert" function in PL/pgSQL, in a way
that I can specify the table were I want to insert/update, the columns
whose values I want to specify, and the values to be inserted.
So far I have come up with a solution whose signature is:
CREATE OR REPLACE FUNCTION upsert(
On 20/09/12 03:08, Merlin Moncure wrote:
On Tue, Sep 18, 2012 at 7:47 PM, David Johnston wrote:
>On Sep 18, 2012, at 20:21, Jean-Christophe Boggio
wrote:
>
>>I'm looking for an article that explains the difference between these
constructs IN POSTGRESQL (the rules seem to differ from one DB
Comments embedded between
>
> David,
>
> Thanks for the verbose explanations, really useful.
>
> However, in my case :
> - type is never NULL
Assuming you mean the "og.type" (i.e., the right-side of the join) even
though the column
David,
Thanks for the verbose explanations, really useful.
However, in my case :
- type is never NULL
- there are no lines from uidinoldgroups that match the "FROM ldap" join.
But I think I got it :
drop table if exists tmpA;
drop table if exists tmpB;
create temp table tmpA (name varchar);
in
Had a simple function calling another function, and the final function
was doing raise log.
When I enabled normal stderr logging, with absurdly full
log_line_prefix, I got this:
#v+
a[psql] u[depesz] d[depesz] r[[local]] h[[local]] p[15444] t[2012-09-13
21:49:37 CEST] m[2012-09-13 21:49:37.840 C
On Tue, 2012-09-18 at 18:39 -0400, Tom Lane wrote:
> Rafal Pietrak writes:
> > postmaster/postmaster.o: In function `PostmasterMain':^M
> > postmaster.c:(.text+0x4bc8): undefined reference to `optreset'^M
> > tcop/postgres.o: In function `process_postgres_switches':^M
> > postgres.c:(.text+0x1422)
Performance.
On our production DB the fast-archiver transfers the datadir in about half
as much time as basebackup.
And since this happens on every failover (since clearing the datadir and
resyncing as if from scratch also takes about half the time as a rsync of
an existing datadir)
--Mike
On
Just curious, is there a reason why you can't use pg_basebackup ?
On Wed, Sep 19, 2012 at 12:27 PM, Mike Roest wrote:
>
>> Is there any hidden issue with this that we haven't seen. Or does anyone
>> have suggestions as to an alternate procedure that will allow 2 slaves to
>> sync concurrently.
>
> Is there any hidden issue with this that we haven't seen. Or does anyone
> have suggestions as to an alternate procedure that will allow 2 slaves to
> sync concurrently.
>
> With some more testing I've done today I seem to have found an issue with
this procedure.
When the slave starts up after t
> I have this query working :
> select profil,count(og.name)
> from ldap l
> left join uidinoldgroups ug on l.uid=ug.uid left join oldgroups og on
> og.id=ug.idgroupe and og.rne='0410030k' and og.type='g'
> where l.profilgeneral='P'
> and l.rne='0410030k'
> group by l.profil
>
> But if I put :
>
Hello,
Actually I have sort of two questions rolled into one: when creating
custom data types, there's the option to implement *_send() and *_recv()
functions in addition to *_in() and *_out(); does pg_dump use them for
binary dumps, and, if not, what uses them? Are they only an optional
optimizat
Our sync script is setup to fail if the pg_start_backup fails as if it
fails for some other reason the sync won't be valid as the backup_label
file will be missing so the slave won't have the correct location to
restart from.
Originally I had gone down the road of changing the sync script such tha
> Specifically what is the error?
>
psql (9.1.5)
Type "help" for help.
postgres=# select pg_start_backup('hotbackup',true);
pg_start_backup
-
61/B20
(1 row)
postgres=# select pg_start_backup('hotbackup',true);
ERROR: a backup is already in progress
HINT: Run pg_stop_backup
On Wed, Sep 19, 2012 at 8:59 AM, Mike Roest wrote:
> Hey Everyone,
> We currently have a 9.1.5 postgres cluster running using streaming
> replication. We have 3 nodes right now
>
> 2 - local that are setup with pacemaker for a HA master/slave set failover
> cluster
> 1 - remote as a DR.
>
> C
Hey Everyone,
We currently have a 9.1.5 postgres cluster running using streaming
replication. We have 3 nodes right now
2 - local that are setup with pacemaker for a HA master/slave set failover
cluster
1 - remote as a DR.
Currently we're syncing with the pretty standard routine
clear local
Merlin Moncure wrote:
> By having the filtering in the where clause, the intended purpose
> of the left join, to return every row of foo, is being defeated
> and the join will behave like an inner join. The right way to do
> it is:
>
> SELECT * FROM foo LEFT JOIN BAR ON foo.id = bar.id AND bar
Good deduction Steve.
Looks like we are going to use the timestamp idea. This way, the ticket will
be open for sale again the second it's hold_until time lapses. The cronjob was
a close second, but there could be a lag-time between runs.
Thanks everyone for all the help.
--
Robert Sosinski
Le 19/09/2012 17:08, Merlin Moncure a écrit :
SELECT * FROM foo LEFT JOIN BAR ON foo.id = bar.id AND bar.col = 'something';
The difference here is that the filtering is now happening at join
time where the left join semantics are playing: always return foo and
return bar rows if and only if the
Le 19/09/2012 02:47, David Johnston a écrit :
> There is no difference in your example. Conceptually though I
> suggest using only table-table conditions in an ON clause and placing
> any table-value conditions into the where.
This is how I use it usually.
> The main time you get differences is
On Tue, Sep 18, 2012 at 7:47 PM, David Johnston wrote:
> On Sep 18, 2012, at 20:21, Jean-Christophe Boggio
> wrote:
>
>> I'm looking for an article that explains the difference between these
>> constructs IN POSTGRESQL (the rules seem to differ from one DB to another) :
>>
>> SELECT A.*
>> FROM
On 19/09/12 19:40, Albe Laurenz wrote:
Guilherme Rodrigues wrote:
I created one table so:
CREATE TABLE clima (
city char(80),
cprc int,
);
And have other table so:
CREATE TABLE city (
namechar(80),
other_thing int,
);
These SQL statements have synt
Em terça-feira, 18 de setembro de 2012 17h37min59s UTC-3, Guilherme Rodrigues
escreveu:
> Hello. I want to change one table already created. Where the comand? thank
> you.
Ok. Thank All.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscriptio
> -Original Message-
> From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-
> ow...@postgresql.org] On Behalf Of Steve Haresnape
> Sent: Wednesday, September 19, 2012 2:37 AM
> To: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] RFE: Column aliases in WHERE clauses
>
> Hi
On Wed, 2012-09-19 at 20:36 +0800, Craig Ringer wrote:
> On 09/19/2012 02:36 PM, Steve Haresnape wrote:
>
> > Since some dialects support the idiom and others don't there can't be
> > any compelling reason to withhold support. It's really a matter of style.
> > For my money the DRY style is better
On 09/19/2012 07:54 PM, Marc Mamin wrote:
hello,
I've found a small logical issue while writing a migration script:
create table vtest (foo int);
create view vtest_v as select * from vtest;
drop table if exists vtest_v;
ERROR: "vtest_v" is not a table
drop view if exists vtest;
ERROR:
On 09/19/2012 02:36 PM, Steve Haresnape wrote:
Since some dialects support the idiom and others don't there can't be
any compelling reason to withhold support. It's really a matter of style.
For my money the DRY style is better.
So you're saying that you want the implementation to effectively
hello,
I've found a small logical issue while writing a migration script:
create table vtest (foo int);
create view vtest_v as select * from vtest;
drop table if exists vtest_v;
ERROR: "vtest_v" is not a table
drop view if exists vtest;
ERROR: "vtest" is not a view
this may be seen as a ni
On 18/09/2012, at 20:19, Jeff Janes wrote:
> I think the one below will show an even larger discrepancy. You are
> doing 2 casts for each comparison,
> so I think the casts overhead will dilute out the comparison.
>
> select count(distinct foo) from ( select cast(random() as varchar(14)) as foo
On 19/09/2012 04:57, Chris Travers wrote:
>
> Natural language semantics will get you into trouble though. After all,
> I think Lisp follows natural language semantics remarkably closely if
> your natural language is Irish Gaelic
Really? I haven't used Irish seriously since I left school - m
Guilherme Rodrigues wrote:
> I created one table so:
>
> CREATE TABLE clima (
> city char(80),
> cprc int,
> );
>
> And have other table so:
>
> CREATE TABLE city (
> namechar(80),
> other_thing int,
> );
These SQL statements have syntax errors (comma aft
Ciao Rafal,
You can download the refreshed version of the patch:
http://archives.postgresql.org/message-id/1347983571.11539.14.ca...@greygoo.devise-it.lan
5. where do I get current-v9.3 from?
git clone git://git.postgresql.org/git/postgresql.git
cd postgresql
git checkout -b aefk
bzcat Arra
36 matches
Mail list logo
