Re: logical replication of truncate command with trigger causes Assert

On Fri, Jun 11, 2021 at 12:20 AM Tom Lane wrote: > > Amit Kapila writes: > > On Wed, Jun 9, 2021 at 8:44 PM Mark Dilger > > wrote: > >> On Jun 9, 2021, at 7:52 AM, Tom Lane wrote: > >>> Somewhat unrelated, but ... am I reading the code correctly that > >>> apply_handle_stream_start and

Re: Race condition in recovery?

At Fri, 11 Jun 2021 14:07:45 +0900 (JST), Kyotaro Horiguchi wrote in > At Thu, 10 Jun 2021 21:53:18 -0400, Tom Lane wrote in > > conchuela's failure is evidently not every time, but this test > > definitely postdates the "fix": conchuela failed recovery_check this time, and > >

Re: Add PortalDrop in exec_execute_message

Alvaro Herrera wrote 2021-06-08 00:07: On 2021-May-27, Yura Sokolov wrote: Alvaro Herrera писал 2021-05-26 23:59: > I don't think they should do that. The portal remains open, and the > libpq interface does that. The portal gets closed at end of transaction > without the need for any

Re: locking [user] catalog tables vs 2pc vs logical rep

On Fri, Jun 11, 2021 at 6:57 AM osumi.takami...@fujitsu.com wrote: > > On Thursday, June 10, 2021 1:30 PM I wrote: > > On Thursday, June 10, 2021 1:14 PM vignesh C > > > On Wed, Jun 9, 2021 at 12:03 PM osumi.takami...@fujitsu.com > > > wrote: > > > > > > > > On Wednesday, June 9, 2021 12:06 PM

Re: Race condition in recovery?

At Thu, 10 Jun 2021 21:53:18 -0400, Tom Lane wrote in > Kyotaro Horiguchi writes: > > At Thu, 10 Jun 2021 09:56:51 -0400, Robert Haas > > wrote in > >> Thanks for the analysis and the patches. I have committed them. > > > Thanks for committing it. > > Please note that conchuela and jacana

Re: libpq debug log

On Mon, Jun 07, 2021 at 11:37:58AM -0400, Robert Haas wrote: > On Sat, Jun 5, 2021 at 11:03 AM Alvaro Herrera > wrote: > > > This added a PQtraceSetFlags() function. We have a dozen PQset*() > > > functions, > > > but this and PQresultSetInstanceData() are the only PQSomethingSet() > > >

Re: PoC/WIP: Extended statistics on expressions

On Sun, Jun 06, 2021 at 09:13:17PM +0200, Tomas Vondra wrote: > > On 6/6/21 7:37 AM, Noah Misch wrote: > > On Sat, Mar 27, 2021 at 01:17:14AM +0100, Tomas Vondra wrote: > >> OK, pushed after a bit more polishing and testing. > > > > This added a "transformed" field to CreateStatsStmt, but it

Re: Question about StartLogicalReplication() error path

On Fri, Jun 11, 2021 at 7:38 AM Jeff Davis wrote: > > StartLogicalReplication() calls CreateDecodingContext(), which says: > > else if (start_lsn < slot->data.confirmed_flush) > { > /* > * It might seem like we should error out in this case, but it's > * pretty common for a

Release 14 Beta 2

Hi, The Release Management Team (Peter Geoghegan, Andrew Dunstan and myself) proposes that the date of the PostgreSQL 14 Beta 2 release will be **Thursday June 24, 2021**, which aligns with the past practice. Thanks, -- Michael signature.asc Description: PGP signature

Re: [bug?] Missed parallel safety checks, and wrong parallel safety

On Thu, Jun 10, 2021 at 10:59 PM Robert Haas wrote: > > On Thu, Jun 10, 2021 at 12:54 AM Amit Kapila wrote: > > Fair enough. So, I think there is a consensus to drop this patch and > > if one wants then we can document these cases. Also, we don't want it > > to enable parallelism for Inserts

Re: Fix dropped object handling in pg_event_trigger_ddl_commands

On Thu, Jun 10, 2021 at 05:07:28PM +0900, Michael Paquier wrote: > Except that these syscache lookups need to be done on an object-type > basis, which is basically what getObjectDescription() & friends now do > where the logic makes sure that we have a correct objectId <-> cacheId > mapping for

Re: Multi-Column List Partitioning

Hi Nitin, On Thu, Jun 3, 2021 at 11:45 PM Nitin Jadhav wrote: > > I'll wait for you to post a new patch addressing at least the comments > > in my earlier email. Also, please make sure to run `make check` > > successfully before posting the patch. :) > > I have fixed all of the review comments

Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

On Thu, Jun 10, 2021 at 7:38 PM Andres Freund wrote: > Well, I'd like to add assertions ensuring the retry path is only entered > when correct - but I feel hesitant about doing so when I can't exercise > that path reliably in at least some of the situations. I originally tested the

Re: Duplicate history file?

On Fri, Jun 11, 2021 at 11:25:51AM +0900, Kyotaro Horiguchi wrote: > > Nevertheless I agree to it, still don't we need a minimum workable > setup as the first step? Something like below. > > === > The following is an example of the minimal archive_command. > > Example: cp %p /blah/%f > >

Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

Hi, On 2021-06-10 19:15:59 -0700, Peter Geoghegan wrote: > On Thu, Jun 10, 2021 at 7:00 PM Andres Freund wrote: > > I'm not convinced - right now we don't exercise this path in tests at > > all. More assertions won't change that - stuff that can be triggered in > > production-ish loads doesn't

Re: Duplicate history file?

Recently my brain is always twisted.. At Fri, 11 Jun 2021 11:25:51 +0900 (JST), Kyotaro Horiguchi wrote in > Anyway it doesn't seem to be the time to do that, but as now that we - know that there's a case where the current example doesn't prevent PG + know that there's a case where the current

Re: Duplicate history file?

At Thu, 10 Jun 2021 10:00:21 -0400, Stephen Frost wrote in > Greetings, > > * Kyotaro Horiguchi (horikyota@gmail.com) wrote: > > At Wed, 09 Jun 2021 16:56:14 +0900, Tatsuro Yamada > > wrote in > > > On 2021/06/09 16:23, Fujii Masao wrote: > > > > Instead, we should consider and document

Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

On Thu, Jun 10, 2021 at 7:00 PM Andres Freund wrote: > I'm not convinced - right now we don't exercise this path in tests at > all. More assertions won't change that - stuff that can be triggered in > production-ish loads doesn't help during development. I do think that > that makes it far too

Re: Patch: Range Merge Join

On Thu, 2021-06-10 at 15:09 +1200, David Rowley wrote: > It shouldn't be a blocker for you, but just so you're aware, there > was > a previous proposal for this in [1] and a patch in [2]. I've include > Jeff here just so he's aware of this. Jeff may wish to state his > intentions with his own

Question about StartLogicalReplication() error path

StartLogicalReplication() calls CreateDecodingContext(), which says: else if (start_lsn < slot->data.confirmed_flush) { /* * It might seem like we should error out in this case, but it's * pretty common for a client to acknowledge a LSN it doesn't have to * do anything for,

timing sensitive failure of test_decoding RT that exists in PG9.6

Hi I by chance found a timing issue that exists in PG9.6 during my process to make a patch-set that should be back-patched to 9.6. I don't judge this is unique in 9.6 or not from HEAD yet. (Then, I don't know like this is solved by HEAD already but not back-patched but can it be ?) Please tell

Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

Peter Geoghegan writes: > ISTM that it would be much more useful to focus on adding an assertion > (or maybe even a "can't happen" error) that fails when the DEAD/goto > path is reached with a tuple whose xmin wasn't aborted. If that was in > place then we would have caught the bug in >

Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

Hi, On 2021-06-10 18:49:50 -0700, Peter Geoghegan wrote: > ISTM that it would be much more useful to focus on adding an assertion > (or maybe even a "can't happen" error) that fails when the DEAD/goto > path is reached with a tuple whose xmin wasn't aborted. If that was in > place then we would

RE: Transactions involving multiple postgres foreign servers, take 2

From: Robert Haas > That is completely unrealistic. As Sawada-san has pointed out > repeatedly, there are tons of things that can go wrong even after the > remote side has prepared the transaction. Preparing a transaction only > promises that the remote side will let you commit the transaction

Re: Race condition in recovery?

Kyotaro Horiguchi writes: > At Thu, 10 Jun 2021 09:56:51 -0400, Robert Haas wrote > in >> Thanks for the analysis and the patches. I have committed them. > Thanks for committing it. Please note that conchuela and jacana are still failing ... conchuela's failure is evidently not every time,

Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

On Thu, Jun 10, 2021 at 5:58 PM Andres Freund wrote: > The problem with writing a test is likely to find a way to halfway > reliably schedule a transaction abort after pruning, but before the > tuple-removal loop? Does anybody see a trick to do so? I asked Alexander about using his pending stop

Re: "an SQL" vs. "a SQL"

On Fri, 11 Jun 2021 at 04:04, Tom Lane wrote: > However, I'm also > unlikely to worry about this point when copy-editing docs. I'm sorry to hear that. Maybe keeping this consistent will be one of those endless jobs like keeping the source code pgindented. We still try to keep that in order

Re: Adjust pg_regress output for new long test names

On Wed, Jun 09, 2021 at 09:31:24AM -0400, Alvaro Herrera wrote: > On 2021-Jun-08, Noah Misch wrote: > > > On Wed, Jun 9, 2021 at 2:51 PM Noah Misch wrote: > > > > Not bad, but I would instead shorten the names to detach-[1234] or > > > > detach-partition-[1234]. The marginal value of the second

Re: Race condition in recovery?

At Thu, 10 Jun 2021 09:56:51 -0400, Robert Haas wrote in > On Wed, Jun 9, 2021 at 9:12 PM Kyotaro Horiguchi > wrote: > > https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=conchuela=2021-06-09%2021%3A12%3A25=recovery-check > > > > > ==~_~===-=-===~_~== > > >

Re: BF assertion failure on mandrill in walsender, v13

On Thu, Jun 10, 2021 at 09:08:06AM -0400, Andrew Dunstan wrote: > On 6/10/21 1:47 AM, Noah Misch wrote: > > On Thu, Jun 10, 2021 at 10:47:20AM +1200, Thomas Munro wrote: > >> Not sure if there is much chance of debugging this one-off failure in > >> without a backtrace (long shot: any chance

Re: Logical replication keepalive flood

At Thu, 10 Jun 2021 12:18:00 +0530, Amit Kapila wrote in > Good analysis. I think this analysis has shown that walsender is > sending messages at top speed as soon as they are generated. So, I am > wondering why there is any need to wait/sleep in such a workload. One > possibility that occurred

RE: locking [user] catalog tables vs 2pc vs logical rep

On Thursday, June 10, 2021 1:30 PM I wrote: > On Thursday, June 10, 2021 1:14 PM vignesh C > > On Wed, Jun 9, 2021 at 12:03 PM osumi.takami...@fujitsu.com > > wrote: > > > > > > On Wednesday, June 9, 2021 12:06 PM Amit Kapila > > wrote: > > > > On Tue, Jun 8, 2021 at 6:24 PM vignesh C > wrote:

Replication protocol doc fix

The docs currently say (introduced in commit 91fa853): "In the event of a backend-detected error during copy-both mode, the backend will issue an ErrorResponse message, discard frontend messages until a Sync message is received, and then issue ReadyForQuery and return to normal processing." But

Re: PostmasterIsAlive() in recovery (non-USE_POST_MASTER_DEATH_SIGNAL builds)

Heikki Linnakangas writes: > On 09/04/2021 07:01, Thomas Munro wrote: >> This seems to work on Linux, macOS, FreeBSD and OpenBSD (and I assume >> any other BSD). Can anyone tell me if it works on illumos, AIX or >> HPUX, and if not, how to fix it or disable the feature gracefully? >> For now the

Re: Testing autovacuum wraparound (including failsafe)

Hi, On 2021-06-10 16:42:01 +0300, Anastasia Lubennikova wrote: > Cool. Thank you for working on that! > Could you please share a WIP patch for the $subj? I'd be happy to help with > it. I've attached the current WIP state, which hasn't evolved much since this message... I put the test in

Re: Race condition in InvalidateObsoleteReplicationSlots()

On 2021-Jun-10, Álvaro Herrera wrote: > I wrote a test (0002) to cover the case of signalling a walsender, which > is currently not covered (we only deal with the case of a standby that's > not running). There are some sharp edges in this code -- I had to make > it use background_psql() to send

Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

Hi, On 2021-06-08 19:18:18 -0500, Justin Pryzby wrote: > I reproduced the issue on a new/fresh cluster like this: > > ./postgres -D data -c autovacuum_naptime=1 -c > autovacuum_analyze_scale_factor=0.005 -c log_autovacuum_min_duration=-1 > psql -h /tmp postgres -c "CREATE TABLE t(i int); INSERT

Re: speed up verifying UTF-8

I wrote: > Also, if SSE is accepted into the tree, then the C fallback is only important on platforms like PowerPC64 and Arm64, so we can make the tradeoff by testing those more carefully. I'll test on PowerPC soon. I got around to testing on POWER8 / Linux / gcc 4.8.5 and found a regression in

Re: doc issue missing type name "multirange" in chapter title

Justin Pryzby writes: > If it's confusing to say "and" twice, then perhaps you'd say: > Functions and Operators for Range and Multirange Types Uh, that's still two "and"s. In any case, I think it's better to keep this section heading aligned with all of its siblings.

Re: doc issue missing type name "multirange" in chapter title

On Thu, Jun 10, 2021 at 11:46:46PM +0300, Alexander Korotkov wrote: > On Fri, May 7, 2021 at 8:18 AM Pavel Stehule wrote: > > I searched operators for multirange type, and the current doc is little bit > > messy, because chapter "Range Functions and Operators" contains operators > > and

Re: "an SQL" vs. "a SQL"

On Fri, 11 Jun 2021 at 09:39, Andrew Dunstan wrote: > I suspect "an historic" is bordering on archaic even in the UK these days. Yeah, that's a weird one. Maybe https://en.wikipedia.org/wiki/H-dropping is to blame. David

Re: "an SQL" vs. "a SQL"

On Fri, 11 Jun 2021 at 02:48, Isaac Morland wrote: > > On Thu, 10 Jun 2021 at 10:43, David Rowley wrote: >> >> - requires an MIT Kerberos installation and opens TCP/IP listen >> sockets. >> + requires a MIT Kerberos installation and opens TCP/IP listen sockets. >> >> I think all of

Re: unnesting multirange data types

+{ oid => '1293', descr => 'expand mutlirange to set of ranges', typo: mutlirange Thanks Jonathan for excercising this implementation sooner than later. -- Justin

Re: Race condition in InvalidateObsoleteReplicationSlots()

Here's a version that I feel is committable (0001). There was an issue when returning from the inner loop, if in a previous iteration we had released the lock. In that case we need to return with the lock not held, so that the caller can acquire it again, but weren't. This seems pretty hard to

Re: "an SQL" vs. "a SQL"

On 6/10/21 5:32 PM, Tom Lane wrote: > Gavin Flower writes: >> On 11/06/21 8:17 am, Isaac Morland wrote: >>> ... But then there is "an historic occasion" so go figure. >> The 'h' in 'historic' is silent, at least it used to be -- I think now >> it is almost silent. So using 'an historic

Re: "an SQL" vs. "a SQL"

Gavin Flower writes: > On 11/06/21 8:17 am, Isaac Morland wrote: >> ... But then there is "an historic occasion" so go figure. > The 'h' in 'historic' is silent, at least it used to be -- I think now > it is almost silent. So using 'an historic occasion' is correct. It's silent according to

Re: Error on pgbench logs

Bonjour Michaël, Here is an updated patch. While having a look at Kyotaro-san patch, I noticed that the aggregate stuff did not print the last aggregate. I think that it is a side effect of switching the precision from per-second to per-µs. I've done an attempt at also fixing that which

Re: doc issue missing type name "multirange" in chapter title

Hi! Sorry for the late reply. On Fri, May 7, 2021 at 8:18 AM Pavel Stehule wrote: > I searched operators for multirange type, and the current doc is little bit > messy, because chapter "Range Functions and Operators" contains operators and > functions for multirange type too. > > I think so

Re: "an SQL" vs. "a SQL"

On 11/06/21 8:17 am, Isaac Morland wrote: On Thu, 10 Jun 2021 at 16:11, Gavin Flower mailto:gavinflo...@archidevsys.co.nz>> wrote: On 11/06/21 2:48 am, Isaac Morland wrote: > “A MIT …”? As far as I know it is pronounced M - I - T, which would > imply that it should use “an”. The

Re: "an SQL" vs. "a SQL"

On Thu, 10 Jun 2021 at 16:11, Gavin Flower wrote: > On 11/06/21 2:48 am, Isaac Morland wrote: > > > “A MIT …”? As far as I know it is pronounced M - I - T, which would > > imply that it should use “an”. The following page seems believable and > > is pretty unequivocal on the issue: > > > >

Re: "an SQL" vs. "a SQL"

On 11/06/21 2:48 am, Isaac Morland wrote: On Thu, 10 Jun 2021 at 10:43, David Rowley > wrote: -      requires an MIT Kerberos installation and opens TCP/IP listen sockets. +       requires a MIT Kerberos installation and opens TCP/IP listen sockets.

Re: unnesting multirange data types

On Thu, Jun 10, 2021 at 8:57 PM Jonathan S. Katz wrote: > On 6/10/21 1:24 PM, Alexander Korotkov wrote: > > I agree that unnest(), cast to array and subscription are missing > > points. Proper subscription support requires expanded object > > handling. And that seems too late for v14. > >

Re: logical replication of truncate command with trigger causes Assert

Amit Kapila writes: > On Wed, Jun 9, 2021 at 8:44 PM Mark Dilger > wrote: >> On Jun 9, 2021, at 7:52 AM, Tom Lane wrote: >>> Somewhat unrelated, but ... am I reading the code correctly that >>> apply_handle_stream_start and related routines are using Asserts >>> to check that the remote sent

Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

On 2021-Jun-10, Peter Geoghegan wrote: > On Thu, Jun 10, 2021 at 10:29 AM Matthias van de Meent > wrote: > > I see one exit for HEAPTUPLE_DEAD on a potentially recently committed > > xvac (?), and we might also check against recently committed > > transactions if xmin == xmax, although

Re: unnesting multirange data types

On 6/10/21 1:24 PM, Alexander Korotkov wrote: > Hi, all! > > On Thu, Jun 10, 2021 at 2:00 AM Jonathan S. Katz wrote: >> On 6/9/21 4:56 PM, Alvaro Herrera wrote: >>> On 2021-Jun-09, Jonathan S. Katz wrote: >>> I did a couple more tests around this. As suspected, in PL/pgSQL, there

Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

On Thu, Jun 10, 2021 at 10:29 AM Matthias van de Meent wrote: > I see one exit for HEAPTUPLE_DEAD on a potentially recently committed > xvac (?), and we might also check against recently committed > transactions if xmin == xmax, although apparently that is not > implemented right now. I don't

Re: [bug?] Missed parallel safety checks, and wrong parallel safety

On Thu, Jun 10, 2021 at 12:54 AM Amit Kapila wrote: > Fair enough. So, I think there is a consensus to drop this patch and > if one wants then we can document these cases. Also, we don't want it > to enable parallelism for Inserts where we are trying to pursue the > approach to have a flag in

Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

On Thu, 10 Jun 2021 at 19:07, Peter Geoghegan wrote: > > On Thu, Jun 10, 2021 at 9:57 AM Matthias van de Meent > wrote: > > > By "matches what we expect", I meant "involves a just-aborted > > > transaction". We could defensively verify that the inserting > > > transaction concurrently aborted at

Re: unnesting multirange data types

Hi, all! On Thu, Jun 10, 2021 at 2:00 AM Jonathan S. Katz wrote: > On 6/9/21 4:56 PM, Alvaro Herrera wrote: > > On 2021-Jun-09, Jonathan S. Katz wrote: > > > >> I did a couple more tests around this. > >> > >> As suspected, in PL/pgSQL, there is no way to unpack or iterate over a > >> multirange

Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

Hi, On 2021-06-10 17:49:05 +0200, Matthias van de Meent wrote: > Apart from this, I'm also quite certain that the goto-branch that > created this infinite loop should have been dead code: In a correctly > working system, the GlobalVis*Rels should always be at least as strict > as the

Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

On Thu, Jun 10, 2021 at 9:57 AM Matthias van de Meent wrote: > > By "matches what we expect", I meant "involves a just-aborted > > transaction". We could defensively verify that the inserting > > transaction concurrently aborted at the point of retrying/calling > > heap_page_prune() a second

Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

On Thu, 10 Jun 2021 at 18:03, Peter Geoghegan wrote: > > On Thu, Jun 10, 2021 at 8:49 AM Matthias van de Meent > wrote: > > Could you elaborate on what this "matches what we expect" entails? > > > > Apart from this, I'm also quite certain that the goto-branch that > > created this infinite loop

Re: Transactions involving multiple postgres foreign servers, take 2

On Fri, Jun 4, 2021 at 4:04 AM tsunakawa.ta...@fujitsu.com wrote: > Why does the user have to get an error? Once the local transaction has been > prepared, which means all remote ones also have been prepared, the whole > transaction is determined to commit. So, the user doesn't have to

Re: RFC: Logging plan of the running query

On Wed, Jun 9, 2021 at 1:14 PM torikoshia wrote: > Updated the patch. Thanks for the patch. Here are some comments on v3 patch: 1) We could just say "Requests to log query plan of the presently running query of a given backend along with an untruncated query string in the server logs." Instead

Re: "an SQL" vs. "a SQL"

David Rowley writes: > If you really feel that strongly about not changing this then I can > drop this. However, I'll likely growl every time I see "a SQL" in the > docs from now on. [ shrug... ] I'm not going to stand in your way. However, I'm also unlikely to worry about this point when

Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

On Thu, Jun 10, 2021 at 8:49 AM Matthias van de Meent wrote: > Could you elaborate on what this "matches what we expect" entails? > > Apart from this, I'm also quite certain that the goto-branch that > created this infinite loop should have been dead code: In a correctly > working system, the

Re: "an SQL" vs. "a SQL"

On Fri, 11 Jun 2021 at 03:24, Tom Lane wrote: > If there were some semblance of an overall consensus on the spelling, > I'd be fine with weeding out the stragglers. But when the existing > usages are only about 2-to-1 in one direction or the other, I feel > quite confident in predicting that

Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

On Wed, 9 Jun 2021 at 22:45, Peter Geoghegan wrote: > > On Wed, Jun 9, 2021 at 11:45 AM Andres Freund wrote: > > Good find! > > +1 > > > > The attached patch fixes this inconsistency > > > > I think I prefer applying the fix and the larger changes separately. > > I wonder if it's worth making

Re: "an SQL" vs. "a SQL"

David Rowley writes: > On Fri, 11 Jun 2021 at 02:53, Tom Lane wrote: >> Indeed. I think this is entirely pointless; there's zero hope that >> any consistency you might establish right now will persist very long. > hmm. Yet we do have other standards which we do manage to maintain. If there

Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

On Wed, 9 Jun 2021 at 20:45, Andres Freund wrote: > > Specifically, the issue is that it uses the innocuous looking > > else if (RelationIsAccessibleInLogicalDecoding(rel)) > return horizons.catalog_oldest_nonremovable; > > but that's not sufficient, because > > #define

Re: "an SQL" vs. "a SQL"

On Fri, 11 Jun 2021 at 02:53, Tom Lane wrote: > Indeed. I think this is entirely pointless; there's zero hope that > any consistency you might establish right now will persist very long. > The largest effect of this proposed patch will be to create > back-patching headaches. hmm. Yet we do

Re: "an SQL" vs. "a SQL"

Alvaro Herrera writes: > On 2021-Jun-10, David Rowley wrote: >> It seems we have no standard as to if we say "a SQL" or "an SQL". > I was just reading the standard a couple of days ago and happened to > notice that the standard itself in some places uses "a SQL" and in other > places "an SQL".

Re: "an SQL" vs. "a SQL"

On Fri, 11 Jun 2021 at 02:35, Alvaro Herrera wrote: > > On 2021-Jun-10, David Rowley wrote: > > My regex foo is not strong enough to think how I might find multiline > > instances. > > This catches some of these: > > ag "\sa[\s*]*\n[\s*]*(A|E|F|H|I|L|M|N|O|S|X)[A-Z]{2,5}\s" Thanks. I ended up

Re: "an SQL" vs. "a SQL"

On Thu, 10 Jun 2021 at 10:43, David Rowley wrote: > - requires an MIT Kerberos installation and opens TCP/IP listen > sockets. > + requires a MIT Kerberos installation and opens TCP/IP listen > sockets. > > I think all of these should use "a" rather than "an". > “A MIT …”? As far as

Re: Multiple hosts in connection string failed to failover in non-hot standby mode

I wrote: > Now I'm inclined to go back to the first-draft patch I had, which just > dropped the first problematic test case, and added gssencmode=disable > to the second one. Done that way. If we figure out why the GSS code is acting strangely on hamerkop, maybe this can be reverted --- but it

Re: "an SQL" vs. "a SQL"

On Fri, 11 Jun 2021 at 02:04, David Rowley wrote: > I came up with the attached patch. Further searching using: git grep -E "\s(an|An)\s(F|H|L|M|N|S|X)[A-Z]{2,5}" (i.e vowel sounding, but not actually starting with a vowel then manually looking for pronounceable ones.) - by a response from

Re: "an SQL" vs. "a SQL"

On 2021-Jun-10, David Rowley wrote: > I thought it might be worth having this conversation before we branch for v15. > > It seems we have no standard as to if we say "a SQL" or "an SQL". I was just reading the standard a couple of days ago and happened to notice that the standard itself in some

Re: "an SQL" vs. "a SQL"

On Thu, Jun 10, 2021 at 1:27 AM David Rowley wrote: > > I think we should change all 55 instances of "a SQL" in the docs to > use "an SQL" and leave the 800 other instances of "a SQL" alone. +1 Consistency is good. Roberto

Re: "an SQL" vs. "a SQL"

On Thu, 10 Jun 2021 at 20:58, Daniel Gustafsson wrote: > > > On 10 Jun 2021, at 10:54, Dave Page wrote: > > > .. I would perhaps suggest extending to any user-visible messages in the > > code. > > I agree, consistent language between docs and user-facing messages is > important. Yeah, agreed.

Re: Duplicate history file?

Greetings, * Kyotaro Horiguchi (horikyota@gmail.com) wrote: > At Wed, 09 Jun 2021 16:56:14 +0900, Tatsuro Yamada > wrote in > > On 2021/06/09 16:23, Fujii Masao wrote: > > > Instead, we should consider and document "better" command for > > > archive_command, or implement something like

Re: CALL versus procedures with output-only arguments

Peter Eisentraut writes: > On 08.06.21 01:10, Tom Lane wrote: >> Here is said update (rolled up into one patch this time; maybe that will >> avoid the apply problems you had). > This patch looks good to me. Thanks for reviewing! > A minor comment: You changed the docs in some places like this:

Re: Race condition in recovery?

On Wed, Jun 9, 2021 at 9:12 PM Kyotaro Horiguchi wrote: > https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=conchuela=2021-06-09%2021%3A12%3A25=recovery-check > > > ==~_~===-=-===~_~== > > pgsql.build/src/test/recovery/tmp_check/log/025_stuck_on_old_timeline_cascade.log > >

Re: Decoding speculative insert with toast leaks memory

On Thu, Jun 10, 2021 at 2:12 PM Dilip Kumar wrote: > > On Wed, Jun 9, 2021 at 8:59 PM Alvaro Herrera wrote: > > > > May I suggest to use a different name in the blurt_and_lock_123() > > function, so that it doesn't conflict with the one in > > insert-conflict-specconflict? Thanks > > Renamed to

Re: Testing autovacuum wraparound (including failsafe)

On Thu, Jun 10, 2021 at 10:52 AM Andres Freund wrote: > > I started to write a test for $Subject, which I think we sorely need. > > Currently my approach is to: > - start a cluster, create a few tables with test data > - acquire SHARE UPDATE EXCLUSIVE in a prepared transaction, to prevent >

Re: BF assertion failure on mandrill in walsender, v13

On 6/10/21 1:47 AM, Noah Misch wrote: > On Thu, Jun 10, 2021 at 10:47:20AM +1200, Thomas Munro wrote: >> Not sure if there is much chance of debugging this one-off failure in >> without a backtrace (long shot: any chance there's still a core >> file?) > No; it was probably in a directory deleted

Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options

On Thu, Jun 10, 2021 at 9:17 AM Bharath Rupireddy wrote: > > I don't know the answer; my guess is that all this has become obsolete > > and the whole Assert and the dodgy comment can just be deleted. > > Hm. I get it. Unfortunately the commit b1ff33f is missing information > on what the coverity

Re: speed up verifying UTF-8

On Wed, Jun 9, 2021 at 7:02 AM Heikki Linnakangas wrote: > What is the worst case scenario for this algorithm? Something where the > new fast ASCII check never helps, but is as fast as possible with the > old code. For that, I added a repeating pattern of '123456789012345ä' to > the test set

Re: Fix a few typos in brin_minmax_multi.c

On 6/10/21 10:14 AM, David Rowley wrote: On Sat, 5 Jun 2021 at 16:33, David Rowley wrote: During a recent cleanup of brin_minmax_multi.c I noticed a few typos. I've attached a patch to fix these. I ended up finding a few more in mcv.c and push them. Thanks! -- Tomas Vondra EnterpriseDB:

Re: PostmasterIsAlive() in recovery (non-USE_POST_MASTER_DEATH_SIGNAL builds)

On 09/04/2021 07:01, Thomas Munro wrote: On Wed, Mar 31, 2021 at 7:02 PM Thomas Munro wrote: On Fri, Mar 12, 2021 at 7:55 PM Thomas Munro wrote: On Thu, Mar 11, 2021 at 7:34 PM Michael Paquier wrote: Wow. This probably means that we would be able to get rid of USE_POSTMASTER_DEATH_SIGNAL?

Re: Make relfile tombstone files conditional on WAL level

On 05/03/2021 00:02, Thomas Munro wrote: Hi, I'm starting a new thread for this patch that originated as a side-discussion in [1], to give it its own CF entry in the next cycle. This is a WIP with an open question to research: what could actually break if we did this? I don't see a problem.

Re: when the startup process doesn't

On Thu, Jun 10, 2021 at 03:19:20PM +0530, Nitin Jadhav wrote: > > > > + {"log_min_duration_startup_process", PGC_SUSET, > > > > LOGGING_WHEN, > > > > > > > > I think it should be PGC_SIGHUP, to allow changing it during runtime. > > > > Obviously it has no effect except during

Re: when the startup process doesn't

> > > + {"log_min_duration_startup_process", PGC_SUSET, > > > LOGGING_WHEN, > > > > > > I think it should be PGC_SIGHUP, to allow changing it during runtime. > > > Obviously it has no effect except during startup, but the change will be > > > effective if the current process

Re: Patch: Range Merge Join

Thank you for the feedback. I removed the redundant comments from the patch and added this thread to the July CF [1]. Best Regards, Thomas Mannhart [1] https://commitfest.postgresql.org/33/3160/ Am Do., 10. Juni 2021 um 05:10 Uhr schrieb David Rowley < dgrowle...@gmail.com>: > On Thu, 10 Jun

Re: "an SQL" vs. "a SQL"

> On 10 Jun 2021, at 10:54, Dave Page wrote: > .. I would perhaps suggest extending to any user-visible messages in the code. I agree, consistent language between docs and user-facing messages is important. -- Daniel Gustafsson https://vmware.com/

Re: "an SQL" vs. "a SQL"

On Thu, Jun 10, 2021 at 9:31 AM Peter Eisentraut < peter.eisentr...@enterprisedb.com> wrote: > On 10.06.21 09:26, David Rowley wrote: > > It seems we have no standard as to if we say "a SQL" or "an SQL". > > The SQL standard uses "an SQL-something". > I use both commonly, but the argument for

Re: Decoding speculative insert with toast leaks memory

On Wed, Jun 9, 2021 at 8:59 PM Alvaro Herrera wrote: > > May I suggest to use a different name in the blurt_and_lock_123() > function, so that it doesn't conflict with the one in > insert-conflict-specconflict? Thanks Renamed to blurt_and_lock(), is that fine? I haved fixed other comments and

Re: CALL versus procedures with output-only arguments

On 08.06.21 01:10, Tom Lane wrote: I wrote: Hmm, these are atop HEAD from a week or so back. The cfbot seems to think they still apply. In any case, I was about to spend some effort on the docs, so I'll post an updated version soon (hopefully today). Here is said update (rolled up into one

Re: Decoding of two-phase xacts missing from CREATE_REPLICATION_SLOT command

On Wed, Jun 9, 2021 at 9:57 PM Amit Kapila wrote: > > On Wed, Jun 9, 2021 at 4:50 PM Amit Kapila wrote: > > > > On Wed, Jun 9, 2021 at 1:53 AM Jeff Davis wrote: > > > > > > On Tue, 2021-06-08 at 17:41 +1000, Ajin Cherian wrote: > > > > Here's an updated patchset that adds back in the option for

Re: [External Sender] Re: A modest proposal vis hierarchical queries: MINUS in the column list

Tom Lane writes: >Andrew Dunstan writes: >> On 6/7/21 6:10 PM, Tom Lane wrote: >>> Note that it's not like SQL hasn't heard of projections before. >>> You can always do "SELECT a, b, d FROM subquery-yielding-a-b-c-d". >>> So the proposed syntax would save a small amount of typing, but >>> it's

Re: "an SQL" vs. "a SQL"

On 10.06.21 09:26, David Rowley wrote: It seems we have no standard as to if we say "a SQL" or "an SQL". The SQL standard uses "an SQL-something". However, we mostly use "an SQL" in the docs. ~/pg_src$ cd doc/ ~/pg_src/doc$ git grep -E "\s(a|A)\sSQL\s" | wc -l 55 ~/pg_src/doc$ git grep -E

  1   2   >