Re: [HACKERS] Postgresql gives error that role goes not exists while it exists
2017-10-03 5:49 GMT-03:00 Nick Dro <postgre...@walla.co.il>: > 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] Logical Replication - test_decoding - unchanged-toast-datum
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 (pgsql-hackers@postgresql.org) To make cha
Re: [HACKERS] Logical Replication - test_decoding - unchanged-toast-datum
2017-09-26 1:11 GMT-03:00 Abhinav Singh <abhinav.theg...@gmail.com>: > 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] Built-in plugin for logical decoding output
2017-09-26 2:46 GMT-03:00 Alvaro Hernandez <a...@ongres.com>: > 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] Enhancements to passwordcheck
2017-09-25 15:04 GMT-03:00 Bossart, Nathan <bossa...@amazon.com>: > 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-23 14:01 GMT-03:00 Alvaro Hernandez <a...@ongres.com>: > 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] Built-in plugin for logical decoding output
2017-09-22 19:28 GMT-03:00 Gregory Brail <gregbr...@google.com>: > 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] user-based query white list
2017-07-03 3:11 GMT-03:00 Tim Burgan <timbur...@gmail.com>: > > 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] 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] [BUGS] BUG #14699: Statement trigger and logical replication
2017-06-16 22:08 GMT-03:00 Peter Eisentraut <peter.eisentraut@2ndquadrant. com>: > > 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] 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] Restrictions of logical replication
2017-06-16 4:00 GMT-03:00 Tatsuo Ishii <is...@sraoss.co.jp>: > 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] ALTER SUBSCRIPTION ..SET PUBLICATION refresh is not throwing error.
2017-05-26 21:29 GMT-03:00 Petr Jelinek <petr.jeli...@2ndquadrant.com>: > > 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] 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 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] ALTER SUBSCRIPTION ..SET PUBLICATION refresh is not throwing error.
2017-05-23 6:00 GMT-03:00 tushar <tushar.ah...@enterprisedb.com>: > > 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] PG 10 release notes
2017-05-04 22:26 GMT-03:00 Andres Freund <and...@anarazel.de>: > 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] 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] 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] Should pg_current_wal_location() become pg_current_wal_lsn()
2017-04-19 1:32 GMT-03:00 Michael Paquier <michael.paqu...@gmail.com>: > 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>
[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 <eu...@timbira.com.br>
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)
/*
* XXX: max_replication_slots
Re: [HACKERS] Different table schema in logical replication crashes
2017-04-14 22:36 GMT-03:00 Petr Jelinek <petr.jeli...@2ndquadrant.com>: > 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] 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] [PATCH] Warn users about duplicate configuration parameters
2017-04-07 12:14 GMT-03:00 Aleksander Alekseev <a.aleks...@postgrespro.ru>: > 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>
Re: [HACKERS] createlang/droplang deprecated
2017-03-18 12:29 GMT-03:00 Tom Lane <t...@sss.pgh.pa.us>: > > 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] Upgrading postmaster's log messages about bind/listen errors
2017-03-10 1:43 GMT-03:00 Tom Lane <t...@sss.pgh.pa.us>: > 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] Logical Replication and Character encoding
On 01-02-2017 00:05, Kyotaro HORIGUCHI wrote: > - Subscriber connects with client_encoding specification and the > output plugin pgoutput decide whether it accepts the encoding > or not. If the subscriber doesn't, pgoutput send data without > conversion. > I don't think storage without conversion is an acceptable approach. We should provide options to users such as ignore tuple or NULL for column(s) with conversion problem. I wouldn't consider storage data without conversion because it silently show incorrect data and we historically aren't flexible with conversion routines. -- 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 WIP
On 15-01-2017 15:13, Petr Jelinek wrote: > I am not quite sure I agree with this. Either it's system object and we > don't replicate it (which I would have considered to be anything with > Oid < FirstNormalObjectId) or it's user made and then it should be > replicated. Filtering by schema name is IMHO way too fragile (what stops > user creating additional tables there for example). > What happens if you replicate information_schema tables? AFAICS, those tables are already in the subscriber database. And will it generate error or warning? (I'm not sure how this functionality deals with schemas.) Also, why do I want to replicate a information schema table? Their contents are static and, by default, it is already in each database. Information schema isn't a catalog but I think it is good to exclude it from FOR ALL TABLES clause because the use case is almost zero. Of course, it should be documented. Also, if someone wants to replicate an information schema table, it could do it with ALTER PUBLICATION. -- 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] Rename pg_switch_xlog to pg_switch_wal
On 12-01-2017 10:56, David Steele wrote: >> So, to sum up things on this thread, here are the votes about the use >> of aliases or a pure breakage: >> - No to aliases, shake the world: Stephen, Tom, David F, Vik, Bruce M => 5 >> - Yes to aliases: Michael P, Andres, Peter E., Cynthia S, Jim N, >> Vladimir, Simon R, Fujii-san => 8 >> If I misunderstood things, please feel free to speak up. > > I'm also in the "no to aliases" camp. > +1. Even if we don't document aliases, one day some applications will break when someone decided to clean up this code. Let's do it smoothly. As Robert suggested in the other email: extension to create old names. -- 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] Retiring from the Core Team
On 11-01-2017 21:29, Josh Berkus wrote: > For that reason, as of today, I am stepping down from the PostgreSQL > Core Team. > Thanks for your hard work! Your contributions were very important and valuable for community growth. I'm sure you will continue to advocate PostgreSQL. -- 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 collation import to backend
On 18-12-2016 18:30, Peter Eisentraut wrote:
> Updated patch with that fix.
>
Peter, I reviewed and improved your patch.
* I document the new function. Since collation is a database object, I
chose "Database Object Management Functions" section.
* I've added a check to any-encoding database because I got 'FATAL:
collation "C" already exists' on Debian 8, although, I didn't get on
CentOS 7. The problem is that Debian has two locales for C (C and
C.UTF-8) and CentOS has just one (C).
* I've added OidIsValid to test the new collation row.
* I've changed the parameter order. Schema seems more important than
if_not_exists. Also, we generally leave those boolean parameters for the
end of list. I don't turn if_not_exists optional but IMO it would be a
good idea (default = true).
* You removed some #if and #ifdef while moving things around. I put it back.
* You didn't pgident some lines of code but I'm sure you didn't for a
small patch footprint.
* I didn't test on Windows.
* As a last comment, you set cost = 100 and it seems reasonable because
it lasts 411 ms to scan/load 923 collations in my slow VM. However,
successive executions takes ~1200 ms.
I'm attaching the complete and also a patch at the top of your last patch.
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 10e3186..1e52a48 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -19190,6 +19190,38 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
in the database's default tablespace, the tablespace can be specified as 0.
+
+ Operating system collations are loaded with the
+ pg_import_system_collations function, shown in .
+
+
+
+Collation Functions
+
+
+ Name Return Type Description
+
+
+
+
+
+pg_import_system_collations
+pg_import_system_collations(schema regnamespace, if_not_exists boolean)
+
+ void
+ Import operating system collations
+
+
+
+
+
+
+ pg_import_system_collations loads collations that it finds on
+ the operating system into system catalog pg_collation,
+ skipping those that are already present.
+
+
diff --git a/src/backend/catalog/pg_collation.c b/src/backend/catalog/pg_collation.c
index 63c2eb9..694c0f6 100644
--- a/src/backend/catalog/pg_collation.c
+++ b/src/backend/catalog/pg_collation.c
@@ -98,10 +98,21 @@ CollationCreate(const char *collname, Oid collnamespace,
PointerGetDatum(collname),
Int32GetDatum(-1),
ObjectIdGetDatum(collnamespace)))
- ereport(ERROR,
+ {
+ if (if_not_exists)
+ {
+ ereport(NOTICE,
+(errcode(ERRCODE_DUPLICATE_OBJECT),
+ errmsg("collation \"%s\" already exists, skipping",
+ collname)));
+ return InvalidOid;
+ }
+ else
+ ereport(ERROR,
(errcode(ERRCODE_DUPLICATE_OBJECT),
errmsg("collation \"%s\" already exists",
collname)));
+ }
/* open pg_collation */
rel = heap_open(CollationRelationId, RowExclusiveLock);
diff --git a/src/backend/commands/collationcmds.c b/src/backend/commands/collationcmds.c
index e108b50..cf3acea 100644
--- a/src/backend/commands/collationcmds.c
+++ b/src/backend/commands/collationcmds.c
@@ -139,7 +139,7 @@ DefineCollation(ParseState *pstate, List *names, List *parameters)
collctype,
false);
- if (!newoid)
+ if (!OidIsValid(newoid))
return InvalidObjectAddress;
ObjectAddressSet(address, CollationRelationId, newoid);
@@ -183,6 +183,7 @@ IsThereCollationInNamespace(const char *collname, Oid nspOid)
}
+#ifdef HAVE_LOCALE_T
/*
* "Normalize" a locale name, stripping off encoding tags such as
* ".utf8" (e.g., "en_US.utf8" -> "en_US", but "br_FR.iso885915@euro"
@@ -216,13 +217,15 @@ normalize_locale_name(char *new, const char *old)
return changed;
}
+#endif /* HAVE_LOCALE_T */
Datum
pg_import_system_collations(PG_FUNCTION_ARGS)
{
- bool if_not_exists = PG_GETARG_BOOL(0);
- Oid nspid = PG_GETARG_OID(1);
+#if defined(HAVE_LOCALE_T) && !defined(WIN32)
+ Oid nspid = PG_GETARG_OID(0);
+ bool if_not_exists = PG_GETARG_BOOL(1);
FILE *locale_a_handle;
char localebuf[NAMEDATALEN]; /* we assume ASCII so this is fine */
@@ -321,6 +324,7 @@ pg_import_system_collations(PG_FUNCTION_ARGS)
if (count == 0)
ereport(ERROR,
(errmsg("no usable system locales were found")));
+#endif /* not HAVE_LOCALE_T && not WIN32 */
PG_RETURN_VOID();
}
diff --git a/src/include/catalog/pg_proc.h b/src/include/catalog/pg_proc.h
index b0126a9..bb8637e 100644
--- a/src/include/catalog/pg_proc.h
+++ b/src/include/catalog/pg_proc.h
@@ -5345,7 +5345,7 @@ DESCR(&quo
Re: [HACKERS] ALTER SYSTEM for pg_hba.conf
On 04-01-2017 17:30, Tom Lane wrote: > Simon Riggs <si...@2ndquadrant.com> writes: >> My next thought is ALTER SYSTEM support for pg_hba.conf, especially >> since that would make it easier to do a formal test of Haribabu's >> pg_hba view patch by adding each of the options one by one and then >> juggling them. > > It's quite unclear from this spec what you have in mind to control the > entry order. Also, I'd personally be -1 on inventing a pile of new SQL > keywords for this. Why not do it with a function, instead? Or for extra > credit, finish the pg_hba view work first and then make it an updatable > view. > Even if you made the view updatable, you need a field to control the order. It has the line_number but an specific field would be desirable (someone could add a blank or comment line between querying the view and typing the update command). Also, in-place update a .conf file was something vetoed in the ALTER SYSTEM design and I think it was a clever idea. If we decided to mix automated and hand editing, a rewrite on every change is an easier path. Unlike ALTER SYSTEM, I'm afraid we can't invent a pg_hba.auto.conf because (i) order matters and (ii) it stops processing when a rule matches. In this case, we'll limit the feature usefulness. If we don't invent new fields in pg_hba.conf, a function could be a solution instead of a SQL syntax. However, a new field could break compatibility (unless we stick with a default value that could not be a good idea in the security pov). -- 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] s/xlog/wal/ in tools and function names?
On 01-12-2016 23:02, Michael Paquier wrote: >>> Should we also: >>> >>> - rename pg_switch_xlog and friends to pg_switch_wal? >>> - rename pg_recievexlog to pg_revievewal (and others in bin/)? >>> - rename pg_xlogdump to pg_waldump? >> >> I think yes to all. > +1. > I was hesitant to propose that, but if there is a will do move > everything... Documentation would point to different pages if the > utilities are renamed, so that's not helpful when comparing features > across major releases... We may want to keep those files with their > historical names. > It seems confusing if we rename the tool but not the documentation file name. Let's put a blinking message in the release notes saying 'tool X was renamed to tool Y'. The only thing we should do is add on each tool page something like: pg_waldump (formerly called pg_xlogdump) ... >>> - if we do rename, should we keep aliases for functions and symlinks for >>> tools? >> >> I think no. > +1. If the packager wants to do those aliases, it is up to him/her. > =# select proname from pg_proc where proname ~ 'xlog'; > proname > - > pg_current_xlog_location > pg_current_xlog_insert_location > pg_current_xlog_flush_location > pg_xlogfile_name_offset > pg_xlogfile_name > pg_xlog_location_diff > pg_last_xlog_receive_location > pg_last_xlog_replay_location > pg_is_xlog_replay_paused > pg_switch_xlog > pg_xlog_replay_pause > pg_xlog_replay_resume > (12 rows) > In those cases, let's keep the functions as wrappers and undocumented. In a few releases, we could remove them without breaking softwares that rely on them. -- 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] 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] 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] 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
[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 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
Re: [HACKERS] to_date_valid()
On 02-07-2016 22:04, Andreas 'ads' Scherbaum wrote: > The attached patch adds a new function "to_date_valid()" which will > validate the date and return an error if the input and output date do > not match. Tests included, documentation update as well. > Why don't you add a third parameter (say, validate = true | false) instead of creating another function? The new parameter could default to false to not break compatibility. -- 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 vs vacuum_cost_delay
On 16-06-2016 09:05, Magnus Hagander wrote: > Shouldn't pg_upgrade turn off vacuum cost delay when it vacuums the new > cluster? Not talking about the post-analyze script, but when it runs > vacuumdb to analyze and freeze before loading the new schema, in > prepare_new_cluster()? Those run during downtime, so it seems like you'd > want those to run as fast as possible. > Doesn't --new-options do the job? -- 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 safety tagging of extension functions
On 01-06-2016 20:52, Andreas Karlsson wrote: > I think at least three of the four aggregate functions are little used, > so I do not think many users would be affected. And only min(citext) and > max(citext) can make use of the parallel aggregation. > > The functions are: > > min(citext) > max(citext) > int_array_aggregate(int4) > rewrite(tsquery[]) > I don't think those functions are used a lot (as you said) to justify adding more code in 9.6. Let's not be in a hurry on something that can wait some months. -- 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] Add EXPLAIN (ALL) shorthand
On 20-05-2016 20:34, Robert Haas wrote: > Hmm, my experience is different. I use EXPLAIN (ANALYZE, VERBOSE) a > lot, but EXPLAIN (ANALYZE, BUFFERS) only rarely. I wonder if a GUC is > the way to go. > I wouldn't like a command output controlled by GUC. EXPLAIN is used a lot in bug/performance reports. I'm predicting users that will have trouble while using EXPLAIN if someone change the suggested GUC. It also breaks clients/applications that parse EXPLAIN. I don't want another bytea_output. However, if someone wants to suggest turning on/off some option defaults, I'm all ears. -- 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] Accurate list of Keywords / Datatypes?
On 10-05-2016 22:22, David G. Johnston wrote: > I don't know how the docs, this function, and the source code relate to > each other. > Function is built around ScanKeywords structure which in turn is built using parser/kwlist.h. -- 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] Does Type Have = Operator?
On 10-05-2016 22:28, David G. Johnston wrote: > Technically "is not distinct from" would be more correct. > Ooops. Fat fingered the statement. Also, forgot to consider null case. euler=# \pset null 'NULL' Null display is "NULL". euler=# select x.a, y.b, x.a IS NOT DISTINCT FROM y.b AS "INDF", x.a = y.b AS "=" FROM (VALUES (3), (6), (NULL)) AS x (a), (VALUES (3), (6), (NULL)) AS y (b); a | b | INDF | = --+--+--+-- 3 |3 | t| t 3 |6 | f| f 3 | NULL | f| NULL 6 |3 | f| f 6 |6 | t| t 6 | NULL | f| NULL NULL |3 | f| NULL NULL |6 | f| NULL NULL | NULL | t| NULL (9 rows) -- 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] alter table alter column ... (larger type) ... when there are dependent views
On 10-05-2016 20:59, Rob Bygrave wrote: > Having read all the previous discussions on the general topic of > altering tables with dependent views I realise this is a complex and > difficult issue in general but I'd like to see if there was some support > for looking at these 3 more specific changes. > 1. making a varchar column larger e.g. varchar(10) -> varchar(20) > 2. changing int to bigint > 3. changing varchar to text > It seems an useful feature request. I've already crossed that bridge while maintaining such a dynamic database schemas. I don't see why we couldn't implement this feature. I'll take a stab at it for the first commitfest. > I have seen that there are people motivated enough to update > pg_attribute directly (update pg_attribute a set a.atttypmod = 20 + 4 ...). > Yuk, this definitely bypass the ATExecAlterColumnType(). It is a hack and must be done with care. -- 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] Does Type Have = Operator?
On 10-05-2016 21:12, David E. Wheeler wrote: > This makes sense, of course, and I could fix it by comparing text > values instead of json values when the values are JSON. But of course > the lack of a = operator is not limited to JSON. So I’m wondering if > there’s an interface at the SQL level to tell me whether a type has > an = operator? That way I could always use text values in those > situations. > There isn't an equality notation at catalogs. You could try "SELECT oprname FROM pg_operator WHERE oprcode::text ~ 'eq'" but it is too fragile. You could also try oprname, oprrest or oprjoin but the result is worse than the former solution. You definitely need a hack. Also, IS DISTINCT FROM is an alias for = operator per standard IIRC. -- 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 German translation
On 09-05-2016 11:25, Christian Ullrich wrote: > here is a patch for the German translation that removes (all) five > instances of *the* most annoying mistake ever. > We generally don't work with patches for translations. Instead, we send all PO files. We have a separate repository [1] to deal with translations that is merged with upstream before each release. > By the way, is there any documentation anywhere about how and where to > send translation patches? I'm just guessing here. > Take a look at https://wiki.postgresql.org/wiki/NLS Subscribe to pgsql-translators [2] to send corrections / translations. [1] http://git.postgresql.org/gitweb/?p=pgtranslation/messages.git;a=summary [2] http://www.postgresql.org/list/pgsql-translators/ -- 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] Accurate list of Keywords / Datatypes?
On 07-05-2016 22:53, Robins Tharakan wrote: > Should I be looking somewhere else? Parse keywords from Git Source file > (if so where)? Parse PG Documentation? > src/include/parser/kwlist.h -- 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] minor message improvement
Hi,
While updating translations, I noticed that access/transam/xlog.c:6174
contains different messages that could be the same.
"ignoring file \"%s\" because no file \"%s\" exists"
a few lines above
"ignoring \"%s\" file because no \"%s\" file exists"
Attached is a patch that turn it into one.
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index f9644db..b473f19 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -6179,7 +6179,7 @@ StartupXLOG(void)
TABLESPACE_MAP, TABLESPACE_MAP_OLD)));
else
ereport(LOG,
- (errmsg("ignoring \"%s\" file because no \"%s\" file exists",
+ (errmsg("ignoring file \"%s\" because no file \"%s\" exists",
TABLESPACE_MAP, BACKUP_LABEL_FILE),
errdetail("Could not rename file \"%s\" to \"%s\": %m.",
TABLESPACE_MAP, TABLESPACE_MAP_OLD)));
--
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 to revert
On 03-05-2016 20:25, Craig Ringer wrote: > On 4 May 2016 at 01:12, Peter Geoghegan <p...@heroku.com > <mailto:p...@heroku.com>> wrote: > > On Tue, May 3, 2016 at 9:58 AM, Alvaro Herrera > <alvhe...@2ndquadrant.com <mailto:alvhe...@2ndquadrant.com>> wrote: > > As its committer, I tend to agree about reverting that feature. Craig > > was just posting some more patches, and I have the pg_recvlogical > > changes here (--endpos) which after some testing are not quite looking > > ready to go -- plus we still have to write the actual Perl test scripts > > that would use it. Taken together, this is now looking to me a bit > > rushed, so I prefer to cut my losses here and revert the patch so that > > we can revisit it for 9.7. > > I think it's a positive development that we can take this attitude to > reverting patches. It should not be seen as a big personal failure, > because it isn't. Stigmatizing reverts incentivizes behavior that > leads to bad outcomes. > > > Indeed. Being scared to revert also makes the barrier to committing > something and getting it into more hands, for longer, under a variety of > different conditions higher. Not a ton of help with this particular > feature but quite important with others. > > While I'm personally disappointed by this outcome, I also can't really > disagree with it. The whole area is a bit of a mess and hard to work on, > and as demonstrated my understanding of it when I wrote the original > patch was incomplete. We could commit the rewritten function, but ... > rewriting a feature just before beta1 probably says it's just not baked > yet, right? > You said that in another thread... > The upside of all this is that now I have a decent picture of how it > should all look and how timeline following, failover capability etc can > be introduced in a staged way. I'd also like to get rid of the use of > various globals to pass timeline information "around" the walsender and > share more of the logic between the code paths. > Question is: is the actual code so useless that it can't even be a 1.0 release? A lot of (complex) features were introduced with the notion that will be improved in the next version. However, if the code is buggy or there are serious API problems, revert them. -- 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 <and...@anarazel.de > <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] [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] [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] 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] 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 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] 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] 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] 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] 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] 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 <vi...@wagner.pp.ru > <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] 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] 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] 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 <pete...@gmx.net> 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 <michael.paqu...@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] 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] 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 <eu...@timbira.com.br> 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
[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 <eu...@timbira.com.br>
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 <eu...@timbira.com.br>
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 <eu...@timbira.com.br>
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
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
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] 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] 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] 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 <eu...@timbira.com.br>
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
Re: [HACKERS] vacuumdb sentence
On 18-09-2015 00:59, Amit Kapila wrote:
On Fri, Sep 18, 2015 at 8:30 AM, Euler Taveira <eu...@timbira.com.br
<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
[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
[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 <eu...@timbira.com.br>
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 <eu...@timbira.com.br> 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
[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 <eu...@timbira.com.br>
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
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
[HACKERS] small typo
Hi, Attached is a small typo. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento diff --git a/contrib/pg_buffercache/pg_buffercache_pages.c b/contrib/pg_buffercache/pg_buffercache_pages.c index 98016fc..761c277 100644 --- a/contrib/pg_buffercache/pg_buffercache_pages.c +++ b/contrib/pg_buffercache/pg_buffercache_pages.c @@ -142,7 +142,7 @@ pg_buffercache_pages(PG_FUNCTION_ARGS) LWLockAcquire(BufMappingPartitionLockByIndex(i), LW_SHARED); /* - * Scan though all the buffers, saving the relevant fields in the + * Scan through all the buffers, saving the relevant fields in the * fctx-record structure. */ for (i = 0; i NBuffers; i++) -- 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
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] 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 and...@2ndquadrant.com 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 eu...@timbira.com
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 eu...@timbira.com
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 eu...@timbira.com
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
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
[HACKERS] nls and server log
Hi, Currently the same message goes to server log and client app. Sometimes it bothers me since I have to analyze server logs and discovered that lc_messages is set to pt_BR and to worse things that stup^H^H^H application parse some error messages in portuguese. My solution has been a modified version of pgBadger (former was pgfouine) -- that has its problems: (i) translations are not as stable as english messages, (ii) translations are not always available and it means there is a mix of translated and untranslated messages and (iii) it is minor version dependent. I'm tired to fight against those problems and started to research if there is a good solution for backend. I'm thinking to carry both translated and untranslated messages if we ask to. We store the untranslated messages if the new GUC (say server_lc_messages) is set. The cost will be copy to new five variables (message, detail, detail_log, hint, and context) in ErrorData struct that will be used iif server_lc_messages is set. A possible optimization is not to use the new variables if the lc_messages and server_lc_messages does not match. My use case is a server log in english but I'm perfect fine allowing server log in spanish and client messages in french. Is it an acceptable plan? Ideas? -- 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 description
Hi,
The pg_recvlogical docs was rewritten but someone forgot to tweak the
help description. It is a bit late in the 9.4 cycle but let be consistent.
Regards,
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
From 4c6c146e100575fbf02c6160bd919fbd92505708 Mon Sep 17 00:00:00 2001
From: Euler Taveira eu...@timbira.com
Date: Mon, 8 Dec 2014 11:25:29 -0300
Subject: [PATCH] Let be consistent with the docs. The new sentence describes
better ('control' instead of 'receive') what pg_recvlogical is for.
---
src/bin/pg_basebackup/pg_recvlogical.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/bin/pg_basebackup/pg_recvlogical.c b/src/bin/pg_basebackup/pg_recvlogical.c
index 0d97638..9966cd7 100644
--- a/src/bin/pg_basebackup/pg_recvlogical.c
+++ b/src/bin/pg_basebackup/pg_recvlogical.c
@@ -62,7 +62,7 @@ static void disconnect_and_exit(int code);
static void
usage(void)
{
- printf(_(%s receives PostgreSQL logical change streams.\n\n),
+ printf(_(%s controls PostgreSQL logical decoding streams.\n\n),
progname);
printf(_(Usage:\n));
printf(_( %s [OPTION]...\n), progname);
--
2.1.3
--
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] 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] Changeset Extraction v7.6.1
On 01-06-2014 02:57, Andres Freund wrote: On 2014-06-01 00:50:58 -0500, Jim Nasby wrote: On 5/31/14, 9:11 AM, Andres Freund wrote: On 2014-02-21 15:14:15 -0600, Jim Nasby wrote: On 2/17/14, 7:31 PM, Robert Haas wrote: But do you really want to keep that snapshot around long enough to copy the entire database? I bet you don't: if the database is big, holding back xmin for long enough to copy the whole thing isn't likely to be fun. I can confirm that this would be epic fail, at least for londiste. It takes about 3 weeks for a new copy of a ~2TB database. There's no way that'd work with one snapshot. (Granted, copy performance in londiste is rather lackluster, but still...) I'd marked this email as todo: If you have such a huge database you can, with logical decoding at least, use a basebackup using pg_basebackup or pg_start/stop_backup() and roll forwards from that... That'll hopefull make such huge copies much faster. Just keep in mind that one of the use cases for logical replication is upgrades. Should still be fine. Make a physical copy; pg_upgrade; catchup via logical rep. Have in mind that it is not an option if you want to copy *part* of the database(s) (unless you have space available and want to do the cleanup after upgrade). In a near future, a (new) tool could do (a) copy schema, (b) accumulate modifications while copying data, (c) copy whole table and (d) apply modifications for selected table(s)/schema(s). Such a tool could even be an alternative to pg_upgrade. -- 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] cosmetic fixes
Hi,
Here are some more trivial fixes in pg_recvlogical message style.
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
From 0bbf437b490a92afa4b14e4903188bcf795f8e47 Mon Sep 17 00:00:00 2001
From: Euler Taveira eu...@timbira.com
Date: Sun, 18 May 2014 20:26:00 -0300
Subject: [PATCH] Style fixes.
Lowercase help statements. Also, use an existing statement to reduce the
number of strings to be translated.
---
src/bin/pg_basebackup/pg_recvlogical.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/bin/pg_basebackup/pg_recvlogical.c b/src/bin/pg_basebackup/pg_recvlogical.c
index a585303..651cc40 100644
--- a/src/bin/pg_basebackup/pg_recvlogical.c
+++ b/src/bin/pg_basebackup/pg_recvlogical.c
@@ -83,13 +83,13 @@ usage(void)
printf(_( -F --fsync-interval=SECS\n
frequency of syncs to the output file (default: %d)\n), (fsync_interval / 1000));
printf(_( -o, --option=NAME[=VALUE]\n
- Specify option NAME with optional value VALUE, to be passed\n
+ specify option NAME with optional value VALUE, to be passed\n
to the output plugin\n));
printf(_( -P, --plugin=PLUGINuse output plugin PLUGIN (default: %s)\n), plugin);
printf(_( -s, --status-interval=SECS\n
time between status packets sent to server (default: %d)\n), (standby_message_timeout / 1000));
printf(_( -S, --slot=SLOTuse existing replication slot SLOT instead of starting a new one\n));
- printf(_( -I, --startpos=PTR Where in an existing slot should the streaming start\n));
+ printf(_( -I, --startpos=PTR where in an existing slot should the streaming start\n));
printf(_(\nAction to be performed:\n));
printf(_( --create create a new replication slot (for the slotname see --slot)\n));
printf(_( --startstart streaming in a replication slot (for the slotname see --slot)\n));
@@ -935,7 +935,7 @@ main(int argc, char **argv)
if (sscanf(PQgetvalue(res, 0, 1), %X/%X, hi, lo) != 2)
{
fprintf(stderr,
- _(%s: could not parse log location \%s\\n),
+ _(%s: could not parse transaction log location \%s\\n),
progname, PQgetvalue(res, 0, 1));
disconnect_and_exit(1);
}
--
2.0.0.rc0
--
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 tests
On 15-05-2014 18:09, Andres Freund wrote: I have some preliminary tests for the pg_recvlogical binary using the infrastructure Peter added. I am wondering if somebody has a good idea about how to make the tests more meaningful. Currently all that's tested are simple commands. Not the main functionality namely the actual streaming of changes. Could you post your preliminary patch? I wonder if somebody has a great idea for cancelling pg_recvlogical after a while. Right now my best idea is to add a new --stop-after-messages parameter. Does anybody have a better idea? pgbench uses two stop conditions: (i) number of transactions and (ii) time. These could be applied to pg_recvlogical too. --transactions=NUM --time=NUM If that's the way, would somebody object to tests and the parameter being added now? The potential harm seems pretty low and the additional tests would cover the walsender interface that's not covered by any tests right now... beta is not the right time to add even a *minor* functionality. Let's do it for 9.5. -- 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] Various cosmetic fixes
Hi,
While updating pt-br translation I noticed that some sentences could be
improved. I also fix some style glitches. A set of patches are attached.
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
From 87a499cd8fe6a1d0c491b3263c3daf66856cf6f1 Mon Sep 17 00:00:00 2001
From: Euler Taveira eu...@timbira.com
Date: Wed, 14 May 2014 14:17:00 -0300
Subject: [PATCH 01/11] Fix style.
Use the same messages from pg_receivexlog because they were copied from
it.
---
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 194d10f..52dc839 100644
--- a/src/bin/pg_basebackup/pg_recvlogical.c
+++ b/src/bin/pg_basebackup/pg_recvlogical.c
@@ -965,14 +965,14 @@ main(int argc, char **argv)
}
else if (noloop)
{
- fprintf(stderr, _(%s: disconnected.\n), progname);
+ fprintf(stderr, _(%s: disconnected\n), progname);
exit(1);
}
else
{
fprintf(stderr,
/* translator: check source for value for %d */
- _(%s: disconnected. Waiting %d seconds to try again.\n),
+ _(%s: disconnected; waiting %d seconds to try again\n),
progname, RECONNECT_SLEEP_TIME);
pg_usleep(RECONNECT_SLEEP_TIME * 100);
}
--
2.0.0.rc0
From 864aabd419ce3f4ae5afcf751ebeb22eb9f0e257 Mon Sep 17 00:00:00 2001
From: Euler Taveira eu...@timbira.com
Date: Wed, 14 May 2014 14:18:53 -0300
Subject: [PATCH 02/11] Don't hardwire default values.
Avoid hardwiring default values in help. Also, provide the unit
(seconds) in the parameter value (following style elsewhere).
---
src/bin/pg_basebackup/pg_recvlogical.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/bin/pg_basebackup/pg_recvlogical.c b/src/bin/pg_basebackup/pg_recvlogical.c
index 52dc839..e7d2e97 100644
--- a/src/bin/pg_basebackup/pg_recvlogical.c
+++ b/src/bin/pg_basebackup/pg_recvlogical.c
@@ -80,14 +80,14 @@ usage(void)
printf(_( -w, --no-password never prompt for password\n));
printf(_( -W, --password force password prompt (should happen automatically)\n));
printf(_(\nReplication options:\n));
- printf(_( -F --fsync-interval=INTERVAL\n
- frequency of syncs to the output file (in seconds, defaults to 10)\n));
+ printf(_( -F --fsync-interval=SECS\n
+ frequency of syncs to the output file (default: %d)\n), (fsync_interval / 1000));
printf(_( -o, --option=NAME[=VALUE]\n
Specify option NAME with optional value VALUE, to be passed\n
to the output plugin\n));
- printf(_( -P, --plugin=PLUGINuse output plugin PLUGIN (defaults to test_decoding)\n));
- printf(_( -s, --status-interval=INTERVAL\n
- time between status packets sent to server (in seconds, defaults to 10)\n));
+ printf(_( -P, --plugin=PLUGINuse output plugin PLUGIN (default: %s)\n), plugin);
+ printf(_( -s, --status-interval=SECS\n
+ time between status packets sent to server (default: %d)\n), (standby_message_timeout / 1000));
printf(_( -S, --slot=SLOTuse existing replication slot SLOT instead of starting a new one\n));
printf(_( -I, --startpos=PTR Where in an existing slot should the streaming start\n));
printf(_(\nAction to be performed:\n));
--
2.0.0.rc0
From fc089e4946e2c8780eae34ac08d9b6839470e8b4 Mon Sep 17 00:00:00 2001
From: Euler Taveira eu...@timbira.com
Date: Wed, 14 May 2014 14:20:44 -0300
Subject: [PATCH 03/11] Fix typo.
s/pg_receivexlog/pg_recvlogical/
---
doc/src/sgml/ref/pg_recvlogical.sgml | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/doc/src/sgml/ref/pg_recvlogical.sgml b/doc/src/sgml/ref/pg_recvlogical.sgml
index 4170c8e..edc52c0 100644
--- a/doc/src/sgml/ref/pg_recvlogical.sgml
+++ b/doc/src/sgml/ref/pg_recvlogical.sgml
@@ -226,13 +226,12 @@ PostgreSQL documentation
termoption--fsync-interval=replaceableinterval_seconds/replaceable/option/term
listitem
para
-How often should
-link linkend=app-pgreceivexlogapplicationpg_receivexlog/application/link
-issue sync commands to ensure the parameter--outputfile/parameter
-is safely flushed to disk without being asked by the server to do
-so. Specifying an interval of literal0/literal disables issuing
-fsyncs altogether, while still reporting progress the server.
-In this case, data may be lost in the event of a crash.
+How often should applicationpg_recvlogical/application issue sync
+commands to ensure the parameter--outputfile/parameter is safely
+flushed to disk without being asked by the server to do so. Specifying
+an interval of literal0/literal disables issuing fsyncs altogether
Re: [HACKERS] pg_shmem_allocations view
On 04-05-2014 08:44, Andres Freund wrote: I've more than once wanted to know what allocated shared memory in postgres installation is used for. Especially with more an more extensions around that's quite useful. A few years ago I had to provide such information an did something similar. Is it useful? Yes. However, it is a developer's feature. On 2014-05-04 13:44:17 +0200, Andres Freund wrote: Thinking about this, I think it was a mistake to not add a 'name' field to dynamic shared memory's dsm_control_item. Right now it's very hard to figure out which extension allocated a dsm segment. Imo we should change that before 9.4 is out. I am not suggesting to use it to identify segments, but just as an identifier, passed in into dsm_create(). +1. Imo there should be a corresponding pg_dynshmem_allocations to pg_shmem_allocations. ... or another boolean column (say 'dynamic') and just one view. -- 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] psql \d+ and oid display
On 27-03-2014 10:15, Bruce Momjian wrote: When we made OIDs optional, we added an oid status display to \d+: test= \d+ test Table public.test Column | Type | Modifiers | Storage | Stats target | Description +-+---+-+--+- x | integer | | plain | | -- Has OIDs: no Do we want to continue displaying that OID line, or make it optional for cases where the value doesn't match default_with_oids? That line is still important for those tables that have oids. Once a while I see with oids set (mainly by mistake or misinformation). The 8.0 (last version that have default_with_oids = on) is dead for more than 3 years. Is it time to remove the d_w_o or even announce to remove it in 2 releases? Regarding to remove the Has OIDs line, it seems that it is just noise since almost all tables does not have oids. However, if you remove that line you'll have to fix the regression tests and also can break third part extensions that use \d+ (we can live with that). If we agree to remove d_w_o, don't worry with that line because it will be removed soon. -- 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] Is this a bug?
On 13-03-2014 00:11, Fabrízio de Royes Mello wrote: Shouldn't the ALTER statements below raise an exception? For consistency, yes. Who cares? I mean, there is no harm in resetting an unrecognized parameter. Have in mind that tighten it up could break scripts. In general, I'm in favor of validating things. euler@euler=# reset noname; ERROR: 42704: unrecognized configuration parameter noname LOCAL: set_config_option, guc.c:5220 -- 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
