Re: PG 13 release notes, first draft
On Mon, May 04, 2020 at 11:16:00PM -0400, Bruce Momjian wrote: > Allow skipping of WAL for new tables and indexes if wal_level is 'minimal' > (Noah Misch) Kyotaro Horiguchi authored that one. (I committed it.) The commit message noted characteristics, some of which may deserve mention in the notes: - Crash recovery was losing tuples written via COPY TO. This fixes the bug. - Out-of-tree table access methods will require changes. - Users setting a timeout on COMMIT may need to adjust that timeout, and log_min_duration_statement analysis will reflect time consumption moving to COMMIT from commands like COPY. - COPY has worked this way for awhile; this extends it to all modifications.
Re: PG 13 release notes, first draft
> 5 мая 2020 г., в 08:16, Bruce Momjian написал(а): > > I have committed the first draft of the PG 13 release notes. You can > see them here: > > https://momjian.us/pgsql_docs/release-13.html > > It still needs markup, word wrap, and indenting. The community doc > build should happen in a few hours. I'm not sure, but probably it worth mentioning in "General performance" section that TOAST (and everything pglz-compressed) decompression should be significantly faster in v13. https://github.com/postgres/postgres/commit/c60e520f6e0e8db9618cad042df071a6752f3c06 Best regards, Andrey Borodin.
Re: Own index methods
Hi! > 5 мая 2020 г., в 17:21, Benjamin Schaller > написал(а): > > Even though it's described as fairly complicated: If I would want to define > my own index method, what would be a good approach to do so? I'm working on presentation describing how to fork AM out of core to extension. Hope to be available soon. I'll send you a link when it's available. This small code copy-pasting helps to narrow focus (postgres codebase is big), makes experiments with new not yet committed features easier and allows to "specialise" generic indexes more precisely. Best regards, Andrey Borodin.
Re: Another modest proposal for docs formatting: catalog descriptions
Hello Tom, oid OID Meh. I'm not a fan of overuse of upper case --- it's well established that that's harder to read than lower or mixed case. And it's definitely project policy that type names are generally treated as identifiers not keywords, even if some of them happen to be keywords under the hood. I found "oid oid" stuttering kind of strange, hence an attempt at suggesting something that could distinguish them. The markup I had in mind was for the field name and for the type name, but no decoration beyond that. Ok. If they are displayed a little differently afterwards that'd may help. As for the references, it seems to me that your notation would lead people to think that there are actual FK constraints in place, which of course there are not (especially not on the views). In practice the system ensures that the target exists, so it is as-if there would be a foreign key enforced? My point is that using differing syntaxes for the more-or-less the same concept does not help user understand the semantics, but maybe that is just me. I'm not hugely against it but I prefer what I suggested. Ok! -- Fabien.
Re: PG 13 release notes, first draft
Hello Bruce, * "DOCUMENT THE DEFAULT GENERATION METHOD" => The default is still to generate data client-side. My point is that the docs are not clear about this. Indeed. Can you fix it? Sure. Attached patch adds an explicit sentence about it, as it was only hinted about in the default initialization command string, and removes a spurious empty paragraph found nearby. -- Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml index c9a9f0e0e5..ef75e5328c 100644 --- a/doc/src/sgml/ref/pgbench.sgml +++ b/doc/src/sgml/ref/pgbench.sgml @@ -198,6 +198,8 @@ pgbench options d Generate data and load it into the standard tables, replacing any data already present. +Default is to generate data client-side (g) +and transmit it over the connection. With g (client-side data generation), @@ -218,9 +220,6 @@ pgbench options d message when generating data into pgbench_accounts table. - - -
Re: PG compilation error with Visual Studio 2015/2017/2019
On Wed, May 6, 2020 at 4:19 AM Juan José Santamaría Flecha wrote: > > On Tue, May 5, 2020 at 1:34 PM Amit Kapila wrote: >> >> >> Apart from that, I have made a few other changes in comments, fixed >> typos, and ran pgindent. Let me know what do you think of attached >> patches? > > > The patches are definitely in better shape. > > I think that the definition of get_iso_localename() should be consistent > across all versions, that is HEAD like back-patched. > Fair enough. I have changed such that get_iso_localename is the same in HEAD as it is backbranch patches. I have attached backbranch patches for the ease of verification. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com From ef8eff4ea52305e095dff0f461f1ed16e109eb2b Mon Sep 17 00:00:00 2001 From: Amit Kapila Date: Tue, 5 May 2020 15:26:12 +0530 Subject: [PATCH v17] Fix the MSVC build for versions 2015 and later. Visual Studio 2015 and later versions should still be able to do the same as Visual Studio 2012, but the declaration of locale_name is missing in _locale_t, causing the code compilation to fail, hence this falls back instead on to enumerating all system locales by using EnumSystemLocalesEx to find the required locale name. If the input argument is in Unix-style then we can get ISO Locale name directly by using GetLocaleInfoEx() with LCType as LOCALE_SNAME. In passing, change the documentation references to the now obsolete links. Note that this problem occurs only with NLS enabled builds. Author: Juan José Santamaría Flecha, Davinder Singh and Amit Kapila Reviewed-by: Ranier Vilela and Amit Kapila Backpatch-through: 9.5 Discussion: CAHzhFSFoJEWezR96um4-rg5W6m2Rj9Ud2CNZvV4NWc9tXV7aXQ@mail.gmail.com">https://postgr.es/m/CAHzhFSFoJEWezR96um4-rg5W6m2Rj9Ud2CNZvV4NWc9tXV7aXQ@mail.gmail.com --- src/backend/utils/adt/pg_locale.c | 236 -- 1 file changed, 203 insertions(+), 33 deletions(-) diff --git a/src/backend/utils/adt/pg_locale.c b/src/backend/utils/adt/pg_locale.c index 2562eb5..11d05c7 100644 --- a/src/backend/utils/adt/pg_locale.c +++ b/src/backend/utils/adt/pg_locale.c @@ -234,6 +234,7 @@ pg_perm_setlocale(int category, const char *locale) result = IsoLocaleName(locale); if (result == NULL) result = (char *) locale; + elog(DEBUG3, "IsoLocaleName() executed; locale: \"%s\"", result); #endif /* WIN32 */ break; #endif /* LC_MESSAGES */ @@ -971,65 +972,234 @@ cache_locale_time(void) * string. Furthermore, msvcr110.dll changed the undocumented _locale_t * content to carry locale names instead of locale identifiers. * - * MinGW headers declare _create_locale(), but msvcrt.dll lacks that symbol. - * IsoLocaleName() always fails in a MinGW-built postgres.exe, so only - * Unix-style values of the lc_messages GUC can elicit localized messages. In - * particular, every lc_messages setting that initdb can select automatically - * will yield only C-locale messages. XXX This could be fixed by running the - * fully-qualified locale name through a lookup table. + * Visual Studio 2015 should still be able to do the same as Visual Studio + * 2012, but the declaration of locale_name is missing in _locale_t, causing + * this code compilation to fail, hence this falls back instead on to + * enumerating all system locales by using EnumSystemLocalesEx to find the + * required locale name. If the input argument is in Unix-style then we can + * get ISO Locale name directly by using GetLocaleInfoEx() with LCType as + * LOCALE_SNAME. + * + * MinGW headers declare _create_locale(), but msvcrt.dll lacks that symbol in + * releases before Windows 8. IsoLocaleName() always fails in a MinGW-built + * postgres.exe, so only Unix-style values of the lc_messages GUC can elicit + * localized messages. In particular, every lc_messages setting that initdb + * can select automatically will yield only C-locale messages. XXX This could + * be fixed by running the fully-qualified locale name through a lookup table. * * This function returns a pointer to a static buffer bearing the converted * name or NULL if conversion fails. * - * [1] http://msdn.microsoft.com/en-us/library/windows/desktop/dd373763.aspx - * [2] http://msdn.microsoft.com/en-us/library/windows/desktop/dd373814.aspx + * [1] https://docs.microsoft.com/en-us/windows/win32/intl/locale-identifiers + * [2] https://docs.microsoft.com/en-us/windows/win32/intl/locale-names + */ + +#if _MSC_VER >= 1900 +/* + * Callback function for EnumSystemLocalesEx() in get_iso_localename(). + * + * This function enumerates all system locales, searching for one that matches + * an input with the format: [_], e.g. + * English[_United States] + * + * The input is a three wchar_t array as an LPARAM. The first element is the + * locale_name we want to match, the second element is an allocated buffer + * where the Unix-style locale is copied if a match is found, and the third + * element is the search status, 1 if a match wa
Re: Optimization for hot standby XLOG_STANDBY_LOCK redo
And one more question, what LogAccessExclusiveLocks in LogStandbySnapshot is used for? Can We remove this. > 2020年5月6日 上午10:36，邱宇航 写道： > > I mean that all resources protected by XLOG_STANDBY_LOCK should redo later. > The semantics of XLOG_STANDBY_LOCK is still kept. >
Re: Optimization for hot standby XLOG_STANDBY_LOCK redo
I mean that all resources protected by XLOG_STANDBY_LOCK should redo later. The semantics of XLOG_STANDBY_LOCK is still kept. > 2020年4月30日 下午7:12，Amit Kapila 写道： > > On Thu, Apr 30, 2020 at 4:07 PM 邱宇航 wrote: >> >> I noticed that in hot standby, XLOG_STANDBY_LOCK redo is sometimes block by >> another query, and all the rest redo is blocked by this lock getting >> operation, which is not good and often happed in my database, so the hot >> standby will be left behind and master will store a lot of WAL which can’t >> be purged. >> >> So here is the idea: >> We can do XLOG_STANDBY_LOCK redo asynchronously, and the rest redo will >> continue. >> > > Hmm, I don't think we can do this. The XLOG_STANDBY_LOCK WAL is used > for AccessExclusiveLock on a Relation which means it is a lock for a > DDL operation. If you skip processing the WAL for this lock, the > behavior of queries running on standby will be unpredictable. > Consider a case where on the master, the user has dropped the table > and when it will replay such an operation on standby the > concurrent queries on t1 will be blocked due to replay of > XLOG_STANDBY_LOCK WAL and if you skip that WAL, the drop of table and > query on the same table can happen simultaneously leading to > unpredictable behavior. > > -- > With Regards, > Amit Kapila. > EnterpriseDB: http://www.enterprisedb.com
Re: Another modest proposal for docs formatting: catalog descriptions
On 5/5/20 7:42 PM, Tom Lane wrote: > Here's a really quick-n-dirty prototype patch that just converts the > pg_aggregate table to the proposed style, plus a screenshot for those > who don't feel like actually building the docs with the patch. Not opposed to building the docs, but the screenshot expedites things ;) > Looking at the results, it seems like we could really use a bit more > horizontal space between the column names and data types, and perhaps > also between the types and the (references) annotations. Other than > that it looks decent. I don't know what's the cleanest way to add > some space there --- I'd rather not have the SGML text do it explicitly. If each element (i.e. column name, data type) is wrapped in a HTML element with its own class (e.g. a span) it's fairly easy to add that space with CSS. I'm not sure the ramifications for the PDFs though. > There's room for complaint that this takes up more vertical space than > the old way, assuming you have a reasonably wide window. I'm not > terribly bothered by that, but maybe someone else will be? I'm inclined > to think that that's well worth the benefit that we won't feel compelled > to keep column descriptions short. I think for reference materials, vertical space is acceptable. It seems to be the "mobile way" of doing things, since people are scrolling down. (And unlike the mailing lists, we don't need to keep the font small ;) Anyway, +1 > BTW, this being just a test hack, I repurposed the "func_table_entry" and > "func_signature" style marker roles. If we do this for real then of > course we'd want to use different roles, even if they happen to mark up > the same for now. Agreed. Thanks, Jonathan signature.asc Description: OpenPGP digital signature
Re: Unify drop-by-OID functions
Only as a homework, is this function completely useless?
ItemPointerData
systable_scan_next(Relation heapRelation,
Oid indexId,
bool indexOK,
Snapshot snapshot,
int nkeys, ScanKey key)
{
SysScanDesc scan;
HeapTuple htup;
ItemPointerData tid;
scan = systable_beginscan(heapRelation, indexId, indexOK, snapshot,
nkeys, key);
htup = systable_getnext(scan);
if (HeapTupleIsValid(htup))
tid = &htup->t_self;
else
tid = NULL;
systable_endscan(scan);
return tid;
}
regards,
Ranier Vilela
Re: PG compilation error with Visual Studio 2015/2017/2019
On Tue, May 5, 2020 at 1:34 PM Amit Kapila wrote: > > Apart from that, I have made a few other changes in comments, fixed > typos, and ran pgindent. Let me know what do you think of attached > patches? > The patches are definitely in better shape. I think that the definition of get_iso_localename() should be consistent across all versions, that is HEAD like back-patched. Regards, Juan José Santamaría Flecha
Re: xid wraparound danger due to INDEX_CLEANUP false
On Wed, 6 May 2020 at 07:14, Peter Geoghegan wrote: > > On Tue, May 5, 2020 at 2:52 PM Masahiko Sawada > wrote: > > So IIUC the problem is that since we skip both, > > oldst_btpo_xact could be seen as a "future" xid during vacuum. Which > > will be a cause of that vacuum misses pages which can actually be > > recycled. > > This is also my understanding of the problem. > > > I think we can fix this issue by calling vacuumcleanup callback when > > an anti-wraparound vacuum even if INDEX_CLEANUP is false. That way we can > > let index AM make decisions whether doing cleanup index at least once > > until XID wraparound, same as before. > > +1 > > Can you work on a patch? Yes, I'll submit a bug fix patch. Regards, -- Masahiko Sawadahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Postgres Windows build system doesn't work with python installed in Program Files
On Tue, May 5, 2020 at 4:06 PM Michael Paquier wrote: > On Mon, May 04, 2020 at 03:42:20PM +0200, Juan José Santamaría Flecha > wrote: > > +1, seems like the way to go to me. > > Attached is a patch for that and I have gone with a simple solution, > with some bonus comments about the way things happen. > This solves the issue. Please forgive me if I am being too nitpicky, but I find the comments a little too verbose, a usage format might be more visual and easier to explain: Usage: build [[CONFIGURATION] COMPONENT] The options are case-insensitive. CONFIGURATION sets the configuration to build, "debug" or "release" (by default). COMPONENT defines a component to build. An empty option means all components. Regards, Juan José Santamaría Flecha
Re: xid wraparound danger due to INDEX_CLEANUP false
On Tue, May 5, 2020 at 2:52 PM Masahiko Sawada wrote: > So IIUC the problem is that since we skip both, > oldst_btpo_xact could be seen as a "future" xid during vacuum. Which > will be a cause of that vacuum misses pages which can actually be > recycled. This is also my understanding of the problem. > I think we can fix this issue by calling vacuumcleanup callback when > an anti-wraparound vacuum even if INDEX_CLEANUP is false. That way we can > let index AM make decisions whether doing cleanup index at least once > until XID wraparound, same as before. +1 Can you work on a patch? -- Peter Geoghegan
Re: Unify drop-by-OID functions
Em ter., 5 de mai. de 2020 às 18:11, Alvaro Herrera <
alvhe...@2ndquadrant.com> escreveu:
> On 2020-May-05, Ranier Vilela wrote:
>
> > And in that specific case, leaving resources blocked, which perhaps, in
> my
> > humble opinion, could be released quickly.
>
> I very much doubt that you can measure any difference at all between
> these two codings of the function.
>
> I agree with the principle you mention, of not holding resources for
> long if they can be released earlier; but in this case the table_close
> call occurs across a ReleaseSysCache() call, which is hardly of
> significance. It's not like you have to wait for some other
> transaction, or wait for I/O, or anything like that that would make it
> measurable.
>
Locally it may not be as efficient, but it is a question, to follow the
good programming practices, among them, not to break anything, not to
block, and if it is not possible, release soon.
In at least one case, there will not even be a block, which is an
improvement.
Another version, that could, be, without using ERROR.
+static void
+DropObjectById(const ObjectAddress *object)
+{
+ int cacheId;
+ Relation rel;
+ HeapTuple tup;
+
+ cacheId = get_object_catcache_oid(object->classId);
+
+ /*
+ * Use the system cache for the oid column, if one exists.
+ */
+ if (cacheId >= 0)
+ {
+ tup = SearchSysCache1(cacheId, ObjectIdGetDatum(object->objectId));
+ if (HeapTupleIsValid(tup)) {
+rel = table_open(object->classId, RowExclusiveLock);
+CatalogTupleDelete(rel, &tup->t_self);
+table_close(rel, RowExclusiveLock);
+ReleaseSysCache(tup);
+ }
+ else
+ elog(LOG, "cache lookup failed for %s %u",
+ get_object_class_descr(object->classId), object->objectId);
+ }
+ else
+ {
+ ScanKeyData skey[1];
+ SysScanDesc scan;
+
+ ScanKeyInit(&skey[0],
+ get_object_attnum_oid(object->classId),
+ BTEqualStrategyNumber, F_OIDEQ,
+ ObjectIdGetDatum(object->objectId));
+
+rel = table_open(object->classId, RowExclusiveLock);
+ scan = systable_beginscan(rel, get_object_oid_index(object->classId),
true,
+ NULL, 1, skey);
+
+ /* we expect exactly one match */
+ tup = systable_getnext(scan);
+ if (HeapTupleIsValid(tup))
+CatalogTupleDelete(rel, &tup->t_self);
+ else
+ elog(LOG, "could not find tuple for %s %u",
+ get_object_class_descr(object->classId), object->objectId);
+
+systable_endscan(scan);
+table_close(rel, RowExclusiveLock);
+ }
+}
+
regards,
Ranier Vilela
Re: xid wraparound danger due to INDEX_CLEANUP false
On Sat, 18 Apr 2020 at 03:22, Robert Haas wrote: > > On Thu, Apr 16, 2020 at 6:49 PM Andres Freund wrote: > > Yea. _bt_vacuum_needs_cleanup() needs to check if > > metad->btm_oldest_btpo_xact is older than the FreezeLimit computed by > > vacuum_set_xid_limits() and vacuum the index if so even if INDEX_CLEANUP > > false. > > I'm still fairly unclear on what the actual problem is here, and on > how we propose to fix it. It seems to me that we probably don't have a > problem in the case where we don't advance relfrozenxid or relminmxid, > because in that case there's not much difference between the behavior > created by this patch and a case where we just error out due to an > interrupt or something before reaching the index cleanup stage. I > think that the problem is that in the case where we do relfrozenxid, > we might advance it past some XID value stored in the index metadata. > Is that right? I think advancing relfrozenxid past oldest_btpo_xact actually cannot be a problem. If a subsequent vacuum sees oldest_btpo_xact is an old xid, we can recycle pages. Before introducing to INDEX_CLEANUP = false, we used to invoke either bulkdelete or vaucumcleanup at least once in each vacuum. And thanks to relfrozenxid, a table is periodically vacuumed by an anti-wraparound vacuum. But with this feature, we can unconditionally skip both bulkdelete and vacuumcleanup. So IIUC the problem is that since we skip both, oldst_btpo_xact could be seen as a "future" xid during vacuum. Which will be a cause of that vacuum misses pages which can actually be recycled. I think we can fix this issue by calling vacuumcleanup callback when an anti-wraparound vacuum even if INDEX_CLEANUP is false. That way we can let index AM make decisions whether doing cleanup index at least once until XID wraparound, same as before. Originally the motivation of disabling INDEX_CLEANUP was to skip index full scan when anti-wraparound vacuum to reduce the execution time. By this change, we will end up doing an index full scan also in some anti-wraparound vacuum case but we still can skip that if there is no recyclable page in an index. Regards, -- Masahiko Sawadahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PG 13 release notes, first draft
On Tue, May 5, 2020 at 04:39:58PM -0500, Justin Pryzby wrote: > On Tue, May 05, 2020 at 05:34:26PM -0400, Bruce Momjian wrote: > > On Tue, May 5, 2020 at 02:37:16PM -0400, Bruce Momjian wrote: > > > On Tue, May 5, 2020 at 12:50:11PM -0500, Justin Pryzby wrote: > > > > Do you want to include any of these? > > > > > > > > 5823677acc Provide pgbench --show-script to dump built-in scripts. > > > > I have added the above entry to the release notes. > > +2019-07-16 [ce8f94676] Report the time taken by pgbench initialization steps. > +Allow pgbench to dump script contents using --show-script (Fabien Coelho) > > I think you confused these? > > ce8f946764 Report the time taken by pgbench initialization steps. > 5823677acc Provide pgbench --show-script to dump built-in scripts. You are correct, fixed. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: PG 13 release notes, first draft
On Tue, May 05, 2020 at 05:34:26PM -0400, Bruce Momjian wrote: > On Tue, May 5, 2020 at 02:37:16PM -0400, Bruce Momjian wrote: > > On Tue, May 5, 2020 at 12:50:11PM -0500, Justin Pryzby wrote: > > > Do you want to include any of these? > > > > > > 5823677acc Provide pgbench --show-script to dump built-in scripts. > > I have added the above entry to the release notes. +2019-07-16 [ce8f94676] Report the time taken by pgbench initialization steps. +Allow pgbench to dump script contents using --show-script (Fabien Coelho) I think you confused these? ce8f946764 Report the time taken by pgbench initialization steps. 5823677acc Provide pgbench --show-script to dump built-in scripts. -- Justin
Re: PG 13 release notes, first draft
On Tue, May 5, 2020 at 05:31:26PM -0400, Tom Lane wrote: > Alvaro Herrera writes: > > On 2020-May-05, Bruce Momjian wrote: > >> I tried a few approaches but ended up with this: > >> > >> Improve control of prepared statement parameter logging (Alexey > >> Bashtanov, Álvaro Herrera) > >> > >> The GUC setting log_parameter_max_length controls the maximum > >> length of parameter values output during statement non-error > >> logging, and log_parameter_max_length_on_error does the same > >> for error statement logging. Previously, prepared statement > >> parameters were not logged during errors. > > > This seems good to me. I think Tom Lane should be listed as coauthor of > > this item. > > Not necessary, I didn't do much on that. OK, removed. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: PG 13 release notes, first draft
On Tue, May 5, 2020 at 02:37:16PM -0400, Bruce Momjian wrote: > On Tue, May 5, 2020 at 12:50:11PM -0500, Justin Pryzby wrote: > > Do you want to include any of these? > > > > 5823677acc Provide pgbench --show-script to dump built-in scripts. I have added the above entry to the release notes. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: PG 13 release notes, first draft
Alvaro Herrera writes: > On 2020-May-05, Bruce Momjian wrote: >> I tried a few approaches but ended up with this: >> >> Improve control of prepared statement parameter logging (Alexey >> Bashtanov, Álvaro Herrera) >> >> The GUC setting log_parameter_max_length controls the maximum >> length of parameter values output during statement non-error >> logging, and log_parameter_max_length_on_error does the same >> for error statement logging. Previously, prepared statement >> parameters were not logged during errors. > This seems good to me. I think Tom Lane should be listed as coauthor of > this item. Not necessary, I didn't do much on that. regards, tom lane
Re: Unify drop-by-OID functions
On 2020-May-05, Ranier Vilela wrote: > And in that specific case, leaving resources blocked, which perhaps, in my > humble opinion, could be released quickly. I very much doubt that you can measure any difference at all between these two codings of the function. I agree with the principle you mention, of not holding resources for long if they can be released earlier; but in this case the table_close call occurs across a ReleaseSysCache() call, which is hardly of significance. It's not like you have to wait for some other transaction, or wait for I/O, or anything like that that would make it measurable. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PG 13 release notes, first draft
On Tue, May 5, 2020 at 03:44:37PM -0400, Alvaro Herrera wrote: > On 2020-May-05, Bruce Momjian wrote: > > > On Tue, May 5, 2020 at 12:50:11PM -0500, Justin Pryzby wrote: > > > Do you want to include any of these? > > > > > > 5823677acc Provide pgbench --show-script to dump built-in scripts. > > > ce8f946764 Report the time taken by pgbench initialization steps. > > > > I am kind of unclear how much of pgbench changes to put in the release > > notes since the use seems so specialized, but maybe that is wrong. > > Maybe it would make sense to group all pgbench changes in a subsection > of their own? pgbench already has its own section in the docs: E.1.3.8.2. pgbench I would be glad to expand it since it is easy to pick out pgbench items from the commit logs. > > > a01e1b8b9d Add new part SQL/MDA to information_schema.sql_parts > > > 33e27c3785c5ce8a3264d6af2550ec5adcebc517 > > > 2fc2a88e67 Remove obsolete information schema tables > > > > Uh, that didn't seem significant. > > Maybe have one item "modernize information_schema", and then describe > all the changes together in a single item. Uh, so I am unclear when we are adding items to information_schema because we now support them, and when they are new features of information_schema. > > I tried a few approaches but ended up with this: > > > > Improve control of prepared statement parameter logging (Alexey > > Bashtanov, Álvaro Herrera) > > > > The GUC setting log_parameter_max_length controls the maximum > > length of parameter values output during statement non-error > > logging, and log_parameter_max_length_on_error does the same > > for error statement logging. Previously, prepared statement > > parameters were not logged during errors. > > This seems good to me. I think Tom Lane should be listed as coauthor of > this item. Added. > > I used this text: > > > > Allow vacuum commands run by vacuumdb to operate in parallel mode > > (Masahiko Sawada) > > > > This is enabled with the new --parallel option. > > I think the vacuumdb item should be merged with the item for 40d964ec9, > since this is just about vacuumdb gaining control of the new VACUUM > feature. It's not something you can use separately from that. Well, it is under Server Commands and has a new flag, so I thought it should be here. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: PG 13 release notes, first draft
On Tue, May 5, 2020 at 03:21:00PM -0400, Alvaro Herrera wrote: > On 2020-May-05, Bruce Momjian wrote: > > > > |Allow incremental sorting (James Coleman, Alexander Korotkov) > > > s/Allow/Implement/ ? > > > > Agreed. > > FWIW I think Tomas Vondra should be credited as coauthor of this > feature. He didn't list himself as author in the commit message but I'm > pretty sure that's out of modesty, not lack of contribution. Thanks, added. We will hunt that modesty down! LOL -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: PG 13 release notes, first draft
On Tue, May 5, 2020 at 01:45:37PM -0500, Justin Pryzby wrote: > On Tue, May 05, 2020 at 02:10:24PM -0400, Bruce Momjian wrote: > > > > > | This is controlled by GUC wal_skip_threshold. > > > > > I think you should say that's a size threshold which determines which > > > > > strategy > > > > > to use (WAL or fsync). > > > > > > > > I went with: > > > > The WAL write amount where this happens is controlled by > > > > wal_skip_threshold. > > > > > > > > They can use the doc link if they want more detail. > > > > > > I guess I would say "relations larger than wal_skip_threshold will be > > > fsynced > > > rather than copied to WAL" > > > > How is this? > > > > Relations larger than wal_skip_threshold will have their files fynsced > > rather than writing their WAL records. > > I see I was too late, but: > > Fix typo (fynsc) and maybe add parens(). Ah, I was looking for fsync to fix that and could not find it. Now I found it with that spelling, I ended up using "fsync'ed". -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: PG 13 release notes, first draft
On Tue, May 5, 2020 at 11:44:33AM -0700, Jeff Davis wrote: > On Mon, 2020-05-04 at 23:16 -0400, Bruce Momjian wrote: > > I have committed the first draft of the PG 13 release notes. You can > > see them here: > > > > https://momjian.us/pgsql_docs/release-13.html > > > > It still needs markup, word wrap, and indenting. The community doc > > build should happen in a few hours. > > Regarding grouping sets: > > Just like hash aggregation, grouping sets could exceed work_mem by > large amounts in v12. Now, in v13, they both use disk when appropriate. Oh, another place I should change "not used" to "avoided". Thanks. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: PG 13 release notes, first draft
On Tue, May 05, 2020 at 03:44:37PM -0400, Alvaro Herrera wrote: > On 2020-May-05, Bruce Momjian wrote: > > On Tue, May 5, 2020 at 12:50:11PM -0500, Justin Pryzby wrote: > > > Do you want to include any of these? > > > > > > 5823677acc Provide pgbench --show-script to dump built-in scripts. > > > ce8f946764 Report the time taken by pgbench initialization steps. > > > > I am kind of unclear how much of pgbench changes to put in the release > > notes since the use seems so specialized, but maybe that is wrong. > > Maybe it would make sense to group all pgbench changes in a subsection > of their own? > > > > a01e1b8b9d Add new part SQL/MDA to information_schema.sql_parts > > > 33e27c3785c5ce8a3264d6af2550ec5adcebc517 > > > 2fc2a88e67 Remove obsolete information schema tables > > > > Uh, that didn't seem significant. > > Maybe have one item "modernize information_schema", and then describe > all the changes together in a single item. FYI, I did the same as last year, so I found these from output of something like git log --cherry-pick REL_12_STABLE...master I asked to avoid false negatives, not because I specifically want those commits mentioned. > > I used this text: > > > > Allow vacuum commands run by vacuumdb to operate in parallel mode > > (Masahiko Sawada) > > > > This is enabled with the new --parallel option. > > I think the vacuumdb item should be merged with the item for 40d964ec9, > since this is just about vacuumdb gaining control of the new VACUUM > feature. It's not something you can use separately from that. +1 -- Justin
Re: PG 13 release notes, first draft
On 2020-May-05, Bruce Momjian wrote: > On Tue, May 5, 2020 at 12:50:11PM -0500, Justin Pryzby wrote: > > Do you want to include any of these? > > > > 5823677acc Provide pgbench --show-script to dump built-in scripts. > > ce8f946764 Report the time taken by pgbench initialization steps. > > I am kind of unclear how much of pgbench changes to put in the release > notes since the use seems so specialized, but maybe that is wrong. Maybe it would make sense to group all pgbench changes in a subsection of their own? > > a01e1b8b9d Add new part SQL/MDA to information_schema.sql_parts > > 33e27c3785c5ce8a3264d6af2550ec5adcebc517 > > 2fc2a88e67 Remove obsolete information schema tables > > Uh, that didn't seem significant. Maybe have one item "modernize information_schema", and then describe all the changes together in a single item. > I tried a few approaches but ended up with this: > > Improve control of prepared statement parameter logging (Alexey > Bashtanov, Álvaro Herrera) > > The GUC setting log_parameter_max_length controls the maximum > length of parameter values output during statement non-error > logging, and log_parameter_max_length_on_error does the same > for error statement logging. Previously, prepared statement > parameters were not logged during errors. This seems good to me. I think Tom Lane should be listed as coauthor of this item. > I used this text: > > Allow vacuum commands run by vacuumdb to operate in parallel mode > (Masahiko Sawada) > > This is enabled with the new --parallel option. I think the vacuumdb item should be merged with the item for 40d964ec9, since this is just about vacuumdb gaining control of the new VACUUM feature. It's not something you can use separately from that. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PG 13 release notes, first draft
On 5/5/20 3:21 PM, Alvaro Herrera wrote: On 2020-May-05, Bruce Momjian wrote: |Allow incremental sorting (James Coleman, Alexander Korotkov) s/Allow/Implement/ ? Agreed. FWIW I think Tomas Vondra should be credited as coauthor of this feature. He didn't list himself as author in the commit message but I'm pretty sure that's out of modesty, not lack of contribution. +1. -- -David da...@pgmasters.net
Re: PG 13 release notes, first draft
On 2020-May-05, Bruce Momjian wrote: > > |Allow incremental sorting (James Coleman, Alexander Korotkov) > > s/Allow/Implement/ ? > > Agreed. FWIW I think Tomas Vondra should be credited as coauthor of this feature. He didn't list himself as author in the commit message but I'm pretty sure that's out of modesty, not lack of contribution. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: WAL usage calculation patch
On Tue, May 5, 2020 at 12:44 PM Amit Kapila wrote: > > On Mon, May 4, 2020 at 8:03 PM Julien Rouhaud wrote: > > > > On Mon, May 4, 2020 at 6:10 AM Amit Kapila wrote: > > > > > > On Thu, Apr 30, 2020 at 2:19 PM Julien Rouhaud wrote: > > > > > > > > Here's the patch. I included the content of > > > > v3-fix_explain_wal_output.patch you provided before, and tried to > > > > consistently replace full page writes/fpw to full page images/fpi > > > > everywhere on top of it (so documentation, command output, variable > > > > names and comments). > > > > > > > > > > Your patch looks mostly good to me. I have made slight modifications > > > which include changing the non-text format in show_wal_usage to use a > > > capital letter for the second word, which makes it similar to Buffer > > > usage stats, and additionally, ran pgindent. > > > > > > Let me know what do you think of attached? > > > > Thanks a lot Amit. It looks perfect to me! > > > > Pushed. Thanks!
Re: PG 13 release notes, first draft
On Tue, May 05, 2020 at 02:10:24PM -0400, Bruce Momjian wrote: > > > > | This is controlled by GUC wal_skip_threshold. > > > > I think you should say that's a size threshold which determines which > > > > strategy > > > > to use (WAL or fsync). > > > > > > I went with: > > > The WAL write amount where this happens is controlled by > > > wal_skip_threshold. > > > > > > They can use the doc link if they want more detail. > > > > I guess I would say "relations larger than wal_skip_threshold will be > > fsynced > > rather than copied to WAL" > > How is this? > > Relations larger than wal_skip_threshold will have their files fynsced > rather than writing their WAL records. I see I was too late, but: Fix typo (fynsc) and maybe add parens(). -- Justin
Re: PG 13 release notes, first draft
On Mon, 2020-05-04 at 23:16 -0400, Bruce Momjian wrote: > I have committed the first draft of the PG 13 release notes. You can > see them here: > > https://momjian.us/pgsql_docs/release-13.html > > It still needs markup, word wrap, and indenting. The community doc > build should happen in a few hours. Regarding grouping sets: Just like hash aggregation, grouping sets could exceed work_mem by large amounts in v12. Now, in v13, they both use disk when appropriate. There's an open item where we will consider tweaking the GUCs, so the descriptions might change slightly. Regards, Jeff Davis
Re: PG 13 release notes, first draft
On Tue, May 5, 2020 at 12:50:11PM -0500, Justin Pryzby wrote: > Do you want to include any of these? > > 5823677acc Provide pgbench --show-script to dump built-in scripts. > ce8f946764 Report the time taken by pgbench initialization steps. I am kind of unclear how much of pgbench changes to put in the release notes since the use seems so specialized, but maybe that is wrong. > 751c63cea0 Remove pg_regress' --load-language option. Well, for the same reasons, that is our regression tests, which I assume is more for internal use. > 33753ac9d7 Add object names to partition integrity violations. Improving error messages is not something I usually cover. People like to see the better error messages, but don't really value knowing about them before-hand, I am guessing. > 246f136e76 Improve handling of parameter differences in physical replication That seems to fall in the category above. > a01e1b8b9d Add new part SQL/MDA to information_schema.sql_parts > 33e27c3785c5ce8a3264d6af2550ec5adcebc517 Uh, that didn't seem significant. > 2fc2a88e67 Remove obsolete information schema tables > b9b408c487 Record parents of triggers (tgparentid) > 2b2bacdca0 Reset statement_timeout between queries of a multi-query string. That seemed like a bug fix for unusual usage. > 09f08930f0 initdb: Change authentication defaults Change the defaults for the > pg_hba.conf generated by initdb to "peer" or "md5" Uh, that was reverted: Author: Peter Eisentraut 2019-07-22 [796188658] Revert "initdb: Change authentication defaults" Revert "initdb: Change authentication defaults" This reverts commit 09f08930f0f6fd4a7350ac02f29124b919727198. The buildfarm client needs some adjustments first. > >Improve control of prepared statement parameter logging > >The GUC setting log_parameter_max_length controls the maximum length of > >parameter values output during statement logging, and > >log_parameter_max_length_on_error allows parameters to be output on > I think the original commit (ba79cb5d) gets lost in the description of the > details and the following commit. I would say: > |Emit parameter values during query bind/execute errors and allow control of > the max length logged by statement logging (Alexey Bashtanov, Álvaro Herrera) > |The GUC setting log_parameter_max_length controls the maximum length of > parameter values output during statement logging, and > log_parameter_max_length_on_error allows parameters to be output on > |error. > Or maybe split that into two items. I struggled on this one because we are both limiting parameter length when logging of normal queries _and_ adding paramater logging of error queries, also with a length limit. I tried a few approaches but ended up with this: Improve control of prepared statement parameter logging (Alexey Bashtanov, Álvaro Herrera) The GUC setting log_parameter_max_length controls the maximum length of parameter values output during statement non-error logging, and log_parameter_max_length_on_error does the same for error statement logging. Previously, prepared statement parameters were not logged during errors. > > Allow track_activity_query_size to be set to 1MB (Vyacheslav Makarov) > Say "*up* to 1MB". Agreed. > > super users > say "superuser" ? All fixed, thanks. > >Allow allow_system_table_mods to be changed after server start (Peter > >Eisentraut) > >Disallow non-super users from modifying system tables when > >allow_system_table_mods is set (Peter Eisentraut) > I think these two entries can be merged. Uh, they are quite different. The first one is about not requiring a reboot, while the second is a fix for allowing users do things when it is set that they should not be able to do. > >Add parallel control of the vacuumdb command using --parallel (Masahiko > >Sawada) > >Allow reindexdb to operate in parallel (Julien Rouhaud) > >Parallel mode is enabled with the new --jobs option. > > It's probably worth saying that vacuumdb --parallel just passes (parallel N) > option to the vacuum command, which means that it processes indexes in > parallel. > Whereas reindexdb --jobs is a client-side feature, creating a separate > sessions > for each. Oh, wow, good point, and very subtle. I used this text: Allow vacuum commands run by vacuumdb to operate in parallel mode (Masahiko Sawada) This is enabled with the new --parallel option. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: Unify drop-by-OID functions
Em ter., 5 de mai. de 2020 às 14:57, Robert Haas
escreveu:
> On Tue, May 5, 2020 at 1:43 PM Ranier Vilela wrote:
> > I see, the famous "cliché".
>
> By using the word cliché, and by putting it in quotes, you seem to
> suggest that you consider my argument dubious. However, I stand by it.
> Code shouldn't be changed without understanding the reasons behind the
> current coding. Doing so very often breaks things.
>
Sorry Robert, It was not my intention. I didn't know that using quotes
would change your understanding.
Of course, I find your arguments very valid and valuable.
And I understand that there are many interrelated things, which can break
if done in the wrong order.
Maybe I used the wrong word, in this case, the cliché.
What I mean is, the cliché, does some strange things, like leaving
variables to be declared, assigned in and not used.
And in that specific case, leaving resources blocked, which perhaps, in my
humble opinion, could be released quickly.
I think the expected behavior is being the same, with the changes I
proposed, IMHO.
+static void
+DropObjectById(const ObjectAddress *object)
+{
+ int cacheId;
+ Relation rel;
+ HeapTuple tup;
+
+ cacheId = get_object_catcache_oid(object->classId);
+
+ /*
+ * Use the system cache for the oid column, if one exists.
+ */
+ if (cacheId >= 0)
+ {
+ tup = SearchSysCache1(cacheId, ObjectIdGetDatum(object->objectId));
+ if (!HeapTupleIsValid(tup))
+ elog(ERROR, "cache lookup failed for %s %u",
+ get_object_class_descr(object->classId), object->objectId);
+
+rel = table_open(object->classId, RowExclusiveLock);
+ CatalogTupleDelete(rel, &tup->t_self);
+table_close(rel, RowExclusiveLock);
+
+ ReleaseSysCache(tup);
+ }
+ else
+ {
+ ScanKeyData skey[1];
+ SysScanDesc scan;
+
+ ScanKeyInit(&skey[0],
+ get_object_attnum_oid(object->classId),
+ BTEqualStrategyNumber, F_OIDEQ,
+ ObjectIdGetDatum(object->objectId));
+
+rel = table_open(object->classId, RowExclusiveLock);
+ scan = systable_beginscan(rel, get_object_oid_index(object->classId),
true,
+ NULL, 1, skey);
+
+ /* we expect exactly one match */
+ tup = systable_getnext(scan);
+ if (!HeapTupleIsValid(tup))
+ elog(ERROR, "could not find tuple for %s %u",
+ get_object_class_descr(object->classId), object->objectId);
+
+ CatalogTupleDelete(rel, &tup->t_self);
+ systable_endscan(scan);
+
+table_close(rel, RowExclusiveLock);
+ }
+}
And again, your opinion is very important to me.
best regards,
Ranier Vilela
Re: PG 13 release notes, first draft
On Tue, May 5, 2020 at 12:50:01PM -0500, Justin Pryzby wrote: > On Tue, May 05, 2020 at 01:18:09PM -0400, Bruce Momjian wrote: > > > |Release date: 2020-05-03 > > > => Should say 2020-XX-XX, before someone like me goes and installs it > > > everywhere in sight. > > > > Agreed! > > > > > |These triggers cannot change the destination partition. > > > => Maybe say "cannot change which partition is the destination" > > Looks like you copied my quote mark :( I kind of liked it, but OK, removed. ;-) > > > | Allow hash aggregation to use disk storage for large aggregation result > > > sets (Jeff Davis) > > > | Previously, hash aggregation was not used if it was expected to use > > > more than work_mem memory. This is controlled by enable_hashagg_disk. > > > => enable_hashagg_disk doesn't behave like other enable_* parameters. > > > As I understand, disabling it only "opportunisitically" avoids plans > > > which are > > > *expected* to overflow work_mem. I think we should specifically say > > > that, and > > > maybe suggest recalibrating work_mem. > > > > I went with "avoided": > > > > Previously, hash aggregation was avoided if it was expected to use more > > than work_mem memory. This is controlled by enable_hashagg_disk. > > I think we should expand on this: > > |Previously, hash aggregation was avoided if it was expected to use more than > |work_mem memory, but it wasn't enforced, and hashing could still exceed > |work_mem. To get back the old behavior, increasing work_mem. I think work_mem has too many other effects to recommend just changing it for this. > |The parameter enable_hashagg_disk controls whether a plan which is *expected* > |to spill to disk will be considered. During execution, an aggregate node > which > |exceeding work_mem will spill to disk regardless of this parameter. > > I wrote something similar here: > https://www.postgresql.org/message-id/20200407223900.GT2228%40telsasoft.com I think this kind of information should be in our docs, not really the release notes. > > > | This is controlled by GUC wal_skip_threshold. > > > I think you should say that's a size threshold which determines which > > > strategy > > > to use (WAL or fsync). > > > > I went with: > > The WAL write amount where this happens is controlled by > > wal_skip_threshold. > > > > They can use the doc link if they want more detail. > > I guess I would say "relations larger than wal_skip_threshold will be fsynced > rather than copied to WAL" How is this? Relations larger than wal_skip_threshold will have their files fynsced rather than writing their WAL records. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: Unify drop-by-OID functions
On Tue, May 5, 2020 at 1:43 PM Ranier Vilela wrote: > I see, the famous "cliché". By using the word cliché, and by putting it in quotes, you seem to suggest that you consider my argument dubious. However, I stand by it. Code shouldn't be changed without understanding the reasons behind the current coding. Doing so very often breaks things. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: PG 13 release notes, first draft
Do you want to include any of these? 5823677acc Provide pgbench --show-script to dump built-in scripts. ce8f946764 Report the time taken by pgbench initialization steps. 751c63cea0 Remove pg_regress' --load-language option. 33753ac9d7 Add object names to partition integrity violations. 246f136e76 Improve handling of parameter differences in physical replication a01e1b8b9d Add new part SQL/MDA to information_schema.sql_parts 33e27c3785c5ce8a3264d6af2550ec5adcebc517 2fc2a88e67 Remove obsolete information schema tables b9b408c487 Record parents of triggers (tgparentid) 2b2bacdca0 Reset statement_timeout between queries of a multi-query string. 09f08930f0 initdb: Change authentication defaults Change the defaults for the pg_hba.conf generated by initdb to "peer" or "md5" >Improve control of prepared statement parameter logging >The GUC setting log_parameter_max_length controls the maximum length of >parameter values output during statement logging, and >log_parameter_max_length_on_error allows parameters to be output on I think the original commit (ba79cb5d) gets lost in the description of the details and the following commit. I would say: |Emit parameter values during query bind/execute errors and allow control of the max length logged by statement logging (Alexey Bashtanov, Álvaro Herrera) |The GUC setting log_parameter_max_length controls the maximum length of parameter values output during statement logging, and log_parameter_max_length_on_error allows parameters to be output on |error. Or maybe split that into two items. > Allow track_activity_query_size to be set to 1MB (Vyacheslav Makarov) Say "*up* to 1MB". > super users say "superuser" ? >Allow allow_system_table_mods to be changed after server start (Peter >Eisentraut) >Disallow non-super users from modifying system tables when >allow_system_table_mods is set (Peter Eisentraut) I think these two entries can be merged. >Add parallel control of the vacuumdb command using --parallel (Masahiko Sawada) >Allow reindexdb to operate in parallel (Julien Rouhaud) >Parallel mode is enabled with the new --jobs option. It's probably worth saying that vacuumdb --parallel just passes (parallel N) option to the vacuum command, which means that it processes indexes in parallel. Whereas reindexdb --jobs is a client-side feature, creating a separate sessions for each. -- Justin
Re: PG 13 release notes, first draft
On Tue, May 05, 2020 at 01:18:09PM -0400, Bruce Momjian wrote: > > |Release date: 2020-05-03 > > => Should say 2020-XX-XX, before someone like me goes and installs it > > everywhere in sight. > > Agreed! > > > |These triggers cannot change the destination partition. > > => Maybe say "cannot change which partition is the destination" Looks like you copied my quote mark :( > > | Allow hash aggregation to use disk storage for large aggregation result > > sets (Jeff Davis) > > | Previously, hash aggregation was not used if it was expected to use more > > than work_mem memory. This is controlled by enable_hashagg_disk. > > => enable_hashagg_disk doesn't behave like other enable_* parameters. > > As I understand, disabling it only "opportunisitically" avoids plans which > > are > > *expected* to overflow work_mem. I think we should specifically say that, > > and > > maybe suggest recalibrating work_mem. > > I went with "avoided": > > Previously, hash aggregation was avoided if it was expected to use more > than work_mem memory. This is controlled by enable_hashagg_disk. I think we should expand on this: |Previously, hash aggregation was avoided if it was expected to use more than |work_mem memory, but it wasn't enforced, and hashing could still exceed |work_mem. To get back the old behavior, increasing work_mem. | |The parameter enable_hashagg_disk controls whether a plan which is *expected* |to spill to disk will be considered. During execution, an aggregate node which |exceeding work_mem will spill to disk regardless of this parameter. I wrote something similar here: https://www.postgresql.org/message-id/20200407223900.GT2228%40telsasoft.com > > | This is controlled by GUC wal_skip_threshold. > > I think you should say that's a size threshold which determines which > > strategy > > to use (WAL or fsync). > > I went with: > The WAL write amount where this happens is controlled by > wal_skip_threshold. > > They can use the doc link if they want more detail. I guess I would say "relations larger than wal_skip_threshold will be fsynced rather than copied to WAL" -- Justin
Re: Unify drop-by-OID functions
Em ter., 5 de mai. de 2020 às 14:29, Robert Haas escreveu: > On Tue, May 5, 2020 at 1:22 PM Ranier Vilela wrote: > > Ok, so the question. If (3) is not safe, obvious we shouldn't use, and > must call table_close, after systable_endscan. > > Now (1) and (2), I would have no hesitation in using it. > > I work with ERP, and throughout the time, the later, lock resources and > release them soon, the better, for the performance of the system as a whole. > > Even if it doesn't make much difference locally, using this process, > throughout the system, efficiency is noticeable. > > Apparently, it is more code, but it is less resources used and for less > time. > > And (2), if it is a case, frequently, no table would be blocked in this > function. > > Nobody here is going to question the concept that it's better to use > resources for less time rather than more, but the wisdom of sticking > to well-established coding patterns instead of inventing altogether > new ones is also well-understood. There are often good reasons why the > code is written in the way that it is, and it's important to > understand those before proposing to change things. > I see, the famous "cliché". regards, Ranier Vilela > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
Re: Unify drop-by-OID functions
On Tue, May 5, 2020 at 1:22 PM Ranier Vilela wrote: > Ok, so the question. If (3) is not safe, obvious we shouldn't use, and must > call table_close, after systable_endscan. > Now (1) and (2), I would have no hesitation in using it. > I work with ERP, and throughout the time, the later, lock resources and > release them soon, the better, for the performance of the system as a whole. > Even if it doesn't make much difference locally, using this process, > throughout the system, efficiency is noticeable. > Apparently, it is more code, but it is less resources used and for less time. > And (2), if it is a case, frequently, no table would be blocked in this > function. Nobody here is going to question the concept that it's better to use resources for less time rather than more, but the wisdom of sticking to well-established coding patterns instead of inventing altogether new ones is also well-understood. There are often good reasons why the code is written in the way that it is, and it's important to understand those before proposing to change things. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: Unify drop-by-OID functions
Em ter., 5 de mai. de 2020 às 13:06, Robert Haas
escreveu:
> On Fri, May 1, 2020 at 5:32 PM Ranier Vilela wrote:
> > I can suggest improvements?
> >
> > 1. In case Object is cached, delay open_table until the last moment, for
> the row to be blocked as little as possible and close the table as quickly
> as possible.
> > 2. In case Object is cached and the tuple is invalid, do not open table.
> > 3. Otherwise, is it possible to call systable_endscan, after table_close?
> >
> > I think that lock resources, for as little time as possible, it is an
> advantage..
>
> Only if it's correct, which (3) definitely wouldn't be, and I'm
> doubtful about (1) as well.
>
Ok, so the question. If (3) is not safe, obvious we shouldn't use, and must
call table_close, after systable_endscan.
Now (1) and (2), I would have no hesitation in using it.
I work with ERP, and throughout the time, the later, lock resources and
release them soon, the better, for the performance of the system as a whole.
Even if it doesn't make much difference locally, using this process,
throughout the system, efficiency is noticeable.
Apparently, it is more code, but it is less resources used and for less
time.
And (2), if it is a case, frequently, no table would be blocked in this
function.
Simple examples.
Exemple 1:
FILE * f;
f = fopen("data.txt", "r");
if (f != NULL) {
char buf[512];
size_t result;
result = fread(&buf, sizeof(char), 512, f);
fclose(f); // we no longer need the resource, release.
if (result != 0) {
process(buf);
printf("buf=%s\n", buf);
}
}
Exemple 2:
FILE * f;
f = fopen("data.txt", "r");
if (f != NULL) {
char buf[512];
size_t result;
result = fread(&buf, sizeof(char), 512, f);
if (result != 0) {
process(buf);
printf("buf=%s\n", buf);
}
fclose(f); // resource blocked until the end.
}
regards,
Ranier Vilela
Re: PG 13 release notes, first draft
On Tue, May 5, 2020 at 11:45:03AM -0500, Justin Pryzby wrote: > |Release date: 2020-05-03 > => Should say 2020-XX-XX, before someone like me goes and installs it > everywhere in sight. Agreed! > |These triggers cannot change the destination partition. > => Maybe say "cannot change which partition is the destination" > > |Allow incremental sorting (James Coleman, Alexander Korotkov) > s/Allow/Implement/ ? Agreed. > |If a result is already sorted by several keys, > s/keys/leading keys/ Agreed. > | Allow hash aggregation to use disk storage for large aggregation result > sets (Jeff Davis) > | Previously, hash aggregation was not used if it was expected to use more > than work_mem memory. This is controlled by enable_hashagg_disk. > => enable_hashagg_disk doesn't behave like other enable_* parameters. > As I understand, disabling it only "opportunisitically" avoids plans which are > *expected* to overflow work_mem. I think we should specifically say that, and > maybe suggest recalibrating work_mem. I went with "avoided": Previously, hash aggregation was avoided if it was expected to use more than work_mem memory. This is controlled by enable_hashagg_disk. > |This new behavior sets pages as all-visible > I think it should say "can allow setting pages all-visible" > It doesn't do anything special to force anything to be allvisible. OK, updated to: This new behavior allows pages to be set as all-visible, which then allows index-only scans, and reduces the work necessary when the table needs to be frozen. > | This is controlled by GUC wal_skip_threshold. > I think you should say that's a size threshold which determines which strategy > to use (WAL or fsync). I went with: The WAL write amount where this happens is controlled by wal_skip_threshold. They can use the doc link if they want more detail. > | Improve the performance of replay of DROP DATABASE commands that use many > tablespaces (Fujii Masao) > "when replaying DROP DATABASE commands if many tablespaces are in use" OK, updated to: Improve the performance when replaying DROP DATABASE commands when many tablespaces are in use (Fujii Masao) > > |Improve performance for truncation of very larger relations (Kirk Jamison) > *large Fixed. > |Server variable backtrace_functions specifies which C functions should > generate backtraces on error. > Could you say "GUC" so it's easy to search for ? Uh, I kind of back and forth on whether GUC or server variable is better. I kind of mix them up so people will know what GUC is. > | This is controlled by ssl_min_protocol_version. > | This behavior can be enabled using wal_receiver_create_temp_slot. > | This is controlled by logical_decoding_work_mem. > | This is enabled using ignore_invalid_pages. > Say GUC in these places, too ? Oh, uh, I am not sure. These will all have links too. > |Previously, server restart was required to change primary_conninfo and > primary_slot_name. > *a* server restart Agreed. > | Speedup recovery by prefetching pages (Thomas Munro) > "Speed up" or accelerate or "Improve speed of". > Speedup (one word) sounds like a noun. Uh, someone requested I remove that, so I have. > > | Fix bugs in ALTER TABLE where later clauses overlap changes made by earlier > clauses in the same command (Tom Lane) > s/where/when/ ? Agreed. > | The new function, jsonb_set_lax(), allows null new values to either set the > specified key to JSON null, delete the key, raise exception, or ignore > operation. IS 'return_target' CLEAR? > ignore *the* operation Agreed. > | time zone-aware output. > timezone-aware ? Uh, time zone is two words. We can do time-zone-aware but that looks odd. > | This makes \gx equivalent to \g (expanded=on). > I would say: "this allows syntax like \g (expand=on) which is equivalent to > \gx" I like that. > |Allow pgbench to partition its 'accounts' table (Fabien COELHO) > Sometimes Fabien's name is/not capitalized. I have already committed a fix for that. > | This is enable using the -c/--restore-target-wal option. > *enabled* Agreed. > | These long-supported options for this are called --superuser and > --no-superuser. > "The supported" not "These long-supported" ? Yep. > I'm not sure, but maybe these patches of mine should be documented? > > commit 24f62e93f314c107b4fa679869e5ba9adb2d545f > Improve psql's \d output for partitioned indexes. > > commit c33869cc3bfc42bce822251f2fa1a2a346f86cc5 > psql \d: Display table where trigger is defined, if inherited > > => Alvaro said the functionality could conceivably be backpatched > (nontrivially), which suggests this doesn't need to be documented, but I think > backpatch would be a bad idea, and I think it should be documented. I looked at these and they looked like incremental changes to psql display in a way that people would say "nice", but not really want to know about it before-hand. Mayb
Re: PG 13 release notes, first draft
|Release date: 2020-05-03 => Should say 2020-XX-XX, before someone like me goes and installs it everywhere in sight. |These triggers cannot change the destination partition. => Maybe say "cannot change which partition is the destination" |Allow incremental sorting (James Coleman, Alexander Korotkov) s/Allow/Implement/ ? |If a result is already sorted by several keys, s/keys/leading keys/ | Allow hash aggregation to use disk storage for large aggregation result sets (Jeff Davis) | Previously, hash aggregation was not used if it was expected to use more than work_mem memory. This is controlled by enable_hashagg_disk. => enable_hashagg_disk doesn't behave like other enable_* parameters. As I understand, disabling it only "opportunisitically" avoids plans which are *expected* to overflow work_mem. I think we should specifically say that, and maybe suggest recalibrating work_mem. |This new behavior sets pages as all-visible I think it should say "can allow setting pages all-visible" It doesn't do anything special to force anything to be allvisible. | This is controlled by GUC wal_skip_threshold. I think you should say that's a size threshold which determines which strategy to use (WAL or fsync). | Improve the performance of replay of DROP DATABASE commands that use many tablespaces (Fujii Masao) "when replaying DROP DATABASE commands if many tablespaces are in use" |Improve performance for truncation of very larger relations (Kirk Jamison) *large |Server variable backtrace_functions specifies which C functions should generate backtraces on error. Could you say "GUC" so it's easy to search for ? | This is controlled by ssl_min_protocol_version. | This behavior can be enabled using wal_receiver_create_temp_slot. | This is controlled by logical_decoding_work_mem. | This is enabled using ignore_invalid_pages. Say GUC in these places, too ? |Previously, server restart was required to change primary_conninfo and primary_slot_name. *a* server restart | Speedup recovery by prefetching pages (Thomas Munro) "Speed up" or accelerate or "Improve speed of". Speedup (one word) sounds like a noun. | Fix bugs in ALTER TABLE where later clauses overlap changes made by earlier clauses in the same command (Tom Lane) s/where/when/ ? | The new function, jsonb_set_lax(), allows null new values to either set the specified key to JSON null, delete the key, raise exception, or ignore operation. IS 'return_target' CLEAR? ignore *the* operation | time zone-aware output. timezone-aware ? | This makes \gx equivalent to \g (expanded=on). I would say: "this allows syntax like \g (expand=on) which is equivalent to \gx" |Allow pgbench to partition its 'accounts' table (Fabien COELHO) Sometimes Fabien's name is/not capitalized. | This is enable using the -c/--restore-target-wal option. *enabled* | These long-supported options for this are called --superuser and --no-superuser. "The supported" not "These long-supported" ? I'm not sure, but maybe these patches of mine should be documented? commit 24f62e93f314c107b4fa679869e5ba9adb2d545f Improve psql's \d output for partitioned indexes. commit c33869cc3bfc42bce822251f2fa1a2a346f86cc5 psql \d: Display table where trigger is defined, if inherited => Alvaro said the functionality could conceivably be backpatched (nontrivially), which suggests this doesn't need to be documented, but I think backpatch would be a bad idea, and I think it should be documented. -- Justin
Re: PG 13 release notes, first draft
> > > > > > Please do list Jürgen, Corey and Roger as authors of the glossary. > > (Actually I should be listed as well, as the time I spent on it was > considerable.) > +1, the time spent was quite considerable
Re: Unify drop-by-OID functions
On Fri, May 1, 2020 at 5:32 PM Ranier Vilela wrote: > I can suggest improvements? > > 1. In case Object is cached, delay open_table until the last moment, for the > row to be blocked as little as possible and close the table as quickly as > possible. > 2. In case Object is cached and the tuple is invalid, do not open table. > 3. Otherwise, is it possible to call systable_endscan, after table_close? > > I think that lock resources, for as little time as possible, it is an > advantage.. Only if it's correct, which (3) definitely wouldn't be, and I'm doubtful about (1) as well. This reminds me: I think that the issues in http://postgr.es/m/ca+tgmoyafyrrdrz94p_qdt+1oong6smovbkghkvsftoncrf...@mail.gmail.com should be considered here - we should guarantee that there's a snapshot registered continuously from before the call to SearchSysCache1 until after the call to CatalogTupleDelete. In the systable_beginscan case, we should be fine as long as the systable_endscan follows the CatalogTupleDelete call. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: PG 13 release notes, first draft
On Tue, May 5, 2020 at 11:48:47AM -0400, Andrew Dunstan wrote: > > On 5/4/20 11:16 PM, Bruce Momjian wrote: > > I have committed the first draft of the PG 13 release notes. You can > > see them here: > > > > https://momjian.us/pgsql_docs/release-13.html > > > > It still needs markup, word wrap, and indenting. The community doc > > build should happen in a few hours. > > > > > Peter Eisentraut gets the credit for Unix domain sockets on Windows, not > me, I just reviewed it. Sorry about that, fixed. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: PG 13 release notes, first draft
On 5/4/20 11:16 PM, Bruce Momjian wrote: > I have committed the first draft of the PG 13 release notes. You can > see them here: > > https://momjian.us/pgsql_docs/release-13.html > > It still needs markup, word wrap, and indenting. The community doc > build should happen in a few hours. > Peter Eisentraut gets the credit for Unix domain sockets on Windows, not me, I just reviewed it. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PG 13 release notes, first draft
On Tue, May 5, 2020 at 11:23:50AM -0400, Alvaro Herrera wrote: > On 2020-May-05, Alvaro Herrera wrote: > > > On 2020-May-05, Bruce Momjian wrote: > > > > > On Tue, May 5, 2020 at 07:43:09AM +0200, Fabien COELHO wrote: > > > > > > I do not see a "documentation" section, whereas there has been > > > > significant > > > > doc changes, such as function table layouts (Tom), glossary (Corey, > > > > Jürgen, > > > > > > I did list the glossary. > > > > Please do list Jürgen, Corey and Roger as authors of the glossary. > > (Actually I should be listed as well, as the time I spent on it was > considerable.) Yep, already done, based on the commit text. :-) -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: PG 13 release notes, first draft
On Tue, May 5, 2020 at 11:14:11AM -0400, Alvaro Herrera wrote: > On 2020-May-05, Bruce Momjian wrote: > > > On Tue, May 5, 2020 at 07:43:09AM +0200, Fabien COELHO wrote: > > > > I do not see a "documentation" section, whereas there has been significant > > > doc changes, such as function table layouts (Tom), glossary (Corey, > > > Jürgen, > > > > I did list the glossary. > > Please do list Jürgen, Corey and Roger as authors of the glossary. Done, from the commit message: Add a glossary to the documentation (Corey Huinker, Jürgen Purtz, Roger Harkavy, Álvaro Herrera) -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: PG 13 release notes, first draft
On 2020-May-05, Alvaro Herrera wrote: > On 2020-May-05, Bruce Momjian wrote: > > > On Tue, May 5, 2020 at 07:43:09AM +0200, Fabien COELHO wrote: > > > > I do not see a "documentation" section, whereas there has been significant > > > doc changes, such as function table layouts (Tom), glossary (Corey, > > > Jürgen, > > > > I did list the glossary. > > Please do list Jürgen, Corey and Roger as authors of the glossary. (Actually I should be listed as well, as the time I spent on it was considerable.) -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PG 13 release notes, first draft
In this item + + + + +Add the ability to remove a function's dependency on an extension (Alvaro Herrera) + + + +The syntax is ALTER FUNCTION .. NO DEPENDS ON. + + + This works for several object types, not just a functions. I propose Add the ability to remove an object's dependency on an extension (Álvaro Herrera) The object can be a function, materialized view, index, or trigger. The syntax is ALTER .. NO DEPENDS ON. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Poll: are people okay with function/operator table redesign?
Oleksandr Shulgin writes:
> Would it be premature to complain about the not-that-great look of Table
> 9.1 now?
> Compare the two attached images: the screenshot from
> https://www.postgresql.org/docs/devel/functions-comparison.html
> vs the GIMP-assisted pipe dream of mine to align it to the right edge of
> the table cell.
Hmph. I experimented with the attached patch, but at least in my browser
it only reduces the spacing inconsistency, it doesn't eliminate it.
And from a semantic standpoint, this is not nice markup.
Doing better would require substantial foolery with sub-columns and I'm
not even sure that it's possible to fix that way. (We don't have huge
control over inter-column spacing, I don't think.)
On the whole, if this is our worst table problem, I'm happy ;-)
regards, tom lane
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index d9b3598..557a3ac 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -222,7 +222,7 @@ repeat('Pg', 4) PgPgPgPg
-datatype < datatype
+datatype < datatype
boolean
Less than
@@ -230,7 +230,7 @@ repeat('Pg', 4) PgPgPgPg
-datatype > datatype
+datatype > datatype
boolean
Greater than
@@ -254,7 +254,7 @@ repeat('Pg', 4) PgPgPgPg
-datatype = datatype
+datatype = datatype
boolean
Equal
Re: PG 13 release notes, first draft
On 2020-May-05, Bruce Momjian wrote: > On Tue, May 5, 2020 at 07:43:09AM +0200, Fabien COELHO wrote: > > I do not see a "documentation" section, whereas there has been significant > > doc changes, such as function table layouts (Tom), glossary (Corey, Jürgen, > > I did list the glossary. Please do list Jürgen, Corey and Roger as authors of the glossary. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: PG 13 release notes, first draft
On Tue, May 5, 2020 at 09:20:39PM +0800, John Naylor wrote: > Hi Bruce, thanks for working on this again! > > + > +Allow UTF-8 escapes, e.g., E'\u', in clients that don't use UTF-8 > encoding (Tom Lane) > + > > I believe the term we want here is "Unicode escapes". This patch is > about the server encoding, which formerly needed to be utf-8 for > non-ascii characters. (I think the client encoding doesn't matter as > long as ascii bytes are represented.) > > + > +The UTF-8 characters must be available in the server encoding. > + > > Same here, s/UTF-8/Unicode/. OK, new text is: Allow Unicode escapes, e.g., E'\u', in clients that don't use UTF-8 encoding (Tom Lane) The Unicode characters must be available in the server encoding. I kept the "UTF-8 encoding" since that is the only Unicode encoding we support. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: PG 13 release notes, first draft
On Tue, May 5, 2020 at 10:07:35AM +0200, Juan José Santamaría Flecha wrote: > > On Tue, May 5, 2020 at 5:16 AM Bruce Momjian wrote: > > I have committed the first draft of the PG 13 release notes. You can > see them here: > > https://momjian.us/pgsql_docs/release-13.html > > It still needs markup, word wrap, and indenting. The community doc > build should happen in a few hours. > > > There is one entry "Add support for collation versions on Windows" where I am > quoted as author. Actually, I was a reviewer, the author is Thomas Munro. Oops, my mistake, fixed. > > Also, I am credited as sole author of "Allow to_date/to_timestamp to recognize > non-English month/day names", when the case is that Tom Lane did more than a > few cosmetics changes when committing and I think he should be quoted as > co-author (if he agrees). OK, updated. The text was: Juan José Santamaría Flecha, reviewed and modified by me, and with reviewed first, and the generic term modified, I had assumed you would the the only one listed. Fixed. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: Another modest proposal for docs formatting: catalog descriptions
Fabien COELHO writes: > My 0.02€: I'm wondering whether the description could/should match SQL > syntax, eg: >oid OID >adrelid OID REFERENCES pg_class(oid) >adnum INT2 REFERENCES pg_attribute(attnum) >… > Or maybe just uppercase type names, especially when repeated? Meh. I'm not a fan of overuse of upper case --- it's well established that that's harder to read than lower or mixed case. And it's definitely project policy that type names are generally treated as identifiers not keywords, even if some of them happen to be keywords under the hood. The markup I had in mind was for the field name and for the type name, but no decoration beyond that. As for the references, it seems to me that your notation would lead people to think that there are actual FK constraints in place, which of course there are not (especially not on the views). I'm not hugely against it but I prefer what I suggested. > I guess that reference targets would still be navigable. Yeah, they'd still have wrappers --- if I recall what those look like in the documentation sources, they don't need any change except for addition of the "(references ...)" text. regards, tom lane
Re: PG 13 release notes, first draft
On Tue, May 5, 2020 at 08:10:54AM +0200, Julien Rouhaud wrote: > Hi, > > On Tue, May 5, 2020 at 7:47 AM Pavel Stehule wrote: > > > > Hi > > > > út 5. 5. 2020 v 5:16 odesílatel Bruce Momjian napsal: > >> > >> I have committed the first draft of the PG 13 release notes. You can > >> see them here: > >> > >> https://momjian.us/pgsql_docs/release-13.html > >> > >> It still needs markup, word wrap, and indenting. The community doc > >> build should happen in a few hours. > > > > > > There is not note about new polymorphic type "anycompatible" > > > > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=24e2885ee304cb6a94fdfc25a1a108344ed9f4f7 > > There's also no note about avoiding full GIN index scan > (https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=4b754d6c16e16cc1a1adf12ab0f48603069a0efd). > That's a corner case optimization but it can be a huge improvement > when you hit the problem. OK, I have added this item: Allow GIN indexes to more efficiently handle NOT restrictions (Nikita Glukhov, Alexander Korotkov, Tom Lane, Julien Rouhaud) -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: PG 13 release notes, first draft
út 5. 5. 2020 v 16:18 odesílatel Bruce Momjian napsal: > On Tue, May 5, 2020 at 07:46:34AM +0200, Pavel Stehule wrote: > > Hi > > > > út 5. 5. 2020 v 5:16 odesílatel Bruce Momjian napsal: > > > > I have committed the first draft of the PG 13 release notes. You can > > see them here: > > > > https://momjian.us/pgsql_docs/release-13.html > > > > It still needs markup, word wrap, and indenting. The community doc > > build should happen in a few hours. > > > > > > There is not note about new polymorphic type "anycompatible" > > > > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h= > > 24e2885ee304cb6a94fdfc25a1a108344ed9f4f7 > > Sorry I missed that. Must have thought it was non-visible work that was > part of another features. Here is the new text: > > Add polymorphic data types for use by functions requiring > compatible arguments (Pavel Stehule) > > The new data types are anycompatible, anycompatiblearray, > anycompatiblenonarray, and anycompatiblerange. > no problem, thank you Pavel > -- > Bruce Momjian https://momjian.us > EnterpriseDB https://enterprisedb.com > > + As you are, so once was I. As I am, so you will be. + > + Ancient Roman grave inscription + >
Re: PG 13 release notes, first draft
On Tue, May 5, 2020 at 07:46:34AM +0200, Pavel Stehule wrote: > Hi > > út 5. 5. 2020 v 5:16 odesílatel Bruce Momjian napsal: > > I have committed the first draft of the PG 13 release notes. You can > see them here: > > https://momjian.us/pgsql_docs/release-13.html > > It still needs markup, word wrap, and indenting. The community doc > build should happen in a few hours. > > > There is not note about new polymorphic type "anycompatible" > > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h= > 24e2885ee304cb6a94fdfc25a1a108344ed9f4f7 Sorry I missed that. Must have thought it was non-visible work that was part of another features. Here is the new text: Add polymorphic data types for use by functions requiring compatible arguments (Pavel Stehule) The new data types are anycompatible, anycompatiblearray, anycompatiblenonarray, and anycompatiblerange. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: Own index methods
Benjamin Schaller writes: > Even though it's described as fairly complicated: If I would want to > define my own index method, what would be a good approach to do so? contrib/bloom would make a sensible template, perhaps. regards, tom lane
Re: Poll: are people okay with function/operator table redesign?
Dean Rasheed writes: > On Mon, 4 May 2020 at 22:22, Tom Lane wrote: >> Now I could have done this example by spelling out all six varieties of >> stddev() separately, and maybe I should've, but it seemed overly bulky >> that way. > FWIW, I prefer having each variety spelled out separately. For > example, I really like the new way that aggregates like sum() and > avg() are displayed. To me, having all the types listed like that is > much more readable than having to read and interpret a piece of free > text. > Similarly, for other functions like gcd(), lcm() and mod(). I think it > would be better to get rid of numeric_type, and just list all the > variants of each function. I had had the same idea to start with, but it didn't survive first contact with table 9.4 (Mathematical Operators). It's not really reasonable to spell out all the variants of + ... especially not if you want to be precise, because then you'd have to list the cross-type variants too. If I counted correctly, there are fourteen variants of binary + that would have to be listed in that table, never mind the other common operators. max() and min() have a similar sort of problem --- the list of variants is just dauntingly long, and it's not that interesting either. I wrote out sum() and avg() the way I did because they have a somewhat irregular mapping from input to output types, so it seemed better to just list the alternatives explicitly. I don't object too much to spelling out the variants of stddev() and variance(), if there's a consensus for that. But getting rid of "numeric_type" entirely seems impractical. regards, tom lane
Re: Postgres Windows build system doesn't work with python installed in Program Files
On Mon, May 04, 2020 at 03:42:20PM +0200, Juan José Santamaría Flecha wrote:
> +1, seems like the way to go to me.
Attached is a patch for that and I have gone with a simple solution,
with some bonus comments about the way things happen. Here are the
patterns I tested for build.pl and the commands it generates, making
sure that we have the same commands with HEAD and the patch:
1) perl build.pl
msbuild pgsql.sln /verbosity:normal /p:Configuration=Release
2) perl build.pl debug
msbuild pgsql.sln /verbosity:normal /p:Configuration=Debug
3) perl build.pl release
msbuild pgsql.sln /verbosity:normal /p:Configuration=Release
4) perl build.pl foo
msbuild foo.vcxproj /verbosity:normal /p:Configuration=Release
5) perl build.pl debug foo
msbuild foo.vcxproj /verbosity:normal /p:Configuration=Debug
6) perl build.pl release foo
msbuild foo.vcxproj /verbosity:normal /p:Configuration=Release
The two warnings show up only in the first case, of course.
--
Michael
diff --git a/src/tools/msvc/build.pl b/src/tools/msvc/build.pl
index de50554e7e..782c9f4f26 100644
--- a/src/tools/msvc/build.pl
+++ b/src/tools/msvc/build.pl
@@ -1,7 +1,9 @@
# -*-perl-*- hey - emacs - this is a perl file
-
+#
+# Script that provides 'make' functionality for msvc builds.
+#
# src/tools/msvc/build.pl
-
+#
use strict;
use warnings;
@@ -36,18 +38,36 @@ do "./src/tools/msvc/config.pl" if (-f "src/tools/msvc/config.pl");
my $vcver = Mkvcbuild::mkvcbuild($config);
-# check what sort of build we are doing
+# Check what sort of build we are doing. Several patterns are
+# supported here depending on how many arguments this script is called
+# with:
+# - No arguments provided imply that all components should be built
+# with a release configuration.
+# - A first optional, case-insensitive, argument can be provided:
+# -- "Release" to trigger a build for all components with a release
+#configuration.
+# -- "Debug" to trigger a build for all components with a debug
+#build.
+# -- Specifying any other value will create a build with a release
+#configuration for the component specified as argument.
+# - A second optional argument can be provided to define a component
+# to build. This can be used with the first argument to build one
+# component at a time with a debug or release configuration.
my $bconf = $ENV{CONFIG} || "Release";
my $msbflags = $ENV{MSBFLAGS} || "";
my $buildwhat = $ARGV[1] || "";
-if (uc($ARGV[0]) eq 'DEBUG')
+
+if (defined($ARGV[0]))
{
- $bconf = "Debug";
-}
-elsif (uc($ARGV[0]) ne "RELEASE")
-{
- $buildwhat = $ARGV[0] || "";
+ if (uc($ARGV[0]) eq 'DEBUG')
+ {
+ $bconf = "Debug";
+ }
+ elsif (uc($ARGV[0]) ne "RELEASE")
+ {
+ $buildwhat = $ARGV[0] || "";
+ }
}
# ... and do it
signature.asc
Description: PGP signature
Re: PG 13 release notes, first draft
On Tue, May 5, 2020 at 04:14:42PM +1200, Thomas Munro wrote: > On Tue, May 5, 2020 at 3:16 PM Bruce Momjian wrote: > > I have committed the first draft of the PG 13 release notes. You can > > see them here: > > > > https://momjian.us/pgsql_docs/release-13.html > > > > It still needs markup, word wrap, and indenting. The community doc > > build should happen in a few hours. > > Hi Bruce, > > Thanks! Some feedback: > > +2020-04-08 [3985b600f] Support PrefetchBuffer() in recovery. > +--> > + > + > +Speedup recovery by prefetching pages (Thomas Munro) > > Unfortunately that commit was just an infrastructural change to allow > the PrefetchBuffer() function to work in recovery, but the main > "prefetching during recovery" patch to actually make use of it to go > faster didn't make it. So this item shouldn't be in the release > notes. Agreed, removed. > +2020-04-07 [4c04be9b0] Introduce xid8-based functions to replace txid_XXX. > +--> > + > + > +Update all transaction id functions to support xid8 (Thomas Munro) > + > + > + > +They use the same names as the xid data type versions. > + > > The names are actually different. How about: "New xid8-based > functions replace the txid family of functions, but the older names > are still supported for backward compatibility." Agreed. > +2019-10-16 [d5ac14f9c] Use libc version as a collation version on glibc > systems > +--> > + > + > +Use the glibc version as the collation version (Thomas Munro) > + > + > + > +If the glibc version changes, a warning will be issued when a > mismatching collation is used. > + > > I would add a qualifier "in some cases", since it doesn't work for > default collations yet. (That'll now have to wait for 14). Done. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: PG 13 release notes, first draft
On Tue, May 5, 2020 at 07:43:09AM +0200, Fabien COELHO wrote: > > Hello Bruce, > > > I have committed the first draft of the PG 13 release notes. You can > > see them here: > > > > https://momjian.us/pgsql_docs/release-13.html > > > > It still needs markup, word wrap, and indenting. The community doc > > build should happen in a few hours. > > Thanks for working on this. > > * Add CREATE DATABASE LOCALE option (Fabien COELHO) > * Add function gen_random_uuid to generate version 4 UUIDs (Fabien COELHO) > > I'm not responsible for these, I just reviewed them. ISTM that the author > for both is the committer, Peter Eisentraut. > > Maybe there is something amiss in the commit-log-to-release-notes script? > My name clearly appears after "reviewed by:?" Sorry, those were all my mistaken reading of the commit message. > > * "DOCUMENT THE DEFAULT GENERATION METHOD" > => The default is still to generate data client-side. My point is that the docs are not clear about this. Can you fix it? > I do not see a "documentation" section, whereas there has been significant > doc changes, such as function table layouts (Tom), glossary (Corey, Jürgen, I did list the glossary. > Roger, Alvarro), binary/text string functions (Karl) and possibly others. I wasn't sure documentation _layout_ changes should be listed. > Having a good documentation contributes to making postgres a very good tool, > improving it is is not very glamorous, ISTM that such contributions should > not be overlooked. Yes, I would be good to know from others if that kind of stuff should be included. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: PG 13 release notes, first draft
Hi Bruce, thanks for working on this again! + +Allow UTF-8 escapes, e.g., E'\u', in clients that don't use UTF-8 encoding (Tom Lane) + I believe the term we want here is "Unicode escapes". This patch is about the server encoding, which formerly needed to be utf-8 for non-ascii characters. (I think the client encoding doesn't matter as long as ascii bytes are represented.) + +The UTF-8 characters must be available in the server encoding. + Same here, s/UTF-8/Unicode/. -- John Naylorhttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Own index methods
Hi, in the Postgres documentation it says: "PostgreSQLprovides the index methods B-tree, hash, GiST, SP-GiST, GIN, and BRIN. Users can also define their own index methods, but that is fairly complicated." (https://www.postgresql.org/docs/12/sql-createindex.html) Even though it's described as fairly complicated: If I would want to define my own index method, what would be a good approach to do so? Best regards
Re: PG 13 release notes, first draft
On Mon, May 4, 2020 at 11:16:00PM -0400, Bruce Momjian wrote: > I have committed the first draft of the PG 13 release notes. You can > see them here: > > https://momjian.us/pgsql_docs/release-13.html > > It still needs markup, word wrap, and indenting. The community doc > build should happen in a few hours. I wanted to point out there are 180 changes listed in the release notes, which very closely matches the count of previous major releases. I don't think there are as many major _features_ in this release as previous ones. Also, I see little to no progress on these features in PG 13: * online checksum changes * zheap * sharding -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: Poll: are people okay with function/operator table redesign?
On Mon, May 4, 2020 at 11:22 PM Tom Lane wrote: > I've now completed updating chapter 9 for the new layout, > and the results are visible at > https://www.postgresql.org/docs/devel/functions.html > There is more to do --- for instance, various contrib modules > have function/operator tables that should be synced with this > design. But this seemed like a good place to pause and reflect. > Would it be premature to complain about the not-that-great look of Table 9.1 now? Compare the two attached images: the screenshot from https://www.postgresql.org/docs/devel/functions-comparison.html vs the GIMP-assisted pipe dream of mine to align it to the right edge of the table cell. I don't have the faintest idea how to achieve that using SGML at the moment, but it just looks so much nicer to me. ;-) Regards, -- Alex
Re: PG compilation error with Visual Studio 2015/2017/2019
On Mon, May 4, 2020 at 6:59 PM Juan José Santamaría Flecha wrote: > > On Thu, Apr 30, 2020 at 5:07 AM Amit Kapila wrote: >> >> >> Okay, thanks. The key point to keep in mind is to avoid touching the >> code related to prior MSVC versions as we might not have set up to >> test those. > > > Please find attached a new version following this approach. > Thanks for the new version. I have found few problems and made changes accordingly. In back-branch patches, I found one major problem. +#if (_MSC_VER >= 1900) /* Visual Studio 2015 or later */ + rc = get_iso_localename(winlocname, iso_lc_messages); +#else Here, we need to free loct, otherwise, it will leak each time this function is called on a newer MSVC version. Also, call to _create_locale is redundant in _MSC_VER >= 1900. So, I have tried to write it differently, see what do you think about it? * + * BEWARE: this function is WIN32 specific, so wchar_t are UTF-16. I am not sure how much relevant is this comment so removed for now. Apart from that, I have made a few other changes in comments, fixed typos, and ran pgindent. Let me know what do you think of attached patches? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com 0001-PG-compilation-error-with-VS-2015-2017-2019_v16.patch Description: Binary data 0001-PG_10-compilation-error-with-VS-2015-2017-2019_v16.patch Description: Binary data 0001-PG9_5-compilation-error-with-VS-2015-2017-2019_v16.patch Description: Binary data
Re: WAL usage calculation patch
On Mon, May 4, 2020 at 8:03 PM Julien Rouhaud wrote: > > On Mon, May 4, 2020 at 6:10 AM Amit Kapila wrote: > > > > On Thu, Apr 30, 2020 at 2:19 PM Julien Rouhaud wrote: > > > > > > Here's the patch. I included the content of > > > v3-fix_explain_wal_output.patch you provided before, and tried to > > > consistently replace full page writes/fpw to full page images/fpi > > > everywhere on top of it (so documentation, command output, variable > > > names and comments). > > > > > > > Your patch looks mostly good to me. I have made slight modifications > > which include changing the non-text format in show_wal_usage to use a > > capital letter for the second word, which makes it similar to Buffer > > usage stats, and additionally, ran pgindent. > > > > Let me know what do you think of attached? > > Thanks a lot Amit. It looks perfect to me! > Pushed. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
Re: Poll: are people okay with function/operator table redesign?
On Mon, 4 May 2020 at 22:22, Tom Lane wrote: > > * is also quite sticky about inserting other sorts > of font-changing environments inside it. As an example, it'll let > you include but not , which seems pretty weird > to me. This is problematic in some places where it's desirable to > have text rather than just a type name, for example > > stddev ( numeric_type > ) > double precision > for real or double precision, > otherwise numeric > > Now I could have done this example by spelling out all six varieties of > stddev() separately, and maybe I should've, but it seemed overly bulky > that way. FWIW, I prefer having each variety spelled out separately. For example, I really like the new way that aggregates like sum() and avg() are displayed. To me, having all the types listed like that is much more readable than having to read and interpret a piece of free text. Similarly, for other functions like gcd(), lcm() and mod(). I think it would be better to get rid of numeric_type, and just list all the variants of each function. Regards, Dean
Re: PG 13 release notes, first draft
On Tue, May 5, 2020 at 5:16 AM Bruce Momjian wrote: > I have committed the first draft of the PG 13 release notes. You can > see them here: > > https://momjian.us/pgsql_docs/release-13.html > > It still needs markup, word wrap, and indenting. The community doc > build should happen in a few hours. > There is one entry "Add support for collation versions on Windows" where I am quoted as author. Actually, I was a reviewer, the author is Thomas Munro. Also, I am credited as sole author of "Allow to_date/to_timestamp to recognize non-English month/day names", when the case is that Tom Lane did more than a few cosmetics changes when committing and I think he should be quoted as co-author (if he agrees). Regards, Juan José Santamaría Flecha
Re: Postgres Windows build system doesn't work with python installed in Program Files
В Tue, 5 May 2020 15:45:48 +0900
Michael Paquier пишет:
> On Fri, May 01, 2020 at 12:48:17PM +0300, Victor Wagner wrote:
> > Maybe. But probably original author of this code was afraid of using
> > too long chain of ->{} in the string substitution.
> >
> > So, I left this style n place.
> >
> > Nonetheless, using qq wouldn't save us from doubling backslashes.
>
> Looking at this part in more details, I find the attached much more
> readable. I have been able to test it on my own Windows environment
I agree, it is better.
> and the problem gets fixed (I have reproduced the original problem as
> well).
--
