On 26 March 2015 at 15:57, Peter Mogensen a...@one.com wrote:
In standard Postgres one-way replication you can get the
txid_snapshot_xmin() of the master on the slave. But with BDR, all nodes
have their own txids. So the above scheme doesn't work unless you can get
the txid which applied the
On Thu, 26 Mar 2015 03:58:59 +
Mitu Verma mitu.ve...@ericsson.com wrote:
We have a customer complaining about the time taken by one of the application
scripts while deleting older data from the log tables.
During the deletion, customer reported that he often sees the below error and
(Please reply-to-all to keep the thread on pgsql-general)
On 26 March 2015 at 18:32, Peter Mogensen a...@one.com wrote:
On 2015-03-26 10:14, Craig Ringer wrote:
I see what you're getting at. You want to prevent stale data from being
reinsterted into a cache by a read from an asynchronous
On 26 March 2015 at 19:08, Peter Mogensen a...@one.com wrote:
On 2015-03-26 11:57, Craig Ringer wrote:
If that's the case then BDR shouldn't make any difference.
It does. Because now with BDR you can't compare txid_current() as saved on
the master with txid_snapshot_xmin() as read by the
On 2015-03-26 19:56:23 +0800, Craig Ringer wrote:
Right. So that's where I think you need to look into commit timestamps as
an alternative, as outlined in prior mail.
I've only quickly skimmed this thread, but it sounds to me you just
could create a logical slot in the standby and do the cache
On 2015-03-26 11:57, Craig Ringer wrote:
If that's the case then BDR shouldn't make any difference.
It does. Because now with BDR you can't compare txid_current() as saved
on the master with txid_snapshot_xmin() as read by the replica.
If however, you could save the txid associated with the
On 2015-03-26 12:56, Craig Ringer wrote:
My comment was with regards to it being on the local node. A master
and synchronous replica isn't a local-node to local-node scenario.
No. But all I'm exploiting is that change events to the local node see
the same logical clock as SELECT statements
Another option, depending on the nature of the data and deletes, would be to
partition the table. I created 7 tables that inherited from the original, one
table for each day of the week. A nightly cron job then runs, leaving alone
yesterday's and today's tables but truncating the other 5.
Hi Leonardo:
On Thu, Mar 26, 2015 at 6:12 PM, Leonardo M. Ramé l.r...@griensu.com wrote:
DELETE From sessions WHERE SESSIONTIMESTAMP '2010-01-01 10:02:02'
ERROR: column sessiontimestamp does not exist
LINE 1: DELETE From sessions WHERE SESSIONTIMESTAMP '2010-01-01 10...
...
DELETE From
El 26/03/15 a las 14:17, Ashesh Vashi escibió:
[Sent through mobile]
On Mar 26, 2015 10:43 PM, Leonardo M. Ramé l.r...@griensu.com
mailto:l.r...@griensu.com wrote:
Ok, I have this table:
CREATE TABLE sessions
(
SESSIONID integer NOT NULL,
SESSIONTIMESTAMP character
On 03/26/2015 10:21 AM, Leonardo M. Ramé wrote:
El 26/03/15 a las 14:18, Adrian Klaver escibió:
On 03/26/2015 10:12 AM, Leonardo M. Ramé wrote:
Ok, I have this table:
CREATE TABLE sessions
(
SESSIONID integer NOT NULL,
SESSIONTIMESTAMP character varying(45) NOT NULL,
SESSIONDATA
update master_items set feedback_to_de = 'Yes'
--Query returned successfully: 591268 rows affected, 1589335 ms execution time.
Here you should better use
update master_items set feedback_to_de = 'Yes' WHERE feedback_to_de 'Yes'
OR
update master_items set feedback_to_de 'Yes' WHERE
On Thu, 26 Mar 2015 14:12:36 -0300
Leonardo M. Ramé l.r...@griensu.com wrote:
Ok, I have this table:
CREATE TABLE sessions
(
SESSIONID integer NOT NULL,
SESSIONTIMESTAMP character varying(45) NOT NULL,
SESSIONDATA character varying(200) DEFAULT NULL::character varying,
[Sent through mobile]
On Mar 26, 2015 10:43 PM, Leonardo M. Ramé l.r...@griensu.com wrote:
Ok, I have this table:
CREATE TABLE sessions
(
SESSIONID integer NOT NULL,
SESSIONTIMESTAMP character varying(45) NOT NULL,
SESSIONDATA character varying(200) DEFAULT NULL::character varying,
On 03/26/2015 10:12 AM, Leonardo M. Ramé wrote:
Ok, I have this table:
CREATE TABLE sessions
(
SESSIONID integer NOT NULL,
SESSIONTIMESTAMP character varying(45) NOT NULL,
SESSIONDATA character varying(200) DEFAULT NULL::character varying,
CONSTRAINT sessions_pkey PRIMARY KEY
El 26/03/15 a las 14:23, Francisco Olarte escibió:
Hi Leonardo:
On Thu, Mar 26, 2015 at 6:12 PM, Leonardo M. Ramé l.r...@griensu.com wrote:
DELETE From sessions WHERE SESSIONTIMESTAMP '2010-01-01 10:02:02'
ERROR: column sessiontimestamp does not exist
LINE 1: DELETE From sessions WHERE
Ok, I have this table:
CREATE TABLE sessions
(
SESSIONID integer NOT NULL,
SESSIONTIMESTAMP character varying(45) NOT NULL,
SESSIONDATA character varying(200) DEFAULT NULL::character varying,
CONSTRAINT sessions_pkey PRIMARY KEY (SESSIONID)
)
Now, when I do:
DELETE From sessions WHERE
El 26/03/15 a las 14:18, Adrian Klaver escibió:
On 03/26/2015 10:12 AM, Leonardo M. Ramé wrote:
Ok, I have this table:
CREATE TABLE sessions
(
SESSIONID integer NOT NULL,
SESSIONTIMESTAMP character varying(45) NOT NULL,
SESSIONDATA character varying(200) DEFAULT NULL::character
Sven Geggus li...@fuchsschwanzdomain.de wrote:
So here is my question:
Would it be possible to have a setup, where one master data database will
act in the above matter (still running osm2pgsl) but will also provide
publicly availabe data for log-shipping standby servers?
We would need
Hi Leonardo:
Aha, the problem, then, was caused by the Create statement. This table was
copied from a MySql dump where all columns were named column.
In part. The problem was caused by non-uniform quote usaga, quotes in
create, no quotes elsewhere.
Had you used quotes in delete or not used
If so, I’d love any pointers or gotchas that it took doing to work out.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 26 Mar 2015, at 1:25, Lavrenz, Steven M slavr...@purdue.edu wrote:
Alright everyone, this is a doozy of a problem. I am new to Postgres so I
appreciate patience/understanding. I have a database of hardware objects,
each of which has several different “channels”. Once per day, these
On 2015-03-26 12:56, Craig Ringer wrote:
At this point I think commit timestamps are likely to be your best
bet, and certainly what you should start looking into first.
I've thought about this, but it seems that since these timestamps are
made on the node doing the change and you have no
On March 25, 2015 09:31:24 PM David G. Johnston wrote:
On Wed, Mar 25, 2015 at 8:58 PM, Mitu Verma mitu.ve...@ericsson.com wrote:
Correcting the subject
And this is why it is considered good form to do compose new message
instead of replying to an existing one. Injecting your new topic
Hello,
I have a question regarding log-shipping replication, but let me first
explain what I currently do.
Usually Openstreetmap Tile Servers are currently set up using a
PostgreSQL/Postgis Database which stores the data need for rendering raster
map-tiles.
After the initial import of a
25 matches
Mail list logo
