On 14 July 2017 at 00:09, Zhu, Joshua wrote:
>
>
> Found these log entries from one of the other node:
>
>
>
> t=2017-07-13 08:35:34 PDT p=27292 a=DEBUG: 0: found valid replication
> identifier 15
>
> t=2017-07-13 08:35:34 PDT p=27292 a=LOCATION:
>
On Thu, Jul 13, 2017 at 2:46 AM, Gregory Nicol wrote:
> Good morning all,
>
>
>
> I can’t seem to get LDAP Authentication working without an OU in the
> ldapbasedn. My users are spread across multiple OUs without a common root
> OU which is why I’m trying to
Oh duh, I'm blind... Thanks!
On 07/13/2017 07:29 PM, David G. Johnston wrote:
On Thursday, July 13, 2017, ProPAAS DBA > wrote:
2) where can I find a complete list of the tg_ variables? I see
this list:
On Thursday, July 13, 2017, ProPAAS DBA wrote:
>
> 2) where can I find a complete list of the tg_ variables? I see this
> list:https://www.postgresql.org/docs/9.4/static/plpgsql-trigger.html
>
> which includes TG_NAME. OLD, NEW, etc but tg_tag and tg_event are not in the
>
Hi All;
we are creating an event trigger on ddl_command_end and I want the
function to know the TABLE and COMMAND run, for example if the ddl
command was an "ALTER TABLE ADD COLUMN X" then I want to pull the table
and the actual alter command. We're running version 9.4 so the
Greetings,
* Gregory Nicol (gregory.ni...@medbank.com.mt) wrote:
> I can't seem to get LDAP Authentication working without an OU in the
> ldapbasedn. My users are spread across multiple OUs without a common root OU
> which is why I'm trying to authenticate with just the DC.
As it looks like
Greetings,
* cen (imba...@gmail.com) wrote:
> Seems like a lot of manual work to me, to automate it I'd basically
> have to diff both directories and then copy only the newest
> differences over to the recovery. So far I was unable to find a
> supersecret git repo with bash scripts accomplishing
That is really unfortunate. It seems it would be a nice feature for
pg_basebackup to simply create a .metadata file in basebackup output
directory or something along those lines.
Non tarballed/compressed basebackup is fine since I can read the label,
but most people probably want to always
Thank you Tom. I have already started running queries from the
corresponding extension. Let's see how far I get! :)
Regards,
Nandish
On Thu, Jul 13, 2017 at 1:03 PM, Tom Lane wrote:
> Nandish Jayaram writes:
> > I have been trying to get pgpointcloud
--- Begin Message ---
Hi List,
I'm m extremely please to see the logical replication aka:
transaction replication feature been implemented in Pg 10, very nice
work done by the contrib of this module/feature!
Since here is mentioned the "replication slots" are located on
master
Nandish Jayaram writes:
> I have been trying to get pgpointcloud running on greenplum 5.0 database.
> This might seem like a convoluted topic to discuss on this mailing list, but
> the reason I am asking here is that Greenplum 5 is based on postgres 8.4
> and pgpointcloud
On Thu, Jul 13, 2017 at 2:45 PM, Edmundo Robles
wrote:
> i executed the commands many times like superuser but that queries
> still running :(
>
> On Thu, Jul 13, 2017 at 11:10 AM, Melvin Davidson
> wrote:
>
>>
>>
>> On Thu, Jul 13, 2017 at 11:57
Hi,
I have been trying to get pgpointcloud running on greenplum 5.0 database.
This might seem like a convoluted topic to discuss on this mailing list, but
the reason I am asking here is that Greenplum 5 is based on postgres 8.4
and pgpointcloud requires at least postgres 9.0 it seems. So I am
On Thu, Jul 13, 2017 at 7:23 PM, Jeff Janes wrote:
> On Thu, Jul 13, 2017 at 1:15 AM, Michael Paquier
> wrote:
>>
>> On Thu, Jul 13, 2017 at 5:26 AM, Jeff Janes wrote:
>> >
>> > I think that none of the recovery information
On Thu, Jul 13, 2017 at 1:15 AM, Michael Paquier
wrote:
> On Thu, Jul 13, 2017 at 5:26 AM, Jeff Janes wrote:
> >
> > I think that none of the recovery information functions
> > (https://www.postgresql.org/docs/9.6/static/functions-admin.
>
Edmundo Robles writes:
> Hi! i have many too long time queries, the oldest is almost 16
> days, so i tried to cancel and terminate with pg_cancel_backend and
> pg_terminate_backend but queries is still running.
>
> STIME ELAPSED ELAPSED %CPU PID COMMAND
>
On Thu, Jul 13, 2017 at 11:57 AM, Edmundo Robles
wrote:
> Hi! i have many too long time queries, the oldest is almost 16 days,
> so i tried to cancel and terminate with pg_cancel_backend and
> pg_terminate_backend but queries is still running.
>
> STIME ELAPSED
Found these log entries from one of the other node:
t=2017-07-13 08:35:34 PDT p=27292 a=DEBUG: 0: found valid replication
identifier 15
t=2017-07-13 08:35:34 PDT p=27292 a=LOCATION:
bdr_establish_connection_and_slot, bdr.c:604
t=2017-07-13 08:35:34 PDT p=27292 a=ERROR: 53400: no free
On Thu, Jul 13, 2017 at 11:06 AM, Igor Korot wrote:
> Hi, Melvin,
>
> On Thu, Jul 13, 2017 at 10:42 AM, Melvin Davidson
> wrote:
>
>>
>> On Thu, Jul 13, 2017 at 10:36 AM, Igor Korot wrote:
>>
>>> Hi, ALL,
>>> Is it possible to get
Hi! i have many too long time queries, the oldest is almost 16 days,
so i tried to cancel and terminate with pg_cancel_backend and
pg_terminate_backend but queries is still running.
STIME ELAPSED ELAPSED %CPU PID COMMAND
jun27 15-23:05:46 1379146 0.3 29660 postgres: argos_admin
dpat wrote:
> i have configure a master-replica replication with new pglogical 2.0.
> I have to replicate data over MPLS/VPN, so there is a possibility that the
> link temporarily interrupts.
> I know that you have to be accurately estimated pg_xlog folder.
> How can I handle the prolonged
Vick Khera writes:
> What exactly does the configure flag to enable systemd support do?
Not a lot. A quick grep for USE_SYSTEMD says it does nothing except
add code in the postmaster to report ready/not-ready state transitions
by calling sd_notify(). We have significantly more
What exactly does the configure flag to enable systemd support do? It seems
to me that building software to the systemd platform is just the same as
building it for windows vs unix or any other platform. One can only hope it
doesn't cause the others to wither away.
On Wed, Jul 12, 2017 at 3:20
On Thu, Jul 13, 2017 at 04:05:43PM +0200, Pavel Stehule wrote:
> what about \pset format wrapped
I prefer the extended format which I find more pleasant to read.
I'm just curious if this expected behavior or a bug / weird
effect of my setup.
If it's considered a bug I'd by willing to try to
Hi, ALL,
Is it possible to get the table ID (or OID) from information_schema somewhere?
Thank you.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
2017-07-13 14:40 GMT+02:00 Simon Ruderich :
> Hello,
>
> I'm using the following minimal ~/.psqlrc:
>
> \pset expanded on
>
> Now when I select rows from a table which are too long to fit the
> screen then I get this output:
>
> simon=> table test;
> -[ RECORD 1
On 07/12/2017 11:25 PM, Tom Lane wrote:
rihad writes:
What if only English letters are used in the textual indices (ascii
0-127), would they still be impacted after datctype
"C"->"en_US.UTF-8" change?
Yes, as even minimal testing would have told you. C sort order is
more
Hello,
I'm using the following minimal ~/.psqlrc:
\pset expanded on
Now when I select rows from a table which are too long to fit the
screen then I get this output:
simon=> table test;
-[ RECORD 1 ]---
Good morning all,
I can't seem to get LDAP Authentication working without an OU in the
ldapbasedn. My users are spread across multiple OUs without a common root OU
which is why I'm trying to authenticate with just the DC.
With pg_hba.conf like this, I can connect successfully from psql...
On Thu, Jul 13, 2017 at 10:30 AM, cen wrote:
> Given a basebackup base.tar.gz and an archive of WAL files, is there any way
> to find out which .backup WAL file is associated with the basebackup from
> command line?
Not from what Postgres ships directly. Without any custom
Hi
Given a basebackup base.tar.gz and an archive of WAL files, is there any
way to find out which .backup WAL file is associated with the basebackup
from command line?
My use case is for a retention policy bash script which:
-deletes all basebackups older than X days
-runs
On Thu, Jul 13, 2017 at 5:26 AM, Jeff Janes wrote:
>
> I think that none of the recovery information functions
> (https://www.postgresql.org/docs/9.6/static/functions-admin.html#FUNCTIONS-RECOVERY-INFO-TABLE)
> can distinguish a hot standby which is connected to an idle
On 13 July 2017 at 01:56, Zhu, Joshua wrote:
> Thanks for the clarification.
>
>
>
> Looks like I am running into a different issue: while trying to pin down
> precisely the steps (and the order in which to perform them) needed to
> remove/rejoin a node, the removal/rejoining
33 matches
Mail list logo