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
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
Sven Geggus 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 to be able to explicit
> 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 fee
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é" 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 <
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,
"SESSION
Hi Leonardo:
On Thu, Mar 26, 2015 at 6:12 PM, "Leonardo M. Ramé" 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 sessions WHE
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: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::characte
On Thu, 26 Mar 2015 14:12:36 -0300
"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,
>CONSTRAIN
El 26/03/15 a las 14:17, Ashesh Vashi escibió:
[Sent through mobile]
On Mar 26, 2015 10:43 PM, Leonardo M. Ramé mailto:l.r...@griensu.com>> wrote:
>
> Ok, I have this table:
>
> CREATE TABLE sessions
> (
> "SESSIONID" integer NOT NULL,
> "SESSIONTIMESTAMP" character varying(45) NOT N
[Sent through mobile]
On Mar 26, 2015 10:43 PM, 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,
> CO
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
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 complete
On March 25, 2015 09:31:24 PM David G. Johnston wrote:
> On Wed, Mar 25, 2015 at 8:58 PM, Mitu Verma 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 into an
> existin
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 wa
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. Run
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
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 cac
On 26 March 2015 at 19:08, Peter Mogensen 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 r
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 Thu, 26 Mar 2015 03:58:59 +
Mitu Verma 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
> because of which tabl
(Please reply-to-all to keep the thread on pgsql-general)
On 26 March 2015 at 18:32, Peter Mogensen 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 replic
On 26 March 2015 at 15:57, Peter Mogensen 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 change
> On 26 Mar 2015, at 1:25, Lavrenz, Steven M 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 channels
> are su
25 matches
Mail list logo
