El 04/11/15 a las 00:05, Tom Lane escribió:
"=?UTF-8?Q?Leonardo_M._Ram=c3=a9?=" writes:
Hi, I'm trying to build the client library of PostgreSql 9.3.x using
this version of MinGW's gcc:
...
g++ -DFRONTEND -I../../src/include -I./src/include/port/win32
-DEXEC_BACKEND "-I../../src/include/port
Hi all,
We have started to convert some oracle sql scripts and converting them to
postgres, but facing some issues to create table.
I have some common doubts in create table script ie.
ALTER TABLE employee
DROP PRIMARY KEY CASCADE;
DROP employee CASCADE CONSTRAINTS;
CREATE TABLE employee
(
Sorry for being kind of late to the party (I was in 2015.PgConf.EU !!), and not
having read
most of the replies, what we have been successfully doing for this problem for
our app
is do it this way :
parents int[] -- where parents stores the path from the node to the root of the
tree
and then ha
Michael Paquier wrote:
>>> The docs mention that "all WAL files" preceding a given point are
>>> removed, personally I understand that as "all 16MB-size segments shall
>>> die", hence excluding backup and history files from the stack. But one
>>> may understand that "WAL files" means everything in
El 04/11/15 a las 06:00, Leonardo M. Ramé escribió:
El 04/11/15 a las 00:05, Tom Lane escribió:
"=?UTF-8?Q?Leonardo_M._Ram=c3=a9?=" writes:
Hi, I'm trying to build the client library of PostgreSql 9.3.x using
this version of MinGW's gcc:
Nevermind, deleted my MinGW instalation, then instal
Le 4 nov. 2015 10:23 AM, "M Tarkeshwar Rao"
a écrit :
>
> Hi all,
>
> We have started to convert some oracle sql scripts and converting them to
postgres, but facing some issues to create table.
>
> I have some common doubts in create table script ie.
>
> ALTER TABLE employee
> DROP PRIMARY KEY CAS
M Tarkeshwar Rao schrieb am 04.11.2015 um 10:21:
> Hi all,
>
> We have started to convert some oracle sql scripts and converting them to
> postgres, but facing some issues to create table.
>
> I have some common doubts in create table script ie.
>
> ALTER TABLE employee
> DROP PRIMARY KEY CA
Hi,
On Wed, Nov 4, 2015 at 1:21 AM, M Tarkeshwar Rao <
m.tarkeshwar@ericsson.com> wrote:
> Hi all,
>
> We have started to convert some oracle sql scripts and converting them to
> postgres, but facing some issues to create table.
>
> I have some common doubts in create table script ie.
>
> ALT
Thanks Jim and Michael for comments.
I'm on pg_repack 1.3.2 (latest sable, no devel version available to check
if it is already fixed).
Michael: your memories are fresh and clear :-), yes, it is part of a
cleanup rollback. The problem is, that the pgrepack_drop call this
statement:
DROP TABLE IF
Hello,
I try to configure auto-analyse task with postgresql 9.4.
I have the following configuration (default configuration):
track_counts = on
autovacuum = on
log_autovacuum_min_duration = -1
autovacuum_max_workers = 3
autovacuum_naptime = 300s
autovacuum_vacuum_threshold = 50
autovacuum_analyze_
On 11/04/2015 05:32 AM, Bertrand Roos wrote:
Hello,
I try to configure auto-analyse task with postgresql 9.4.
I have the following configuration (default configuration):
track_counts = on
autovacuum = on
log_autovacuum_min_duration = -1
autovacuum_max_workers = 3
autovacuum_naptime = 300s
autova
On Wed, 4 Nov 2015 14:32:37 +0100
Bertrand Roos wrote:
>
> I try to configure auto-analyse task with postgresql 9.4.
> I have the following configuration (default configuration):
> track_counts = on
> autovacuum = on
> log_autovacuum_min_duration = -1
> autovacuum_max_workers = 3
> autovacuum_nap
Le 04/11/2015 14:45, Adrian Klaver a écrit :
On 11/04/2015 05:32 AM, Bertrand Roos wrote:
Hello,
I try to configure auto-analyse task with postgresql 9.4.
I have the following configuration (default configuration):
track_counts = on
autovacuum = on
log_autovacuum_min_duration = -1
autovacuum_ma
On 11/04/2015 06:35 AM, Bertrand Roos wrote:
Le 04/11/2015 14:45, Adrian Klaver a écrit :
On 11/04/2015 05:32 AM, Bertrand Roos wrote:
Hello,
I try to configure auto-analyse task with postgresql 9.4.
I have the following configuration (default configuration):
track_counts = on
autovacuum = on
"=?UTF-8?Q?Leonardo_M._Ram=c3=a9?=" writes:
> El 04/11/15 a las 00:05, Tom Lane escribió:
>> Why is it invoking g++ and not gcc?
> I don't know. I just installed MinGW, then ./configure, maybe there's an
> error in the configure script?.
I looked at the configure script carefully, and so far as
Le 04/11/2015 14:55, Bill Moran a écrit :
On Wed, 4 Nov 2015 14:32:37 +0100
Bertrand Roos wrote:
I try to configure auto-analyse task with postgresql 9.4.
I have the following configuration (default configuration):
track_counts = on
autovacuum = on
log_autovacuum_min_duration = -1
autovacuum_
On 11/04/2015 03:03 AM, Achilleas Mantzios wrote:
Sorry for being kind of late to the party (I was in 2015.PgConf.EU
!!), and not having read
most of the replies, what we have been successfully doing for this
problem for our app
is do it this way :
parents int[] -- where parents stores the path
On 11/04/2015 07:43 AM, Bertrand Roos wrote:
Le 04/11/2015 14:55, Bill Moran a écrit :
On Wed, 4 Nov 2015 14:32:37 +0100
Bertrand Roos wrote:
I try to configure auto-analyse task with postgresql 9.4.
I have the following configuration (default configuration):
track_counts = on
autovacuum = o
Bertrand Roos writes:
> In fact, I was telling the question because I have read on some forums
> that the auto vacuum deamon only count dead tuple so only update and
> delete operations can cause the scheduling of auto-analyse.
That might have been true years ago, don't remember at the moment.
On Wed, 4 Nov 2015 16:43:57 +0100
Bertrand Roos wrote:
>
> Le 04/11/2015 14:55, Bill Moran a écrit :
> > On Wed, 4 Nov 2015 14:32:37 +0100
> > Bertrand Roos wrote:
> >> I try to configure auto-analyse task with postgresql 9.4.
> >> I have the following configuration (default configuration):
> >>
Thanks for that tip, Achilleas.
On Wed, Nov 4, 2015 at 7:53 AM, Rob Sargent wrote:
> On 11/04/2015 03:03 AM, Achilleas Mantzios wrote:
>
> Sorry for being kind of late to the party (I was in 2015.PgConf.EU !!),
> and not having read
> most of the replies, what we have been successfully doing for
On Wed, Nov 4, 2015 at 10:16 PM, Jiří Hlinka wrote:
> I'm on pg_repack 1.3.2 (latest sable, no devel version available to check
> if it is already fixed).
>
> Michael: your memories are fresh and clear :-), yes, it is part of a
> cleanup rollback. The problem is, that the pgrepack_drop call this
On Wed, Nov 4, 2015 at 7:16 PM, Albe Laurenz wrote:
> Michael Paquier wrote:
The docs mention that "all WAL files" preceding a given point are
removed, personally I understand that as "all 16MB-size segments shall
die", hence excluding backup and history files from the stack. But on
I'll check if the trigger activity was moving on or waiting for a lock from
logs.
I'm doing simple UPDATES, INSERTs and DELETEs on this table, but frequency
of these DMLs is _very_ high (it is a queue table used for a one-way
selective [just part of data are replicated] replication of queries betw
On Wed, Nov 4, 2015 at 1:31 AM, Tom Lane wrote:
> Victor Blomqvist writes:
> > In case any of you are interested of recreating this problem, I today had
> > the time to create a short example that reproduce the error every time I
> > try.
>
> Hmm. If you just do that serially:
>
> regression=#
25 matches
Mail list logo
