[GENERAL] PLV8 and JS exports / referencing
So, I was trying to use mustache.js in PG by defining a V8 function that
imports it. Older versions worked fine, but in newer versions they use a class
factory and I can't figure out how to reference the mustache stuff that it
creates. Apparently I need to know how our V8 implementation does exports.
Here's the top of mustache.js with the class factory, and my attempted
reference at the bottom (the return which gives me undefined reference). I
tried various invocations and couldn't quite get it. I ended up hacking it up
to remove the factory and change it to explicitly declare a variable to make it
work, but I'd like to avoid that if possible.
If anyone wants to try to reproduce it, replace the snipped out bits using the
contents of mustache.js from http://github.com/janl/mustache.js
CREATE OR REPLACE FUNCTION mustache(template text, view json)
RETURNS TEXT
LANGUAGE plv8
IMMUTABLE
STRICT
AS $$
(function (global, factory) {
if (typeof exports === "object" && exports) {
factory(exports); // CommonJS
} else if (typeof define === "function" && define.amd) {
define(['exports'], factory); // AMD
} else {
factory(global.Mustache = {}); //
Re: [GENERAL] Incomplete startup packet help needed
On Thu, 6 Nov 2014 13:40:14 +0100 Francisco Olarte wrote: > Hi Juan Antonio: > > On Tue, Nov 4, 2014 at 9:54 PM, memtec > wrote: > > > You can force this message executing: > > $ echo | nc SERVER_IP 5432 > > 2014-11-04 21:44:37 CET LOG: incomplete startup packet > > > > What do you need help on? PG uses a binary protocol, you sent it bad data > ( I think this will open connection, send a \n byte, shutdown it ) and it > complained in the first check ( I suppose it is due to the connection > expecting an startup packet with a given format, and it couldn't get it > because it's longer than 1 byte, everything is prety well documented, RTFM > ). FYI: It's very common to get these messages in your log file if you have something like nagios or other monitoring tools checking to see if postgres is up. This is because many of them just test to see if something is listening on the port, without opening a proper postgres connection (i.e. telnet localhost 5432). The just connect to the port then disconnect without sending any data of any kind. -- Jon Erdman (aka StuckMojo) PostgreSQL Zealot pgpgN7OK4rPmE.pgp Description: PGP signature
[GENERAL] Chained slaves smaller?
Hi, I have SR set up in a couple of datacenters, where there’s a master in DC_A with 2 slaves, and a 3rd slave off that master in DC_ B. Also, in DC_B I have 2 slaves chained off the “local master”. Our main database is ~551GB in DC_A and on the replica in B that is subscribed to the real master. However, on one of the chained slaves in DC_B that database is only 484GB. The only thing different about this smaller slave is that it was created by taking a basebackup from the “local master” in DC_B rather than sucking it over the WAN from the true master in DC_A. This makes no sense to me since I thought SR replicas are bit for bit copies, so I’m somewhat concerned. Any ideas how this could be? — Jon Erdman Postgres Zealot -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Chained slaves smaller?
Nevermind. Turns out it was on the wrong timeline and replication was broken. It was smaller because it was 77 days behind. (facepalm) > On Jun 23, 2017, at 2:40 PM, Jon Erdman wrote: > > Hi, > > I have SR set up in a couple of datacenters, where there’s a master in DC_A > with 2 slaves, and a 3rd slave off that master in DC_ B. Also, in DC_B I have > 2 slaves chained off the “local master”. Our main database is ~551GB in DC_A > and on the replica in B that is subscribed to the real master. However, on > one of the chained slaves in DC_B that database is only 484GB. The only thing > different about this smaller slave is that it was created by taking a > basebackup from the “local master” in DC_B rather than sucking it over the > WAN from the true master in DC_A. > > This makes no sense to me since I thought SR replicas are bit for bit copies, > so I’m somewhat concerned. Any ideas how this could be? > — > Jon Erdman > Postgres Zealot -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
