Re: [HACKERS] [PATCH] fix DROP OPERATOR to reset links to itself on commutator and negator
On 26-02-2016 17:51, Roma Sokolov wrote: > Fixed the patch to be more descriptive and to avoid repeating same > computation over and over again. See v2 of the patch attached. > Oh, much better. > Why do you think that? Should I remove them or maybe send as separate > patch? > Because it is not a common practice to test catalog dependency on separate tests (AFAICS initial catalogs are tested with oidjoins.sql). Also, your test case is too huge for such a small use case. If you can reduce it to a small set of commands using some of the oidjoins.sql queries, I think it could be sufficient. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_basebackup compression TODO item
On 03-03-2016 14:44, Magnus Hagander wrote: > On Thu, Mar 3, 2016 at 6:34 PM, Andres Freund <mailto:and...@anarazel.de>> wrote: > > On 2016-03-03 18:31:03 +0100, Magnus Hagander wrote: > > I think we want it at protocol level rather than pg_basebackup level. > > I think we may want both eventually, but I do agree that protocol level > has a lot higher "priority" than that. Something like protocol level > compression has a bit of different tradeofs than compressing base > backups, and it's nice not to compress, uncompress, compress again. > > > > Yeah, good point, we definitely want both. Based on the field experience > I've had (which might differ from others), having it protocol level > would help more people tough, so should be higher prio. > Some time ago, I started a thread [1] to implement compression at protocol level. The use cases are data load over slow links and reduce bandwidth consumption during replication. At that time, there wasn't a consensus about which compression algorithm to choose. After the WAL compression feature, I think we can do some POC with LZ compression (that is already available in common). I'll try to update the code and do some benchmarks. [1] http://www.postgresql.org/message-id/4fd9698f.2090...@timbira.com -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)
On 26-01-2016 09:53, Michael Paquier wrote: > Something like the patch attached would be fine? This wins a backpatch > because the query continuously running eats memory, no? > +1. Although it breaks compatibility, a function that just eats resources is not correct. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] remove wal_level archive
On 26-01-2016 12:56, Simon Riggs wrote: > Removing one of "archive" or "hot standby" will just cause confusion and > breakage, so neither is a good choice for removal. > Agree. > What we should do is > 1. Map "archive" and "hot_standby" to one level with a new name that > indicates that it can be used for both/either backup or replication. > (My suggested name for the new level is "replica"...) > 2. Deprecate "archive" and "hot_standby" so that those will be removed > in a later release. > 3. Add a WARNING at startup (until removal of values) saying something like "'archive' value is deprecated and will be removed in a future version. Use 'replica' value instead." -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Raising the checkpoint_timeout limit
On 01-02-2016 21:13, Andres Freund wrote: > is there any reason for the rather arbitrary and low checkpoint_timeout > limit? > AFAICS the only reason is to run recover quickly. This setting is the same value since day 1. > A high timeout has the advantage that the total amount of full page > writes reduces and, especially if the whole system fits into s_b, that > the total amount of writes to disk is drastically reduced. > This statement could be added to documentation. Using this use case, I want to propose raising the c_t upper limit to one day or even a week. > I'm not sure what'd actually be a good upper limit. I'd be inclined to > even go to as high as a week or so. A lot of our settings have > upper/lower limits that aren't a good idea in general. > A week is an insane default value. However, I'm fine with 10 until 20 minutes (those are the most common values I use for c_t). -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] get current log file
On 02-02-2016 10:22, Armor wrote: > As we known, the name of current log file depends on the number of > seconds (for simple, later I will call it last_syslogger_file_time) > since Epoch when create new log file. So, for this feature, the key is > how syslogger process pass last_syslogger_file_time to backend processes. > I didn't like the name. Let's call it syslogger_file_name. It describes what the variable is (actual file name that syslogger is writing on). > To pass last_syslogger_file_time, we have 2 solutions: 1, add a > global variable to record last_syslogger_file_time which shared by > backends and syslogger, so backends can get last_syslogger_file_time > very easily; 2 syslogger process send last_syslogger_file_time to pgstat > process when last_syslogger_file_time changes, just as other auxiliary > processes send stat message to pgstat process, and pgstat process will > write last_syslogger_file_time into stat file so that backend can > get last_syslogger_file_time via reading this stat file. > I prefer (1) because (i) logfile name is not statistics and (ii) stats collector could not respond in certain circumstances (and even discard some messages). -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] get current log file
On 26-02-2016 08:03, Robert Haas wrote: > I don't think we're going to accept this feature if it might fail in > corner cases. And that design seems awfully complex. > Agree. > The obvious way to implement this, to me at least, seems to be for the > syslogger to write a file someplace in the data directory containing > the name of the current log file. When it switches log files, it > rewrites that file. When you want to know what the current logfile > is, you read that file. > That is not an elegant solution but it is simple. However, it is another file in PGDATA. I can live with that but if we have consensus, let's do it optional. > But there's one thing I'm slightly baffled about: why would you > actually need this? > The use case I have in mind is consume log file by using a tool like logstash. In this case, logstash accepts patterns and you can also use syslog for it. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] get current log file
On 26-02-2016 11:50, Tom Lane wrote: > This needs to be explained a lot more clearly than it has been so far, > else we are going to reject this proposed feature as being more code and > more overhead than is justified. Exactly why would you need a pointer to > the current log file, rather than just configuring whatever tool you use > to vacuum up everything in the pg_log directory? Why would this use-case > not suffer from nasty race conditions (ie, what happens when current log > file changes immediately before or immediately after you look at the > pointer)? > Those are good concerns. Also, we already have emit_log_hook that could grab server log messages. A small extension using the hook (there are some out there) could be use with a log consuming tool. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] fix DROP OPERATOR to reset links to itself on commutator and negator
On 26-02-2016 12:46, Roma Sokolov wrote: > Regression tests are added to check DROP OPERATOR behaves as intended > (including > case with self-commutator and unlikely case with operator being both negator > and > commutator). > I don't think those are mandatory. > Should this patch be added to CommitFest? > Why not? I didn't test your patch but + if (isDelete ? (t->oprcom == baseId || t->oprnegate == baseId) + : !OidIsValid(t->oprcom) || !OidIsValid(t->oprnegate)) ... is hard to understand. Instead, you could separate the conditional expression into a variable. + if (isDelete ? t->oprnegate == baseId : !OidIsValid(t->oprnegate)) It could be separate into a variable to be readable (or at least deserve a comment). (isDelete ? InvalidOid : ObjectIdGetDatum(baseId)) ... and this one too. It is used in 4 places in that function. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Renaming of pg_xlog and pg_clog
On 26-08-2016 09:25, Devrim Gündüz wrote: > On Fri, 2016-08-26 at 21:12 +0900, Michael Paquier wrote: >> In short, with the current names, sometimes users think that pg_xlog >> and pg_clog are just logs. And so it is fine to delete them to free up >> space, corrupting their cluster, because they are just *logs*. > > ...and we also have "pg_logical", that includes a "log" keyword already... > "clog" and "xlog" is almost "log"; "logical" is not. I don't imagine people confusing "logical" meaning "log". -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Renaming some binaries
Hi, I'm bringing this $subject into discussion again. Historically, we are carrying binary names that have been confused newbies. createuser is the worst name so for. Also, names like createdb, initdb, reindexdb, and droplang does not suggest what product it is referring to. Adding a prefix (pg_, pg, ...) would 'make things clear'. If we have a consensus about this change, I suggest renaming the following binaries: clusterdb createdb createlang createuser dropdb droplang dropuser initdb oid2name reindexdb vacuumdb vacuumlo Another major change related to this topic is assemble functionalities from binaries. We currently have 34 binaries (is that a lot for a single software?). Also, some of them have the same principle: execute a administrative or maintenance command. IMHO, from the list above, we could reduce it to: pg_command: clusterdb, createdb, dropdb, createuser, dropuser, createlang, droplang, reindexdb, vacuumdb, vacuumlo. It also has the advantage to allow adding new administrative/maintenance commands to it in the future; pg_oid2name: I don't have a strong opinion that it fits in pg_command; initdb: we already have 'pg_ctl init' (since 9.0) and could remove initdb. Opinions? -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Renaming some binaries
On 26-08-2016 14:03, David Fetter wrote: > Would these make sense as pg_ctl options, or are you separating them > out because they're not instance-wide? If separating them is > important on those grounds, how about something like pg_db or > pg_db_command? > It doesn't make sense because pg_ctl is server-side and pg_command would be client-side. >> pg_oid2name: I don't have a strong opinion that it fits in pg_command; > > I vaguely knew that this existed, but I can't recall having heard of > anybody actually using it. I suppose it's under pg_ctl if the split > above between instance-wide and db-specific holds. > I don't use it for a long time. It also a client-side binary then better place for it is pg_command. BTW, is anybody using it? If so, we could add this functionality to psql and remove it. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Postgresql gives error that role goes not exists while it exists
2017-10-03 5:49 GMT-03:00 Nick Dro : > Can someone assists with the issue posted on StackOverflow? > > https://stackoverflow.com/questions/46540537/postgresql-9-3-creation-of-group-role-causes-permission-problems > > > Creation of new Group Role causes postgresql to think that Login roles does > not exist. I think it's a bug? or at least a wrong error message > I'm not sure. I bet a dime that the role was created as "Iris" and you are trying to assing "iris" (they are different). If you list the roles, we can confirm that. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Move pg_largeobject to a different tablespace *without* turning on system_table_mods.
On 18-10-2016 10:13, Andreas Joseph Krogh wrote: > From time to time pg_largeobject comes up as an issue with being > implemented as a system-catalog. > Did you read the archives [1]? > As I see it, there are 2 relevant use-cases for improving the situation: > 1. Being able to pg_dump *without* any LOs (think of it as >without the contents of pg_largeobject). This is very handy >for testing/troubleshooting. > It could be an option (--no-blobs). The -b option has a limited use case. > 2. Being able to move pg_largeobject to a different tablespace >*without* turning on system_table_mods. This is important for >people storing LOTS of large-objects on separate >disks (non-SSD) and hence in a different tablespace. > Anyone willing to discuss this? > This was proposed a few years ago but no one cared to draft a patch. [1] https://www.postgresql.org/message-id/3073cc9b0910051618t693d15f3u265872908240d...@mail.gmail.com -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Fast Default WIP patch for discussion
On 26-10-2016 12:43, Serge Rielau wrote: > Posting to this group on a Friday evening was obviously a Bad Idea(tm). :-) > Serge, add your patch to the next commitfest [1] so we don't forget to review it. [1] https://commitfest.postgresql.org/11/ -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_recvlogical --endpos
On 01-09-2016 01:41, Craig Ringer wrote: > Here's a rebased version of my pg_recvlogical --endpos patch from the > 9.5 series, updated to incoroprate Álvaro's changes. > I should review this patch in the other commitfest but was swamped with work. The patch is almost ready but I have some points. * We usually don't include itemlist into binary options. I suggest you to add a new paragraph for the first item and the second one you could add a note; * I think you should add a small note explaining the 'endpos' behavior. Also, I think endpos could be inclusive (since recovery also has this behavior by default); * I think there is a typo in those pieces of code: + if (endpos != InvalidXLogRecPtr && walEnd >= endpos) + if (endpos != InvalidXLogRecPtr && cur_record_lsn > endpos) If you decide to be inclusive, it should be > otherwise >=. There could be TAP tests for pg_recvlogical but it is material for another patch. I'll mark this patch waiting on author for your considerations. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Upgrading postmaster's log messages about bind/listen errors
2017-03-10 1:43 GMT-03:00 Tom Lane : > Yeah, my thought was that if we've gotten along without this for 20 years, > it's probably not of interest to most people most of the time. > > +1 for DEBUG1. > 2017-03-09 23:40:12.334 EST [19335] LOG: MultiXact member wraparound > protections are now enabled > It should be DEBUG1 as soon as 9.3 is deprecated. > 2017-03-09 23:40:12.335 EST [19339] LOG: autovacuum launcher started > 2017-03-09 23:40:12.336 EST [19341] LOG: logical replication launcher > started > > +1 for DEBUG1. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento <http://www.timbira.com.br>
Re: [HACKERS] how to implement selectivity injection in postgresql
On 13-08-2014 13:33, Rajmohan C wrote: > SELECT c1, c2, c3, FROM T1, T2, T3 > WHERE T1.x = T2.x AND > T2.y=T3.y AND > T1.x >= ? selectivity 0.1 AND > T2.y > ? selectivity 0.5 AND > T3.z = ? selectivity 0.2 AND > T3.w = ? > > I need to implement Selectivity injection as shown in above query in > PostgreSQL by which we can inject selectivity of each predicate or at least > selectivity at relation level directly as part of query. Is there any > on-going work on this front? If there is no ongoing work on this, How > should I start implementing this feature? > Do you want to force a selectivity? Why don't you let the optimizer do it for you? Trust me it can do it better than you. If you want to force those selectivities for an academic exercise, that information belongs to catalog or could be SET before query starts. Start reading backend/optimizer/README. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] how to implement selectivity injection in postgresql
On 13-08-2014 15:28, Rajmohan C wrote: > Yeah. I have to do it for my academic research. Is it available in > catalogs? It is to be computed at run time from the predicates in the query > right? > The selectivity information is available at runtime. See backend/optimizer/path/costsize.c. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] createlang/droplang deprecated
2017-03-18 12:29 GMT-03:00 Tom Lane : > > But createuser/dropuser are a real problem, because they certainly could > be mistaken for system-level utilities. I proposed something along those lines [1] to fix this historical mistake but we didn't reach a consensus. createuser/dropuser could be a candidate to removal because it is easily replaced by psql -c "command here" like Simon said. If we go to this road, other binaries (that are just a wrapper around an SQL command) could be removed too (such as createdb, dropdb, clusterdb and reindexdb). [1] https://www.postgresql.org/message-id/bdd1adb1-c26d-ad1f-2f15-cc5205606...@timbira.com.br -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento <http://www.timbira.com.br>
Re: [HACKERS] [PATCH] Warn users about duplicate configuration parameters
2017-04-07 12:14 GMT-03:00 Aleksander Alekseev : > Recently I've discovered that if there are multiple values of the same > parameter in postgresql.conf PostgreSQL will silently use the last one. > It looks like not the best approach to me. For instance, user can find > the first value in the config file and expect that it will be used, etc. > Postgres configuration file concept is based on overriding parameter values. It would be annoying if we emit warning for this feature. Also, it is easier to know which file/line the parameter value came from. You can check for duplicates with a small script. -- Euler Taveira Timbira - http://www. timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento <http://www.timbira.com.br>
[HACKERS] Different table schema in logical replication crashes
Hi,
If a certain table has different schemas and the subscriber table has an
unmatched column with a not null constraint, the logical replication
crashes with the above stack trace.
-- publisher
CREATE TABLE test (a integer, b varchar not null, c numeric not null,
PRIMARY KEY(a));
-- subscriber
CREATE TABLE test (a integer, b varchar not null, c numeric not null, d
integer not null, PRIMARY KEY(a));
Program terminated with signal SIGSEGV, Segmentation fault.
#0 list_nth_cell (n=0, list=0x0) at list.c:411
411{
(gdb) bt
#0 list_nth_cell (n=0, list=0x0) at list.c:411
#1 list_nth (list=0x0, n=0) at list.c:413
#2 0x005ddc6b in ExecConstraints
(resultRelInfo=resultRelInfo@entry=0xf96868,
slot=slot@entry=0xf984d8, estate=estate@entry=0xfc3808) at execMain.c:1881
#3 0x0057b0ba in CopyFrom (cstate=0xf980c8) at copy.c:2652
#4 0x006ae3bb in copy_table (rel=) at
tablesync.c:682
#5 LogicalRepSyncTableStart (origin_startpos=0x7ffe9c340640) at
tablesync.c:789
#6 0x006afb0f in ApplyWorkerMain (main_arg=) at
worker.c:1521
#7 0x00684813 in StartBackgroundWorker () at bgworker.c:838
#8 0x0068f6a2 in do_start_bgworker (rw=0xf0cbb0) at
postmaster.c:5577
#9 maybe_start_bgworker () at postmaster.c:5761
#10 0x00690195 in sigusr1_handler (postgres_signal_arg=) at postmaster.c:5015
#11
#12 0x7fcd075f6873 in __select_nocancel () at
../sysdeps/unix/syscall-template.S:81
#13 0x00476c0c in ServerLoop () at postmaster.c:1693
#14 0x00691342 in PostmasterMain (argc=argc@entry=1,
argv=argv@entry=0xee4eb0)
at postmaster.c:1337
#15 0x00478684 in main (argc=1, argv=0xee4eb0) at main.c:228
Are we prepared to support different schemas in v10? Or should we disallow
it for v10 and add a TODO?
--
Euler Taveira Timbira -
http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
<http://www.timbira.com.br>
Re: [HACKERS] Different table schema in logical replication crashes
2017-04-14 22:36 GMT-03:00 Petr Jelinek : > I tried something bit different which seems cleaner to me - use the > pstate->r_table instead of ad-hock locally made up range table and fill > that using standard addRangeTableEntryForRelation. Both in tablesync and > in DoCopy instead of the old coding. > Patch works fine. However, I don't see any documentation about supporting different schemas for logical replication. Is it an oversight? -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento <http://www.timbira.com.br>
[HACKERS] logical replication fixes
Hi,
While inspecting the logical replication code, I found a bug that could
pick the wrong remote relation if they have the same name but different
schemas. Also, I did some spelling/cosmetic changes and fixed an oversight
in the ALTER SUBSCRIPTION documentation. Patches attached.
--
Euler Taveira Timbira -
http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
<http://www.timbira.com.br>
From da4dc2807566958dd89cc9f05bf6a83a996e99c7 Mon Sep 17 00:00:00 2001
From: Euler Taveira
Date: Wed, 12 Apr 2017 21:45:34 -0300
Subject: [PATCH 1/3] Cosmetic and spelling fixes
---
src/backend/catalog/pg_publication.c| 2 +-
src/backend/catalog/pg_subscription.c | 4 ++--
src/backend/replication/logical/message.c | 2 +-
src/backend/replication/logical/origin.c| 18 +-
src/backend/replication/logical/proto.c | 4 ++--
src/backend/replication/logical/tablesync.c | 8
6 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/src/backend/catalog/pg_publication.c b/src/backend/catalog/pg_publication.c
index 9330e23..1987401 100644
--- a/src/backend/catalog/pg_publication.c
+++ b/src/backend/catalog/pg_publication.c
@@ -312,7 +312,7 @@ GetAllTablesPublicationRelations(void)
/*
* Get publication using oid
*
- * The Publication struct and it's data are palloced here.
+ * The Publication struct and its data are palloc'ed here.
*/
Publication *
GetPublication(Oid pubid)
diff --git a/src/backend/catalog/pg_subscription.c b/src/backend/catalog/pg_subscription.c
index a183850..22587a4 100644
--- a/src/backend/catalog/pg_subscription.c
+++ b/src/backend/catalog/pg_subscription.c
@@ -403,7 +403,7 @@ RemoveSubscriptionRel(Oid subid, Oid relid)
/*
* Get all relations for subscription.
*
- * Returned list is palloced in current memory context.
+ * Returned list is palloc'ed in current memory context.
*/
List *
GetSubscriptionRelations(Oid subid)
@@ -450,7 +450,7 @@ GetSubscriptionRelations(Oid subid)
/*
* Get all relations for subscription that are not in a ready state.
*
- * Returned list is palloced in current memory context.
+ * Returned list is palloc'ed in current memory context.
*/
List *
GetSubscriptionNotReadyRelations(Oid subid)
diff --git a/src/backend/replication/logical/message.c b/src/backend/replication/logical/message.c
index 0dc3a9b..ef7d6c5 100644
--- a/src/backend/replication/logical/message.c
+++ b/src/backend/replication/logical/message.c
@@ -20,7 +20,7 @@
* Non-transactional messages are sent to the plugin at the time when the
* logical decoding reads them from XLOG. This also means that transactional
* messages won't be delivered if the transaction was rolled back but the
- * non-transactional one will be delivered always.
+ * non-transactional one will always be delivered.
*
* Every message carries prefix to avoid conflicts between different decoding
* plugins. The plugin authors must take extra care to use unique prefix,
diff --git a/src/backend/replication/logical/origin.c b/src/backend/replication/logical/origin.c
index 5eaf863..cf1a692 100644
--- a/src/backend/replication/logical/origin.c
+++ b/src/backend/replication/logical/origin.c
@@ -24,7 +24,7 @@
* two bytes allow us to be more space efficient.
*
* Replication progress is tracked in a shared memory table
- * (ReplicationStates) that's dumped to disk every checkpoint. Entries
+ * (ReplicationState) that's dumped to disk every checkpoint. Entries
* ('slots') in this table are identified by the internal id. That's the case
* because it allows to increase replication progress during crash
* recovery. To allow doing so we store the original LSN (from the originating
@@ -48,7 +48,7 @@
* pg_replication_slot is required for the duration. That allows us to
* safely and conflict free assign new origins using a dirty snapshot.
*
- * * When creating an in-memory replication progress slot the ReplicationOirgin
+ * * When creating an in-memory replication progress slot the ReplicationOrigin
* LWLock has to be held exclusively; when iterating over the replication
* progress a shared lock has to be held, the same when advancing the
* replication progress of an individual backend that has not setup as the
@@ -162,8 +162,8 @@ static ReplicationState *replication_states;
static ReplicationStateCtl *replication_states_ctl;
/*
- * Backend-local, cached element from ReplicationStates for use in a backend
- * replaying remote commits, so we don't have to search ReplicationStates for
+ * Backend-local, cached element from ReplicationState for use in a backend
+ * replaying remote commits, so we don't have to search ReplicationState for
* the backends current RepOriginId.
*/
static ReplicationState *session_replication_state = NULL;
@@ -441,7 +441,7 @@ ReplicationOriginShmemSize(void)
/*
Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()
2017-04-19 1:32 GMT-03:00 Michael Paquier : > I vote for "location" -> "lsn". I would expect complains about the > current inconsistency at some point, and the function names have been > already changed for this release.. > +1. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento <http://www.timbira.com.br>
Re: [HACKERS] Restrictions of logical replication
2017-06-16 4:00 GMT-03:00 Tatsuo Ishii : > Maybe I am missing something, but I could not find any description > that logical replication does not support large objects and TRUNCATE > in the doc. Do we want to add them to the doc as the restrictions of > the logical replication? > Docs stated "Publications can choose to limit the changes they produce to any combination of INSERT, UPDATE, and DELETE". It is clear that only those DMLs are supported. However, we should mention that large objects are not supported. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento <http://www.timbira.com.br>
Re: [HACKERS] Restrictions of logical replication
2017-06-16 11:03 GMT-03:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > > > Some of that information was sprinkled around, but I have now added a > new section that collects them all in one place. (section 31.4) Shouldn't we mention that COPY is supported? -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento <http://www.timbira.com.br>
Re: [HACKERS] [BUGS] BUG #14699: Statement trigger and logical replication
2017-06-16 22:08 GMT-03:00 Peter Eisentraut : > > The issue is that the logical replication initial data copy fires a > statement trigger for INSERT, because it's implemented as a COPY > internally. > > We should document such behavior. AFAICS we discuss later if we should provide an option to fire statement triggers during initial copy. > By contrast, the normal apply worker does not fire any statement > triggers (because they are not "statements"). > > +1. > We could adjust one or the other or leave it as is. Let's leave it as is. At least until 11. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento <http://www.timbira.com.br>
Re: [HACKERS] CREATE SUBSCRIPTION log noise
2017-06-21 15:14 GMT-03:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > > It doesn't appear to be contingent on anything other than the content of > > the command you just gave it. I don't think we need a NOTICE saying > > that it did that thing I just told it to do--that should be implicit by > > the lack of an ERROR. > > I'm appreciative of this complaint. The point is that we are allocating > resources on a remote host that should not be forgotten. I could go > either way. It is documented that subscription can create a replication slot on remote host as mentioned in section "Replication Slot Management". If we want to maintain the message let's downgrade it to DEBUG1 (as we do with "create implicit index for table") but I prefer to rip it out. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento <http://www.timbira.com.br>
Re: [HACKERS] user-based query white list
2017-07-03 3:11 GMT-03:00 Tim Burgan : > > Since then, is it now possible to configure a user to only be able to > execute a limited white-listing of queries? Is this something that could > now be implemented through extensions? > Since pg_stat_statements infrastructure, it is possible to create extensions that prohibit query execution for certain users (see sql_firewall [1] as an example). [1] https://github.com/uptimejp/sql_firewall -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento <http://www.timbira.com.br>
Re: [HACKERS] Logical decoding truncate
2017-05-11 4:23 GMT-03:00 Friedrich, Steffen < steffen.friedr...@dieboldnixdorf.com>: > I am writing a logical decoding output plugin decoding WAL to SQL which is > finally applied to target database. > > > > Is it possible to decode a TRUNCATE statement and the tables involved? > > Yes, use event triggers. You can decode whatever DDL command you want. > Assuming the SQL statement "TRUNCATE x, y;", I am interested in decoding > the operation TRUNCATE and the corresponding tables x and y so that I can > reconstruct the SQL statement/transaction. > > Is that possible? > > If so, can you please provide an example or point me into the right > direction? > > > Take a look at BDR code (bdr_queue_ddl_commands and bdr_queue_dropped_objects) [1]. It implements DDL replication too. [1] https://github.com/2ndQuadrant/bdr -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento <http://www.timbira.com.br>
Re: [HACKERS] Create subscription with `create_slot=false` and incorrect slot name
2017-05-22 17:52 GMT-03:00 Dmitry Dolgov <9erthali...@gmail.com>: > Maybe this question was already raised before, but I couldn't find a > discussion. When I'm creating a subscription with `create_slot=false` looks > like it's possible to pass a slot name with invalid characters. In this > particular case both publisher and subscriber were on the same machine: > > =# CREATE SUBSCRIPTION test_sub CONNECTION 'dbname=db host=host > port=port user=user' PUBLICATION test_pub WITH (create_slot=false, > slot_name='test slot'); > NOTICE: 0: synchronized table states > LOCATION: CreateSubscription, subscriptioncmds.c:443 > CREATE SUBSCRIPTION > Time: 5.887 ms > > The command succeed even if slot_name is invalid. That's because slot_name isn't validated. ReplicationSlotValidateName() should be called in parse_subscription_options() to avoid a pilot error. IMHO we should prevent a future error (use of invalid slot name). > Of course `test slot` doesn't exist, because I can't create a slot with > incorrect name. And consequently I can't drop this subscription: > > =# DROP SUBSCRIPTION test_sub; > ERROR: XX000: could not drop the replication slot "test slot" on > publisher > DETAIL: The error was: ERROR: replication slot name "test slot" > contains invalid character > HINT: Replication slot names may only contain lower case letters, > numbers, and the underscore character. > LOCATION: DropSubscription, subscriptioncmds.c:947 > Time: 2.615 ms > > Indeed you can drop the subscription. There are two details: (i) subscription should be disabled and (ii) slot name can't be set. bar=# drop subscription sub1; ERROR: could not drop the replication slot "does_not_exist" on publisher DETAIL: The error was: ERROR: replication slot "does_not_exist" does not exist bar=# alter subscription sub1 set (slot_name = NONE); ERROR: cannot set slot_name = NONE for enabled subscription bar=# alter subscription sub1 disable; ALTER SUBSCRIPTION bar=# drop subscription sub1; ERROR: could not drop the replication slot "does_not_exist" on publisher DETAIL: The error was: ERROR: replication slot "does_not_exist" does not exist bar=# alter subscription sub1 set (slot_name = NONE); ALTER SUBSCRIPTION bar=# drop subscription sub1; DROP SUBSCRIPTION Should we add a hint for 'could not drop the replication slot' message? -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento <http://www.timbira.com.br>
Re: [HACKERS] PG 10 release notes
2017-05-04 22:26 GMT-03:00 Andres Freund : > At least I was a bit more optimistic that we'd get a decent json plugin > into care soon-ish. While there was some initial work towards that, it > unfortunately stalled at some point. > > That was my initial idea but there wasn't some interest at that time. wal2json is used in some replication solutions but also for audit and change capture solution. I recently received some patches/suggestions from Daniele Varrazzo [1]. > Euler, are you perchance interested in working towards that? ;) > Sure. I can submit it for the next CF. [1] https://www.postgresql.org/message-id/CA%2Bmi_8bJ_uPr67j-6mbin537DVvfk%3DbOhmWneyBRfbZu89q0tw%40mail.gmail.com -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento <http://www.timbira.com.br>
Re: [HACKERS] ALTER SUBSCRIPTION ..SET PUBLICATION refresh is not throwing error.
2017-05-23 6:00 GMT-03:00 tushar : > > s=# alter subscription s1 set publication skip refresh ; > NOTICE: removed subscription for table public.t > NOTICE: removed subscription for table public.t1 > ALTER SUBSCRIPTION > s=# That's a design flaw. Since SKIP is not a reserved word, parser consider it as a publication name. Instead of causing an error, it executes another command (REFRESH) that is the opposite someone expects. Also, as "skip" is not a publication name, it removes all tables in the subscription. ALTER SUBSCRIPTION name SET PUBLICATION publication_name_list SKIP REFRESH ALTER SUBSCRIPTION name SET PUBLICATION publication_name_list REFRESH opt_definition I think the first command was a bad design. Why don't we transform SKIP REFRESH into a REFRESH option? ALTER SUBSCRIPTION sub1 SET PUBLICATION pub1 REFRESH WITH (skip = true); skip (boolean): specifies that the command will not try to refresh table information. The default is false. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento <http://www.timbira.com.br>
Re: [HACKERS] ALTER SUBSCRIPTION ..SET PUBLICATION refresh is not throwing error.
2017-05-26 17:58 GMT-03:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > On 5/24/17 15:38, Petr Jelinek wrote: > >>> I wonder if we actually need the SKIP REFRESH syntax, there is the > >>> "REFRESH [ WITH ... ]" when user wants to refresh, so if REFRESH is not > >>> specified, we can just behave as if SKIP REFRESH was used, it's not > like > >>> there is 3rd possible behavior. > >> > >> Attached patch does exactly that. > > > > And of course I forgot to update docs... > > Do we want not-refreshing to be the default behavior? It is a different behavior from the initial proposal. However, we fortunately have ALTER SUBSCRIPTION foo REFRESH PUBLICATION and can refresh later. Also, if "refresh" is more popular than "skip", it is just a small word in the command. That's the price we pay to avoid ambiguity that the previous syntax had.At least I think Petr's proposal is less confusing than mine (my proposal maintains current behavior but can cause some confusion). -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento <http://www.timbira.com.br>
Re: [HACKERS] pg_dump ignoring information_schema tables which used in Create Publication.
2017-05-26 17:52 GMT-03:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > > You cannot publish a system catalog. But a user-created table in > information_schema is not a system catalog. Replication of information_schema tables works. However, pg_dump doesn't include information_schema tables into CREATE PUBLICATION command (user-defined information_schema tables aren't included in pg_dump even *before* logical replication). IMO allow publish/subscribe of tables into information_schema is harmless (they aren't special tables like catalogs). Also, how many people would create real tables into information_schema? Almost zero. Let's leave it alone. Since pg_dump doesn't document that information_schema isn't dumped, I think we shouldn't document this for logical replication. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento <http://www.timbira.com.br>
Re: [HACKERS] ALTER SUBSCRIPTION ..SET PUBLICATION refresh is not throwing error.
2017-05-26 21:29 GMT-03:00 Petr Jelinek : > > Actually another possibility would be to remove the REFRESH keyword > completely and just have [ WITH (...) ] and have the refresh option > there, ie simplified version of what you have suggested (without the > ugliness of specifying refresh twice to disable). It will cause confusion. It seems that WITH sets ALTER SUBSCRIPTION properties. Indeed, they are REFRESH properties. I think we shouldn't exclude REFRESH keyword. Syntax leaves no doubt that WITH are REFRESH properties. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento <http://www.timbira.com.br>
Re: [HACKERS] Built-in plugin for logical decoding output
2017-09-22 19:28 GMT-03:00 Gregory Brail : > We have been working on a project that makes extensive use of logical > replication for use inside Apigee (which is a very small part of Google): > > https://github.com/apigee-labs/transicator > > In order to do this, we had to write our own logical replication plugin > because the supplied "test_decoding" plugin from the "contrib" directory was > hard for us to work with. Primarily: > test_decoding is a proof of concept to illustrate the logical decoding potential. It is not intended for production. I developed wal2json [1] for general use. It outputs changes in JSON. It was one of the first logical decoding plugins. > 1) It doesn't include all the fields that we need for Transicator (most > importantly we need the LSN and the 64-bit transaction ID). > wal2json includes both. > 2) It outputs a text format that is hard to parse. > There are a lot of JSON parsers. > I imagine that other users of logical decoding are facing similar problems. > > Would the community support the development of another plugin that is > distributed as part of "contrib" that addresses these issues? I'd be happy > to submit a patch, or GitHub repo, or whatever works best as an example. > (Also, although Transicator uses protobuf, I'm happy to have it output a > simple binary format as well.) > There was a prior discussion and it was suggestted that we have a ready-for-production plugin in core (besides pgoutput). It was suggested [1] that I submit wal2json for 11. I'm in process to clean up the code and hope to submit it to CF2. [1] https://github.com/eulerto/wal2json [2] https://www.postgresql.org/message-id/CAHE3wggh6ucSCB%2BhnSK04xEQx75f3DTz0wPSjRMJFjum6pRrPQ%40mail.gmail.com -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Built-in plugin for logical decoding output
2017-09-23 14:01 GMT-03:00 Alvaro Hernandez : > However, AFAIK, AWS's DMS uses it for production purposes (see > http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html). > It seems a bad idea. AFAICS test_decoding was not designed to be a ready-for-production plugin. It is just a proof of concept for logical decoding. > I would be happy to see another logical decoding plugin into core > starting on 11. However, this also poses a bit of a challenge for middleware > implementors: you need to support one for 9.4-9.5 (test_decoding), another > for 10 (pgoutput) and maybe another for 11 onwards. The idea of asking users > to install a binary plugin is very unsexy, so these are the options > available. > wal2json works for 9.4+ (besides the WAL messages I committed a month ago). Since this boat was already shipped we can arrange some packages for 9.4-10 (an external project) and ask vendors to support the backward-compatible plugin. The middleware implementor will have to support this new plugin format. Being JSON a widespread format, it is easier to refactor the code to parse JSON. > However, having said that, and while json is a great output format for > interoperability, if there's a discussion on which plugin to include next, > I'd also favor one that has some more compact representation format (or that > supports several formats, not only json). > We could certainly extend pgoutput to support more than one format (like pglogical did AFAIR), however, we wouldn't reuse code (different formats) and will have a fat plugin (I don't foresee a plugin using different formats in the same connection. It is difficult to coordinate a change like that having only one-way communication). -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Enhancements to passwordcheck
2017-09-25 15:04 GMT-03:00 Bossart, Nathan : > Currently, the passwordcheck module provides a few basic checks to strengthen > passwords. However, any configuration must be ready at compile time, and many > common password requirements cannot be enforced without creating a custom > version of this module. I think there are a number of useful parameters that > could be added to enable common password restrictions, including the following > list, which is based on some asks from our customers: > > passwordcheck.min_password_length > passwordcheck.min_uppercase_letters > passwordcheck.min_lowercase_letters > passwordcheck.min_numbers > passwordcheck.min_special_chars > +1. > passwordcheck.superuser_can_bypass > It is not clear if it will bypass the checks for (i) a new superuser or (ii) a superuser creating a new role. I wouldn't recommend using such option even tough it is a common practice. > passwordcheck.max_expiry_period > How would you enforce that? If the password expires, you can log in to change the password. If you let him/her to get in and change the password, you can't obligate the user to do that. You could send a message to remember that the password will expire but you can't enforce that (unless you make a change in the protocol). > passwordcheck.force_new_password > Does it mean a password different from the old one? +1. It could be different from the last 3 passwords but we don't store a password history. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Built-in plugin for logical decoding output
2017-09-26 2:46 GMT-03:00 Alvaro Hernandez : > I think that's awesome. Now... back to my original question: what is the > *list* of output plugins supported by managed PostgreSQL solutions? So far > it looks like wal2json for 9.5-9.6 on RDS, and nothing else (it may just be > not complete, but in the best case this list won't be unfortunately > long...). > I can tell by other plugin authors but wal2json for being one of the first plugins available, it is pretty popular. I've heard that it is used in replication and audit solutions. It doesn't support all of the logical decoding features (for example, origin filter) but it is in my roadmap. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Logical Replication - test_decoding - unchanged-toast-datum
2017-09-26 1:11 GMT-03:00 Abhinav Singh : > 5. On the target, when I do a select * and see that the column with > character varying() datatype has changed to 'unchanged-toast-datum'. > The column "is_toast" didn't change its value to "unchanged-toast-datum". It is just a test_decoding convention that means that the value is stored in a TOAST table and it was not changed. test_decoding doesn't show TOAST values to avoid performance problems and to be brief. Try a SELECT in the table and you will see that the value is already there. You didn't write an explicit question but I believe it was your doubt, didn't it? -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Logical Replication - test_decoding - unchanged-toast-datum
7,838,839,840,841,842,843,844,845,846,847,848,849,850,851,852,853,854,855,856,857,858,859,860,861,862,863,864,865,866,867,868,869,870,871,872,873,874,875,876,877,878,879,880,881,882,883,884,885,886,887,888,889,890,891,892,893,894,895,896,897,898,899,900,901,902,903,904,905,906,907,908,909,910,911,912,913,914,915,916,917,918,919,920,921,922,923,924,925,926,927,928,929,930,931,932,933,934,935,936,937,938,939,940,941,942,943,944,945,946,947,948,949,950,951,952,953,954,955,956,957,958,959,960,961,962,963,964,965,966,967,968,969,970,971,972,973,974,975,976,977,978,979,980,981,982,983,984,985,986,987,988,989,990,991,992,993,994,995,996,997,998,999,1000' 1/7DF224D8|295592|COMMIT 295592 1/7DF224D8|295593|BEGIN 295593 1/7DF22510|295593|table public.toast_test1: UPDATE: id[integer]:1 is_not_toast[integer]:1 is_toast[character varying]:unchanged-toast-datum 1/7DF225A0|295593|COMMIT 295593 (10 registros) euler=# SELECT * FROM public.toast_test1; id|is_not_toast|is_toast 1|1|1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,244,245,246,247,248,249,250,251,252,253,254,255,256,257,258,259,260,261,262,263,264,265,266,267,268,269,270,271,272,273,274,275,276,277,278,279,280,281,282,283,284,285,286,287,288,289,290,291,292,293,294,295,296,297,298,299,300,301,302,303,304,305,306,307,308,309,310,311,312,313,314,315,316,317,318,319,320,321,322,323,324,325,326,327,328,329,330,331,332,333,334,335,336,337,338,339,340,341,342,343,344,345,346,347,348,349,350,351,352,353,354,355,356,357,358,359,360,361,362,363,364,365,366,367,368,369,370,371,372,373,374,375,376,377,378,379,380,381,382,383,384,385,386,387,388,389,390,391,392,393,394,395,396,397,398,399,400,401,402,403,404,405,406,407,408,409,410,411,412,413,414,415,416,417,418,419,420,421,422,423,424,425,426,427,428,429,430,431,432,433,434,435,436,437,438,439,440,441,442,443,444,445,446,447,448,449,450,451,452,453,454,455,456,457,458,459,460,461,462,463,464,465,466,467,468,469,470,471,472,473,474,475,476,477,478,479,480,481,482,483,484,485,486,487,488,489,490,491,492,493,494,495,496,497,498,499,500,501,502,503,504,505,506,507,508,509,510,511,512,513,514,515,516,517,518,519,520,521,522,523,524,525,526,527,528,529,530,531,532,533,534,535,536,537,538,539,540,541,542,543,544,545,546,547,548,549,550,551,552,553,554,555,556,557,558,559,560,561,562,563,564,565,566,567,568,569,570,571,572,573,574,575,576,577,578,579,580,581,582,583,584,585,586,587,588,589,590,591,592,593,594,595,596,597,598,599,600,601,602,603,604,605,606,607,608,609,610,611,612,613,614,615,616,617,618,619,620,621,622,623,624,625,626,627,628,629,630,631,632,633,634,635,636,637,638,639,640,641,642,643,644,645,646,647,648,649,650,651,652,653,654,655,656,657,658,659,660,661,662,663,664,665,666,667,668,669,670,671,672,673,674,675,676,677,678,679,680,681,682,683,684,685,686,687,688,689,690,691,692,693,694,695,696,697,698,699,700,701,702,703,704,705,706,707,708,709,710,711,712,713,714,715,716,717,718,719,720,721,722,723,724,725,726,727,728,729,730,731,732,733,734,735,736,737,738,739,740,741,742,743,744,745,746,747,748,749,750,751,752,753,754,755,756,757,758,759,760,761,762,763,764,765,766,767,768,769,770,771,772,773,774,775,776,777,778,779,780,781,782,783,784,785,786,787,788,789,790,791,792,793,794,795,796,797,798,799,800,801,802,803,804,805,806,807,808,809,810,811,812,813,814,815,816,817,818,819,820,821,822,823,824,825,826,827,828,829,830,831,832,833,834,835,836,837,838,839,840,841,842,843,844,845,846,847,848,849,850,851,852,853,854,855,856,857,858,859,860,861,862,863,864,865,866,867,868,869,870,871,872,873,874,875,876,877,878,879,880,881,882,883,884,885,886,887,888,889,890,891,892,893,894,895,896,897,898,899,900,901,902,903,904,905,906,907,908,909,910,911,912,913,914,915,916,917,918,919,920,921,922,923,924,925,926,927,928,929,930,931,932,933,934,935,936,937,938,939,940,941,942,943,944,945,946,947,948,949,950,951,952,953,954,955,956,957,958,959,960,961,962,963,964,965,966,967,968,969,970,971,972,973,974,975,976,977,978,979,980,981,982,983,984,985,986,987,988,989,990,991,992,993,994,995,996,997,998,999,1000 (1 registro) euler=# -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgs
Re: [HACKERS] TODO: replica information functions
On 28-07-2015 15:35, Josh Berkus wrote: pg_standby_is_streaming() returns true if the standby is configured for streaming and is currently connected with the master. returns false if the connection to the master is broken, of if there is no primary_conninfo +1. pg_standby_conninfo() returns connection string to master. Superuser-only for previously discussed reasons -1. It could be retrieved using the proposal below. pg_recovery_config(config_item TEXT) returns the specified configuration item from recovery.conf superuser-only? pg_recovery_config(OUT name text, OUT setting text) SETOF record or pg_recovery_config(OUT name text, OUT setting text, IN all bool) SETOF record This function covers pg_standby_conninfo(). -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] TODO : Allow parallel cores to be used by vacuumdb [ WIP ]
On 08-11-2013 06:20, Dilip kumar wrote: > On 08 November 2013 13:38, Jan Lentfer > > >> For this use case, would it make sense to queue work (tables) in order of >> their size, starting on the largest one? > >> For the case where you have tables of varying size this would lead to a >> reduced overall processing time as it prevents large (read: long processing >> time) tables to be processed in the last step. While processing large tables >> at first and filling up "processing slots/jobs" when they get free with >> smaller tables one after the other would safe overall execution time. > Good point, I have made the change and attached the modified patch. > Don't you submit it for a CF, do you? Is it too late for this CF? -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Changeset Extraction v7.6.1
On 18-02-2014 06:33, Andres Freund wrote: > I really hope there will be nicer ones by the time 9.4 is > released. Euler did send in a json plugin > http://archives.postgresql.org/message-id/52A5BFAE.1040209%2540timbira.com.br > , but there hasn't too much feedback yet. It's hard to start discussing > something that needs a couple of patches to pg before you can develop > your own patch... > BTW, I've updated that code to reflect the recent changes in the API and publish it in [1]. This version is based on the Andres' branch xlog-decoding-rebasing-remapping. I'll continue to polish this code. Regards, [1] https://github.com/eulerto/wal2json -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Storing the password in .pgpass file in an encrypted format
On 21-02-2014 09:49, firoz e v wrote: > Even though, there are ways to set the permissions on .pgpass, to disallow > any access to world or group, the security rules of many organizations > disallow to hold any kind of passwords, as plain text. > Is your goal hiding the password in .pgpass? You could add support to accept md5... storage format as password. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_dump reporing version of server & pg_dump as comments in the output
On 27-02-2014 21:10, Wang, Jing wrote: > Using pg_dump can dump the data into the file with format set to be > 'c','t' or plain text. In the existing version the version of server & > pg_dump is already there when the format of file is 'c' or 't'. And even > for the plain text format file the version of server & pg_dump is > already there if using '--verbose' in pg_dump. Using '--verbose' leads > to some many other prints which are not required always. > I don't buy your argument. Why isn't verbose option sufficient? Did you read the old thread about this [1]? AFAICS a lot of people compare pg_dump diffs. If we apply this patch, it would break those applications. Also, it is *already* available if you add verbose option (which is sufficient to satisfy those that want the client and/or server version) in plain mode (the other modes already include the desired info by default). In the past, timestamps were removed to avoid noise in diffs. [1] http://www.postgresql.org/message-id/3677.1253912...@sss.pgh.pa.us -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] getting rid of maintainer-check
On 03-09-2013 23:41, Peter Eisentraut wrote: > The maintainer-check target never really caught on, I think. Most > people don't run it, and that in turn annoys those who do. Also, it > doesn't provide much functionality. > It has its use (before each release) but I agree that it isn't used during minor version updates (because you need to update only one or two po files). > I propose that we get rid of it and roll the functionality into the > regular build. > By 'regular build' you mean --enable-nls? If so, +1. > - Running duplicate_oids during the regular build was already discussed > elsewhere recently. There are some details to be resolved there, but > it's doable. > This has been bashing sufficient developers along the years. +1. > - Checking for tabs in SGML files can be run during the regular > documentation build without problems. > This one too. +1. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch for reserved connections for replication users
On 15-10-2013 14:34, Josh Berkus wrote: > On 10/15/2013 07:36 AM, Robert Haas wrote: >> On Tue, Oct 15, 2013 at 10:34 AM, Andres Freund >> wrote: >>> Josh said we should treat replication connections in a separate "pool" >>> from normal database connections, right? So you withdraw your earlier >>> objection to that? >> >> I don't think that's what he said. Here's what I was referring to: > > To clarify: I do, indeed, support the idea of treating replication > connections as a pool outside of max_connections. Here's why: > +1. I've already faced the same problem Josh described. Even if it is documented (as in max_wal_senders), it is not easy to figure out why you can't connect (check 2 parameters and query 2 views). Also, the 'check connections' task is so complicated in a monitoring tool. Let's separate the replication connections in another pool (that is not related to user connections). We already have the infrastructure to limit replication connections (max_wal_senders), let's use it. > FATAL: connection limit exceeded for non-superusers > > SHOW max_connections; > > 100 > > SELECT COUNT(*) FROM pg_stat_activity; > > 94 > > SHOW superuser_reserved_connections; > > 3 > > > > ... search around quite a bit, eventually figure out that you have > three replication connections open. We've already set up an illogical > and hard-to-troubleshoot situation where replication connections do not > appear in pg_stat_activity, yet they are counted against max_connections. > Another situation is when you can't run pg_basebackup because automated routines got all of the available connections and the replication user is not a superuser (even if replication user is a superuser, if some app run as superuser there won't be slots available). -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] TODO : Allow parallel cores to be used by vacuumdb [ WIP ]
On 07-11-2013 09:42, Dilip kumar wrote: Dilip, this is on my TODO for 9.4. I've already had a half-backed patch for it. Let's see what I can come up with. > Is it required to move the common code for parallel operation of pg_dump and > vacuumdb to one place and reuse it ? > I'm not sure about that because the pg_dump parallel code is tight to TOC entry. Also, dependency matters for pg_dump while in the scripts case, an order to be choosen will be used. However, vacuumdb can share the parallel code with clusterdb and reindexdb (my patch does it). Of course, a refactor to unify parallel code (pg_dump and scripts) can be done in a separate patch. > Prototype patch is attached in the mail, please provide your > feedback/Suggestions... > I'll try to merge your patch with the one I have here until the next CF. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] TODO : Allow parallel cores to be used by vacuumdb [ WIP ]
On 08-11-2013 05:07, Jan Lentfer wrote: > For the case where you have tables of varying size this would lead to > a reduced overall processing time as it prevents large (read: long > processing time) tables to be processed in the last step. While > processing large tables at first and filling up "processing > slots/jobs" when they get free with smaller tables one after the > other would safe overall execution time. > That is certainly a good strategy (not the optimal [1] -- that is hard to achieve). Also, the strategy must: (i) consider the relation age before size (for vacuum); (ii) consider that you can't pick indexes for the same relation (for reindex). [1] http://www.postgresql.org/message-id/CA+TgmobwxqsagXKtyQ1S8+gMpqxF_MLXv=4350tfzvqawke...@mail.gmail.com -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pg_resetxlog sentences
Hi,
While updating translations, I came across those almost similar sentences.
pg_controldata.c
273 printf(_("Latest checkpoint's oldestCommitTs: %u\n"),
274ControlFile.checkPointCopy.oldestCommitTs);
pg_resetxlog.c
668 printf(_("Latest checkpoint's oldest CommitTs: %u\n"),
669ControlFile.checkPointCopy.oldestCommitTs);
670 printf(_("Latest checkpoint's newest CommitTs: %u\n"),
671ControlFile.checkPointCopy.newestCommitTs);
To be consistent, let's change pg_resetxlog to mimic pg_controldata
sentence. Patch is attached. It is new in 9.5 so backpatch is needed.
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
>From cc8da654ab363366860de6c114bfc9a28561978a Mon Sep 17 00:00:00 2001
From: Euler Taveira
Date: Tue, 15 Sep 2015 22:45:38 -0300
Subject: [PATCH] Use the same word as pg_controldata.
---
src/bin/pg_resetxlog/pg_resetxlog.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/bin/pg_resetxlog/pg_resetxlog.c b/src/bin/pg_resetxlog/pg_resetxlog.c
index b771a63..a1a9e14 100644
--- a/src/bin/pg_resetxlog/pg_resetxlog.c
+++ b/src/bin/pg_resetxlog/pg_resetxlog.c
@@ -665,9 +665,9 @@ PrintControlValues(bool guessed)
ControlFile.checkPointCopy.oldestMulti);
printf(_("Latest checkpoint's oldestMulti's DB: %u\n"),
ControlFile.checkPointCopy.oldestMultiDB);
- printf(_("Latest checkpoint's oldest CommitTs: %u\n"),
+ printf(_("Latest checkpoint's oldestCommitTs: %u\n"),
ControlFile.checkPointCopy.oldestCommitTs);
- printf(_("Latest checkpoint's newest CommitTs: %u\n"),
+ printf(_("Latest checkpoint's newestCommitTs: %u\n"),
ControlFile.checkPointCopy.newestCommitTs);
printf(_("Maximum data alignment: %u\n"),
ControlFile.maxAlign);
--
2.1.4
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pltcl: sentence improvement
Hi,
This simple patch improves a sentence. Spotted while working on translation.
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
>From 7cae997155e222e0a8280018cccf717ab2ee1c38 Mon Sep 17 00:00:00 2001
From: Euler Taveira
Date: Wed, 16 Sep 2015 09:58:52 -0300
Subject: [PATCH] Improve sentence.
Sentence is now consistent with a backend one.
---
src/pl/tcl/pltcl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/pl/tcl/pltcl.c b/src/pl/tcl/pltcl.c
index edfda59..3dcb31f 100644
--- a/src/pl/tcl/pltcl.c
+++ b/src/pl/tcl/pltcl.c
@@ -1055,7 +1055,7 @@ pltcl_trigger_handler(PG_FUNCTION_ARGS, bool pltrusted)
if (ret_numvals % 2 != 0)
ereport(ERROR,
(errcode(ERRCODE_E_R_I_E_TRIGGER_PROTOCOL_VIOLATED),
- errmsg("invalid return list from trigger - must have even # of elements")));
+ errmsg("invalid return list from trigger - must have even number of elements")));
modattrs = (int *) palloc(tupdesc->natts * sizeof(int));
modvalues = (Datum *) palloc(tupdesc->natts * sizeof(Datum));
--
2.1.4
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pltcl: sentence improvement
On 16-09-2015 10:57, Tom Lane wrote:
Euler Taveira writes:
This simple patch improves a sentence. Spotted while working on translation.
I concur that spelling out "#" as "number" is an improvement, but I'm
curious which backend error you think this matches?
It is sort of...
utils/adt/json.c
2088 ereport(ERROR,
2089 (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
2090 errmsg("argument list must have even number of
elements"),
2091 errhint("The arguments of json_build_object() must
consist of alternating keys and values.")));
replication/logical/logicalfuncs.c
361 ereport(ERROR,
362 (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
363 errmsg("array must have even number of
elements")));
Also, if we're going to change this message at all, I'm inclined to
rewrite it completely, because it doesn't really follow the style
guidelines. How about "trigger's return list must have even number of
elements"?
Works for me.
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_resetxlog sentences
On 17-09-2015 00:25, Fujii Masao wrote:
One relevant question is; why doesn't pg_controldata report newestCommitTs?
I thought about it while looking at the code but forgot to ask. AFAICS
it is an oversight. See attached patch.
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
>From 5716c69d7287d97c6eacb13c736c939d0e9223e4 Mon Sep 17 00:00:00 2001
From: Euler Taveira
Date: Thu, 17 Sep 2015 13:48:25 -0300
Subject: [PATCH] Standardize sentences.
Also, add newest CommitTs to pg_controldata. Oversight spotted by Fujii
Masao.
---
src/bin/pg_controldata/pg_controldata.c | 2 ++
src/bin/pg_resetxlog/pg_resetxlog.c | 4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/bin/pg_controldata/pg_controldata.c b/src/bin/pg_controldata/pg_controldata.c
index 704f72d..32e1d81 100644
--- a/src/bin/pg_controldata/pg_controldata.c
+++ b/src/bin/pg_controldata/pg_controldata.c
@@ -273,6 +273,8 @@ main(int argc, char *argv[])
ControlFile.checkPointCopy.oldestMultiDB);
printf(_("Latest checkpoint's oldestCommitTs: %u\n"),
ControlFile.checkPointCopy.oldestCommitTs);
+ printf(_("Latest checkpoint's newestCommitTs: %u\n"),
+ ControlFile.checkPointCopy.newestCommitTs);
printf(_("Time of latest checkpoint:%s\n"),
ckpttime_str);
printf(_("Fake LSN counter for unlogged rels: %X/%X\n"),
diff --git a/src/bin/pg_resetxlog/pg_resetxlog.c b/src/bin/pg_resetxlog/pg_resetxlog.c
index c8c1ac3..d7ac2ba 100644
--- a/src/bin/pg_resetxlog/pg_resetxlog.c
+++ b/src/bin/pg_resetxlog/pg_resetxlog.c
@@ -665,9 +665,9 @@ PrintControlValues(bool guessed)
ControlFile.checkPointCopy.oldestMulti);
printf(_("Latest checkpoint's oldestMulti's DB: %u\n"),
ControlFile.checkPointCopy.oldestMultiDB);
- printf(_("Latest checkpoint's oldest CommitTs: %u\n"),
+ printf(_("Latest checkpoint's oldestCommitTs: %u\n"),
ControlFile.checkPointCopy.oldestCommitTs);
- printf(_("Latest checkpoint's newest CommitTs: %u\n"),
+ printf(_("Latest checkpoint's newestCommitTs: %u\n"),
ControlFile.checkPointCopy.newestCommitTs);
printf(_("Maximum data alignment: %u\n"),
ControlFile.maxAlign);
--
2.1.4
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] vacuumdb sentence
Hi,
Is there a reason to quote "jobs" at this sentence?
190 fprintf(stderr, _("%s: number of parallel \"jobs\" must be at least
1\n"),
progname);
AFAICS "jobs" is neither an identifier nor an option to justify the
quotation. Also, another message a few lines above (correctly) does not
use quotes.
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] vacuumdb sentence
On 18-09-2015 00:59, Amit Kapila wrote:
On Fri, Sep 18, 2015 at 8:30 AM, Euler Taveira mailto:eu...@timbira.com.br>> wrote:
>
> Hi,
>
> Is there a reason to quote "jobs" at this sentence?
>
> 190 fprintf(stderr, _("%s: number of parallel \"jobs\" must be at
least 1\n"),
> progname);
>
> AFAICS "jobs" is neither an identifier nor an option to justify the
quotation. Also, another message a few lines above (correctly) does not
use quotes.
>
jobs is an option, refer vacuumdb docs[1].
Yeah, I know. [Too sleepy to be writing emails...] What I want to say
is: when we want to refer to an option, we usually add "option" after
the quoted name (in this case, it won't make sense). I propose to remove
the quotation because the way the sentence is written it seems we are
referring to the task instead of the option.
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Improving test coverage of extensions with pg_dump
On 17-09-2015 14:21, Michael Paquier wrote: pg_dump relies on attnum to define the column ordering, so one possibility would be to do things more consistently at backend level. Thoughts? According to your example, problem is the columns from the parent table "aa" are added _before_ declaring the inherited table "bb". Then, an attnum from column "d" (part of parent table "aa") is assigned to a lower number than in the original table "bb". Someone can say that we could assign an attnum for column "d" considering all of the inheritance tree. However, attnum is used as an index to arrays (we could bloat some of those) and some logic rely on it to count the number of columns. It would become tablecmds.c into an spaghetti. IMHO a possible way to solve it is adding support for logical column ordering. An ALTER TABLE command (emitted if a parameter was informed) during dump could handle it. BTW, last thread [1] about logical column ordering seems to have died a few months ago. Alvaro? [1] http://www.postgresql.org/message-id/20141209174146.gp1...@alvh.no-ip.org -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Small documentation fix in src/interfaces/ecpg/preproc/po/pt_BR.po
On 06-10-2015 19:49, Andreas 'ads' Scherbaum wrote: When working on a script, I stumbled over a mistake in the pt_BR.po translation for ecpg. Patch attached. I've already fixed it in the translation git. It'll be available only in the next set of releases. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Small documentation fix in src/interfaces/ecpg/preproc/po/pt_BR.po
On 07-10-2015 14:05, Alvaro Herrera wrote: Euler Taveira wrote: On 06-10-2015 19:49, Andreas 'ads' Scherbaum wrote: When working on a script, I stumbled over a mistake in the pt_BR.po translation for ecpg. Patch attached. I've already fixed it in the translation git. It'll be available only in the next set of releases. Thanks. No point in patching 9.0 anymore, BTW. Yeah, I remembered that after git push. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pam auth - add rhost item
On 14-10-2015 17:35, kolo hhmow wrote: Yes, but this is very ugly solution, becasue you have to restart postgresql daemon each time you have added a new user. > Restart != Reload. You can even do it using SQL. This solution which I propose is give an abbility to dinamicaly manage user accounts without need to restart each time a user account entry has change. > Why do you want to double restrict the access? We already have HBA. Also, you could complicate the management because you need to check two different service configurations to figure out why foo user can't log in. I'm not a PAM expert but my impression is that rhost is an optional item. Therefore, advise PAM users to use HBA is a way to not complicate the actual feature. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pam auth - add rhost item
On 15-10-2015 05:41, kolo hhmow wrote: I have already explained this in my previous post. Did you read this? > Yes, I do. So why postgresql give users an abbility to use a pam modules, when in other side there is advice to not use them? Anyway. > Where is such advise? I can't see it in docs [1]. I do not see any complication with this approach. Just use one configuration entry in pg_hba.conf, and rest entries in some database backend of pam module, which is most convenient with lot of entries than editing pg_hba.conf. Why don't you use a group role? I need just one entry in pg_hba.conf. [1] http://www.postgresql.org/docs/current/static/auth-methods.html#AUTH-PAM [2] http://www.postgresql.org/docs/current/static/role-membership.html -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pam auth - add rhost item
On 16-10-2015 10:37, Robert Haas wrote: - Did he implement this correctly? > - Would it break anything? > I did not review the patch. - Are there lots of other knobs we should expose too instead of just one? > We are providing PAM_USER and PAM_CONV. The complete list of options are [1]. Maybe PAM_RUSER? BTW, we could use pg_ident.conf to map user foo (app) to user bar (PAM). - What would it take to turn this into a committable patch? > Review? - Would the cost of exposing this and perhaps some other knobs cost too much in performance for the number of people it would make happy? > No. - If so, should the behavior be GUC-controlled or is there justification for arguing we should drop the whole patch? The patch always set PAM_RHOST, ie. it means I can't disable it (at the postgres side). Is it a problem? Of course the PAM module can provide a way to ignore it but it is not our business. I feel like we've got somebody new showing up to our community with an idea that is not obviously stupid. If we want such people to stick around, we should try to give their ideas a fair shake. I share the same feeling. I wasn't trying to throw a cold water on it. [1] http://pubs.opengroup.org/onlinepubs/8329799/pam_set_item.htm -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pg_recvlogical fixes
Hi,
While testing wal2json, I faced some problems with pg_recvlogical.
Attached is a serie of patches that can improve pg_recvlogical. Patches
#2 and #3 are bugfixes (and should be applied to 9.5 too). Patch #1 is
not mandatory to 9.5.
Short description:
#1: add a bunch of checks to complain when using an option that is not
available in the specified action;
#2: there is a wrong check because startpos option can be specified with
--create-slot;
#3: doesn't ignore startpos in --create-slot because that action could
be specified together with --start action (that uses that option);
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
>From 9b3d63d1744e2b65a7f1a1d44ed166f4c9684771 Mon Sep 17 00:00:00 2001
From: Euler Taveira
Date: Tue, 1 Sep 2015 23:52:55 -0300
Subject: [PATCH 3/3] Fix a startpos override.
Since --create-slot and --start can be specified together, we can't
override startpos while creating a slot (it'll ignore the replication
start position, if specified).
---
src/bin/pg_basebackup/pg_recvlogical.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/bin/pg_basebackup/pg_recvlogical.c b/src/bin/pg_basebackup/pg_recvlogical.c
index b59fe13..a2284d2 100644
--- a/src/bin/pg_basebackup/pg_recvlogical.c
+++ b/src/bin/pg_basebackup/pg_recvlogical.c
@@ -969,7 +969,6 @@ main(int argc, char **argv)
if (!CreateReplicationSlot(conn, replication_slot, plugin,
false, slot_exists_ok))
disconnect_and_exit(1);
- startpos = InvalidXLogRecPtr;
}
if (!do_start_slot)
--
2.1.4
>From 8393aa62cddeaff8cc66b19c6ba36a371b090db1 Mon Sep 17 00:00:00 2001
From: Euler Taveira
Date: Tue, 1 Sep 2015 23:46:33 -0300
Subject: [PATCH 2/3] Fix startpos parameter check.
startpos parameter can be specified together with --create-slot (--start
must be specified too). This check is wrong since --create-slot and
--start could be specified together.
---
src/bin/pg_basebackup/pg_recvlogical.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/bin/pg_basebackup/pg_recvlogical.c b/src/bin/pg_basebackup/pg_recvlogical.c
index 9ce237f..b59fe13 100644
--- a/src/bin/pg_basebackup/pg_recvlogical.c
+++ b/src/bin/pg_basebackup/pg_recvlogical.c
@@ -848,9 +848,9 @@ main(int argc, char **argv)
exit(1);
}
- if (startpos != InvalidXLogRecPtr && (do_create_slot || do_drop_slot))
+ if (startpos != InvalidXLogRecPtr && !do_start_slot)
{
- fprintf(stderr, _("%s: cannot use --create-slot or --drop-slot together with --startpos\n"), progname);
+ fprintf(stderr, _("%s: can only use --startpos together with --start\n"), progname);
fprintf(stderr, _("Try \"%s --help\" for more information.\n"),
progname);
exit(1);
--
2.1.4
>From da241d9e2529888297c0f68bd89706fb59ae5884 Mon Sep 17 00:00:00 2001
From: Euler Taveira
Date: Tue, 1 Sep 2015 23:34:51 -0300
Subject: [PATCH 1/3] pg_recvlogical: Tighten checks for action parameters.
Until now, the mistaken parameters are ignored (which is bad because
that parameter won't take the desired effect). Complaining about the
"wrong" parameter will help the user to fix the problem immediately.
---
doc/src/sgml/ref/pg_recvlogical.sgml | 2 +-
src/bin/pg_basebackup/pg_recvlogical.c | 82 +++---
2 files changed, 77 insertions(+), 7 deletions(-)
diff --git a/doc/src/sgml/ref/pg_recvlogical.sgml b/doc/src/sgml/ref/pg_recvlogical.sgml
index 9d0b58b..a513047 100644
--- a/doc/src/sgml/ref/pg_recvlogical.sgml
+++ b/doc/src/sgml/ref/pg_recvlogical.sgml
@@ -149,7 +149,7 @@ PostgreSQL documentation
In --start mode, start replication from the given
LSN. For details on the effect of this, see the documentation
in
-and . Ignored in other modes.
+and .
diff --git a/src/bin/pg_basebackup/pg_recvlogical.c b/src/bin/pg_basebackup/pg_recvlogical.c
index 93f61c3..9ce237f 100644
--- a/src/bin/pg_basebackup/pg_recvlogical.c
+++ b/src/bin/pg_basebackup/pg_recvlogical.c
@@ -30,12 +30,17 @@
/* Time to sleep between reconnection attempts */
#define RECONNECT_SLEEP_TIME 5
+#define DEFAULT_MESSAGE_TIMEOUT (10 * 1000) /* 10 secs = default */
+#define DEFAULT_FSYNC_INTERVAL (10 * 1000) /* 10 secs = defualt */
+#define DEFAULT_PLUGIN "test_decoding"
+
/* Global Options */
static char *outfile = NULL;
+static char *plugin = NULL;
static int verbose = 0;
static int noloop = 0;
-static int standby_message_timeout = 10 * 1000; /* 10 sec = default */
-static int fsync_interval = 10 * 1000; /* 10 sec = default */
+static int standby_message_timeout = -1;
+static int fsync_interval = -1;
static XLogRecPtr startpos = InvalidXLogRecPtr;
static bool do_create_slot = false;
static bool slot_exists_ok = false;
@@ -45,7 +50,6 @@ static bool do_drop_slot = f
Re: [HACKERS] Duplicated assignment of slot_name in walsender.c
On 20-10-2015 08:28, Bernd Helmle wrote: The 2nd assignment to slot_name looks unnecessary? Yes, it is. Seems to be an oversight. Patch attached. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento >From 87570993d29f2c98121c3a0a75c85cdc4211f24f Mon Sep 17 00:00:00 2001 From: Euler Taveira Date: Wed, 21 Oct 2015 16:52:26 -0300 Subject: [PATCH] Fix a duplicated assignment in walsender code It seems that the 2nd assignment was an oversight. Spotted by Bernd Helmle. --- src/backend/replication/walsender.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/backend/replication/walsender.c b/src/backend/replication/walsender.c index c6043cd..ca1b4b9 100644 --- a/src/backend/replication/walsender.c +++ b/src/backend/replication/walsender.c @@ -834,7 +834,6 @@ CreateReplicationSlot(CreateReplicationSlotCmd *cmd) ReplicationSlotSave(); } - slot_name = NameStr(MyReplicationSlot->data.name); snprintf(xpos, sizeof(xpos), "%X/%X", (uint32) (MyReplicationSlot->data.confirmed_flush >> 32), (uint32) MyReplicationSlot->data.confirmed_flush); -- 2.1.4 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_recvlogical fixes
On 21-10-2015 18:36, Andres Freund wrote: On 2015-10-21 11:52:31 -0300, Euler Taveira wrote: While testing wal2json, I faced some problems with pg_recvlogical. Attached is a serie of patches that can improve pg_recvlogical. Patches #2 and #3 are bugfixes (and should be applied to 9.5 too). Patch #1 is not mandatory to 9.5. #1: add a bunch of checks to complain when using an option that is not available in the specified action; I'm not a fan of doing that. Doing that for every option tends to be more annoying than helpful. E.g. pgbench's checks requires you to pointlessly remove a lot of harmless options just to be able to pass -i. Your comparison is not fair (8 x 28 options). I tend to agree that a lot of check is not nice to maintain. However, it is a good UI practice. #2: there is a wrong check because startpos option can be specified with --create-slot; #3: doesn't ignore startpos in --create-slot because that action could be specified together with --start action (that uses that option); It doesn't make sense to specify it with --create-slot though - you can't even know what a the start position would mean before the slot is created. You can't get older records than the ones at slot creation time, and you can't know what a feature xlog position would mean. If it doesn't make sense, why --create-slot can be specified together with --start at all? Maybe a comment could clarify your point (circa line 902) because it is not clear in docs that a past LSN could not be specified or even a future LSN when both options are specified together. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_basebackup and replication slots
On 26-10-2015 08:58, Joshua D. Drake wrote: Hello, The fact that pg_basebackup doesn't use replicaiton slots, is that a technical limitation or just a, "we need a patch"? It is not in 9.5 but it is already there. commit 0dc848b0314d63188919f1ce943730eac684dccd Author: Peter Eisentraut Date: Tue Jul 21 21:06:45 2015 -0400 pg_basebackup: Add --slot option This option specifies a replication slot for WAL streaming (-X stream), so that there can be continuous replication slot use between WAL streaming during the base backup and the start of regular streaming replication. Reviewed-by: Michael Paquier -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: Fix parallel workers connection bug in pg_dump (Bug #13727)
On 30-10-2015 10:04, Zeus Kronion wrote: I'm still unclear on how to write regression tests for a connectivity bug. Are they necessary in this case? There aren't regression tests for pg_dump. However, your instructions are sufficient to demonstrate the bug. You could continue the thread in -bugs because the discussion started there. Sometimes people track -bugs ML to make sure that some bugs aren't forgotten. Add your patch to the next CF [1]. [1] https://commitfest.postgresql.org/7/ -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Need to print the raw_parse_tree in the Log file
On 07-11-2015 12:21, Praveen M wrote: I would like to print the raw parse tree into the log . Is there any internal utility function to achieve this. If there is none , can you please help me to achieve this. debug_print_parse = on -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade and statistics
On 13-03-2012 21:34, Bruce Momjian wrote: > It might be a solution for cases where we don't modify it. I frankly am > worried that if we copy over statistics even in ASCII that don't match > what the server expects, it might lead to a crash, which has me back to > wanting to speed up vacuumdb. > That was discussed in another thread some time ago [1]. Adopting a hack solution is not the way to go. It could lead to bad consequences in a near future. For 9.2, we could advise users to divide the ANALYZE step into ANALYZE-per-table steps and run them all in parallel. This ANALYZE-per-table ranking could be accomplished using a simple approach like '... row_number() OVER (ORDER BY pg_relation_size(oid) ... WHERE row_number % n = x' (tip stolen from Simon's book). [1] http://archives.postgresql.org/message-id/4f10a728.7090...@agliodbs.com -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] VALID UNTIL
Hi,
I have a hard time figuring out why my replication stopped with a message like
FATAL: password authentication failed for user "foo"
in the logs. I thought it was some pg_hba.conf change, a pgpass modification,
or NOLOGIN option, it wasn't. I was out of options when I remembered to check
if there is a VALID OPTION option set. For my surprise, it wasn't exposed by
\du or even \du+.
euler=# \du
List of roles
-[ RECORD 1 ]--
Role name | euler
Attributes | Superuser, Create role, Create DB, Replication
Member of | {}
-[ RECORD 2 ]--
Role name | foo
Attributes |
Member of | {}
euler=# \du+
List of roles
-[ RECORD 1 ]---
Role name | euler
Attributes | Superuser, Create role, Create DB, Replication
Member of | {}
Description |
-[ RECORD 2 ]---
Role name | foo
Attributes |
Member of | {}
Description |
but after checking in the catalog I got it.
test=# select rolname,rolvaliduntil from pg_authid;
rolname | rolvaliduntil
-+
euler |
foo | 2012-03-01 00:00:00-03
(2 rows)
Is there any reason why it is not exposed? What about exposing that
information in attributes or even in a separate column? It could help
troubleshooting quickly on this case.
--
Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Syntax error and reserved keywords
On 14-03-2012 10:58, Dimitri Fontaine wrote: > Is there a reason for us not to add an HINT: "user" is a reserved > keyword or something like that, other than nobody having been interested > in doing the work? > AFAIK, there is no such warning message in the code. If you're volunteering to do it, please cover all sql commands. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] postgres long options without value
On 04-04-2012 17:07, Peter Eisentraut wrote: > postgres -D ... --debug-print-plan > > which fails, because you need to write --ssl=on or > --debug-print-plan=true etc. > > Have others had the same experience? Would it be worth supporting the > case without value to default to on/true? > Please, don't do it. You can be fooled when we change a parameter default value (specially if you have it in a script that is used in different versions) from major versions. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [patch] for "psql : Allow processing of multiple -f (file) options "
On 09-04-2012 02:43, Vikash3 S wrote: > Please find the patch regarding trivial changes against To Do item list for > "psql : Allow processing of multiple -f (file) options ". > Looking for valuable feedback. > Aren't you forget to cover the single transaction (-1) mode? How would you handle ON_ERROR_* options? Look at the archives for references. Also, your disclaimer doesn't seems attractive; make it clear you're contributing code under the PostgreSQL license. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] comment for "fast promote"
On 27-07-2013 06:57, Tomonari Katsumata wrote:
> 1. replicating 3 servers(A,B,C)
> A->B->C
> ("trigger_file = /tmp/trig" is set in recovery_recovery.conf on B and C.)
>
> 2. stop server A and promoting server B with "touch /tmp/trig;pg_ctl
> promote"
> B->C
> (/tmp/trig file remains on server B)
>
Why don't you setup recovery_end_command parameter? The trigger_file is
important in some (legacy) environments and that is using an external
tool to handle the service initialization.
It seems to me it is an opportunity to improve trigger_file description
(informing a way to cleanup the file created) than to suggest it is not
useful.
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])
On 18-07-2013 17:02, Alvaro Herrera wrote: > I think we should just put the config directives of ALTER SYSTEM into a > file, not dir, alongside postgresql.conf; I would suggest > postgresql.auto.conf. This file is parsed automatically after > postgresql.conf, without requiring an "include" directive in > postgresql.conf. If the user does not want that file, they can remove > it; but a future ALTER SYSTEM will create the file again. No need to > parse stuff to find out whether the directory exists, or the file > exists, or such nonsense. > +1. Let's keep it as simple as possible. There will be the possibility to revisit the directory and/or include* ideas. > I think the only drawback of this is that there's no way to disable > ALTER SYSTEM (i.e. there's no directory you can remove to prevent the > thing from working). > Disable ALTER SYSTEM? No, thanks. Change the postgresql.auto.conf permissions or ownership is an elegant way to disable it. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Remove fsync ON/OFF as a visible option?
On 21-03-2015 17:53, Josh Berkus wrote: > Now, I have *long* been an advocate that we should ship a "stripped" > PostgreSQL.conf which has only the most commonly used settings, and > leave the rest of the settings in the docs and > share/postgresql/postgresql.conf.advanced. Here's my example of such a > file, tailored to PostgreSQL 9.3: > +1. I agree that common used settings in a postgresql.conf file is useful for newbies. How do we ship it? (i) replace postgresql.conf with newbie.conf at $PGDATA; (ii) let postgresql.conf alone and include newbie.conf at the end; (iii) install newbie.conf at share directory and let packagers decide to replace postgresql.conf with it or not; (iv) install newbie.conf at share directory and add an option in initdb to select it as postgresql.conf, say, --config=simple. As a starting point, (i) could be too radical because some DBAs are used to check that occasional parameter at postgresql.conf. (ii) will advocate the newbie configuration file. However, do we want a new configuration file? We already have two and another one could be very confusing. The option (iii) will be effective if popular distributions decided to use newbie.conf as postgresql.conf. An the last option is a flexible way to install a basic configuration (and imo is the way to satisfy those that want basic configuration file available). It also has a way to extend that option to other setups like one-file-per-section or developer-conf. The downside of the proposed newbie.conf is that we need to maintain another configuration file. During beta time, some parameters could be added/removed to/from newbie.conf. > https://github.com/pgexperts/accidentalDBA/blob/master/vagrant/setup/postgres/postgresql.conf > Your example is an good resource for newbies. I would like to see an archive section (separated from replication) and some more log options (where is log_file_prefix and log_duration?). port? A ssl section? track_function? That could have others but those are on my preference list. > While we likely wouldn't want to ship all of the advice in the comments > in that file (the calculations, in particular, have been questioned > since they were last tested with PostgreSQL 8.3), that gives you an > example of what a simple/mainstream pg.conf could look like. I would > further advocate that that file be broken up into segments (resources, > logging, connects, etc.) and placed in conf.d/ > IMHO too many files could confuse simple installations. > All that being said, what *actually* ships with PostgreSQL is up to the > packagers, so anything we do with pg.conf will have a limited impact > unless we get them on board with the idea. > In my experience, packagers tend to follow the default postgresql.conf. They don't add or remove parameters but replace values. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] parallel mode and parallel contexts
On 19-03-2015 15:13, Robert Haas wrote:
> On Wed, Mar 18, 2015 at 5:36 PM, Andres Freund wrote:
>> Reading the README first, the rest later. So you can comment on my
>> comments, while I actually look at the code. Parallelism, yay!
>
I'm also looking at this piece of code and found some low-hanging fruit.
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
>From 3ce5376868f61a67540915b83a15c59a31fc895a Mon Sep 17 00:00:00 2001
From: Euler Taveira
Date: Sun, 26 Apr 2015 13:49:37 -0300
Subject: [PATCH 1/3] fix some typos.
---
src/backend/access/heap/heapam.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index da0b70e..16d8c59 100644
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -2250,7 +2250,7 @@ heap_prepare_insert(Relation relation, HeapTuple tup, TransactionId xid,
/*
* For now, parallel operations are required to be strictly read-only.
* Unlike heap_update() and heap_delete(), an insert should never create
- * a combo CID, so it might be possible to relax this restrction, but
+ * a combo CID, so it might be possible to relax this restriction, but
* not without more thought and testing.
*/
if (IsInParallelMode())
@@ -2666,7 +2666,7 @@ heap_delete(Relation relation, ItemPointer tid,
Assert(ItemPointerIsValid(tid));
/*
- * Forbid this during a parallel operation, lest it allocate a combocid.
+ * Forbid this during a parallel operation, lets it allocate a combocid.
* Other workers might need that combocid for visibility checks, and we
* have no provision for broadcasting it to them.
*/
@@ -3124,7 +3124,7 @@ heap_update(Relation relation, ItemPointer otid, HeapTuple newtup,
Assert(ItemPointerIsValid(otid));
/*
- * Forbid this during a parallel operation, lest it allocate a combocid.
+ * Forbid this during a parallel operation, lets it allocate a combocid.
* Other workers might need that combocid for visibility checks, and we
* have no provision for broadcasting it to them.
*/
@@ -5435,7 +5435,7 @@ heap_inplace_update(Relation relation, HeapTuple tuple)
/*
* For now, parallel operations are required to be strictly read-only.
* Unlike a regular update, this should never create a combo CID, so it
- * might be possible to relax this restrction, but not without more
+ * might be possible to relax this restriction, but not without more
* thought and testing. It's not clear that it would be useful, anyway.
*/
if (IsInParallelMode())
--
2.1.4
>From cf25445d9d21496b6927e9ef45e6c3815fef8ad5 Mon Sep 17 00:00:00 2001
From: Euler Taveira
Date: Sun, 26 Apr 2015 14:24:26 -0300
Subject: [PATCH 2/3] Avoid compiler warnings about unused variables in
assert-disabled builds.
---
src/backend/utils/fmgr/funcapi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/backend/utils/fmgr/funcapi.c b/src/backend/utils/fmgr/funcapi.c
index ebd7ddd..b9f2b06 100644
--- a/src/backend/utils/fmgr/funcapi.c
+++ b/src/backend/utils/fmgr/funcapi.c
@@ -887,7 +887,7 @@ get_func_trftypes(HeapTuple procTup,
Oid **p_trftypes)
{
- Form_pg_proc procStruct = (Form_pg_proc) GETSTRUCT(procTup);
+ Form_pg_proc procStruct PG_USED_FOR_ASSERTS_ONLY = (Form_pg_proc) GETSTRUCT(procTup);
Datum protrftypes;
ArrayType *arr;
int nelems;
--
2.1.4
>From 7d1716fdf84f24a1dddfa02db27d532e06c92c3d Mon Sep 17 00:00:00 2001
From: Euler Taveira
Date: Sun, 26 Apr 2015 14:52:39 -0300
Subject: [PATCH 3/3] Fix some more typos.
---
src/backend/access/transam/README.parallel | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/backend/access/transam/README.parallel b/src/backend/access/transam/README.parallel
index c066fff..2257e4c 100644
--- a/src/backend/access/transam/README.parallel
+++ b/src/backend/access/transam/README.parallel
@@ -76,7 +76,7 @@ Instead, we take a more pragmatic approach. First, we try to make as many of
the operations that are safe outside of parallel mode work correctly in
parallel mode as well. Second, we try to prohibit common unsafe operations
via suitable error checks. These checks are intended to catch 100% of
-unsafe things that a user might do from the SQL interface, but code writen
+unsafe things that a user might do from the SQL interface, but code written
in C can do unsafe things that won't trigger these checks. The error checks
are engaged via EnterParallelMode(), which should be called before creating
a parallel context, and disarmed via ExitParallelMode(), which should be
@@ -108,7 +108,7 @@ worker. This includes:
- The combo CID mappings. This is needed to ensure consistent answers to
tuple visibility checks. The need to synchronize this data structure is
a major reason why we can't support
Re: [HACKERS] initdb start server recommendation
On 01-05-2015 11:14, Bruce Momjian wrote: > Currently initdb outputs suggested text on starting the server: > > Success. You can now start the database server using: > > /u/pgsql/bin/postgres -D /u/pgsql/data > or > /u/pgsql/bin/pg_ctl -D /u/pgsql/data -l logfile start > > I am now thinking pg_ctl should be recommended first. At the time this > text was written pg_ctl was new. > +1. BTW, why are we advocating postgres binary use at all? AFAICS the main postgres (or postmaster) uses are (i) startup script (which also advocate for 'pg_ctl -w') and (ii) disaster/debugging purposes. None of those use cases are intended for general users. Let's make it simple and drop 'postgres' line. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] initdb start server recommendation
On 05-05-2015 16:36, Peter Eisentraut wrote: > 1. I like copying and pasting the "postgres" line during development. > That's not a reason to keep it, necessarily. > I prefer pg_ctl because of symmetry (start, stop, restart, reload and even init). > 2. If you're saying, most people shouldn't run postgres directly, then > most people also shouldn't run initdb directly. This message will > mainly be seen either by developers or testers or tutorial users or > do-it-yourselfers. In which case knowing the functionality of the > postgres program is valid. > I'm not saying to discourage postgres binary use. It has its merit and utility. However, the information after initdb is for general users and not developers/testers (because the latter know how to start the service) -- that's my impression. We have an utility that concentrate all of the necessary modes (even init) to operate postgres service. Why not advocate it for general users? pg_ctl sounds more natural for postgres administration. How do you explain that you have to start the service with 'postgres' but stop it with 'pg_ctl' ou even 'kill'? > 3. It's not clear that pg_ctl is necessarily the best way to start the > server. With things like systemd, launchd, supervisord that like to > manage the daemons directly, using postgres directly might be the > preferable choice. > Agree. However, I'm saying that _general users_ (those that don't use OS init interface) tend to prefer 'pg_ctl' to 'postgres'. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] settings without unit
Hi,
I noticed that a setting in pg_settings without units have NULL and ""
as unit values ("" for integer and NULL for the other ones). Could we be
consistent? It is like that since units were introduced (b517e65). No
unit means unit = NULL. A proposed patch is attached.
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
*** guc.c.orig 2014-09-04 20:16:09.108040521 -0300
--- guc.c 2014-09-04 17:48:35.113897896 -0300
***
*** 7690,7696
values[2] = "min";
break;
default:
! values[2] = "";
break;
}
}
--- 7690,7696
values[2] = "min";
break;
default:
! values[2] = NULL;
break;
}
}
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] What .gitignore files do in the tarball?
On 25-11-2015 10:40, Michael Paquier wrote: > > > On Wed, Nov 25, 2015 at 4:36 PM, Victor Wagner <mailto:vi...@wagner.pp.ru>> wrote: > > I've noticed that source distribution archive of the postgresql contain > more than hundred of .gitignore files and one .gitattributes. > > Is it just a bug nobody bothered to fix, or these files can make > any sense outside git repository? > > > They are harmless and do not consume that much space in a tarball, > contrary to .git/ which has the whole history of the repository. And > this behavior matches for example git-archive. Keeping them also has the > advantage to allow people to deploy a tarball easily in an orphan branch > of a fresh git repository. In a couple of companies where people can > just work from tarballs (this exists and I know some), that's actually > useful to keep them. > Even if they are small, git use will be limited without .git directory. The weird setup you mentioned above could be used but imho it is rare. People who want to work on tarballs are not interested in repository history or which file belongs to repository. If someone wants to develop a patch, we should advice him/her to use git. +1 to remove all of those files. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: About CMake v2
On 24-11-2015 13:35, YUriy Zhuravlev wrote: > News about CMake: > I built postgres, initdb, createdb, psql, pg_ctl using CMake. > After make install you can run initdb after run postgres after createdb and > use it by psql. Only for Linux now and realy bugy (and the code is very dirt) > but it work! > If someone wants to test or to help: > https://github.com/stalkerg/postgres_cmake > I give it a try. Nice WIP. IMHO you should try to support cmake version that are available in the stable releases. Looking at [1], I think the best choice is 2.8.11 (because it will cover Red Hat based distros and also Debian based ones). Are you using a new feature from 3.1? I mean, it should be nice to cover old stable releases, if it is possible. [1] https://cmake.org/Wiki/CMake_Life_Cycle_Considerations -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: About CMake v2
On 26-11-2015 07:33, YUriy Zhuravlev wrote: > On Thursday 26 November 2015 01:29:37 Euler Taveira wrote: >> I give it a try. Nice WIP. IMHO you should try to support cmake version >> that are available in the stable releases. Looking at [1], I think the >> best choice is 2.8.11 (because it will cover Red Hat based distros and >> also Debian based ones). Are you using a new feature from 3.1? I mean, >> it should be nice to cover old stable releases, if it is possible. > Maybe you are right. But by the time I finish my work I think 3.0 will become > a standard. CMake is developing rapidly and soon will have version 3.4.1 > And one more thing: a normal documentation came with 3.0. :) > But I try to check my code for 2.8.11, now I have 3.4.0 (latest for Gentoo). > Have in mind that stable distros have a long cycle and are not released soon. If you are planning your cmake work for 9.6 or even 9.7, it is prudent to suport Red Hat 7 or Debian 8 because it will be a pain in the neck to install a new cmake version just to compile postgres. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: About CMake v2
On 26-11-2015 14:06, YUriy Zhuravlev wrote: > On Thursday 26 November 2015 17:42:16 you wrote: >> No point in doing any work if you don't agree with the basic prerequisites. > I meant that support for older versions of CMake I'll do when will implement > other functions. > I think you don't understand the point: start with the *right* cmake version because you could have to redo (a lot of) your work or have your patch rejected because you don't follow our advice. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] another idea for changing global configuration settings from SQL
On 16-11-2012 12:27, Hannu Krosing wrote:
> Why not just make the sending SIGHUP a separate command as it is now ?
>
> SELECT pg_reload_config();
>
... or even a RELOAD command. I've already coded a WIP patch for such command.
--
Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
diff --git a/doc/src/sgml/ref/allfiles.sgml b/doc/src/sgml/ref/allfiles.sgml
index df84054..f7abb57 100644
--- a/doc/src/sgml/ref/allfiles.sgml
+++ b/doc/src/sgml/ref/allfiles.sgml
@@ -137,6 +137,7 @@ Complete list of usable sgml source files in this directory.
+
diff --git a/doc/src/sgml/ref/reload.sgml b/doc/src/sgml/ref/reload.sgml
new file mode 100644
index 000..42baab9
--- /dev/null
+++ b/doc/src/sgml/ref/reload.sgml
@@ -0,0 +1,51 @@
+
+
+
+
+ RELOAD
+ 7
+ SQL - Language Statements
+
+
+
+ RELOAD
+ reread configuration files
+
+
+
+ RELOAD
+
+
+
+
+RELOAD
+
+
+
+
+ Description
+
+
+ The RELOAD command triggers postgres to
+ reread its configuration files (postgresql.conf,
+ pg_hba.conf, etc.). This allows changing of
+ configuration-file options that do not require a complete restart to take
+ effect. RELOAD command has the same behavior as
+ pg_ctl reload option (see ).
+
+
+
+ Only superusers can call RELOAD.
+
+
+
+
+ Compatibility
+
+
+ The RELOAD command is a
+ PostgreSQL language extension.
+
+
+
diff --git a/doc/src/sgml/reference.sgml b/doc/src/sgml/reference.sgml
index 0872168..ae5fb67 100644
--- a/doc/src/sgml/reference.sgml
+++ b/doc/src/sgml/reference.sgml
@@ -165,6 +165,7 @@
&reassignOwned;
&reindex;
&releaseSavepoint;
+ &reload;
&reset;
&revoke;
&rollback;
diff --git a/src/backend/nodes/copyfuncs.c b/src/backend/nodes/copyfuncs.c
index 9387ee9..5dd6d0e 100644
--- a/src/backend/nodes/copyfuncs.c
+++ b/src/backend/nodes/copyfuncs.c
@@ -4394,6 +4394,9 @@ copyObject(const void *from)
case T_CheckPointStmt:
retval = (void *) makeNode(CheckPointStmt);
break;
+ case T_ReloadStmt:
+ retval = (void *) makeNode(ReloadStmt);
+ break;
case T_CreateSchemaStmt:
retval = _copyCreateSchemaStmt(from);
break;
diff --git a/src/backend/nodes/equalfuncs.c b/src/backend/nodes/equalfuncs.c
index 95a95f4..7118bb6 100644
--- a/src/backend/nodes/equalfuncs.c
+++ b/src/backend/nodes/equalfuncs.c
@@ -2881,6 +2881,9 @@ equal(const void *a, const void *b)
case T_CheckPointStmt:
retval = true;
break;
+ case T_ReloadStmt:
+ retval = true;
+ break;
case T_CreateSchemaStmt:
retval = _equalCreateSchemaStmt(a, b);
break;
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index e4ff76e..b853e8f 100644
--- a/src/backend/parser/gram.y
+++ b/src/backend/parser/gram.y
@@ -245,7 +245,7 @@ static void processCASbits(int cas_bits, int location, const char *constrType,
VariableResetStmt VariableSetStmt VariableShowStmt
ViewStmt CheckPointStmt CreateConversionStmt
DeallocateStmt PrepareStmt ExecuteStmt
- DropOwnedStmt ReassignOwnedStmt
+ DropOwnedStmt ReassignOwnedStmt ReloadStmt
AlterTSConfigurationStmt AlterTSDictionaryStmt
%type select_no_parens select_with_parens select_clause
@@ -571,7 +571,7 @@ static void processCASbits(int cas_bits, int location, const char *constrType,
QUOTE
RANGE READ REAL REASSIGN RECHECK RECURSIVE REF REFERENCES REINDEX
- RELATIVE_P RELEASE RENAME REPEATABLE REPLACE REPLICA
+ RELATIVE_P RELEASE RELOAD RENAME REPEATABLE REPLACE REPLICA
RESET RESTART RESTRICT RETURNING RETURNS REVOKE RIGHT ROLE ROLLBACK
ROW ROWS RULE
@@ -794,6 +794,7 @@ stmt :
| PrepareStmt
| ReassignOwnedStmt
| ReindexStmt
+ | ReloadStmt
| RemoveAggrStmt
| RemoveFuncStmt
| RemoveOperStmt
@@ -1657,6 +1658,20 @@ CheckPointStmt:
}
;
+/*
+ *
+ * RELOAD
+ *
+ */
+
+ReloadStmt:
+ RELOAD
+{
+ ReloadStmt *n = makeNode(ReloadStmt);
+ $$ = (Node *)n;
+}
+ ;
+
/*
*
@@ -12605,6 +12620,7 @@ unreserved_keyword:
| REINDEX
| RELATIVE_P
| RELEASE
+ | RELOAD
| RENAME
| REPEATABLE
| REPLACE
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index b223fee..a0e55df 100644
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend/postmaster/postmaster.c
@@ -2116,6 +2116,15 @@ reset_shared(int port)
CreateSharedMemoryAndSemaphores(false, port);
}
+/*
+ * RELOAD command -- rereads configuration files
+ */
+void
+ReloadConfiguration(void)
+{
+ signal_child(PostmasterPid, SIGHUP);
+}
+
/*
* SIGHUP -- reread config files, and tell children to do same
diff --git a/src/backend/tcop/utility.c b/src/backend/tcop/
Re: [HACKERS] another idea for changing global configuration settings from SQL
On 16-11-2012 12:59, Peter Eisentraut wrote: > Another way might be something like > > SET GLOBAL name = value > That's the exact syntax I'm about to propose for this feature (changing settings using SQL). Are you thinking about allowing changing all configuration settings or just a subset of it? As said by others, using pg_db_role_setting only works for sighup, superuser, and user context. How would you solve the backend and postmaster context? -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Fwd: Successful post to pgsql-hackers
On 09-02-2013 13:45, Gurjeet Singh wrote: > BTW, I hope I understand what selfcopy is: send a copy to yourself. Why would > that be turned on by default? > If you want to reply to yourself... -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Materialized views WIP patch
On 03-03-2013 21:27, Josh Berkus wrote: > I think it would be worth talking about when someone wants to implement > it. I'd imagine it would require setting a GUC, though, which would be > off by default for obvious reasosn. > -1. Why not adding another storage_parameter, say auto_refresh=on? Also, that's another feature. > And of limited utility, as mentioned. > For a first release, that is fine as is. Let's not complicate a feature that has been widely discussed in this development cycle. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SIGHUP not received by custom bgworkers if postmaster is notified
On 21-03-2013 05:06, Michael Paquier wrote: > While playing with custom background workers, I noticed that postmaster does > not notify its registered bgworkers if it receives SIGHUP, > so you have to send a SIGHUP directly to the bgworker process to notify it. > Signal handling is correctly done for SIGQUIT and SIGTERM for shutdown only. > Attached is a patch fixing that, I simply added a call to > SignalUnconnectedWorkers in SIGHUP_handler:postmaster.c. > Per this discussion [1], it seems it is as is by design. AFAICS controlling when change configuration parameters is a feature not a bug. Alvaro said that will include SIGHUP handle in worker_spi (see [2] for how to process configurantion file). [1] http://www.postgresql.org/message-id/20121231140353.gc4...@alvh.no-ip.org [2] http://www.postgresql.org/message-id/1357210591.1964.22.camel@localhost.localdomain -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NOT NULL constraints in foreign tables
On 17-08-2012 16:44, Robert Haas wrote: > On Fri, Aug 17, 2012 at 2:58 PM, Alvaro Herrera > wrote: >> I mean, what are NOT NULL in foreign tables for? Are they harmed or >> helped by having pg_constraint rows? > > As I've mentioned when this has come up before, I think that > constraints on foreign tables should be viewed as declarative > statements about the contents of the foreign data that the DB will > assume true. This could be useful for a variety of purposes: > constraint exclusion, query optimization, etc. > +1. I don't see us providing a mechanism to cross-check changes between data sources. Even if we do it for creation time, schema could be changed behind the scenes. Let's use at least constraints (NOT NULL, CHECK, UNIQUE, PK -- UNIQUE + NOT NULL) to improve optimizer but warn (loudly) that those constraints are merely for optimization. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PoC] load balancing in libpq
On 23-09-2012 07:50, Satoshi Nagayasu wrote: > I have just written the first PoC code to enable load balancing > in the libpq library. > Your POC is totally broken. Just to point out two problems: (i) semicolon (;) is a valid character for any option in the connection string and (ii) you didn't think about PQsetdb[Login](), PQconnectdbParams() and PQconnectStartParams(). If you want to pursue this idea, you should think a way to support same option multiple times (one idea is host1, host2, etc). Isn't it easier to add support on your application or polling software? -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] autovacuum stress-testing our system
On 26-09-2012 09:43, Tomas Vondra wrote: > I've been struggling with autovacuum generating a lot of I/O and CPU on some > of our > systems - after a night spent analyzing this behavior, I believe the current > autovacuum accidentally behaves a bit like a stress-test in some corner cases > (but > I may be seriously wrong, after all it was a long night). > It is known that statistic collector doesn't scale for a lot of databases. It wouldn't be a problem if we don't have automatic maintenance (aka autovacuum). > Next, I'm thinking about ways to solve this: > > 1) turning of autovacuum, doing regular VACUUM ANALYZE from cron - certainly > an >option, but it's rather a workaround than a solution and I'm not very fond > of >it. Moreover it fixes only one side of the problem - triggering the > statfile >writes over and over. The file will be written anyway, although not that >frequently. > It solves your problem if you combine scheduled VA with pgstat.stat in a tmpfs. I don't see it as a definitive solution if we want to scale auto maintenance for several hundreds or even thousands databases in a single cluster (Someone could think it is not that common but in hosting scenarios this is true. DBAs don't want to run several VMs or pg servers just to minimize the auto maintenance scalability problem). > 2) tweaking the timer values, especially increasing PGSTAT_RETRY_DELAY and so > on >to consider several seconds to be fresh enough - Would be nice to have this >as a GUC variables, although we can do another private patch on our own. > But >more knobs is not always better. > It doesn't solve the problem. Also it could be a problem for autovacuum (that make assumptions based in those fixed values). > 3) logic detecting the proper PGSTAT_RETRY_DELAY value - based mostly on the > time >it takes to write the file (e.g. 10x the write time or something). > Such adaptive logic would be good only iff it takes a small time fraction to execute. It have to pay attention to the limits. It appears to be a candidate for exploration. > 4) keeping some sort of "dirty flag" in stat entries - and then writing only > info >about objects were modified enough to be eligible for vacuum/analyze (e.g. >increasing number of index scans can't trigger autovacuum while inserting >rows can). Also, I'm not worried about getting a bit older num of index > scans, >so 'clean' records might be written less frequently than 'dirty' ones. > It minimizes your problem but harms collector tools (that want fresh statistics about databases). > 5) splitting the single stat file into multiple pieces - e.g. per database, >written separately, so that the autovacuum workers don't need to read all >the data even for databases that don't need to be vacuumed. This might be >combined with (4). > IMHO that's the definitive solution. It would be one file per database plus a global one. That way, the check would only read the global.stat and process those database that were modified. Also, an in-memory map could store that information to speed up the checks. The only downside I can see is that you will increase the number of opened file descriptors. > Ideas? Objections? Preferred options? > I prefer to attack 3, sort of 4 (explained in 5 -- in-memory map) and 5. Out of curiosity, did you run perf (or some other performance analyzer) to verify if some (stats and/or autovac) functions pop up in the report? -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] system_information.triggers & truncate triggers
On 26-09-2012 11:08, Simon Riggs wrote: > I suggest we implement that with some kind of switch/case in the view > definition. > -- parameter can be set in a session and defaults to on SET compliance_information_schema TO off; -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Switching timeline over streaming replication
On 27-09-2012 01:30, Amit Kapila wrote: > I understood this point, but currently in documentation of Timelines, this > usecase is not documented (Section 24.3.5). > Timeline documentation was written during PITR implementation. There wasn't SR yet. AFAICS it doesn't cite SR but is sufficiently generic (it use 'wal records' term to explain the feature). Feel free to reword those paragraphs mentioning SR. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hash id in pg_stat_statements
On 01-10-2012 11:22, Magnus Hagander wrote: > As long as we *tell* them under what conditions it might change, I > think it's perfectly fine. Particularly those who are likely to use > this functionality should certainly be capable of understanding that. > Even if we do that it is too much work for those statistics tools, isn't it? Instead of relying on internal structures hash, why don't you expose the query text hash to such tools? If you solve the space normalizations, it is an almost perfect solution for your use case. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hash id in pg_stat_statements
On 02-10-2012 10:15, Peter Geoghegan wrote: > There are other, similar tools that exist in proprietary databases. > They expose a hash value, which is subject to exactly the same caveats > as our own. They explicitly encourage the type of aggregation by > third-party tools that I anticipate will happen with > pg_stat_statements. I want to facilitate this, but I'm confident that > the use of (dbid, userid, querytext) as a "candidate key" by these > tools is going to cause confusion, in subtle ways. By using the hash > value, those tools are exactly as well off as pg_stat_statements is, > which is to say, as well off as possible. > It depends on how you will use this information. If it is for a rapid analysis, it is fine to use a hash because the object internals won't change (I hope not). However, if you want to analyze query statistics for a long period of time (say a few months) or your environment is distributed, you can't use the hash. There isn't a perfect solution but I see both cases being useful for analysis tools. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] install zic binary
Hi, Every year we have a ton of questions about updating the time zone data in Brazil (our politics decided to do it at 90min at the second half). Problem is that there is not sufficient time to release a new minor version with an updated time zone data. It is not a problem for *nix because zic binary is available (even without --with-system-tzdata option) but on Windows, you are hosed (you have no option but build source code). Should we have pg_zic? Sometimes we need to update time zone data but can't upgrade. Why? * you're stacked in an unsupported version; * your code is relying on a strange behavior that was changed in a minor version; * a new minor version was released hours ago but politics decided to change timezone in a hurry (before a new minor version). It happened in my state (Tocantins) last week -- up to 48 hours before starting DST, we don't know if we're in or out DST. That's because the governor decided (without consulting the population) to be in but when people said 'no', he stepped back and requested the president to be out; that was too late. [1] http://mm.icann.org/pipermail/tz/2012-October/018347.html -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] sql_implementation_info still contains old value
On 25-10-2012 15:36, Erik Rijkers wrote: > I would expect 9.2.1 to contain '09.02.0001' (not '09.02.'). > '09.02.' is the initdb'ed version. It seems you upgrade binaries from 9.2 to 9.2.1. euler=# select version(); version -- PostgreSQL 9.1.5 on x86_64-unknown-linux-gnu, compiled by gcc (Debian 4.7.1-7) 4.7.1, 64-bit (1 registro) euler=# select implementation_info_name,character_value from information_schema.sql_implementation_info where implementation_info_name = 'DBMS VERSION'; implementation_info_name | character_value --+- DBMS VERSION | 09.01.0002 (1 registro) It seems we should ignore the last digit or invent a way to update that tuple according to the new minor version. Another option is document that that version is the initdb'ed version. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
