Ok, let me put this way,
I need every transaction coming from application sync with both production
and archive db,
but the transactions I do to clean old data(before 7 days) on production db
in daily maintenance window should not sync with archive db,
Archive db need read-only, used for maintain
On Fri, Jun 10, 2016 at 1:54 PM, rob stone wrote:
>
> Hi Ken,
>
> Would this be static or dynamic?
> For example, if you altered a column to become defined as NOT NULL,
> say, when you build the form used to maintain that table you'd like to
> have a "required" attribute against the input field f
On Fri, Jun 10, 2016 at 1:47 PM, Steve Atkins wrote:
>
> You could name the check constraints, catch the errors and use a
> client-side mapping between constraint name and a friendly error message
> for display in the web interface.
>
> This seems plausible, but not ideal. I could get over the a
On Fri, 2016-06-10 at 13:01 -0700, Ken Tanzer wrote:
> Hi. I was hoping this list might be able to offer some
> help/advice/suggestions/opinions about feasibility for something I
> want to implement, namely converting Postgres constraints into PHP
> logic. Here's the context and explanation:
>
>
> On Jun 10, 2016, at 1:01 PM, Ken Tanzer wrote:
>
> Hi. I was hoping this list might be able to offer some
> help/advice/suggestions/opinions about feasibility for something I want to
> implement, namely converting Postgres constraints into PHP logic. Here's the
> context and explanation:
Hi. I was hoping this list might be able to offer some
help/advice/suggestions/opinions about feasibility for something I want to
implement, namely converting Postgres constraints into PHP logic. Here's
the context and explanation:
I work on a PHP web app using Postgres. When possible, we try t
> This seems relevant...
>
> http://bdr-project.org/docs/stable/logical-vs-physical.html
thanks. very useful.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Fri, Jun 10, 2016 at 2:12 PM, Rakesh Kumar
wrote:
> Sorry if this question was asked before. As I understand currently
> BDR does not support the replicating nodes to run different major
> versions, like
> 9.4 <-> 9.5.
>
> Is this in the works?
>
This seems relevant...
http://bdr-project
Sorry if this question was asked before. As I understand currently
BDR does not support the replicating nodes to run different major
versions, like
9.4 <-> 9.5.
Is this in the works?
thanks
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscript
Jeff Janes writes:
> On Fri, Jun 10, 2016 at 9:20 AM, Jeff Janes wrote:
>> I think you should pick a new operator name, not try to reuse %.
> On second thought, it could use overloading distinguished with
> different argument types, so it doesn't need a different name, but I
> don't know if it i
On 06/10/2016 10:20 AM, David G. Johnston wrote:
Can you be more precise? A single table can only be placed onto one
file system.
Only if those different file systems have different physical
characteristics is using a tablespace likely to be a good solution. In
other scenarios having some kin
> On Jun 10, 2016, at 9:27 AM, Sridhar N Bamandlapally
> wrote:
>
> This is what I feel will give me solution to maintain production
> (current+7days) and archive(current+history) without any etl/scheduler
>
> But there is no feature available in any database
>
> Sridhar
> Opentext
>
If
On Fri, Jun 10, 2016 at 1:12 PM, Rakesh Kumar
wrote:
> > Their main problem to overcome when using them is that they tie
> PostgreSQL
> > much more tightly to the underlying configuration of the operating system
> > and thus you need to ensure that your processes and procedures
> accommodate
> >
> Their main problem to overcome when using them is that they tie PostgreSQL
> much more tightly to the underlying configuration of the operating system
> and thus you need to ensure that your processes and procedures accommodate
> that reality since the tools that PostgreSQL provides can only do s
On Fri, Jun 10, 2016 at 4:11 AM, Sridhar N Bamandlapally <
sridhar@gmail.com> wrote:
> Hi
>
> Is there any feature in PostgreSQL where online DW (Dataware housing) is
> possible ?
>
> am looking for scenario like
>
> 1. Production DB will have CURRENT + LAST 7 DAYS data only
>
> 2. Archive/DW
On Fri, Jun 10, 2016 at 12:49 PM, Francisco Olarte
wrote:
> I may be wrong but ...
>
> On Fri, Jun 10, 2016 at 6:33 PM, Sridhar N Bamandlapally
> wrote:
> > One thing we can restrict to "begin noarchive" transaction block are
> DELETE
> > and SELECT only
> > On 10 Jun 2016 21:57, "Sridhar N Bama
I may be wrong but ...
On Fri, Jun 10, 2016 at 6:33 PM, Sridhar N Bamandlapally
wrote:
> One thing we can restrict to "begin noarchive" transaction block are DELETE
> and SELECT only
> On 10 Jun 2016 21:57, "Sridhar N Bamandlapally"
> wrote:
>> This is what I feel will give me solution to mainta
On Fri, Jun 10, 2016 at 9:20 AM, Jeff Janes wrote:
> On Thu, Jun 9, 2016 at 1:57 AM, Greg Navis wrote:
>> Artur, no worries, I'm not writing any code ;-)
>>
>> I did the following:
>>
>> CREATE TYPE trgm_match AS (match TEXT, threshold NUMERIC);
>
> I would probably use REAL, not NUMERIC. But ma
On Fri, Jun 10, 2016 at 12:26 PM, Rakesh Kumar
wrote:
> I saw a slide recently where the use of tablespaces was discouraged.
> What does the community think of tablespaces.
>
They are a tool and their use should neither be encouraged nor discouraged
but rather understood and used when appropriat
One thing we can restrict to "begin noarchive" transaction block are DELETE
and SELECT only
Sridhar
Opentext
On 10 Jun 2016 21:57, "Sridhar N Bamandlapally"
wrote:
> This is what I feel will give me solution to maintain production
> (current+7days) and archive(current+history) without any etl/sc
I saw a slide recently where the use of tablespaces was discouraged.
What does the community think of tablespaces.
thanks
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
This is what I feel will give me solution to maintain production
(current+7days) and archive(current+history) without any etl/scheduler
But there is no feature available in any database
Sridhar
Opentext
On 10 Jun 2016 19:03, "Craig Ringer" wrote:
> On 10 June 2016 at 18:56, John R Pierce wrote
On Thu, Jun 9, 2016 at 1:57 AM, Greg Navis wrote:
> Artur, no worries, I'm not writing any code ;-)
>
> I did the following:
>
> CREATE TYPE trgm_match AS (match TEXT, threshold NUMERIC);
I would probably use REAL, not NUMERIC. But maybe there is good
reason to use NUMERIC.
> CREATE OR REPLACE
On 10 June 2016 at 18:56, John R Pierce wrote:
> On 6/10/2016 2:18 AM, Sridhar N Bamandlapally wrote:
>
>> This/These will be performed in Production to clean-up archive which will
>> not be sync with Archive/DW DB only
>>
>> one heads-up is Archive/DW DB may need to build WITHOUT CONSTRAINTS
>>
On 06/10/2016 04:23 AM, Moreno Andreo wrote:
Hi Yogesh,
here
https://www.postgresql.org/docs/9.3/static/release.html
you can find all release notes, including changelogs for all versions.
Also a one page version:
https://bucardo.org/postgres_all_versions.html
HTH,
Moreno.
Il 10/06/20
Hi Yogesh,
here
https://www.postgresql.org/docs/9.3/static/release.html
you can find all release notes, including changelogs for all
versions.
HTH,
Moreno.
Il 10/06/2016 13:17, Yogesh Sharma ha scritto:
Dear All,
Thanks for your support.
Could you please assist for changelog version option used to find the
differences between the versions.
In addition we required information of changes done in all releases from 8.1.2
to 9.3.6.
Thanks in advance .
Regards,
Yogesh
On 6/10/2016 2:18 AM, Sridhar N Bamandlapally wrote:
This/These will be performed in Production to clean-up archive which
will not be sync with Archive/DW DB only
one heads-up is Archive/DW DB may need to build WITHOUT CONSTRAINTS
May need to introduce ARCHIVE system/tag in pg_hba.conf
there
One thing looks possible ( feature not available), just an idea
example/syntax:
BEGIN NOARCHIVE;
--- transaction-1
--- transaction-2
.
.
--- transaction-N
END;
This/These will be performed in Production to clean-up archive which will
not be sync with Archive/DW DB only
one heads-up
On 10 June 2016 at 16:11, Sridhar N Bamandlapally
wrote:
> Hi
>
> Is there any feature in PostgreSQL where online DW (Dataware housing) is
> possible ?
>
> am looking for scenario like
>
> 1. Production DB will have CURRENT + LAST 7 DAYS data only
>
> 2. Archive/DW DB will have CURRENT + COMPLETE
On 6/10/2016 1:11 AM, Sridhar N Bamandlapally wrote:
Is there any feature in PostgreSQL where online DW (Dataware housing)
is possible ?
am looking for scenario like
1. Production DB will have CURRENT + LAST 7 DAYS data only
2. Archive/DW DB will have CURRENT + COMPLETE HISTORY
expecting som
Hi
Is there any feature in PostgreSQL where online DW (Dataware housing) is
possible ?
am looking for scenario like
1. Production DB will have CURRENT + LAST 7 DAYS data only
2. Archive/DW DB will have CURRENT + COMPLETE HISTORY
expecting something like streaming, but not ETL
Thanks
Sridhar
32 matches
Mail list logo