Re: To all who wish to unsubscribe
On Mon, Nov 20, 2017 at 1:11 PM, Tom Lane wrote: > Vick Khera writes: > > Did the list software change? All my messages from here are not being > properly auto-files by the filter I have set up. > > Yes - did you not see either of the "migration to pglister" messages? > There's a summary of the changes at > > https://wiki.postgresql.org/wiki/PGLister_Announce > > Those looking to unsubscribe should also read that page. Sending > "unsubscribe" messages to the list will not accomplish anything > except to annoy the rest of the list membership. > It might get you a video full of foul language :) https://youtu.be/eC9rmsI7dnw?t=1m42s > > regards, tom lane > > -- Carl K
Re: migrations (was Re: To all who wish to unsubscribe)
I would like to remind everyone that a) we are all friends, and b) we don't need to reply to everything. Now for some humour https://xkcd.com/386/ "someone is wrong on the internet" Tail of Banana talk, just before Get me off your ... very strong language https://youtu.be/eC9rmsI7dnw?t=1m32s (I make videos of presentations, that is a friend giving me something to test new video mixing software.) And thank you list admins for doing your admin things, both technical and soft. On Wed, Nov 22, 2017 at 8:43 AM, Tom Lane wrote: > Geoff Winkless writes: > > On 22 November 2017 at 14:19, Vick Khera wrote: > >> This sounds to me like you're going to run afoul of CAN-SPAM > unsubscribe rules. You should re-think this workflow. > > > CAN-SPAM only applies to commercial email, "the primary purpose of > > which is the commercial advertisement or promotion of a commercial > > product or service”. This is a discussion mailing list and as such > > does not come under the remit of CAN-SPAM. > > Even if it did, you do not need a community account to unsubscribe, > only if you want to adjust your subscription in some other way. > > regards, tom lane > > -- Carl K
Re: a back up question
Nothing wrong with lots of tables and data. Don't impose any constraints on your problem you don't need to. Like what are you backing up to?$400 for a 1T ssd or $80 fo a 2T usb3 spinny disk. If you are backing up while the db is being updated, you need to make sure updates are queued until the backup is done. don't mess with that process. personally I would assume the db is always being updated and expect that. On Tue, Dec 5, 2017 at 3:52 PM, Martin Mueller < martinmuel...@northwestern.edu> wrote: > Are there rules for thumb for deciding when you can dump a whole database > and when you’d be better off dumping groups of tables? I have a database > that has around 100 tables, some of them quite large, and right now the > data directory is well over 100GB. My hunch is that I should divide and > conquer, but I don’t have a clear sense of what counts as “too big” these > days. Nor do I have a clear sense of whether the constraints have to do > with overall size, the number of tables, or machine memory (my machine has > 32GB of memory). > > > > Is 10GB a good practical limit to keep in mind? > > > > > -- Carl K
Re: a back up question
On Tue, Dec 5, 2017 at 4:15 PM, Alvaro Herrera wrote: > Carl Karsten wrote: > > Nothing wrong with lots of tables and data. > > > > Don't impose any constraints on your problem you don't need to. > > > > Like what are you backing up to?$400 for a 1T ssd or $80 fo a 2T usb3 > > spinny disk. > > > > If you are backing up while the db is being updated, you need to make > sure > > updates are queued until the backup is done. don't mess with that > > process. personally I would assume the db is always being updated and > > expect that. > > A backup generated by pg_dump never includes writes that are in flight > while the backup is being taken. That would make the backup absolutely > worthless! > Hmm, i kinda glossed over my point: if you come up with your own process to chop up the backup into little pieces, you risk letting writes in, and then yeah, worthless. -- Carl K
