Re: Added missing tab completion for alter subscription set option

On Sun, May 23, 2021 at 04:24:59PM +0530, vignesh C wrote: > /* Complete "CREATE SUBSCRIPTION ... WITH ( " */ > else if (HeadMatches("CREATE", "SUBSCRIPTION") && TailMatches("WITH", > "(")) > - COMPLETE_WITH("copy_data", "connect", "create_slot", "enabled", > -

Re: Error on pgbench logs

At Fri, 11 Jun 2021 15:23:41 +0900, Michael Paquier wrote in > On Thu, Jun 10, 2021 at 11:29:30PM +0200, Fabien COELHO wrote: > > + /* flush remaining stats */ > > + if (!logged && latency == 0.0) > > + logAgg(logfile, agg); > > You are right, this is missi

Re: Duplicate history file?

At Fri, 11 Jun 2021 10:48:32 +0800, Julien Rouhaud wrote in > 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 exa

Re: Multi-Column List Partitioning

On Fri, Jun 11, 2021 at 12:37 PM Amit Langote wrote: > I will look at other parts of the patch next week hopefully. For > now, attached is a delta patch that applies on top of your v1, which > does: > > * Simplify partition_list_bsearch() and partition_lbound_datum_cmp() > * Make qsort_partition

Re: Error on pgbench logs

On Thu, Jun 10, 2021 at 11:29:30PM +0200, Fabien COELHO wrote: > + /* flush remaining stats */ > + if (!logged && latency == 0.0) > + logAgg(logfile, agg); You are right, this is missing the final stats. Why the choice of latency here for the check? Th

Re: Question about StartLogicalReplication() error path

On Fri, 2021-06-11 at 10:13 +0530, Amit Kapila wrote: > Because sometimes clients don't have to do anything for xlog records. > One example is WAL for DDL where logical decoding didn't produce > anything for the client but later with keepalive we send the LSN of > WAL where DDL has finished and the

Re: Race condition in recovery?

At Thu, 10 Jun 2021 21:53:18 -0400, Tom Lane wrote in tgl> Please note that conchuela and jacana are still failing ... I forgot jacana's case.. It is failing for the issue the first patch should have fixed. > ==~_~===-=-===~_~== > pgsql.build/src/test/recovery/tmp_check/log/025_stuck_on_old_t

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 related

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 > > https://build

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 clien

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 A

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 a

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() > > > functi

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 didn

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 clien

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 wher

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 the

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 g

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 lazy_scan_prun

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 > > Howeve

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 he

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 eas

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 patc

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 m

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 > GetOldestN

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 ha

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 upo

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, b

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 e

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 despi

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 w

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&dt=2021-06-09%2021%3A12%3A25&stg=recovery-check > > > > > ==~_~===-=-===~_~== > > > pgsql.build/src/t

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 there'

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 t

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 src/bac

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 a

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 t

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. reg

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 function

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 t

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 h

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 occasio

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 th

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 seems

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 th

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 f

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: > > > > http

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. > > Agreed

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 st

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 apparently

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 i

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 fol

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 pg_c

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 vacrel->Oldes

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 time.

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 s

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 receive

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 o

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 copy-

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 Glob

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 inco

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 the

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 we

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 Rel

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 have

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". I

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 us

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 se

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 cl

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 pg_a

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&dt=2021-06-09%2021%3A12%3A25&stg=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 > aut

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 t

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 (thes

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. I

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 startup

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 crashes.

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 20

  1   2   >