> Now the logical decoding client connects to B (the new primary). The
> replication slot doesn't exist. So, it creates it and starts streaming.
> This is where the problem lies - as it would begin streaming from LSN 4
> (anything after what has already been committed), because I have no way
> (tha
On Wed, 2016-08-10 at 13:33 +1200, Patrick B wrote:
> hi guys,
>
>
> just setting up a new DB using PostgreSQL 9.5.
>
>
> I've created a new username for the code, called codeuser.
>
> To give the username access to all the tables, views, etc I ran:
>
> > GRANT INSERT, SELECT, UPDATE, DELETE
hi guys,
just setting up a new DB using PostgreSQL 9.5.
I've created a new username for the code, called codeuser.
To give the username access to all the tables, views, etc I ran:
GRANT INSERT, SELECT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO
> codeuser;
Is that ok? Is that enough?
Christian Ohler writes:
> ... (But that's a guess. AFAICT, creating a temp table
> also produces WAL records, so perhaps checking for them is no better
> than checking for a transaction ID after all.)
Well, creating a temp table makes entries in the system catalogs, which
requires both an XID a
On Mon, Aug 8, 2016 at 8:23 AM, Kevin Grittner wrote:
> Your check for a exclusive self-lock on transactionid should work.
> It may be possible to find a way to do it that is less expensive,
> so I would definitely encapsulate that in a function; but off-hand
> I'm not thinking of a better way.
G
Hi,
I'm just curious about the reasons of the design of 'DO' statement so that
it is not able to return result of the SELECT in its body.
References:
https://www.postgresql.org/docs/current/static/sql-do.html
http://stackoverflow.com/questions/14652477/how-to-perform-a-select-query-in-a-do-b
Adrian,
All the logs posted were from syslog (that’s were postgres writes its log on
our Ubuntu install)
>> 1) I got 7 transactions back in single user mode
>> Aug 7 23:40:57 p2 postgres[30376]: [5-1] 2016-08-07 23:40:57 CEST WARNING:
>> database "public" must be vacuumed within 999893 transa
--
David Rader
dav...@openscg.com
On Tue, Aug 9, 2016 at 10:23 AM, wrote:
> Logged by: Nicolas David
> Email address: nicolas.da...@verosoftware.com
> PostgreSQL version: 9.2.5
> Operating system: Windows 10
> Description:
>
> Dear All,
>
> we have a chinese customer that have m
"hari.prasath" writes:
> I am using jsonb for storing key-value pair information(500 keys) and it
> was a very big data set with some 10M rows. Whenever i try to extract some
> keys(let say some 10 keys and its values) its really very slow.
> Is this due to jsonb parsing (or) each time json
On Mon, Aug 8, 2016 at 5:59 PM, Craig Boucher
wrote:
> Thanks Kevin for your response. I've Googled and debated natural
> vs surrogate keys and I just find surrogate keys easier to work
> with (maybe I'm just being lazy). It just seems that a
> description or name is most often the natural key.
On Tue, Aug 9, 2016 at 4:50 AM, hari.prasath wrote:
> Is there any tentative schedule for real-time or incremental(only
> applying delta changes) refresh of materialized views.?.
There is work in progress, but no hard schedule. Unfortunately, it
has often been set aside to address more im
Hi,
El 08/08/16 a las 05:57, Pekka Rinne escribió:
>
> Meanwhile I did some more testing with my environment using repmgr3 and
> noticed an issue with promoting standby node. Here is roughly what I did.
>
> 1. Install repmgr3.1.2 RPM to all nodes as upgrade to previous 2.0.2.
> 2. I took repmgr
Hi all
Is there any tentative schedule for real-time or incremental(only
applying delta changes) refresh of materialized views.?. Since in concurrent
refresh the full view has been created from the base tables.
cheers
- Harry
Hi all
I am using jsonb for storing key-value pair information(500 keys) and it
was a very big data set with some 10M rows. Whenever i try to extract some
keys(let say some 10 keys and its values) its really very slow.
Is this due to jsonb parsing (or) each time json will be loaded from
14 matches
Mail list logo
