Cloud Vision V1 API - Class Google::Cloud::Vision::V1::ImageAnnotator::Operations (v0.6.4)
Reference documentation and code samples for the Cloud Vision V1 API class Google::Cloud::Vision::V1::ImageAnnotator::Operations.
Service that implements Longrunning Operations API.
Inherits
- Object
Methods
.configure
def self.configure() { |config| ... } -> Operations::Configuration
Configuration for the ImageAnnotator Operations API.
- (config) — Configure the Operations client.
- config (Operations::Configuration)
#cancel_operation
def cancel_operation(request, options = nil) -> ::Google::Protobuf::Empty
def cancel_operation(name: nil) -> ::Google::Protobuf::Empty
Starts asynchronous cancellation on a long-running operation. The server
makes a best effort to cancel the operation, but success is not
guaranteed. If the server doesn't support this method, it returns
google.rpc.Code.UNIMPLEMENTED
. Clients can use
Operations.GetOperation or
other methods to check whether the cancellation succeeded or whether the
operation completed despite cancellation. On successful cancellation,
the operation is not deleted; instead, it becomes an operation with
an Operation.error value with a google.rpc.Status.code of 1,
corresponding to Code.CANCELLED
.
def cancel_operation(request, options = nil) -> ::Google::Protobuf::Empty
cancel_operation
via a request object, either of type
Longrunning::CancelOperationRequest or an equivalent Hash.
- request (::Google::Longrunning::CancelOperationRequest, ::Hash) — A request object representing the call parameters. Required. To specify no parameters, or to keep all the default parameter values, pass an empty Hash.
- options (::Gapic::CallOptions, ::Hash) — Overrides the default settings for this call, e.g, timeout, retries, etc. Optional.
def cancel_operation(name: nil) -> ::Google::Protobuf::Empty
cancel_operation
via keyword arguments. Note that at
least one keyword argument is required. To specify no parameters, or to keep all
the default parameter values, pass an empty Hash as a request object (see above).
- name (::String) — The name of the operation resource to be cancelled.
- (response, operation) — Access the result along with the RPC operation
- response (::Google::Protobuf::Empty)
- operation (::GRPC::ActiveCall::Operation)
- (::Google::Cloud::Error) — if the RPC is aborted.
Basic example
require "google/longrunning" # Create a client object. The client can be reused for multiple calls. client = Google::Longrunning::Operations::Client.new # Create a request. To set request fields, pass in keyword arguments. request = Google::Longrunning::CancelOperationRequest.new # Call the cancel_operation method. result = client.cancel_operation request # The returned object is of type Google::Protobuf::Empty. p result
#configure
def configure() { |config| ... } -> Operations::Configuration
Configure the ImageAnnotator Operations instance.
The configuration is set to the derived mode, meaning that values can be changed, but structural changes (adding new fields, etc.) are not allowed. Structural changes should be made on Operations.configure.
- (config) — Configure the Operations client.
- config (Operations::Configuration)
#delete_operation
def delete_operation(request, options = nil) -> ::Google::Protobuf::Empty
def delete_operation(name: nil) -> ::Google::Protobuf::Empty
Deletes a long-running operation. This method indicates that the client is
no longer interested in the operation result. It does not cancel the
operation. If the server doesn't support this method, it returns
google.rpc.Code.UNIMPLEMENTED
.
def delete_operation(request, options = nil) -> ::Google::Protobuf::Empty
delete_operation
via a request object, either of type
Longrunning::DeleteOperationRequest or an equivalent Hash.
- request (::Google::Longrunning::DeleteOperationRequest, ::Hash) — A request object representing the call parameters. Required. To specify no parameters, or to keep all the default parameter values, pass an empty Hash.
- options (::Gapic::CallOptions, ::Hash) — Overrides the default settings for this call, e.g, timeout, retries, etc. Optional.
def delete_operation(name: nil) -> ::Google::Protobuf::Empty
delete_operation
via keyword arguments. Note that at
least one keyword argument is required. To specify no parameters, or to keep all
the default parameter values, pass an empty Hash as a request object (see above).
- name (::String) — The name of the operation resource to be deleted.
- (response, operation) — Access the result along with the RPC operation
- response (::Google::Protobuf::Empty)
- operation (::GRPC::ActiveCall::Operation)
- (::Google::Cloud::Error) — if the RPC is aborted.
Basic example
require "google/longrunning" # Create a client object. The client can be reused for multiple calls. client = Google::Longrunning::Operations::Client.new # Create a request. To set request fields, pass in keyword arguments. request = Google::Longrunning::DeleteOperationRequest.new # Call the delete_operation method. result = client.delete_operation request # The returned object is of type Google::Protobuf::Empty. p result
#get_operation
def get_operation(request, options = nil) -> ::Gapic::Operation
def get_operation(name: nil) -> ::Gapic::Operation
Gets the latest state of a long-running operation. Clients can use this method to poll the operation result at intervals as recommended by the API service.
def get_operation(request, options = nil) -> ::Gapic::Operation
get_operation
via a request object, either of type
Longrunning::GetOperationRequest or an equivalent Hash.
- request (::Google::Longrunning::GetOperationRequest, ::Hash) — A request object representing the call parameters. Required. To specify no parameters, or to keep all the default parameter values, pass an empty Hash.
- options (::Gapic::CallOptions, ::Hash) — Overrides the default settings for this call, e.g, timeout, retries, etc. Optional.
def get_operation(name: nil) -> ::Gapic::Operation
get_operation
via keyword arguments. Note that at
least one keyword argument is required. To specify no parameters, or to keep all
the default parameter values, pass an empty Hash as a request object (see above).
- name (::String) — The name of the operation resource.
- (response, operation) — Access the result along with the RPC operation
- response (::Gapic::Operation)
- operation (::GRPC::ActiveCall::Operation)
- (::Gapic::Operation)
- (::Google::Cloud::Error) — if the RPC is aborted.
Basic example
require "google/longrunning" # Create a client object. The client can be reused for multiple calls. client = Google::Longrunning::Operations::Client.new # Create a request. To set request fields, pass in keyword arguments. request = Google::Longrunning::GetOperationRequest.new # Call the get_operation method. result = client.get_operation request # The returned object is of type Gapic::Operation. You can use this # object to check the status of an operation, cancel it, or wait # for results. Here is how to block until completion: result.wait_until_done! timeout: 60 if result.response? p result.response else puts "Error!" end
#initialize
def initialize() { |config| ... } -> Operations
Create a new Operations client object.
- (config) — Configure the Client client.
- config (Operations::Configuration)
- (Operations) — a new instance of Operations
#list_operations
def list_operations(request, options = nil) -> ::Gapic::PagedEnumerable<::Gapic::Operation>
def list_operations(name: nil, filter: nil, page_size: nil, page_token: nil) -> ::Gapic::PagedEnumerable<::Gapic::Operation>
Lists operations that match the specified filter in the request. If the
server doesn't support this method, it returns UNIMPLEMENTED
.
NOTE: the name
binding allows API services to override the binding
to use different resource name schemes, such as users//operations
. To
override the binding, API services can add a binding such as
"/v1/{name=users/}/operations"
to their service configuration.
For backwards compatibility, the default name includes the operations
collection id, however overriding users must ensure the name binding
is the parent resource, without the operations collection id.
def list_operations(request, options = nil) -> ::Gapic::PagedEnumerable<::Gapic::Operation>
list_operations
via a request object, either of type
Longrunning::ListOperationsRequest or an equivalent Hash.
- request (::Google::Longrunning::ListOperationsRequest, ::Hash) — A request object representing the call parameters. Required. To specify no parameters, or to keep all the default parameter values, pass an empty Hash.
- options (::Gapic::CallOptions, ::Hash) — Overrides the default settings for this call, e.g, timeout, retries, etc. Optional.
def list_operations(name: nil, filter: nil, page_size: nil, page_token: nil) -> ::Gapic::PagedEnumerable<::Gapic::Operation>
list_operations
via keyword arguments. Note that at
least one keyword argument is required. To specify no parameters, or to keep all
the default parameter values, pass an empty Hash as a request object (see above).
- name (::String) — The name of the operation's parent resource.
- filter (::String) — The standard list filter.
- page_size (::Integer) — The standard list page size.
- page_token (::String) — The standard list page token.
- (response, operation) — Access the result along with the RPC operation
- response (::Gapic::PagedEnumerable<::Gapic::Operation>)
- operation (::GRPC::ActiveCall::Operation)
- (::Gapic::PagedEnumerable<::Gapic::Operation>)
- (::Google::Cloud::Error) — if the RPC is aborted.
Basic example
require "google/longrunning" # Create a client object. The client can be reused for multiple calls. client = Google::Longrunning::Operations::Client.new # Create a request. To set request fields, pass in keyword arguments. request = Google::Longrunning::ListOperationsRequest.new # Call the list_operations method. result = client.list_operations request # The returned object is of type Gapic::PagedEnumerable. You can # iterate over all elements by calling #each, and the enumerable # will lazily make API calls to fetch subsequent pages. Other # methods are also available for managing paging directly. result.each do |response| # Each element is of type ::Google::Longrunning::Operation. p response end
#wait_operation
def wait_operation(request, options = nil) -> ::Gapic::Operation
def wait_operation(name: nil, timeout: nil) -> ::Gapic::Operation
Waits until the specified long-running operation is done or reaches at most
a specified timeout, returning the latest state. If the operation is
already done, the latest state is immediately returned. If the timeout
specified is greater than the default HTTP/RPC timeout, the HTTP/RPC
timeout is used. If the server does not support this method, it returns
google.rpc.Code.UNIMPLEMENTED
.
Note that this method is on a best-effort basis. It may return the latest
state before the specified timeout (including immediately), meaning even an
immediate response is no guarantee that the operation is done.
def wait_operation(request, options = nil) -> ::Gapic::Operation
wait_operation
via a request object, either of type
Longrunning::WaitOperationRequest or an equivalent Hash.
- request (::Google::Longrunning::WaitOperationRequest, ::Hash) — A request object representing the call parameters. Required. To specify no parameters, or to keep all the default parameter values, pass an empty Hash.
- options (::Gapic::CallOptions, ::Hash) — Overrides the default settings for this call, e.g, timeout, retries, etc. Optional.
def wait_operation(name: nil, timeout: nil) -> ::Gapic::Operation
wait_operation
via keyword arguments. Note that at
least one keyword argument is required. To specify no parameters, or to keep all
the default parameter values, pass an empty Hash as a request object (see above).
- name (::String) — The name of the operation resource to wait on.
- timeout (::Google::Protobuf::Duration, ::Hash) — The maximum duration to wait before timing out. If left blank, the wait will be at most the time permitted by the underlying HTTP/RPC protocol. If RPC context deadline is also specified, the shorter one will be used.
- (response, operation) — Access the result along with the RPC operation
- response (::Gapic::Operation)
- operation (::GRPC::ActiveCall::Operation)
- (::Gapic::Operation)
- (::Google::Cloud::Error) — if the RPC is aborted.
Basic example
require "google/longrunning" # Create a client object. The client can be reused for multiple calls. client = Google::Longrunning::Operations::Client.new # Create a request. To set request fields, pass in keyword arguments. request = Google::Longrunning::WaitOperationRequest.new # Call the wait_operation method. result = client.wait_operation request # The returned object is of type Gapic::Operation. You can use this # object to check the status of an operation, cancel it, or wait # for results. Here is how to block until completion: result.wait_until_done! timeout: 60 if result.response? p result.response else puts "Error!" end


my name is majd , I'm 26 years old ,I studied a civil engineering and worked for two years as a structural designer engineer , my goals in life is folloing my passion and learning new things
my name is majd , I'm 26 years old ,I studied a civil engineering and worked for two years as a structural designer engineer , my goals in life is folloing my passion and learning new things


As a smart phone user, there are very few things that are still really frustrating. By and large, the operating systems for most major smartphones are, at this point, polished incredibly well. However, the process of switching between wifi and cellular network coverage is still mistifyingly bad. As the phone loses wifi strength, the transmission of data becomes increasingly less reliable on the poor network, but there’s no attempt made to establish a cellular connection.
It’s like my phone is absolutely startled that I walk around with it while accessing data. It always seems to act like nothing of this sort had ever happenned before.
I think this can be fixed by using empirical models of where connections are dropped to perdict regions where wifi is likely to fail around a cell phone user. Using this information, I want to create a library that will allow application developers to take predictive action when their users are about to enter rough internet seas.
I think this project will take roughly three phases.
Aquire data for as many network/wifi transitions as possible to model where these transitions occur.
As of the writing, it’s unclear what the uncertainty for this transition is, when the effective wifi transmission stops, and when the cell network is switched over to. We’d like to have enough data, if only for a relatively small geographic area initially, that we can effectively model the wireless characteristics of a pilot area.
Model the pilot area to generate regions of likely network failure.
In order for the data to be meaningfully used, it needs to be converted from a large series of points to a set of regions where connection failure is likely.  This step will also involve the deployment of a backend capable of repsonding to latitude longitude pairs with sets of regions.
Deploy a library which responds to the set of regions and takes meaningful action to minimize disruption.
Without the ability to use this data in real time, the data is really only useful to IT people trying to see where their network is covered. We’d like to develop a library that will begin cacheing in advance when nearing a poor service area and will reduce cacheing in a good service area. I’d like to implement switching from wifi to WWAN programaticaly, but that’s likely impossible without the cooperation of the phone providers.
Spotter is currently part of the way through the first step. The project is working on the simulator, but it’s not yet tested on an actual iPhone, pending an Apple developer license. With some luck, we can begin limited beta testing of the client by the end of the month.
I’m currently set up to use Parse.com as the backend for this project, but this could change as the project scales. Parse has the immense bennefit of providing an easy to use cross platform library allowing us to potentially extend this project to other device types as time goes forward. I’m quite open to hearing other possible alternatives, but it certainly seems like Parse is the best solution for now.
Questions/comments? Please log an issue on our github https://github.com/estsauver/spotter, I’d love to hear from you. If you don’t have to


data class Info
Class that represents User info. |
|
data class UserOptionalParameters : OptionalParameters
Class that contains information about all the OptionalParameters the User module requests can have. It also knows how this information should be constructed in the body of the request. |
|
data class UserResponse
Class that represents the User response from the server. |


Toggle navigation
Moody
Home
Register Here
Login
About
DESCRIPTIVE TERMS
Zoe
Paavo
different
value
throw
juggernaut
Home
teams
sorts
Got
progressive
good
Driver
many
same
Terrace
last
fingers
Bedford
play
Much
State
loads
Prelude
tales
solid
decade
fit
killer
Therapy
pack
something
spectrum
debut
crowd
years
Station
HQ
peaceful
trance
pop
voice
cant
Alchemy
Beyond
excitement
much
Perth
lasers
quintessential
Genres:
trance
dance
electronic
Related Artists:
Copyright © RKELLY 2015


Jacqui's Shop
Left
Right
Reveal
Push
Overlay
Left Panel
This is the the left panel
Close
Right Panel
This is the the right panel
Close


Includes
Meals | Pick-Up & Drop | Activities | Guide | Accommodation
Over View:
- Trip Starting From: Leh
- Trip Location: Kargil
- Available Group Departure:
- Jan: 13,14,20,21,26,27,28
- Feb: 2,3
STORIES
{% for item in okay %}*{{item.0}}
{{item.1}}
Meals | Pick-Up & Drop | Activities | Guide | Accommodation
Over View:
*{{item.0}}
{{item.1}}


THE FUNERAL
A film review by Vince Waldron
Copyright 1997 Vince Waldron
The Funeral finds B-movie director turned indie auteur Abel Ferrara returning to the gangster film, the genre that provided the setting for his barely-noticed 1990 B-movie masterwork, "King of New York." But despite the presence of Christopher Walken at the center of both films, Ferrara's latest meditation on murder, morality and the nature of sin bears a much stronger kinship to the director's more recent philosophical tracts, "The Addiction" and "Bad Lieutenant," And, much as I admire the director's efforts to tackle the spiritual and moral underpinnings that lie beneath the surface of such durable staples of the B-movie maker's palatte as gangster films, vampire movies and urban cop melodramas, I'm sorry to observe that thus far I've found the director's genre-bending experiments an uneasy mix, burdened by far too much self-conscious talk and not nearly enough character-driven action. Which is shame, since Ferrara demonstrates as sure a grasp of pulp character and convention as any American director since Sam Fuller, another director who rarely shied from exploring the multiple layers of his pulp subject matter, though rarely at the expense of its relentless momentum. But in age when so many independent film makers seem content to set their sights no higher than emulating the flash and fire of Quentin Tarantino, I suppose I can hardly complain when a director of Ferrara's talent and ambition chooses to pattern himself after Robert Bresson.
-- Please reply directly to me at:
<EMAIL_ADDRESS>Vince Waldron
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


Hello There 👋
My name isAhmed Sanad
Working with passion as full time developer. I have a diverse set of skills like design, HTML, CSS, Javascript and much more libraries and tools for both front-end & back-end which comes all togther to deliver Working with mastery and commitment.
About
Father of two daughters, holder of a Bachelor of Science in Chemistry, which was the basis of my education on analyzing problems and working to find a logical solution to them. I learned coding by myself Because of my passion for software.
Tools & Skills
C
HTML
CSS
Javascript
React.js
Node.js
Express
MySQL
MongoDB
Git


We got systems!
- synergize bricks-and-clicks systems
- iterate strategic niches
- deliver visionary portals
- transform cross-platform supply-chains
- target 24/365 technologies
- envisioneer impactful web-readiness
- brand value-added infomediaries
- leverage front-end experiences
- facilitate end-to-end paradigms
- incubate end-to-end e-business
- mesh extensible e-services
- engineer sexy platforms


| PostgreSQL 9.6.15 Documentation | |||
|---|---|---|---|
| Prev | Up | Chapter 28. Monitoring Database Activity | Next |
PostgreSQL's statistics collector is a subsystem that supports collection and reporting of information about server activity. Presently, the collector can count accesses to tables and indexes in both disk-block and individual-row terms. It also tracks the total number of rows in each table, and information about vacuum and analyze actions for each table. It can also count calls to user-defined functions and the total time spent in each one.
PostgreSQL also supports reporting dynamic information about exactly what is going on in the system right now, such as the exact command currently being executed by other server processes, and which other connections exist in the system. This facility is independent of the collector process.
Since collection of statistics adds some overhead to query execution, the system can be configured to collect or not collect information. This is controlled by configuration parameters that are normally set in postgresql.conf. (See Chapter 19 for details about setting configuration parameters.)
The parameter track_activities enables monitoring of the current command being executed by any server process.
The parameter track_counts controls whether statistics are collected about table and index accesses.
The parameter track_functions enables tracking of usage of user-defined functions.
The parameter track_io_timing enables monitoring of block read and write times.
Normally these parameters are set in postgresql.conf so that they apply to all server processes, but it is possible to turn them on or off in individual sessions using the SET command. (To prevent ordinary users from hiding their activity from the administrator, only superusers are allowed to change these parameters with SET.)
The statistics collector transmits the collected information to other PostgreSQL processes through temporary files. These files are stored in the directory named by the stats_temp_directory parameter, pg_stat_tmp by default. For better performance, stats_temp_directory can be pointed at a RAM-based file system, decreasing physical I/O requirements. When the server shuts down cleanly, a permanent copy of the statistics data is stored in the pg_stat subdirectory, so that statistics can be retained across server restarts. When recovery is performed at server start (e.g. after immediate shutdown, server crash, and point-in-time recovery), all statistics counters are reset.
Several predefined views, listed in Table 28-1, are available to show the current state of the system. There are also several other views, listed in Table 28-2, available to show the results of statistics collection. Alternatively, one can build custom views using the underlying statistics functions, as discussed in Section 28.2.3.
When using the statistics to monitor collected data, it is important to realize that the information does not update instantaneously. Each individual server process transmits new statistical counts to the collector just before going idle; so a query or transaction still in progress does not affect the displayed totals. Also, the collector itself emits a new report at most once per PGSTAT_STAT_INTERVAL milliseconds (500 ms unless altered while building the server). So the displayed information lags behind actual activity. However, current-query information collected by track_activities is always up-to-date.
Another important point is that when a server process is asked to display
any of these statistics, it first fetches the most recent report emitted by
the collector process and then continues to use this snapshot for all
statistical views and functions until the end of its current transaction.
So the statistics will show static information as long as you continue the
current transaction. Similarly, information about the current queries of
all sessions is collected when any such information is first requested
within a transaction, and the same information will be displayed throughout
the transaction.
This is a feature, not a bug, because it allows you to perform several
queries on the statistics and correlate the results without worrying that
the numbers are changing underneath you. But if you want to see new
results with each query, be sure to do the queries outside any transaction
block. Alternatively, you can invoke
pg_stat_clear_snapshot
(), which will discard the
current transaction's statistics snapshot (if any). The next use of
statistical information will cause a new snapshot to be fetched.
A transaction can also see its own statistics (as yet untransmitted to the collector) in the views pg_stat_xact_all_tables, pg_stat_xact_sys_tables, pg_stat_xact_user_tables, and pg_stat_xact_user_functions. These numbers do not act as stated above; instead they update continuously throughout the transaction.
Table 28-1. Dynamic Statistics Views
| View Name | Description |
|---|---|
| pg_stat_activity | One row per server process, showing information related to the current activity of that process, such as state and current query. See pg_stat_activity for details. |
| pg_stat_replication | One row per WAL sender process, showing statistics about replication to that sender's connected standby server. See pg_stat_replication for details. |
| pg_stat_wal_receiver | Only one row, showing statistics about the WAL receiver from that receiver's connected server. See pg_stat_wal_receiver for details. |
| pg_stat_ssl | One row per connection (regular and replication), showing information about SSL used on this connection. See pg_stat_ssl for details. |
| pg_stat_progress_vacuum | One row for each backend (including autovacuum worker processes) running VACUUM, showing current progress. See Section 28.4.1. |
Table 28-2. Collected Statistics Views
| View Name | Description |
|---|---|
| pg_stat_archiver | One row only, showing statistics about the WAL archiver process's activity. See pg_stat_archiver for details. |
| pg_stat_bgwriter | One row only, showing statistics about the background writer process's activity. See pg_stat_bgwriter for details. |
| pg_stat_database | One row per database, showing database-wide statistics. See pg_stat_database for details. |
| pg_stat_database_conflicts | One row per database, showing database-wide statistics about query cancels due to conflict with recovery on standby servers. See pg_stat_database_conflicts for details. |
| pg_stat_all_tables | One row for each table in the current database, showing statistics about accesses to that specific table. See pg_stat_all_tables for details. |
| pg_stat_sys_tables | Same as pg_stat_all_tables, except that only system tables are shown. |
| pg_stat_user_tables | Same as pg_stat_all_tables, except that only user tables are shown. |
| pg_stat_xact_all_tables | Similar to pg_stat_all_tables, but counts actions taken so far within the current transaction (which are not yet included in pg_stat_all_tables and related views). The columns for numbers of live and dead rows and vacuum and analyze actions are not present in this view. |
| pg_stat_xact_sys_tables | Same as pg_stat_xact_all_tables, except that only system tables are shown. |
| pg_stat_xact_user_tables | Same as pg_stat_xact_all_tables, except that only user tables are shown. |
| pg_stat_all_indexes | One row for each index in the current database, showing statistics about accesses to that specific index. See pg_stat_all_indexes for details. |
| pg_stat_sys_indexes | Same as pg_stat_all_indexes, except that only indexes on system tables are shown. |
| pg_stat_user_indexes | Same as pg_stat_all_indexes, except that only indexes on user tables are shown. |
| pg_statio_all_tables | One row for each table in the current database, showing statistics about I/O on that specific table. See pg_statio_all_tables for details. |
| pg_statio_sys_tables | Same as pg_statio_all_tables, except that only system tables are shown. |
| pg_statio_user_tables | Same as pg_statio_all_tables, except that only user tables are shown. |
| pg_statio_all_indexes | One row for each index in the current database, showing statistics about I/O on that specific index. See pg_statio_all_indexes for details. |
| pg_statio_sys_indexes | Same as pg_statio_all_indexes, except that only indexes on system tables are shown. |
| pg_statio_user_indexes | Same as pg_statio_all_indexes, except that only indexes on user tables are shown. |
| pg_statio_all_sequences | One row for each sequence in the current database, showing statistics about I/O on that specific sequence. See pg_statio_all_sequences for details. |
| pg_statio_sys_sequences | Same as pg_statio_all_sequences, except that only system sequences are shown. (Presently, no system sequences are defined, so this view is always empty.) |
| pg_statio_user_sequences | Same as pg_statio_all_sequences, except that only user sequences are shown. |
| pg_stat_user_functions | One row for each tracked function, showing statistics about executions of that function. See pg_stat_user_functions for details. |
| pg_stat_xact_user_functions | Similar to pg_stat_user_functions, but counts only calls during the current transaction (which are not yet included in pg_stat_user_functions). |
The per-index statistics are particularly useful to determine which indexes are being used and how effective they are.
The pg_statio_ views are primarily useful to determine the effectiveness of the buffer cache. When the number of actual disk reads is much smaller than the number of buffer hits, then the cache is satisfying most read requests without invoking a kernel call. However, these statistics do not give the entire story: due to the way in which PostgreSQL handles disk I/O, data that is not in the PostgreSQL buffer cache might still reside in the kernel's I/O cache, and might therefore still be fetched without requiring a physical read. Users interested in obtaining more detailed information on PostgreSQL I/O behavior are advised to use the PostgreSQL statistics collector in combination with operating system utilities that allow insight into the kernel's handling of I/O.
Table 28-3. pg_stat_activity View
| Column | Type | Description |
|---|---|---|
| datid | oid | OID of the database this backend is connected to |
| datname | name | Name of the database this backend is connected to |
| pid | integer | Process ID of this backend |
| usesysid | oid | OID of the user logged into this backend |
| usename | name | Name of the user logged into this backend |
| application_name | text | Name of the application that is connected to this backend |
| client_addr | inet | IP address of the client connected to this backend. If this field is null, it indicates either that the client is connected via a Unix socket on the server machine or that this is an internal process such as autovacuum. |
| client_hostname | text | Host name of the connected client, as reported by a reverse DNS lookup of client_addr. This field will only be non-null for IP connections, and only when log_hostname is enabled. |
| client_port | integer | TCP port number that the client is using for communication with this backend, or -1 if a Unix socket is used |
| backend_start | timestamp with time zone | Time when this process was started, i.e., when the client connected to the server |
| xact_start | timestamp with time zone | Time when this process' current transaction was started, or null if no transaction is active. If the current query is the first of its transaction, this column is equal to the query_start column. |
| query_start | timestamp with time zone | Time when the currently active query was started, or if state is not active, when the last query was started |
| state_change | timestamp with time zone | Time when the state was last changed |
| wait_event_type | text | The type of event for which the backend is waiting, if any;
otherwise NULL. Possible values are:
|
| wait_event | text | Wait event name if backend is currently waiting, otherwise NULL. See Table 28-4 for details. |
| state | text | Current overall state of this backend.
Possible values are:
|
| backend_xid | xid | Top-level transaction identifier of this backend, if any. |
| backend_xmin | xid | The current backend's xmin horizon. |
| query | text | Text of this backend's most recent query. If state is active this field shows the currently executing query. In all other states, it shows the last query that was executed. |
The pg_stat_activity view will have one row per server process, showing information related to the current activity of that process.
Note: The wait_event and state columns are independent. If a backend is in the active state, it may or may not be waiting on some event. If the state is active and wait_event is non-null, it means that a query is being executed, but is being blocked somewhere in the system.
Table 28-4. wait_event Description
| Wait Event Type | Wait Event Name | Description |
|---|---|---|
| LWLockNamed | ShmemIndexLock | Waiting to find or allocate space in shared memory. |
| OidGenLock | Waiting to allocate or assign an OID. | |
| XidGenLock | Waiting to allocate or assign a transaction id. | |
| ProcArrayLock | Waiting to get a snapshot or clearing a transaction id at transaction end. | |
| SInvalReadLock | Waiting to retrieve or remove messages from shared invalidation queue. | |
| SInvalWriteLock | Waiting to add a message in shared invalidation queue. | |
| WALBufMappingLock | Waiting to replace a page in WAL buffers. | |
| WALWriteLock | Waiting for WAL buffers to be written to disk. | |
| ControlFileLock | Waiting to read or update the control file or creation of a new WAL file. | |
| CheckpointLock | Waiting to perform checkpoint. | |
| CLogControlLock | Waiting to read or update transaction status. | |
| SubtransControlLock | Waiting to read or update sub-transaction information. | |
| MultiXactGenLock | Waiting to read or update shared multixact state. | |
| MultiXactOffsetControlLock | Waiting to read or update multixact offset mappings. | |
| MultiXactMemberControlLock | Waiting to read or update multixact member mappings. | |
| RelCacheInitLock | Waiting to read or write relation cache initialization file. | |
| CheckpointerCommLock | Waiting to manage fsync requests. | |
| TwoPhaseStateLock | Waiting to read or update the state of prepared transactions. | |
| TablespaceCreateLock | Waiting to create or drop the tablespace. | |
| BtreeVacuumLock | Waiting to read or update vacuum-related information for a B-tree index. | |
| AddinShmemInitLock | Waiting to manage space allocation in shared memory. | |
| AutovacuumLock | Autovacuum worker or launcher waiting to update or read the current state of autovacuum workers. | |
| AutovacuumScheduleLock | Waiting to ensure that the table it has selected for a vacuum still needs vacuuming. | |
| SyncScanLock | Waiting to get the start location of a scan on a table for synchronized scans. | |
| RelationMappingLock | Waiting to update the relation map file used to store catalog to filenode mapping. | |
| AsyncCtlLock | Waiting to read or update shared notification state. | |
| AsyncQueueLock | Waiting to read or update notification messages. | |
| SerializableXactHashLock | Waiting to retrieve or store information about serializable transactions. | |
| SerializableFinishedListLock | Waiting to access the list of finished serializable transactions. | |
| SerializablePredicateLockListLock | Waiting to perform an operation on a list of locks held by serializable transactions. | |
| OldSerXidLock | Waiting to read or record conflicting serializable transactions. | |
| SyncRepLock | Waiting to read or update information about synchronous replicas. | |
| BackgroundWorkerLock | Waiting to read or update background worker state. | |
| DynamicSharedMemoryControlLock | Waiting to read or update dynamic shared memory state. | |
| AutoFileLock | Waiting to update the postgresql.auto.conf file. | |
| ReplicationSlotAllocationLock | Waiting to allocate or free a replication slot. | |
| ReplicationSlotControlLock | Waiting to read or update replication slot state. | |
| CommitTsControlLock | Waiting to read or update transaction commit timestamps. | |
| CommitTsLock | Waiting to read or update the last value set for the transaction timestamp. | |
| ReplicationOriginLock | Waiting to setup, drop or use replication origin. | |
| MultiXactTruncationLock | Waiting to read or truncate multixact information. | |
| OldSnapshotTimeMapLock | Waiting to read or update old snapshot control information. | |
| LWLockTranche | clog | Waiting for I/O on a clog (transaction status) buffer. |
| commit_timestamp | Waiting for I/O on commit timestamp buffer. | |
| subtrans | Waiting for I/O a subtransaction buffer. | |
| multixact_offset | Waiting for I/O on a multixact offset buffer. | |
| multixact_member | Waiting for I/O on a multixact_member buffer. | |
| async | Waiting for I/O on an async (notify) buffer. | |
| oldserxid | Waiting to I/O on an oldserxid buffer. | |
| wal_insert | Waiting to insert WAL into a memory buffer. | |
| buffer_content | Waiting to read or write a data page in memory. | |
| buffer_io | Waiting for I/O on a data page. | |
| replication_origin | Waiting to read or update the replication progress. | |
| replication_slot_io | Waiting for I/O on a replication slot. | |
| proc | Waiting to read or update the fast-path lock information. | |
| buffer_mapping | Waiting to associate a data block with a buffer in the buffer pool. | |
| lock_manager | Waiting to add or examine locks for backends, or waiting to join or exit a locking group (used by parallel query). | |
| predicate_lock_manager | Waiting to add or examine predicate lock information. | |
| Lock | relation | Waiting to acquire a lock on a relation. |
| extend | Waiting to extend a relation. | |
| page | Waiting to acquire a lock on page of a relation. | |
| tuple | Waiting to acquire a lock on a tuple. | |
| transactionid | Waiting for a transaction to finish. | |
| virtualxid | Waiting to acquire a virtual xid lock. | |
| speculative token | Waiting to acquire a speculative insertion lock. | |
| object | Waiting to acquire a lock on a non-relation database object. | |
| userlock | Waiting to acquire a userlock. | |
| advisory | Waiting to acquire an advisory user lock. | |
| BufferPin | BufferPin | Waiting to acquire a pin on a buffer. |
Note: For tranches registered by extensions, the name is specified by extension and this will be displayed as wait_event. It is quite possible that user has registered the tranche in one of the backends (by having allocation in dynamic shared memory) in which case other backends won't have that information, so we display extension for such cases.
Here is an example of how wait events can be viewed
SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event is NOT NULL; pid | wait_event_type | wait_event ------+-----------------+--------------- 2540 | Lock | relation 6644 | LWLockNamed | ProcArrayLock (2 rows)
Table 28-5. pg_stat_replication View
| Column | Type | Description |
|---|---|---|
| pid | integer | Process ID of a WAL sender process |
| usesysid | oid | OID of the user logged into this WAL sender process |
| usename | name | Name of the user logged into this WAL sender process |
| application_name | text | Name of the application that is connected to this WAL sender |
| client_addr | inet | IP address of the client connected to this WAL sender. If this field is null, it indicates that the client is connected via a Unix socket on the server machine. |
| client_hostname | text | Host name of the connected client, as reported by a reverse DNS lookup of client_addr. This field will only be non-null for IP connections, and only when log_hostname is enabled. |
| client_port | integer | TCP port number that the client is using for communication with this WAL sender, or -1 if a Unix socket is used |
| backend_start | timestamp with time zone | Time when this process was started, i.e., when the client connected to this WAL sender |
| backend_xmin | xid | This standby's xmin horizon reported by hot_standby_feedback. |
| state | text | Current WAL sender state |
| sent_location | pg_lsn | Last transaction log position sent on this connection |
| write_location | pg_lsn | Last transaction log position written to disk by this standby server |
| flush_location | pg_lsn | Last transaction log position flushed to disk by this standby server |
| replay_location | pg_lsn | Last transaction log position replayed into the database on this standby server |
| sync_priority | integer | Priority of this standby server for being chosen as the synchronous standby |
| sync_state | text | Synchronous state of this standby server |
The pg_stat_replication view will contain one row per WAL sender process, showing statistics about replication to that sender's connected standby server. Only directly connected standbys are listed; no information is available about downstream standby servers.
Table 28-6. pg_stat_wal_receiver View
| Column | Type | Description |
|---|---|---|
| pid | integer | Process ID of the WAL receiver process |
| status | text | Activity status of the WAL receiver process |
| receive_start_lsn | pg_lsn | First transaction log position used when WAL receiver is started |
| receive_start_tli | integer | First timeline number used when WAL receiver is started |
| received_lsn | pg_lsn | Last transaction log position already received and flushed to disk, the initial value of this field being the first log position used when WAL receiver is started |
| received_tli | integer | Timeline number of last transaction log position received and flushed to disk, the initial value of this field being the timeline number of the first log position used when WAL receiver is started |
| last_msg_send_time | timestamp with time zone | Send time of last message received from origin WAL sender |
| last_msg_receipt_time | timestamp with time zone | Receipt time of last message received from origin WAL sender |
| latest_end_lsn | pg_lsn | Last transaction log position reported to origin WAL sender |
| latest_end_time | timestamp with time zone | Time of last transaction log position reported to origin WAL sender |
| slot_name | text | Replication slot name used by this WAL receiver |
| conninfo | text | Connection string used by this WAL receiver, with security-sensitive fields obfuscated. |
The pg_stat_wal_receiver view will contain only one row, showing statistics about the WAL receiver from that receiver's connected server.
Table 28-7. pg_stat_ssl View
| Column | Type | Description |
|---|---|---|
| pid | integer | Process ID of a backend or WAL sender process |
| ssl | boolean | True if SSL is used on this connection |
| version | text | Version of SSL in use, or NULL if SSL is not in use on this connection |
| cipher | text | Name of SSL cipher in use, or NULL if SSL is not in use on this connection |
| bits | integer | Number of bits in the encryption algorithm used, or NULL if SSL is not used on this connection |
| compression | boolean | True if SSL compression is in use, false if not, or NULL if SSL is not in use on this connection |
| clientdn | text | Distinguished Name (DN) field from the client certificate used, or NULL if no client certificate was supplied or if SSL is not in use on this connection. This field is truncated if the DN field is longer than NAMEDATALEN (64 characters in a standard build) |
The pg_stat_ssl view will contain one row per backend or WAL sender process, showing statistics about SSL usage on this connection. It can be joined to pg_stat_activity or pg_stat_replication on the pid column to get more details about the connection.
Table 28-8. pg_stat_archiver View
| Column | Type | Description |
|---|---|---|
| archived_count | bigint | Number of WAL files that have been successfully archived |
| last_archived_wal | text | Name of the last WAL file successfully archived |
| last_archived_time | timestamp with time zone | Time of the last successful archive operation |
| failed_count | bigint | Number of failed attempts for archiving WAL files |
| last_failed_wal | text | Name of the WAL file of the last failed archival operation |
| last_failed_time | timestamp with time zone | Time of the last failed archival operation |
| stats_reset | timestamp with time zone | Time at which these statistics were last reset |
The pg_stat_archiver view will always have a single row, containing data about the archiver process of the cluster.
Table 28-9. pg_stat_bgwriter View
| Column | Type | Description |
|---|---|---|
| checkpoints_timed | bigint | Number of scheduled checkpoints that have been performed |
| checkpoints_req | bigint | Number of requested checkpoints that have been performed |
| checkpoint_write_time | double precision | Total amount of time that has been spent in the portion of checkpoint processing where files are written to disk, in milliseconds |
| checkpoint_sync_time | double precision | Total amount of time that has been spent in the portion of checkpoint processing where files are synchronized to disk, in milliseconds |
| buffers_checkpoint | bigint | Number of buffers written during checkpoints |
| buffers_clean | bigint | Number of buffers written by the background writer |
| maxwritten_clean | bigint | Number of times the background writer stopped a cleaning scan because it had written too many buffers |
| buffers_backend | bigint | Number of buffers written directly by a backend |
| buffers_backend_fsync | bigint | Number of times a backend had to execute its own
fsync call (normally the background writer handles those
even when the backend does its own write) |
| buffers_alloc | bigint | Number of buffers allocated |
| stats_reset | timestamp with time zone | Time at which these statistics were last reset |
The pg_stat_bgwriter view will always have a single row, containing global data for the cluster.
Table 28-10. pg_stat_database View
| Column | Type | Description |
|---|---|---|
| datid | oid | OID of a database |
| datname | name | Name of this database |
| numbackends | integer | Number of backends currently connected to this database. This is the only column in this view that returns a value reflecting current state; all other columns return the accumulated values since the last reset. |
| xact_commit | bigint | Number of transactions in this database that have been committed |
| xact_rollback | bigint | Number of transactions in this database that have been rolled back |
| blks_read | bigint | Number of disk blocks read in this database |
| blks_hit | bigint | Number of times disk blocks were found already in the buffer cache, so that a read was not necessary (this only includes hits in the PostgreSQL buffer cache, not the operating system's file system cache) |
| tup_returned | bigint | Number of rows returned by queries in this database |
| tup_fetched | bigint | Number of rows fetched by queries in this database |
| tup_inserted | bigint | Number of rows inserted by queries in this database |
| tup_updated | bigint | Number of rows updated by queries in this database |
| tup_deleted | bigint | Number of rows deleted by queries in this database |
| conflicts | bigint | Number of queries canceled due to conflicts with recovery in this database. (Conflicts occur only on standby servers; see pg_stat_database_conflicts for details.) |
| temp_files | bigint | Number of temporary files created by queries in this database. All temporary files are counted, regardless of why the temporary file was created (e.g., sorting or hashing), and regardless of the log_temp_files setting. |
| temp_bytes | bigint | Total amount of data written to temporary files by queries in this database. All temporary files are counted, regardless of why the temporary file was created, and regardless of the log_temp_files setting. |
| deadlocks | bigint | Number of deadlocks detected in this database |
| blk_read_time | double precision | Time spent reading data file blocks by backends in this database, in milliseconds |
| blk_write_time | double precision | Time spent writing data file blocks by backends in this database, in milliseconds |
| stats_reset | timestamp with time zone | Time at which these statistics were last reset |
The pg_stat_database view will contain one row for each database in the cluster, showing database-wide statistics.
Table 28-11. pg_stat_database_conflicts View
| Column | Type | Description |
|---|---|---|
| datid | oid | OID of a database |
| datname | name | Name of this database |
| confl_tablespace | bigint | Number of queries in this database that have been canceled due to dropped tablespaces |
| confl_lock | bigint | Number of queries in this database that have been canceled due to lock timeouts |
| confl_snapshot | bigint | Number of queries in this database that have been canceled due to old snapshots |
| confl_bufferpin | bigint | Number of queries in this database that have been canceled due to pinned buffers |
| confl_deadlock | bigint | Number of queries in this database that have been canceled due to deadlocks |
The pg_stat_database_conflicts view will contain one row per database, showing database-wide statistics about query cancels occurring due to conflicts with recovery on standby servers. This view will only contain information on standby servers, since conflicts do not occur on master servers.
Table 28-12. pg_stat_all_tables View
| Column | Type | Description |
|---|---|---|
| relid | oid | OID of a table |
| schemaname | name | Name of the schema that this table is in |
| relname | name | Name of this table |
| seq_scan | bigint | Number of sequential scans initiated on this table |
| seq_tup_read | bigint | Number of live rows fetched by sequential scans |
| idx_scan | bigint | Number of index scans initiated on this table |
| idx_tup_fetch | bigint | Number of live rows fetched by index scans |
| n_tup_ins | bigint | Number of rows inserted |
| n_tup_upd | bigint | Number of rows updated (includes HOT updated rows) |
| n_tup_del | bigint | Number of rows deleted |
| n_tup_hot_upd | bigint | Number of rows HOT updated (i.e., with no separate index update required) |
| n_live_tup | bigint | Estimated number of live rows |
| n_dead_tup | bigint | Estimated number of dead rows |
| n_mod_since_analyze | bigint | Estimated number of rows modified since this table was last analyzed |
| last_vacuum | timestamp with time zone | Last time at which this table was manually vacuumed (not counting VACUUM FULL) |
| last_autovacuum | timestamp with time zone | Last time at which this table was vacuumed by the autovacuum daemon |
| last_analyze | timestamp with time zone | Last time at which this table was manually analyzed |
| last_autoanalyze | timestamp with time zone | Last time at which this table was analyzed by the autovacuum daemon |
| vacuum_count | bigint | Number of times this table has been manually vacuumed (not counting VACUUM FULL) |
| autovacuum_count | bigint | Number of times this table has been vacuumed by the autovacuum daemon |
| analyze_count | bigint | Number of times this table has been manually analyzed |
| autoanalyze_count | bigint | Number of times this table has been analyzed by the autovacuum daemon |
The pg_stat_all_tables view will contain one row for each table in the current database (including TOAST tables), showing statistics about accesses to that specific table. The pg_stat_user_tables and pg_stat_sys_tables views contain the same information, but filtered to only show user and system tables respectively.
Table 28-13. pg_stat_all_indexes View
| Column | Type | Description |
|---|---|---|
| relid | oid | OID of the table for this index |
| indexrelid | oid | OID of this index |
| schemaname | name | Name of the schema this index is in |
| relname | name | Name of the table for this index |
| indexrelname | name | Name of this index |
| idx_scan | bigint | Number of index scans initiated on this index |
| idx_tup_read | bigint | Number of index entries returned by scans on this index |
| idx_tup_fetch | bigint | Number of live table rows fetched by simple index scans using this index |
The pg_stat_all_indexes view will contain one row for each index in the current database, showing statistics about accesses to that specific index. The pg_stat_user_indexes and pg_stat_sys_indexes views contain the same information, but filtered to only show user and system indexes respectively.
Indexes can be used by simple index scans, "bitmap" index scans, and the optimizer. In a bitmap scan the output of several indexes can be combined via AND or OR rules, so it is difficult to associate individual heap row fetches with specific indexes when a bitmap scan is used. Therefore, a bitmap scan increments the pg_stat_all_indexes.idx_tup_read count(s) for the index(es) it uses, and it increments the pg_stat_all_tables.idx_tup_fetch count for the table, but it does not affect pg_stat_all_indexes.idx_tup_fetch. The optimizer also accesses indexes to check for supplied constants whose values are outside the recorded range of the optimizer statistics because the optimizer statistics might be stale.
Note: The idx_tup_read and idx_tup_fetch counts can be different even without any use of bitmap scans, because idx_tup_read counts index entries retrieved from the index while idx_tup_fetch counts live rows fetched from the table. The latter will be less if any dead or not-yet-committed rows are fetched using the index, or if any heap fetches are avoided by means of an index-only scan.
Table 28-14. pg_statio_all_tables View
| Column | Type | Description |
|---|---|---|
| relid | oid | OID of a table |
| schemaname | name | Name of the schema that this table is in |
| relname | name | Name of this table |
| heap_blks_read | bigint | Number of disk blocks read from this table |
| heap_blks_hit | bigint | Number of buffer hits in this table |
| idx_blks_read | bigint | Number of disk blocks read from all indexes on this table |
| idx_blks_hit | bigint | Number of buffer hits in all indexes on this table |
| toast_blks_read | bigint | Number of disk blocks read from this table's TOAST table (if any) |
| toast_blks_hit | bigint | Number of buffer hits in this table's TOAST table (if any) |
| tidx_blks_read | bigint | Number of disk blocks read from this table's TOAST table indexes (if any) |
| tidx_blks_hit | bigint | Number of buffer hits in this table's TOAST table indexes (if any) |
The pg_statio_all_tables view will contain one row for each table in the current database (including TOAST tables), showing statistics about I/O on that specific table. The pg_statio_user_tables and pg_statio_sys_tables views contain the same information, but filtered to only show user and system tables respectively.
Table 28-15. pg_statio_all_indexes View
| Column | Type | Description |
|---|---|---|
| relid | oid | OID of the table for this index |
| indexrelid | oid | OID of this index |
| schemaname | name | Name of the schema this index is in |
| relname | name | Name of the table for this index |
| indexrelname | name | Name of this index |
| idx_blks_read | bigint | Number of disk blocks read from this index |
| idx_blks_hit | bigint | Number of buffer hits in this index |
The pg_statio_all_indexes view will contain one row for each index in the current database, showing statistics about I/O on that specific index. The pg_statio_user_indexes and pg_statio_sys_indexes views contain the same information, but filtered to only show user and system indexes respectively.
Table 28-16. pg_statio_all_sequences View
| Column | Type | Description |
|---|---|---|
| relid | oid | OID of a sequence |
| schemaname | name | Name of the schema this sequence is in |
| relname | name | Name of this sequence |
| blks_read | bigint | Number of disk blocks read from this sequence |
| blks_hit | bigint | Number of buffer hits in this sequence |
The pg_statio_all_sequences view will contain one row for each sequence in the current database, showing statistics about I/O on that specific sequence.
Table 28-17. pg_stat_user_functions View
| Column | Type | Description |
|---|---|---|
| funcid | oid | OID of a function |
| schemaname | name | Name of the schema this function is in |
| funcname | name | Name of this function |
| calls | bigint | Number of times this function has been called |
| total_time | double precision | Total time spent in this function and all other functions called by it, in milliseconds |
| self_time | double precision | Total time spent in this function itself, not including other functions called by it, in milliseconds |
The pg_stat_user_functions view will contain one row for each tracked function, showing statistics about executions of that function. The track_functions parameter controls exactly which functions are tracked.
Other ways of looking at the statistics can be set up by writing queries that use the same underlying statistics access functions used by the standard views shown above. For details such as the functions' names, consult the definitions of the standard views. (For example, in psql you could issue \d+ pg_stat_activity.) The access functions for per-database statistics take a database OID as an argument to identify which database to report on. The per-table and per-index functions take a table or index OID. The functions for per-function statistics take a function OID. Note that only tables, indexes, and functions in the current database can be seen with these functions.
Additional functions related to statistics collection are listed in Table 28-18.
Table 28-18. Additional Statistics Functions
| Function | Return Type | Description |
|---|---|---|
pg_backend_pid() | integer | Process ID of the server process handling the current session |
pg_stat_get_activity (integer) | setof record | Returns a record of information about the backend with the specified PID, or one record for each active backend in the system if NULL is specified. The fields returned are a subset of those in the pg_stat_activity view. |
pg_stat_get_snapshot_timestamp() | timestamp with time zone | Returns the timestamp of the current statistics snapshot |
pg_stat_clear_snapshot() | void | Discard the current statistics snapshot |
pg_stat_reset() | void | Reset all statistics counters for the current database to zero (requires superuser privileges by default, but EXECUTE for this function can be granted to others.) |
pg_stat_reset_shared (text) | void | Reset some cluster-wide statistics counters to zero, depending on the argument (requires superuser privileges by default, but EXECUTE for this function can be granted to others). Calling pg_stat_reset_shared('bgwriter') will zero all the counters shown in the pg_stat_bgwriter view. Calling pg_stat_reset_shared('archiver') will zero all the counters shown in the pg_stat_archiver view. |
pg_stat_reset_single_table_counters (oid) | void | Reset statistics for a single table or index in the current database to zero (requires superuser privileges by default, but EXECUTE for this function can be granted to others) |
pg_stat_reset_single_function_counters (oid) | void | Reset statistics for a single function in the current database to zero (requires superuser privileges by default, but EXECUTE for this function can be granted to others) |
pg_stat_get_activity
, the underlying function of
the pg_stat_activity view, returns a set of records
containing all the available information about each backend process.
Sometimes it may be more convenient to obtain just a subset of this
information. In such cases, an older set of per-backend statistics
access functions can be used; these are shown in Table 28-19.
These access functions use a backend ID number, which ranges from one
to the number of currently active backends.
The function pg_stat_get_backend_idset
provides a
convenient way to generate one row for each active backend for
invoking these functions. For example, to show the PIDs and
current queries of all backends:
SELECT pg_stat_get_backend_pid(s.backendid) AS pid, pg_stat_get_backend_activity(s.backendid) AS query FROM (SELECT pg_stat_get_backend_idset() AS backendid) AS s;
Table 28-19. Per-Backend Statistics Functions
| Function | Return Type | Description |
|---|---|---|
pg_stat_get_backend_idset() | setof integer | Set of currently active backend ID numbers (from 1 to the number of active backends) |
pg_stat_get_backend_activity(integer) | text | Text of this backend's most recent query |
pg_stat_get_backend_activity_start(integer) | timestamp with time zone | Time when the most recent query was started |
pg_stat_get_backend_client_addr(integer) | inet | IP address of the client connected to this backend |
pg_stat_get_backend_client_port(integer) | integer | TCP port number that the client is using for communication |
pg_stat_get_backend_dbid(integer) | oid | OID of the database this backend is connected to |
pg_stat_get_backend_pid(integer) | integer | Process ID of this backend |
pg_stat_get_backend_start(integer) | timestamp with time zone | Time when this process was started |
pg_stat_get_backend_userid(integer) | oid | OID of the user logged into this backend |
pg_stat_get_backend_wait_event_type(integer) | text | Wait event type name if backend is currently waiting, otherwise NULL. See Table 28-4 for details. |
pg_stat_get_backend_wait_event(integer) | text | Wait event name if backend is currently waiting, otherwise NULL. See Table 28-4 for details. |
pg_stat_get_backend_xact_start(integer) | timestamp with time zone | Time when the current transaction was started |


Canada sits right above the United States, making up a big part of North America. The countries are so close, in fact, that in some of the northern states, Canada is only a short drive away. This can make it easy to assume that Canada and America are the same but that couldn't be further from the truth.
Between politics, religion, currency, and food, there are lots of differences between the two countries.
Most of the rest of the world (and America) looks at Canada as the weaker, more polite North American cousin. We've even gotten pretty good at playing the second fiddle over the years. But that doesn't mean we don't sneak up from time to time like Donovan Bailey and claim a few victories over our Yankee neighbours. Here are 20 ranked reasons why Canada is way better than the United States, all selected by a true Canadian. Oh, and none of them have to do with hockey.
Entering a US household is a lot like a pachyderm pen at the zoo. To Canadians, it just seems wrong to wear your outside shoes inside. Score one for Canadian cleanliness.
Statistics place the US murder-per-capita rate at about five times that of Canada’s. And that’s just looking at one statistic (albeit, the most important one). Plus we have the best health care system (more on that later).
In Canada, life is way easier because most day-to-day math equations can be solved by understanding the power of 10. Oh, you need a ridiculously complicated conversion chart to bake a cake, America? That’s too bad.
Revolutionizing women's underwear and paving the way for Victoria's Secret is the crown jewel of reasons why Canada is better than the US We were light years ahead on the Wonderbra and we demand recognition. Well, not really demand, because we're also very polite. Sorry for calling you barbarians.
Well, there is actually many things to say about why USA is better than Canada. But just these two points will be sufficent..


--- title: Authorization Policy description: Configuration for access control on workloads. location: https://istio.io/docs/reference/config/security/authorization-policy.html layout: protoc-gen-docs generator: protoc-gen-docs schema: istio.security.v1beta1.AuthorizationPolicy weight: 20 aliases: [/docs/reference/config/authorization/authorization-policy] number_of_entries: 8 ---
Istio Authorization Policy enables access control on workloads in the mesh.
Authorization policy supports both allow and deny policies. When allow and deny policies are used for a workload at the same time, the deny policies are evaluated first. The evaluation is determined by the following rules:
For example, the following authorization policy sets the action
to “ALLOW”
to create an allow policy. The default action is “ALLOW” but it is useful
to be explicit in the policy.
It allows requests from:
to access the workload with:
when the request has a valid JWT token issued by “https://accounts.google.com”.
Any other requests will be denied.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: httpbin
namespace: foo
spec:
action: ALLOW
rules:
- from:
- source:
principals: ["cluster.local/ns/default/sa/sleep"]
- source:
namespaces: ["test"]
to:
- operation:
methods: ["GET"]
paths: ["/info*"]
- operation:
methods: ["POST"]
paths: ["/data"]
when:
- key: request.auth.claims[iss]
values: ["https://accounts.google.com"]
The following is another example that sets action
to “DENY” to create a deny policy.
It denies requests from the “dev” namespace to the “POST” method on all workloads
in the “foo” namespace.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: httpbin
namespace: foo
spec:
action: DENY
rules:
- from:
- source:
namespaces: ["dev"]
to:
- operation:
methods: ["POST"]
Authorization Policy scope (target) is determined by “metadata/namespace” and an optional “selector”.
For example,
The following authorization policy applies to workloads containing label “app: httpbin” in namespace bar.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: policy
namespace: bar
spec:
selector:
matchLabels:
app: httpbin
The following authorization policy applies to all workloads in namespace foo.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: policy
namespace: foo
spec:
{}
The following authorization policy applies to workloads containing label “version: v1” in all namespaces in the mesh. (Assuming the root namespace is configured to “istio-config”).
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: policy
namespace: istio-config
spec:
selector:
matchLabels:
version: v1
AuthorizationPolicy enables access control on workloads.
For example, the following authorization policy denies all requests to workloads in namespace foo.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: deny-all
namespace: foo
spec:
{}
The following authorization policy allows all requests to workloads in namespace foo.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: allow-all
namespace: foo
spec:
rules:
- {}
Rule matches requests from a list of sources that perform a list of operations subject to a list of conditions. A match occurs when at least one source, operation and condition matches the request. An empty rule is always matched.
Any string field in the rule supports Exact, Prefix, Suffix and Presence match:
Source specifies the source identities of a request. Fields in the source are ANDed together.
For example, the following source matches if the principal is “admin” or “dev” and the namespace is “prod” or “test” and the ip is not “<IP_ADDRESS>”.
principals: ["admin", "dev"]
namespaces: ["prod", "test"]
not_ipblocks: ["<IP_ADDRESS>"]
Operation specifies the operations of a request. Fields in the operation are ANDed together.
For example, the following operation matches if the host has suffix “.example.com” and the method is “GET” or “HEAD” and the path doesn’t have prefix “/admin”.
hosts: ["*.example.com"]
methods: ["GET", "HEAD"]
not_paths: ["/admin*"]
Condition specifies additional required attributes.
From includes a list or sources.
To includes a list or operations.
Action specifies the operation to take.
| Name | Description |
|---|---|
ALLOW |
Allow a request only if it matches the rules. This is the default type. |
DENY |
Deny a request if it matches any of the rules. |


| Attribute | Description | Required |
|---|---|---|
| id | The reference id to store this HttpClient under. | No. |
| refId | The reference id of the HttpClient this element refers to. | No. |
| stateRefId | The HttpState object to use. | No. Uses a default HttpState. |
Create http client params.
| Attribute | Description | Required |
|---|---|---|
| strict | Should we be strict on the protocol. | No. |
| authenticationPreemptive | Should we pre-emptively try to authenticate? | No. |
| connectionManagerTimeout | The timeout for the connection manager. | No. |
| contentCharSet | The content character set | No. |
| cookiePolicy | The cookie policy (IGNORE_COOKIES, RFC_2109, NETSCAPE or DEFAULT) | No. |
| credentialCharSet | No. | |
| httpElementCharSet | No. | |
| soTimeout | No. | |
| version | The HTTP version. | No. |
Create a client parameter.
| Attribute | Description | Required |
|---|---|---|
| name | The parameter name | Yes. |
| value | The parameter value. | Yes. |
Create a host configuration.
| Attribute | Description | Required |
|---|---|---|
| host | The host to connect to. | No. |
| port | No. | |
| protocol | No. | |
| address | No. | |
| proxyHost | The proxyHost to connect to. | No. |
| proxyPort | No. |
Specify HostParams.
| <hostParams> subelements are identical to those of <clientParams> |
|---|
Create (or reference an existing) HttpState for use with this HTTP client. This is necessary if you wish to enable authentication, or retain state across multiple method calls.
| Please see the httpState documentation for more details on this element |
|---|
<httpClient id="client1">
<clientParams cookiePolicy="RFC_2109" />
</httpClient>
Copyright © 2002-2003 Ant-Contrib Project. All rights Reserved.


CSAPI(Account) Category Reference
| Declared in | CSAPI+Account.h |
Tasks
-
– getAPIKeyWithSiteURL:username:password:completionHandler:errorHandler:
Allows a client or designer to retrieve their API key, given their username, password, and site URL.
-
– getClients:errorHandler:
Get a list of all the clients in your account, including their name & ID.
-
– getBillingDetails:errorHandler:
Returns billing details for your account, including the number of credits in your account.
-
– getCountries:errorHandler:
Get a list of valid countries.
-
– getTimezones:errorHandler:
Get a list of valid timezones.
-
– getSystemDate:errorHandler:
Get the current time.
-
– addAdministratorWithName:emailAddress:completionHandler:errorHandler:
Adds a new administrator to the account. An invitation will be sent to the new administrator via email
-
– updateAdministratorWithEmailAddress:name:newEmailAddress:completionHandler:errorHandler:
Updates the email address and/or name of an administrator.
-
– getAdministrators:errorHandler:
Contains a list of all (active or invited) administrators associated with a particular account.
-
– getAdministratorWithEmailAddress:completionHandler:errorHandler:
Returns the details of a single administrator associated with an account.
-
– deleteAdministratorWithEmailAddress:completionHandler:errorHandler:
Changes the status of an active administrator to a deleted administrator. They will no longer be able to log into this account
-
– setPrimaryContactWithEmailAddress:completionHandler:errorHandler:
Sets the primary contact for the account to be the administrator with the specified email address.
-
– getPrimaryContact:errorHandler:
Returns the email address of the administrator who is selected as the primary contact for this account.
-
– getExternalSessionUrl:chrome:url:integratorID:clientID:completionHandler:errorHandler:
Returns a URL which initiates a new external session for the user with the given email address.
Instance Methods
addAdministratorWithName:emailAddress:completionHandler:errorHandler:
Adds a new administrator to the account. An invitation will be sent to the new administrator via email
- (void)addAdministratorWithName:(NSString *)name emailAddress:(NSString *)emailAddress completionHandler:(void ( ^ ) ( NSString *administratorEmailAddress ))completionHandler errorHandler:(CSAPIErrorHandler)errorHandler
Parameters
- name
Name of the person
- emailAddress
Email address of the person
- completionHandler
Completion callback, with email address of the administrator as the only argument
- errorHandler
Error callback
Discussion
http://www.campaignmonitor.com/api/account/#adding_an_admin
Declared In
CSAPI+Account.h
deleteAdministratorWithEmailAddress:completionHandler:errorHandler:
Changes the status of an active administrator to a deleted administrator. They will no longer be able to log into this account
- (void)deleteAdministratorWithEmailAddress:(NSString *)emailAddress completionHandler:(void ( ^ ) ( void ))completionHandler errorHandler:(CSAPIErrorHandler)errorHandler
Parameters
- emailAddress
The email address of the administrator to be deleted.
- completionHandler
Completion callback
- errorHandler
Error callback
Discussion
http://www.campaignmonitor.com/api/account/#deleting_an_admin
Declared In
CSAPI+Account.h
getAPIKeyWithSiteURL:username:password:completionHandler:errorHandler:
Allows a client or designer to retrieve their API key, given their username, password, and site URL.
- (void)getAPIKeyWithSiteURL:(NSString *)siteURL username:(NSString *)username password:(NSString *)password completionHandler:(void ( ^ ) ( NSString *APIKey ))completionHandler errorHandler:(CSAPIErrorHandler)errorHandler
Parameters
- siteURL
The base URL of the CreateSend site. e.g. http://example.createsend.com/.
- username
The username for the account
- password
The password for the account
- completionHandler
Completion callback, with the API Key as the first and only argument
- errorHandler
Error callback
Discussion
http://www.campaignmonitor.com/api/account/#getting_your_api_key
Declared In
CSAPI+Account.h
getAdministratorWithEmailAddress:completionHandler:errorHandler:
Returns the details of a single administrator associated with an account.
- (void)getAdministratorWithEmailAddress:(NSString *)emailAddress completionHandler:(void ( ^ ) ( CSAdministrator *administrator ))completionHandler errorHandler:(CSAPIErrorHandler)errorHandler
Parameters
- emailAddress
The email address of the administrator whose information should be retrieved.
- completionHandler
Completion callback, with a
CSAdministrator
as the only argument.
- errorHandler
Error callback
Discussion
http://www.campaignmonitor.com/api/account/#getting_account_admin
Declared In
CSAPI+Account.h
getAdministrators:errorHandler:
Contains a list of all (active or invited) administrators associated with a particular account.
- (void)getAdministrators:(void ( ^ ) ( NSArray *administrators ))completionHandler errorHandler:(CSAPIErrorHandler)errorHandler
Parameters
- completionHandler
Completion callback, with an array of
CSAdministrator
objects as the first and only argument
- errorHandler
Error callback
Discussion
http://www.campaignmonitor.com/api/account/#getting_account_admins
Declared In
CSAPI+Account.h
getBillingDetails:errorHandler:
Returns billing details for your account, including the number of credits in your account.
- (void)getBillingDetails:(void ( ^ ) ( CSBillingDetails *billingDetails ))completionHandler errorHandler:(CSAPIErrorHandler)errorHandler
Parameters
- completionHandler
Completion callback, including a
CSBillingDetails
object as the first and only argument
- errorHandler
Error callback
Discussion
http://www.campaignmonitor.com/api/account/#getting_your_billing_details
Declared In
CSAPI+Account.h
getClients:errorHandler:
Get a list of all the clients in your account, including their name & ID.
- (void)getClients:(void ( ^ ) ( NSArray *clients ))completionHandler errorHandler:(CSAPIErrorHandler)errorHandler
Parameters
- completionHandler
Completion callback, with an array of
CSClient
objects as the first and only argument
- errorHandler
Error callback
Discussion
http://www.campaignmonitor.com/api/account/#getting_your_clients
Declared In
CSAPI+Account.h
getCountries:errorHandler:
Get a list of valid countries.
- (void)getCountries:(void ( ^ ) ( NSArray *countries ))completionHandler errorHandler:(CSAPIErrorHandler)errorHandler
Parameters
- completionHandler
Completion callback, including a list of country names as an
NSArray
- errorHandler
Error callback
Discussion
http://www.campaignmonitor.com/api/account/#getting_valid_countries
See Also
Declared In
CSAPI+Account.h
getExternalSessionUrl:chrome:url:integratorID:clientID:completionHandler:errorHandler:
Returns a URL which initiates a new external session for the user with the given email address.
- (void)getExternalSessionUrl:(NSString *)email chrome:(NSString *)chrome url:(NSString *)url integratorID:(NSString *)integratorID clientID:(NSString *)clientID completionHandler:(void ( ^ ) ( NSString *sessionUrl ))completionHandler errorHandler:(CSAPIErrorHandler)errorHandler
Parameters
The email address of the Campaign Monitor user for whom the login session should be created.
- chrome
Which ‘chrome’ to display – Must be either “all”, “tabs”, or “none”.
- url
The URL to display once logged in. e.g. “/subscribers/”
- integratorID
The integrator ID. You need to contact Campaign Monitor support to get an integrator ID.
- clientID
The Client ID of the client which should be active once logged in to the Campaign Monitor account.
- completionHandler
Completion callback, with the session URL as the only argument
- errorHandler
Error callback
Discussion
http://www.campaignmonitor.com/api/account/#single_sign_on
Declared In
CSAPI+Account.h
getPrimaryContact:errorHandler:
Returns the email address of the administrator who is selected as the primary contact for this account.
- (void)getPrimaryContact:(void ( ^ ) ( NSString *primaryContactEmailAddress ))completionHandler errorHandler:(CSAPIErrorHandler)errorHandler
Parameters
- completionHandler
Completion callback, with email address of the primary contact as the only argument
- errorHandler
Error callback
Discussion
http://www.campaignmonitor.com/api/account/#getting_primary_contact
Declared In
CSAPI+Account.h
getSystemDate:errorHandler:
Get the current time.
- (void)getSystemDate:(void ( ^ ) ( NSDate *systemDate ))completionHandler errorHandler:(CSAPIErrorHandler)errorHandler
Parameters
- completionHandler
Completion callback, including the current time as an
NSDate
- errorHandler
Error callback
Discussion
http://www.campaignmonitor.com/api/account/#getting_the_current_date
See Also
Declared In
CSAPI+Account.h
getTimezones:errorHandler:
Get a list of valid timezones.
- (void)getTimezones:(void ( ^ ) ( NSArray *timezones ))completionHandler errorHandler:(CSAPIErrorHandler)errorHandler
Parameters
- completionHandler
Completion callback, including a list of timezone names as an
NSArray
- errorHandler
Error callback
Discussion
http://www.campaignmonitor.com/api/account/#getting_valid_timezones
See Also
Declared In
CSAPI+Account.h
setPrimaryContactWithEmailAddress:completionHandler:errorHandler:
Sets the primary contact for the account to be the administrator with the specified email address.
- (void)setPrimaryContactWithEmailAddress:(NSString *)emailAddress completionHandler:(void ( ^ ) ( NSString *primaryContactEmailAddress ))completionHandler errorHandler:(CSAPIErrorHandler)errorHandler
Parameters
- emailAddress
The email address of the administrator to be assigned as the primary contact for the account.
- completionHandler
Completion callback, with email address of the primary contact as the only argument
- errorHandler
Error callback
Discussion
http://www.campaignmonitor.com/api/account/#setting_primary_contact
Declared In
CSAPI+Account.h
updateAdministratorWithEmailAddress:name:newEmailAddress:completionHandler:errorHandler:
Updates the email address and/or name of an administrator.
- (void)updateAdministratorWithEmailAddress:(NSString *)currentEmailAddress name:(NSString *)name newEmailAddress:(NSString *)newEmailAddress completionHandler:(void ( ^ ) ( NSString *administratorEmailAddress ))completionHandler errorHandler:(CSAPIErrorHandler)errorHandler
Parameters
- currentEmailAddress
The email address of the admin whose details will be updated. This is regarded as the ‘old’ email address.
- name
Name of the administrator
- newEmailAddress
New email address of the person
- completionHandler
Completion callback, with email address of the administrator as the only argument
- errorHandler
Error callback
Discussion
http://www.campaignmonitor.com/api/account/#updating_an_admin
Declared In
CSAPI+Account.h


Farata recipe
Farata is the Mauritian version of Indian paratha, a layered,
flaky, pan-fried flatbread. It consists of three basic ingredients: flour, water, and oil.
Faratas are traditionally served warm,
accompanying spicy curry dishes or any kind of chutney. The farata itself taste so good, so
when you add spicy curry such as fish or chicken curry, accompanied with turban squash
which melts in the mouth, its like an explosion of flavour with a mixture of texture.
List of ingrediens needed.
- 1kg of white flour.
- 800ml of warm water.
- 4 tablespoon of butter (melted).
- salt and vegetable oil to adjust.
Steps for preparation of the farata.
- In a mixing bowl, rub melted butter into flour until it resembles breadcrumbs.
Gradually add the warm water to make soft dough.
Cover the dough mixture with a cloth and set aside for at least
15 minutes to rest.⏳
-
Divide the dough into eight equal portions and form a ball with each one of them,
then roll out into discs with a rolling pin.🙌
-
Brush disc with melted butter and fold over into half circle.
Brush again with melted butter and fold over once more into a triangle.🔺
- Roll out the triangular shape into a flat layer.
-
Grease a hot griddle or tava (frying Pan) and
place the rolled bread onto the hot griddle.
-
Fry for a minute approximately on each side –
it may be necessary to turn them over more often
to ensure thorough cooking and to prevent burning.🔥
-
keep in an air-dry container before serving.🤤
Here your can find a few links for the best recipes for the farata making.
🧐
-
Oil free recipe
-
From honey kitchen


Test Case 4 |
| Back to all test cases |
| Code snippet. |
public static void main(String[] args) { // TODO Auto-generated method stub try { Socket client = new Socket("localhost", 1238); ObjectOutputStream out = new ObjectOutputStream(client.getOutputStream()); out.flush(); ObjectInputStream in = new ObjectInputStream(client.getInputStream()); System.out.println("Buffer size: " + client.getSendBufferSize()); for (int i = 0 ; i < 10 ; i++) { if ( i == 3 ) { Thread.currentThread().interrupt(); System.out.println("Interrupted."); } out.writeObject("From Client: Hellow." + i); out.flush(); System.out.println(in.readObject()); } }catch(Exception exc) { exc.printStackTrace(); } } |
| Created exception |
java.net.ConnectException: Connection refused: connect at java.net.DualStackPlainSocketImpl.connect0(Native Method) at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source) at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source) at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source) at java.net.AbstractPlainSocketImpl.connect(Unknown Source) at java.net.PlainSocketImpl.connect(Unknown Source) at java.net.SocksSocketImpl.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at java.net.Socket. |
| Show solutions from SurfClipse |


http://www.tcltk.com
.
Ptolemy is written in C++, and uses Tcl/Tk and the X Window System.
See http://ptolemy.eecs.berkeley.edu
for further information.
http://ptolemy.eecs.berkeley.edu/tycho/Tycho.html
has instructions and Itcl binaries.
We have also used Windows NT to develop Tycho, but some of the features
that use exec
are broken.
The Macintosh port requires Itcl2.2p2, the prebuilt Itcl2.2 binaries will not work. The Macintosh port is basically untested.
http://www.tcltk.com
http://ptolemy.eecs.berkeley.edu/tycho
You might find useful information on the Tycho homepage at
http://ptolemy.eecs.berkeley.edu/tycho
.
If you are really stumped, you can send mail to<EMAIL_ADDRESS>.
Your mail should include:
This was a design decision made by the Tycho authors. In some cases, we decided to use a simpler widget. In other cases the functionality we needed was missing. We also wanted the widget we wrote to use some of the features of Tycho, such as automatically generated documentation and active Tcl examples.
Also, we wanted to be able to provide an easily extensible environment for non-programmers, which makes an interpreted language such as Tcl a stronger candidate than a compiled language such as Java.


|
Perl Weekly
Issue #39 - 2012-04-23 - A Moose in New York and Camelia in Oslo
latest | archive | by Gabor Szabo
|
|
Welcome to all the new members!
The Perl Weekly was mentioned in Hacker Newsletter of Kale Davis. I'd like to take the opportunity and recommend his weekly collection of items from Hacker news. I saw quite a few interesting articles mentioned there!
On other news, I finally bought my flight ticket to Kiev. I was invited to the Perl Mova Workshop in Kiev, along with Tatsuhiko Miyagawa and Florian Ragwitz. Very flattering. This is going to be my first time in Ukraine and I am planning to be touristy on the days before the workshop. If the locals are interested, we might even have a mini hackathon.
And now to the news...
|
|
|
Headlines
|
Poet: a web framework for Mason
Though I've never used Mason or any of the modules Jonathan Swartz wrote, every time he announces something it seems to me something really serious and well thought out. Maybe because in his post Jonathan also mentions Hearst Digital Media, that has been using the earlier versions of this framework for 6 years now. Maybe for some other reason. In any case, I'd recommend checking out his announcement.
|
|
Big Announcements on PrePAN
It is now out in the open and Kentaro passed the ownership to Kyoto.pm. If you don't know it yet, PrePAN helps people discuss their plans for creating modules for CPAN. It certainly looks nice! The source code is on Github.
|
|
SCK - 2.5 is Out !
A URL shortener system in Perl Dancer written by geistteufel. The source code is on Github.
|
|
Announcements
|
|
|
nginx-perl: the state of things
Nginx::Perl, maintained by Alexandr Gomoliako, provides full-featured perl support for nginx via a Perl API. This version provides an asynchronous API.
|
|
New Citrus Perl keeping ahead of the $->MainLoop
Mark Dootson has release version 14 of Citrus Perl and then quickly followed it with version 14a fixing an issue with the release. The objective of the Citrus Perl distribution is to make it very easy to re-package applications written in WxPerl on any of the 3 major platforms.
|
|
Articles
|
|
|
HTML::TableExtract is beautiful
In this post, Sinan Unur gives a beautiful example how Perl can help with unemployment. Or at least how you can use the HTML::TableExtract module to, well, extract tables from an HTML page. Also, I think posting beautiful examples of Perl solutions to actual problem is much better than complaining about bad examples.
|
|
SSL security in HTTP::Tiny
Mike Doherty is asking a dangerous question. Why is there no SSL support in core perl? Till that happens he offers an explanation on how to use SSL with HTTP::Tiny and how to even validate the SSL certificate.
|
|
One Unit of Stepping Up
Joel Berger tells us the story of how he contacted Chris Maloney, the author of Physics::Unit who has not touched his module for 8 years. What would you say if someone contacted you about such ancient history?
|
|
Dependencies, Minimizers, and Regressing to JavaScript
Last week there was a little drama over a bug Ovid found in a YAML code written by Ingy. Now chromatic takes his sharp keyboard and tells us his opinion about writing software for people who cannot install software...
|
|
A success story for Config::Model
Dominique Dumont, the author of Config::Model shares an e-mail he got telling the story of 'a script that was never intended to be used for more than a few month. But as things go, we were still using it after a few years.' - oh how familiar is that? It needed a way to configure it.
|
|
|
|
Discussion
|
|
|
Testing
|
A late Perl QA Hackathon 2012 post scriptum
Renormalist (Steffen Schwigon) was also in Paris working on some really boring stuff (his words). But wait, his benchmarks show that perl got 20% slower somewhere between 5.8 and 5.10 and stayed that way. Except, that it seems the latest changes in 5.15 got the speed back.
|
|
Code
|
Still alive, Inline::Lua?
Rob Hoeltz is looking for Tassilo von Parseval as he would like to take over the maintenance of Inline::Lua. Does anyone have direct contact with him?
|
|
git-age-report
Dave Rolsky provides a nice solution in Perl to find the files in a git repository, that have not been changed for a long time. But then it got golfed to some really short solution using find and xargs. Of course the latter won't work on Windows.
|
|
SnipMate Cheatsheets Generator
Do you remember the Template::Caribou project of Yanick Champoux? Now he is using that module and explains in detail how to create the templates that will generate the cheat sheets.
|
|
|
|
Fun
|
|
|
DC-Baltimore Perl Workshop 2012
Thomas Klausner from Vienna.pm visited the US and attended his first ever Perl Workshop in the US. Read his fun report and check out his pictures.
|
|
Slides
|
|
|
Videos
|
It's about unicorns
Sebastian Riedel posted the video created by Glen Hinkle praising Mojolicious. It's a funny video and it is only 1:08 min long.
|
|
Perl 6
Participants of the Perl 6 Hackathon in Oslo have already written four reports. Pick your favorite author here:
|
|
|
|
|
|
|
|
|
Editors
|
1.0.1 released
Perlipse is a Perl editor based on Eclipse written by Jae Gangemi. I have not tried it but I am happy to see more tools for Perl developers.
|
|
Other
|
My favorite editor is Vim
Sinan Unur explains why Vim is his favourite editor, even though he hardly knows it and how a $20 investment helped him reduce his time wasting by 30%. I like how he puts real numbers to his 'cost' and 'profit'.
|
|
Events
|
|
|
|
|
YAPC::NA
June 13-15, 2012, Madison, Wisconsin, USA
|
|
|
|
You know, you could get the Perl Weekly right in your mailbox. Every Week. Free of charge!
|


THANK YOU!
Your submission has been received.
I will be in touch within 2 business days
HOME
|
PRICING
|
PORTFOLIO
|


{% extends 'layouts/shop.html' %} {% block content %}
Cloud Servers on SoftLayer, an IBM Company
All the power a Bare Metal can deliver, hourly!


At AppsCode, we focus on helping you achieve the outcomes you need to make your business successful. Our Support plans are designed to give you the right mix of tools and access to expertise so that you can be successful with AppsCode products while optimizing performance, managing risk, and keeping costs under control.
Our pricing plans are product specific and you will need a separate subscription for each product.
Our pricing plans are designed to meet your need, risk tolerance and budget constraints
If you have a question, we are here to help! Don't hesitate to reach out.
Talk an expert about {{ $p.name }}
Schedule a MeetingDownload the {{ $p.name }} White Paper
Download NowSubscribe to Our Newsletter
Learn about {{ $p.name }} from our docs
Read the DocsMonthly plans are subject to a 30 day minimum term. Monthly plans can be upgraded anytime. Annual plans can be downgraded at the end of the term.
Our payment processing is powerd by Stripe. You credit card data never touches our servers. For more information, please visit stripe.com.
There is no cancellation fee. But plans are subject to minimum duration as stated above.
We accept all popular credit/debit cards such as Visa, Mastercard, American Express, Discover, etc. We also accept ACH debit/credit.


notarize directly to KMD with your own dpow network
this is what #kmdlabs does
is dirt cheap
Biz11-Dec-19 07:25 PM
Yeah, we had someone suggest this. Not a bad thought
Alright11-Dec-19 07:25 PM
roughly 1 KMD/day/chain with 7 minsigs at freq 5(edited)
Biz11-Dec-19 07:26 PM
Still non-ideal, but something to think about
Alright11-Dec-19 07:26 PM
could be even cheaper if you tweak the stuff mentioned above
Biz11-Dec-19 07:26 PM
Tradeoffs between cost and security
Alright11-Dec-19 07:26 PM
always
1
Biz11-Dec-19 07:29 PM
Is there a reason that 64 was chosen for the number of notary nodes? Or relatively arbitrary
Alright11-Dec-19 07:29 PM
64bit mask
could be redesigned, but have to consider number of connections between nodes
64 is a massive amount of connections already, adding even 1 more adds a lot more
trying to think of equation for it
Biz11-Dec-19 07:39 PM
Ah, so in your implementation, those nodes are constantly connected
This makes sense
jl777c11-Dec-19 07:39 PM
whoever said it costs $10K per year for BTC txfees is off by a factor of 10 or more
Biz11-Dec-19 07:40 PM
That was my feeling as well @jl777c
jl777c11-Dec-19 07:40 PM
for a 13 signature notarization, we are paying about $10 each
Alright11-Dec-19 07:40 PM
it's like $9-10 every 10 minutes
jl777c11-Dec-19 07:40 PM
about 50 BTC per year
Alright11-Dec-19 07:40 PM
not including server costs, man hours, etc(edited)
Biz11-Dec-19 07:41 PM
Ah, well what’s the point of a notarization every 10 minutes?
When a single block can take longer than that to confirm once?
jl777c11-Dec-19 07:41 PM
limiting the time to conduct a 51% attack
on the non-notarized blocks
if you notarized once per day, the cost would be a lot lower, but you would go an entire day between notarizations
Biz11-Dec-19 07:41 PM
I don’t see how a non-confirmed BTC tx should be used to prevent that
jl777c11-Dec-19 07:42 PM
the non-notarized blocks are at risk
BTC blocks arrive on average once per 10 minutes
Biz11-Dec-19 07:42 PM
Okay. So just design choices we aren’t seeing eye to eye on really
I would think once per hour would be sufficient to prevent large rollbacks.
Or maybe once per 30 minutes
jl777c11-Dec-19 07:46 PM
then the cost is only $500 per day
artik12311-Dec-19 08:10 PM
I was thinking about an idea of an oracle that tracks BTC fees.
So that notaries tx fee will be just enough to be included in the BTC chain but not more than that. I think that it can save a lot of money.(edited)


And the peace came to me In The Sweet Hereafter
As reviewed by James Brundage
Indeed the hereafter is sweet. I watched the film on vacation, at a friends, having been cramped in a town where I was isolated from the foreign film, the independent film. Sundance award winners, Cannes award winners: all of them, excluded from my quaint little hamlet. However, I made it a resolution to rent a "real" movie while away, and I did.
 This alone, however, did not win it the Grand Prix. What got it that was the subtle, beautiful way that the stories are all intertwined: the lawyer with his own daemons who tries to channel their anger towards an adversary that does not exist.  The survivor confined to a wheelchair. The daughter of the lawyer, a compulsive liar who may or may not have AIDS and has been in drug clinics all her life.
The Sweet Hereafter takes its morals out of a children' book, in which a piper lead all of the children of the town into a magical cave save one: a cripple (symbolic, of course, of the wheelchair girl), who is the only one who can see the truth after all that has transpired. It is a homage to the happenstance, to the terrible tragedies that befall us and leave us wondering "why?" The irony being that the one who was most affected by the accident is the one who wants revenge the least, and who realizes the truth: that there is no one to blame, but that we must have someone to lay our guilty conscience upon.
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


A page created to experiment with a combination of CSS and HTML for a fictional Cupcake Shop Client.
A page created using only HTML for a persons first webpage.
A page which highlights how one says hello and goodbye in pig latin.
A page which highlights how one says goodbye in many languages
A alteration of a cookie recipe
This is a page for a fictional beach resort
This is a minimalist attempt to the look of wikkipedias main page
This is a second attempt to create and modify using the BootStrap framework
This is a styling project using the bootstrap framework
This is a project to create a page for a fictional Animal Shelter in Portland
This is a page for built to highlight pcitures for a interior designer
This is designed page for a fictional british band
This is a page which uses a mix of html and css to jazz up a resume for a rocket ship specalist
This was a prepatory assigment in pracicing the assignment, creation and use of classes in formating a page.
This is a site created to highlight the basic apperance of a blod using minimal html and css in the look and feel.