Hi All,
Try to configure pglogical in such way:
srv1, srv2: CentOS 6.7, PostgreSQL 9.5.1, pglogical 1.0.1
On both servers created database "xdray", schema is common and consists
tables t1 and t2.
The srv1 writes to the t1. The t1 added to replication set repset_t1 on
the srv1.
The srv2 writes t
If anybody puts together a "just the facts" document after Oracle's
attack on PostgreSQL in Russia, please make sure it's drawn to the
attention of this mailing list for the benefit of those who aren't in
-advocacy.
I was discussing this sort of thing elsewhere in the context of MS's
apparent
On Fri, Mar 18, 2016 at 5:46 PM, Adrian Klaver
wrote:
> They should be able to, see below. If that is not your case, then more
> information is needed.
>
You can see your own queries, however non-superuser will not see the query
for other users. You will be able to see the other info, though.
I
Hello fellow pgsql users,
I am programming a word game backend in PL/pgSQL and have already reached a
point, where (too) many stored functions are declared in a single file
words.sql:
# SELECT proname || '(' || oidvectortypes(proargtypes) || ')'
FROM pg_proc INNER JOIN pg_namespace ns ON
Hi
2016-03-21 15:42 GMT+01:00 Alexander Farber :
> Hello fellow pgsql users,
>
> I am programming a word game backend in PL/pgSQL and have already reached
> a point, where (too) many stored functions are declared in a single file
> words.sql:
>
> # SELECT proname || '(' || oidvectortypes(proargty
2016-03-21 16:42 GMT+02:00 Alexander Farber :
> I would prefer to have every stored function in a separate file (which
> would make reading git history easier too) and include them from words.sql.
>
> Is there such a thing for PostgreSQL 9.5.1 available please and if not -
> could you share your a
On 03/21/2016 07:42 AM, Alexander Farber wrote:
Hello fellow pgsql users,
I am programming a word game backend in PL/pgSQL and have already
reached a point, where (too) many stored functions are declared in a
single file words.sql:
# SELECT proname || '(' || oidvectortypes(proargtypes) || ')'
Mark Morgan Lloyd schrieb am 21.03.2016 um 14:44:
> I was discussing this sort of thing elsewhere in the context of MS's
> apparent challenge to Oracle and IBM, and the dominant feeling
> appeared to be that actual use of things like Oracle RAC was
> vanishingly uncommon. Which surprised me, and wh
Thanks for your replies.
While I use "\i" regularly I just didn't realize it would be suitable here
as well :-)
Regards
Alex
On 03/21/2016 07:54 AM, Bert wrote:
Ccing list
Hello Ardian,
The PostgreSQL version is 9.4.5
The reason I have the 'returning' statement in the update section is
because I only insert the data that has not been updated. I don't see
why I would need to return anything in the insert section?
W
On Sun, Mar 20, 2016 at 9:31 AM, Michael Paquier
wrote:
> And the patch attached gives the following output:
> With title:
> =# \watch 1
> Watch every 1sSun Mar 20 22:28:38 2016
> popo
> a
> ---
> 1
> (1 row)
>
> And without title:
> Watch every 1sSun Mar 20 22:29:31 2016
>
> a
> ---
>
On Mon, Mar 21, 2016 at 7:44 AM, Mark Morgan Lloyd
wrote:
> If anybody puts together a "just the facts" document after Oracle's attack
> on PostgreSQL in Russia, please make sure it's drawn to the attention of
> this mailing list for the benefit of those who aren't in -advocacy.
>
> I was discussi
On Mon, Mar 21, 2016 at 8:03 AM, Robert Haas wrote:
> On Sun, Mar 20, 2016 at 9:31 AM, Michael Paquier
> wrote:
> > And the patch attached gives the following output:
> > With title:
> > =# \watch 1
> > Watch every 1sSun Mar 20 22:28:38 2016
> > popo
> > a
> > ---
> > 1
> > (1 row)
>
Thi
On 03/21/2016 07:15 AM, Vick Khera wrote:
On Fri, Mar 18, 2016 at 5:46 PM, Adrian Klaver
mailto:adrian.kla...@aklaver.com>> wrote:
They should be able to, see below. If that is not your case, then
more information is needed.
You can see your own queries, however non-superuser will not
That is easy to check.
Let's do the same test again:
# select count(1) from dlp.st_itemseat;
count
---
12
(1 row)
# select count(1) from loaddlp.st_itemseat_insert;
count
---
87 --> of which 12 are already in the dlp.st_itemseat table
(1 row)
# explain analyze *
QUERY
PLA
Hi,
My question is related to correspondence of postgresql "timezone" parameter
with OS timezone settings in debian and red hat family systems.
In debian by default postgresql "timezone" parameter value is "localtime"
and it succesfully gets current OS timezone. (most probably it is not
dynamical
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Alexander Farber
Sent: Monday, March 21, 2016 10:43 AM
To: pgsql-general
Subject: [GENERAL] Including SQL files
Hello fellow pgsql users,
I am programming a word game backend in PL/pgSQL and have al
On Mon, Mar 21, 2016 at 11:17 AM, David G. Johnston
wrote:
>> And does everybody agree that this is a desirable change?
>
> Adding the title is desirable. While I'm inclined to bike-shed this
> anything that gets it in I can live with and so I'm content letting the
> author/committer decide where
On 03/21/2016 08:29 AM, Bert wrote:
My mistake, Cced wrong list.
That is easy to check.
Let's do the same test again:
# select count(1) from dlp.st_itemseat;
count
---
12
(1 row)
# select count(1) from loaddlp.st_itemseat_insert;
count
---
87 --> of which 12 are alr
On 03/21/2016 08:29 AM, Bert wrote:
That is easy to check.
Let's do the same test again:
# select count(1) from dlp.st_itemseat;
count
---
12
(1 row)
# select count(1) from loaddlp.st_itemseat_insert;
count
---
87 --> of which 12 are already in the dlp.st_itemseat tab
On 03/21/2016 10:57 AM, Thomas Kellerer wrote:
So - at least as far as I can tell - it's usually only used where
high-availability is really important, e.g. where zero-downtime is required.
If you can live with a short downtime, a hot standby is much cheaper and
probably not that much slower.
On 3/21/16, 9:10 AM, "pgsql-general-ow...@postgresql.org on behalf of Rakesh
Kumar" wrote:
>On 03/21/2016 10:57 AM, Thomas Kellerer wrote:
>
>> So - at least as far as I can tell - it's usually only used where
>> high-availability is really important, e.g. where zero-downtime is required.
>> I
Robert Haas writes:
> Well, the title isn't normally centered, but yeah, that is odd. Yeah,
> that is odd. Come to think of it, I think I might have expected the
> title to appear *above* "Watch every %s", not below it. That might
> decrease the oddness.
AFAICS, it appears *beside* it with thi
On Mon, Mar 21, 2016 at 10:14 AM, Tom Lane wrote:
> Robert Haas writes:
> > Well, the title isn't normally centered, but yeah, that is odd. Yeah,
> > that is odd. Come to think of it, I think I might have expected the
> > title to appear *above* "Watch every %s", not below it. That might
> >
"David G. Johnston" writes:
> I'd rather not omit sleep but removing "Watch every" is fine (preferred
> actually), so:
> Title Is Here Mon Mar 21 15:05:06 2016 (5s)
Meh ... seems a bit awkward to me. Couldn't you include " (5s)" in the
title, if you want that info? If it's variable, you cou
I have 5 GIN indexes on a PG 9.3 table containing about 50 million records.
Each index covers a "group" of common records like billing address,
shipping address, contact names, etc.
When first created, the indexes works miracles in speeding up the full text
search of these fields. However, I'm run
Pavel Suderevsky writes:
> My question is related to correspondence of postgresql "timezone" parameter
> with OS timezone settings in debian and red hat family systems.
> In debian by default postgresql "timezone" parameter value is "localtime"
> and it succesfully gets current OS timezone. (most
On Monday, March 21, 2016, Tom Lane wrote:
> "David G. Johnston" > writes:
> > I'd rather not omit sleep but removing "Watch every" is fine (preferred
> > actually), so:
> > Title Is Here Mon Mar 21 15:05:06 2016 (5s)
>
> Meh ... seems a bit awkward to me. Couldn't you include " (5s)" in the
On Mon, Mar 21, 2016 at 2:09 PM, David G. Johnston
wrote:
> On Monday, March 21, 2016, Tom Lane wrote:
>> "David G. Johnston" writes:
>> > I'd rather not omit sleep but removing "Watch every" is fine (preferred
>> > actually), so:
>> > Title Is Here Mon Mar 21 15:05:06 2016 (5s)
>>
>> Meh ..
Chris Spencer writes:
> I have 5 GIN indexes on a PG 9.3 table containing about 50 million records.
> Each index covers a "group" of common records like billing address,
> shipping address, contact names, etc.
> When first created, the indexes works miracles in speeding up the full text
> search
On Monday, March 21, 2016, Robert Haas wrote:
> On Mon, Mar 21, 2016 at 2:09 PM, David G. Johnston
> > wrote:
> > On Monday, March 21, 2016, Tom Lane >
> wrote:
> >> "David G. Johnston" > writes:
> >> > I'd rather not omit sleep but removing "Watch every" is fine
> (preferred
> >> > actually), so
David G. Johnston wrote:
> Tom doesn't care enough to veto and you don't really care...
>
> I'll admit it's awkward because it's abbreviated but if someone enters
> \watch 5 and then sees (5s) in the title I think they can put two and two
> together.
>
> If the watched query takes a long to run,
"David G. Johnston" writes:
> I'll admit it's awkward because it's abbreviated but if someone enters
> \watch 5 and then sees (5s) in the title I think they can put two and two
> together.
Where I find this to be awkward is that the format is randomly different
between the user-title and no-user-
Alvaro Herrera writes:
> (I'll also use this opportunity to complain again about not being able
> to use floating point sleep time.)
That's not unreasonable either, though it seems like material for a
separate patch.
regards, tom lane
--
Sent via pgsql-general mailing
On Monday, March 21, 2016, Tom Lane wrote:
> "David G. Johnston" > writes:
> > I'll admit it's awkward because it's abbreviated but if someone enters
> > \watch 5 and then sees (5s) in the title I think they can put two and two
> > together.
>
> Where I find this to be awkward is that the format
Thanks for the tips.
What constitutes a "large" work_mem? My server has 61GB of memory and my
work_mem is currently set to include all of that. What percent of my total
memory should I lower that to so it won't impact GIN updates?
On Mon, Mar 21, 2016 at 2:27 PM, Tom Lane wrote:
>
> Chris Spence
Chris Spencer writes:
> What constitutes a "large" work_mem? My server has 61GB of memory and my
> work_mem is currently set to include all of that.
Ouch. That's a mistake independently of GIN. The primary usage of
work_mem is to define how much memory an individual sorting or hashing
query ste
"David G. Johnston" writes:
> On Monday, March 21, 2016, Tom Lane wrote:
>> What about just discarding the old format entirely, and printing one of
>> these two things:
>>
>> Timestamp (every Ns)
>>
>> User Given Title Timestamp (every Ns)
> This works for me.
If I don't hear objections PDQ,
Tom Lane wrote:
> "David G. Johnston" writes:
> > On Monday, March 21, 2016, Tom Lane wrote:
> >> What about just discarding the old format entirely, and printing one of
> >> these two things:
> >>
> >> Timestamp (every Ns)
> >>
> >> User Given Title Timestamp (every Ns)
>
> > This works for
On Mon, Mar 21, 2016 at 10:55 AM, Chris Spencer wrote:
> I have 5 GIN indexes on a PG 9.3 table containing about 50 million records.
> Each index covers a "group" of common records like billing address, shipping
> address, contact names, etc.
>
> When first created, the indexes works miracles in s
On Tue, Mar 22, 2016 at 6:25 AM, Tom Lane wrote:
> If I don't hear objections PDQ, I'm going to update the docs and commit
> it like that.
Thanks!
--
Michael
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/m
On Monday, March 21, 2016, Tom Lane wrote:
> "David G. Johnston" > writes:
> > On Monday, March 21, 2016, Tom Lane >
> wrote:
> >> What about just discarding the old format entirely, and printing one of
> >> these two things:
> >>
> >> Timestamp (every Ns)
> >>
> >> User Given Title Timestamp (e
42 matches
Mail list logo
