| http { | |
| ... | |
| # redirect map in http block - remove fbclid argument from the end | |
| map $request_uri $redirect_fbclid { | |
| "~^(.*?)([?&]fbclid=[a-zA-Z0-9_-]+)$" $1; | |
| } | |
| ... |
A modest proposal for a first-class destiny operator equivalent in Svelte components that's also valid JS.
Svelte 2 has a concept of computed properties, which are updated whenever their inputs change. They're powerful, if a little boilerplatey, but there's currently no place for them in Svelte 3.
This means that we have to use functions. Instead of this...
<!-- Svelte 2 -->
<h1>HELLO {NAME}!</h1>
Our database has fast rate of transactions. I did think, that such rate is impossible, until I've seen it with my eyes. I've been instinctively insisting on fixing code to reduce number of transactions (sometimes successful), but never checked what are consequences for database.
One of consequences is fast rate of autovacuum VACUUM FREEZE.
VACUUM is essential for Postgresql to mark non-visible rows (those which were normal rows, but became invisible because of update or delete) as visible to PG. Note, that they become visible only to PG, previously PG didn't know they are free for use, and thus had allocated extra buffers in the end of a table for any new rows (inserts or updates). PG not knowing which rows are free for use is another problem, which causes table bloat, which deserves another post.
VACUUM FREEZE is special kind of VACUUM. From resource usage perspective, it differs from VACUUM by that it has to scan full table (normal VACUUM processes only buffers known to contain at
| #lang racket/gui | |
| (define chess-piece-snip-class | |
| (make-object | |
| (class snip-class% | |
| (super-new) | |
| (send this set-classname "chess-piece-snip")))) | |
| (send (get-the-snip-class-list) add chess-piece-snip-class) |
| package main | |
| import ( | |
| "net/http" | |
| "compress/gzip" | |
| "io/ioutil" | |
| "strings" | |
| "sync" | |
| "io" | |
| ) |
This is a slightly stripped down version from our internal bug tracker. The point of posting this publicly is part FYI, part peer review. I'm hoping someone can look at this, disagree, and tell me all the downsides of using the C locale or point out things I've misunderstood. The Recommendations section in particular is contextualized by our database serving a SaaS product for users from many different locales, thus making locale a render level concern. YMMV, caveat emptor, etc.
Collation defines the character ordering for textual data. For Postgres, https://www.postgresql.org/docs/current/static/locale.html:
The locale settings influence the following SQL features:
- Sort order in queries using ORDER BY or the standard comparison operators on textual data
- The
upper,lower, andinitcapfunctions
| MIT License | |
| Copyright (c) 2018 Noel Bundick | |
| Permission is hereby granted, free of charge, to any person obtaining a copy | |
| of this software and associated documentation files (the "Software"), to deal | |
| in the Software without restriction, including without limitation the rights | |
| to use, copy, modify, merge, publish, distribute, sublicense, and/or sell | |
| copies of the Software, and to permit persons to whom the Software is | |
| furnished to do so, subject to the following conditions: |
| package main | |
| // functionally same as `main.go`, with different trigger definition | |
| import ( | |
| "database/sql" | |
| "fmt" | |
| sqlite "github.com/mattn/go-sqlite3" | |
| "log" | |
| "os" | |
| ) |
| package main | |
| import ( | |
| "crypto/tls" | |
| "flag" | |
| "fmt" | |
| "log" | |
| "net/http" | |
| "os" | |
| "os/user" |