At Thu, 4 Aug 2022 19:01:33 +0900, 荒井元成 wrote in
> Thank you for your reply.
>
> SQLServer supports Unicode Variation Selector, so I would like PostgreSQL to
> support them as well.
I studied the code a bit further, then found that simple comparison
can ignore selectors by using nondeterministi
Hi Hou-san, here are my review comments for the patch v15-0001:
==
1. Commit Message
CREATE/ALTER/DROP TABLE (*)
At first, I thought "(*)" looks like a SQL syntax element.
SUGGESTION:
CREATE/ALTER/DROP TABLE - - Note #1, Note #2
...
Note #1 – blah blah
Note #2 – yada yada
==
2. src/
On Thu, Aug 4, 2022 at 10:25 PM Thomas Munro wrote:
> FYI florican and lapwing showed:
>
> 2022-08-05 01:04:29.903 EDT [34485:5] FATAL: deduplication failed to
> add heap tid to pending posting list
> 2022-08-05 01:04:29.903 EDT [34485:6] CONTEXT: WAL redo at 0/49708D8
> for Btree/DEDUP: ninterv
On Fri, Aug 5, 2022 at 3:56 PM Peter Geoghegan wrote:
> On Thu, Jun 9, 2022 at 11:20 AM Robert Haas wrote:
> > I think I'd feel more comfortable if you wrote the patch, if that's
> > possible.
>
> Okay, pushed a fix just now.
FYI florican and lapwing showed:
2022-08-05 01:04:29.903 EDT [34485:
On Fri, Aug 5, 2022 at 2:59 AM Andres Freund wrote:
>
> Hi,
>
> On 2022-08-03 16:45:23 +0530, Dilip Kumar wrote:
> > Another version of the patch which closes the smgr at the end using
> > smgrcloserellocator() and I have also added a commit message.
>
> What's the motivation behind the explicit c
On Fri, Aug 5, 2022 at 5:36 AM Andres Freund wrote:
>
> Hi,
>
> On August 4, 2022 4:20:16 PM PDT, Tom Lane wrote:
> >Yeah, the assumption that P_NEW would automatically match the source block
> >was making me itchy too. An explicit test-and-elog seems worth the
> >cycles.
>
> Is there a good rea
On Thu, Aug 4, 2022 at 8:41 PM Tom Lane wrote:
>
> John Naylor writes:
> > RepOriginId is a typedef for uint16, so this can't print the wrong
answer,
> > but it is inconsistent with other uses. So it seems we don't need to
> > backpatch this one?
>
> Um ... if it's int16, then it can't be an OID
At Thu, 4 Aug 2022 10:56:45 +0200, Marco Slot wrote in
> On Wed, Aug 11, 2021 at 1:37 PM Amit Kapila wrote:
> > I think it is and the context is generated via
> > output_plugin_error_callback. Is this reproducible for you and if so,
> > can you share a test case or some steps to reproduce this?
On Thu, Aug 4, 2022 at 6:31 PM Masahiko Sawada wrote:
>
> On Tue, Aug 2, 2022 at 8:59 PM Amit Kapila wrote:
> >
> > On Tue, Jul 26, 2022 at 9:07 AM Amit Kapila wrote:
> >
> > Let me try to summarize the discussion so that it is easier for others
> > to follow. The work in this thread is to avoid
On Fri, Aug 5, 2022 at 4:31 AM Tom Lane wrote:
>
> I wrote:
> > While I'm at it, I would like to strenuously object to the current
> > framing of CreateAndCopyRelationData as a general-purpose copying
> > mechanism.
>
> And while I'm piling on, how is this bit in RelationCopyStorageUsingBuffer
> n
On Fri, Aug 5, 2022 at 5:15 AM Nathan Bossart
wrote:
>
> On Thu, Aug 04, 2022 at 02:58:14PM +0700, John Naylor wrote:
> > Were you considering adding the new function to simd.h now that that's
> > committed? It's a bit up in the air what should go in there, but this
new
> > function is low-level a
On Thu, Jun 9, 2022 at 11:20 AM Robert Haas wrote:
> I think I'd feel more comfortable if you wrote the patch, if that's possible.
Okay, pushed a fix just now.
Thanks
--
Peter Geoghegan
On Thu, Aug 4, 2022 at 7:13 PM Tom Lane wrote:
>
> Masahiko Sawada writes:
> > Yes. I've attached patches for backbranches.
>
> FWIW, I'd recommend waiting till after next week's wrap before
> pushing these. While I'm definitely in favor of doing this,
> the odds of introducing a bug are nonzero
At Tue, 26 Apr 2022 08:26:59 +0200, Laurenz Albe
wrote in
> While this may mitigate the problem, I don't think it will deal with
> all the cases which could cause a transaction to end up committed locally,
> but not on the synchronous standby. I think that only using the full
> power of two-pha
On Thu, Aug 4, 2022 at 7:11 PM Tom Lane wrote:
> [pile^2] Also, what is the rationale for locking the target buffer
> but not the source buffer? That seems pretty hard to justify from
> here, even granting the assumption that we don't expect any other
> processes to be interested in these buffer
On Thu, Aug 4, 2022 at 7:01 PM Tom Lane wrote:
> And while I'm piling on, how is this bit in RelationCopyStorageUsingBuffer
> not completely broken?
Ouch. That's pretty bad.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Thu, Aug 4, 2022 at 6:02 PM Tom Lane wrote:
> Robert Haas writes:
> > I have reviewed this patch and I don't see a problem with it. However,
> > it would be nice if Andres or someone else who understands this area
> > well (Tom? Thomas?) would also review it, because I also reviewed
> > what's
On Thu, Aug 4, 2022 5:49 PM shiy.f...@fujitsu.com wrote:
>
> On Thu, Aug 4, 2022 2:28 PM Masahiko Sawada
> wrote:
> >
> > On Thu, Aug 4, 2022 at 10:37 AM Amit Kapila
> > wrote:
> > >
> > > On Wed, Aug 3, 2022 at 10:21 AM Amit Kapila
>
> > wrote:
> > > >
> > > > Pushed this one and now I'll loo
On Tue, Aug 02, 2022 at 07:32:54PM +0900, Michael Paquier wrote:
> As a quick update from my side, I intend to look and apply 0001~0003
> (not double-checked yet) shortly.
And a couple of days later, these look fine so done as of 47ab1ac and
718fe0a. 0002 and 0003 have been merged together.
--
Mi
On Mon, Jul 11, 2022 at 12:30 PM Alvaro Herrera wrote:
> $ git blame configure
> fatal: could not open object name list: .git-blame-ignore-revs
>
> My first workaround was to add empty .git-blame-ignore-revs in all
> checkouts. This was moderately ok (shrug), until after a recent `tig`
> upgrade
Andres Freund writes:
> Is there a good reason to rely on P_NEW at all? Both from an efficiency
> and robustness POV it seems like it'd be better to use smgrextend to
> bulk extend just after smgrcreate() and then fill s_b u using RBM_ZERO
> (or whatever it is called). That bulk smgrextend would
Andres Freund writes:
> On August 4, 2022 4:11:13 PM PDT, Tom Lane wrote:
>> [pile^2] Also, what is the rationale for locking the target buffer
>> but not the source buffer? That seems pretty hard to justify from
>> here, even granting the assumption that we don't expect any other
>> processes
Hi,
On August 4, 2022 4:20:16 PM PDT, Tom Lane wrote:
>Yeah, the assumption that P_NEW would automatically match the source block
>was making me itchy too. An explicit test-and-elog seems worth the
>cycles.
Is there a good reason to rely on P_NEW at all? Both from an efficiency and
robustness
Hi,
On August 4, 2022 4:11:13 PM PDT, Tom Lane wrote:
>I wrote:
>> And while I'm piling on, how is this bit in RelationCopyStorageUsingBuffer
>> not completely broken?
>
>[pile^2] Also, what is the rationale for locking the target buffer
>but not the source buffer? That seems pretty hard to ju
Andres Freund writes:
> On 2022-08-04 19:01:06 -0400, Tom Lane wrote:
>> (This seems worth fixing before beta3, as it looks like a rather
>> nasty data corruption hazard.)
> Ugh, yes. And even with this fixed I think this should grow at least an
> assertion that the block numbers match, probably
Andres Freund writes:
> On 2022-08-04 18:05:25 -0400, Tom Lane wrote:
>> In any case, DROP DATABASE is far from the only place with a problem.
> What other place has a database corrupting potential of this magnitude just
> because interrupts are accepted? We throw valid s_b contents away and the
Hi,
On 2022-08-04 19:01:06 -0400, Tom Lane wrote:
> And while I'm piling on, how is this bit in RelationCopyStorageUsingBuffer
> not completely broken?
>
> /* Read block from source relation. */
> srcBuf = ReadBufferWithoutRelcache(src->rd_locator, forkNum, blkno,
>
I wrote:
> And while I'm piling on, how is this bit in RelationCopyStorageUsingBuffer
> not completely broken?
[pile^2] Also, what is the rationale for locking the target buffer
but not the source buffer? That seems pretty hard to justify from
here, even granting the assumption that we don't exp
I wrote:
> While I'm at it, I would like to strenuously object to the current
> framing of CreateAndCopyRelationData as a general-purpose copying
> mechanism.
And while I'm piling on, how is this bit in RelationCopyStorageUsingBuffer
not completely broken?
/* Read block from source relati
Hi,
On 2022-08-04 18:05:25 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Yea. I think at the very least we need to start holding interrupts before
> > the
> > DropDatabaseBuffers() and do so until commit. That's probably best done by
> > doing the transaction commit inside dropdb.
>
> We'v
On Fri, 5 Aug 2022 at 01:20, Phil Florent wrote:
> with fakedata as (
>select 'hello' word
>union all
>select 'world' word
> )
> select *
> from (
>select word, count(*) over (partition by word) nb from fakedata
> ) t where nb = 1;
>
On Thu, Aug 04, 2022 at 06:02:50PM -0400, Tom Lane wrote:
> The "invalidation" comment bothered me for awhile, but I think it's
> fine: we know that no other backend can connect to the source DB
> because we have it locked,
About that - is it any problem that the currently-connected db can be used
On Thu, Aug 04, 2022 at 02:58:14PM +0700, John Naylor wrote:
> Were you considering adding the new function to simd.h now that that's
> committed? It's a bit up in the air what should go in there, but this new
> function is low-level and generic enough to be a candidate...
I don't have a strong op
Andres Freund writes:
> Yea. I think at the very least we need to start holding interrupts before the
> DropDatabaseBuffers() and do so until commit. That's probably best done by
> doing the transaction commit inside dropdb.
We've talked before about ignoring interrupts across commit, but
I find
Robert Haas writes:
> I have reviewed this patch and I don't see a problem with it. However,
> it would be nice if Andres or someone else who understands this area
> well (Tom? Thomas?) would also review it, because I also reviewed
> what's in the tree now and that turns out to be buggy, which lea
Hi,
On 2022-08-04 11:19:28 -0700, Jacob Champion wrote:
> My intention had not quite been for this to be a referendum on the
> decision for every patch -- we can do that if it helps, but I don't
> think we necessarily have to have unanimity on the bucketing for every
> patch in order for the new s
Hi,
On 2022-08-04 16:38:35 +0530, Dilip Kumar wrote:
> So basically, from this we can say it is completely a problem with
> drop databases, I mean I can produce any behavior by interrupting drop
> database
> 1. If we created some tables/inserted data and the drop database got
> cancelled, it might
Hi,
On 2022-08-04 16:07:01 -0400, Robert Haas wrote:
> On Wed, Aug 3, 2022 at 7:15 AM Dilip Kumar wrote:
> > Another version of the patch which closes the smgr at the end using
> > smgrcloserellocator() and I have also added a commit message.
>
> I have reviewed this patch and I don't see a prob
Hi,
On 2022-08-03 16:45:23 +0530, Dilip Kumar wrote:
> Another version of the patch which closes the smgr at the end using
> smgrcloserellocator() and I have also added a commit message.
What's the motivation behind the explicit close?
> @@ -258,8 +258,8 @@ ScanSourceDatabasePgClass(Oid tbid, O
Justin Pryzby writes:
> On Thu, Aug 04, 2022 at 04:07:01PM -0400, Robert Haas wrote:
>> I'm inclined to hold off on committing this until next week, not only
> +1
+1 ... there are some other v15 open items that I don't think we'll
see fixed for beta3, either.
regards, to
On Thu, Aug 04, 2022 at 04:07:01PM -0400, Robert Haas wrote:
> I'm inclined to hold off on committing this until next week, not only
+1
I don't see any reason to hurry to fix problems that occur when DROP DATABASE
is interrupted.
Sorry to beat up your patches so much and for such crappy test cas
Hi hackers!
I've made a rebase according to Andres and Aleksander comments.
Rebased branch resides here:
https://github.com/postgrespro/postgres/tree/toasterapi_clean
I've decided to leave only the first 2 patches for review and send less
significant
changes after the main patch will be straighte
On Wed, Aug 3, 2022 at 7:15 AM Dilip Kumar wrote:
> Another version of the patch which closes the smgr at the end using
> smgrcloserellocator() and I have also added a commit message.
I have reviewed this patch and I don't see a problem with it. However,
it would be nice if Andres or someone else
On Thu, Aug 4, 2022 at 12:31 PM Robert Haas wrote:
> > What about autoanalyze?
>
> What about it?
It has a tendency to consume an XID, here or there, quite
unpredictably. I've noticed that this often involves an analyze of
pg_statistic. Have you accounted for that?
You said upthread that you don
On Thu, Aug 4, 2022 at 3:10 PM Tom Lane wrote:
> Robert Haas writes:
> > I think the most practical alternative is to put this file back to the
> > way it was before I started tinkering with it, and revisit this issue
> > after the release.
>
> Yeah, that seems like the right thing. We are runni
On Thu, Aug 4, 2022 at 3:23 PM Peter Geoghegan wrote:
> On Thu, Aug 4, 2022 at 12:15 PM Robert Haas wrote:
> > Given that the old cluster is suffering no new write
> > transactions, there's probably exactly two values that are legal: one
> > being the value from the old cluster, which we know, an
On Thu, Aug 4, 2022 at 12:15 PM Robert Haas wrote:
> Given that the old cluster is suffering no new write
> transactions, there's probably exactly two values that are legal: one
> being the value from the old cluster, which we know, and the other
> being whatever a vacuum of that table would produ
On Thu, Aug 4, 2022 at 12:59 PM Andres Freund wrote:
> Why you think it's better to not have the test than to have a very limited
> amount of fuzziness (by using the next xid as an upper limit). What's the bug
> that will reliably pass the nextxid fuzzy comparison, but not an exact
> comparison?
Robert Haas writes:
> I think the most practical alternative is to put this file back to the
> way it was before I started tinkering with it, and revisit this issue
> after the release.
Yeah, that seems like the right thing. We are running too low on time
to have any confidence that a modified v
On Thu, Aug 4, 2022 at 1:49 PM Tom Lane wrote:
> Note that the patch you proposed at [1] will not fix anything.
> It turns off autovac in the new node, but the buildfarm failures
> we've seen appear to be due to autovac running on the old node.
> (I believe that autovac in the new node is *also* a
On Wed, Aug 3, 2022 at 2:05 PM Matthias van de Meent
wrote:
> On Wed, 3 Aug 2022 at 20:04, Jacob Champion wrote:
> > Is that enough, or should we do more?
>
> "The CF Checklist" seems to refer to only the page that is (or seems
> to be) intended for the CFM only. We should probably also update th
Hi Andres,
My intention had not quite been for this to be a referendum on the
decision for every patch -- we can do that if it helps, but I don't
think we necessarily have to have unanimity on the bucketing for every
patch in order for the new state to be useful.
On 8/3/22 12:46, Andres Freund wr
On Thu, Aug 4, 2022 at 11:07 AM Tom Lane wrote:
> How much will that add to the test's runtime? I could get behind this
> idea if it's not exorbitantly expensive.
I'm not sure offhand, but I suspect it wouldn't be too bad.
--
Peter Geoghegan
Peter Geoghegan writes:
> Perhaps amcheck's verify_heapam() function can be used here. What
> could be better than exhaustively verifying that the relfrozenxid (and
> relminmxid) invariants hold for every single tuple in the table?
How much will that add to the test's runtime? I could get behind
On Thu, Aug 4, 2022 at 9:44 AM Robert Haas wrote:
> But if you don't want to do that, and you also don't want to have
> random failures, the only alternatives are weakening the check and
> removing the test. It's kind of hard to say which is better, but I'm
> inclined to think that if we just weak
Robert Haas writes:
> IMHO it's 100% clear how to make it robust. If you want to check that
> two values are the same, you can't let one of them be overwritten by
> an unrelated event in the middle of the check. There are many specific
> things we could do here, a few of which I proposed in my pre
On Fri, 2022-07-29 at 11:53 +0900, Kyotaro Horiguchi wrote:
>
> That makes the memorycontext-tree structure unstable because
> CacheMemoryContext can be created on-the-fly.
>
> Honestly I don't like to call CreateCacheMemoryContext in the two
> functions on-the-fly. Since every process that call
Hi,
On 2022-08-04 12:43:49 -0400, Robert Haas wrote:
> On Thu, Aug 4, 2022 at 10:26 AM Tom Lane wrote:
> > Robert Haas writes:
> > > 100 << 2^32, so it's not terrible, but I'm honestly coming around to
> > > the view that we ought to just nuke this test case.
> >
> > I'd hesitated to suggest tha
On Thu, Aug 4, 2022 at 10:26 AM Tom Lane wrote:
> Robert Haas writes:
> > 100 << 2^32, so it's not terrible, but I'm honestly coming around to
> > the view that we ought to just nuke this test case.
>
> I'd hesitated to suggest that, but I think that's a fine solution.
> Especially since we can a
> On 18 Jul 2022, at 22:55, Robert Haas wrote:
>
> On Thu, Jun 23, 2022 at 5:49 AM Jakub Wartak wrote:
>> Cool. As for GUC I'm afraid there's going to be resistance of adding yet
>> another GUC (to avoid many knobs). Ideally it would be nice if we had some
>> advanced/deep/hidden parameters
On Thu, 04 Aug 2022 at 19:29, Daniel Verite wrote:
> Japin Li wrote:
>
>> However, if the database is in production, we cannot go into single-user
>> mode, should we provide an option to change this behavior on the fly?
>
> It already exists, through PGOPTIONS, which appears to work
> for
> On 4 Aug 2022, at 00:44, Junwang Zhao wrote:
> Attachment is a patch with the "just" removed.
I think this is a change for better, so I've pushed it. Thanks for the
contribution!
--
Daniel Gustafsson https://vmware.com/
Robert Haas writes:
> 100 << 2^32, so it's not terrible, but I'm honestly coming around to
> the view that we ought to just nuke this test case.
I'd hesitated to suggest that, but I think that's a fine solution.
Especially since we can always put it back in later if we think
of a more robust way.
On Thu, Aug 04, 2022 at 06:32:38AM -0400, David Steele wrote:
> On 8/4/22 04:06, Kyotaro Horiguchi wrote:
> >At Wed, 3 Aug 2022 23:24:56 -0700, Noah Misch wrote in
> I think in this case a HINT might be sufficient to at least keep people
> from
> wasting time tracking down a problem t
"Jonathan S. Katz" writes:
> On 8/3/22 4:19 PM, Tom Lane wrote:
>> I like the idea of txid_current(), but we have no comparable
>> function for mxid do we? While you could get both numbers from
>> pg_control_checkpoint(), I doubt that's sufficiently up-to-date.
> ...unless we force a checkpoint
On Thu, Aug 4, 2022 at 10:02 AM Jonathan S. Katz wrote:
> Attached is the "band-aid / sloppy" version of the patch. Given from the
> test examples I kept seeing deltas over 100 for relfrozenxid, I chose
> 1000. The mxid delta was less, but I kept it at 1000 for consistency
> (and because I hope th
On Wed, Aug 3, 2022 at 7:19 PM Tom Lane wrote:
> "Jonathan S. Katz" writes:
> > I did rule out wanting to do the "xid + $X" check after reviewing some
> > of the output. I think that both $X could end up varying, and it really
> > feels like a bandaid.
>
> It is that. I wouldn't feel comfortable
On 8/3/22 4:19 PM, Tom Lane wrote:
"Jonathan S. Katz" writes:
I did rule out wanting to do the "xid + $X" check after reviewing some
of the output. I think that both $X could end up varying, and it really
feels like a bandaid.
It is that. I wouldn't feel comfortable with $X less than 100 or
Masahiko Sawada writes:
> Yes. I've attached patches for backbranches.
FWIW, I'd recommend waiting till after next week's wrap before
pushing these. While I'm definitely in favor of doing this,
the odds of introducing a bug are nonzero, so right before a
release deadline doesn't seem like a good
John Naylor writes:
> On Tue, Aug 2, 2022 at 1:11 AM Justin Pryzby wrote:
> ereport(ERROR,
> (errcode(ERRCODE_OBJECT_IN_USE),
> - errmsg("could not drop replication origin with OID %d, in use by PID %d",
> + errmsg("could not drop replication origin with OID %u, in use by PID %d",
> RepOrigi
On Thu, Aug 04, 2022 at 01:19:59PM +, Phil Florent wrote:
> A DSS developer from my company, Julien Roze, reported me an error I cannot
> explained. Is it a new behavior or a bug ?
>
> Original query is much more complicated but here is a simplified test case
> with postgresql 14 and 15 beta
On Thu, Aug 4, 2022 at 9:56 PM Alvaro Herrera wrote:
> Another point for backpatch: EnableDisableTrigger() changes API, which
> is potentially not good. In backbranches I'll keep the function
> unchanged and add another function with the added argument,
> EnableDisableTriggerNew().
+1
> So exte
Hi,
A DSS developer from my company, Julien Roze, reported me an error I cannot
explained. Is it a new behavior or a bug ?
Original query is much more complicated but here is a simplified test case with
postgresql 14 and 15 beta 2 on Debian 11, packages from pgdg :
Ver Cluster Port Status Owne
On Wed, Aug 3, 2022 at 4:14 PM Andres Freund wrote:
> I don't think this scenario would fundamentally change - we already keep the
> set of subxids in backend local memory (e.g. either a dedicated
> TransactionStateData or an element in ->childXids) and in the locking table
> (via XactLockTableIns
On Tue, Aug 2, 2022 at 8:59 PM Amit Kapila wrote:
>
> On Tue, Jul 26, 2022 at 9:07 AM Amit Kapila wrote:
> >
> > On Tue, Jul 26, 2022 at 7:13 AM Jonathan S. Katz
> > wrote:
> > >
> > > Thanks for the example. I agree that it is fairly simple to reproduce.
> > >
> > > I understand that "copy_dat
Another point for backpatch: EnableDisableTrigger() changes API, which
is potentially not good. In backbranches I'll keep the function
unchanged and add another function with the added argument,
EnableDisableTriggerNew().
So extensions that want to be compatible with both old and current
versions
On Wed, 3 Aug 2022 at 20:18, Andres Freund wrote:
> On 2022-08-01 17:42:49 +0100, Simon Riggs wrote:
> > The reason for the slowdown is clear: when we overflow we check every
> > xid against subtrans, producing a large stream of lookups. Some
> > previous hackers have tried to speed up subtrans -
On Sat, Jul 30, 2022 at 1:59 AM Robert Haas wrote:
> One solution to all this is to do as Dilip proposes here: for system
> relations, keep assigning the OID as the initial relfilenumber.
> Actually, we really only need to do this for pg_largeobject; all the
> other relfilenumber values could be
Japin Li wrote:
> However, if the database is in production, we cannot go into single-user
> mode, should we provide an option to change this behavior on the fly?
It already exists, through PGOPTIONS, which appears to work
for local_preload_libraries, in a quick test.
That is, you can lo
On Thursday, July 28, 2022 5:17 PM Peter Smith wrote:
> Here are some review comments for the HEAD_v7-0001 patch:
>
> ==
>
> 1.
>
> I have a fundamental question about this patch.
>
> IIUC the purpose of this patch is to ensure that (when
> publish_via_root = true) the copy of the partiti
Hi,
It appears that config.sgml and pg_settings have not been updated, even
though a new subcategory was added in 249d649. a55a984 may have been
missed in the cleaning.
--
Category is 'CONNECTIONS AND AUTHENTICATION' and subcategory is
'Connection Settings' at config.sgml.
Category is 'CONNEC
On Thu, Aug 4, 2022 at 9:41 AM Dilip Kumar wrote:
>
> On Thu, Aug 4, 2022 at 12:18 AM Justin Pryzby wrote:
> >
> > On Wed, Aug 03, 2022 at 11:26:43AM -0700, Andres Freund wrote:
> > > Hm. This looks more like an issue of DROP DATABASE not being
> > > interruptible. I
> > > suspect this isn't act
On Thu, Aug 4, 2022 at 4:38 PM Michael Paquier wrote:
> On Tue, Aug 02, 2022 at 07:25:49PM +0900, Michael Paquier wrote:
> > These declarations are linked to comments with their file paths, so
> > making that automated looks rather complicated to me. I have looked
> > at the surroundings without
On 8/4/22 04:06, Kyotaro Horiguchi wrote:
At Wed, 3 Aug 2022 23:24:56 -0700, Noah Misch wrote in
I think in this case a HINT might be sufficient to at least keep people from
wasting time tracking down a problem that has already been fixed.
Here's a patch to add that HINT. I figure it's bette
On Tue, Aug 2, 2022 at 1:11 AM Justin Pryzby wrote:
>
> On Mon, Aug 01, 2022 at 08:04:54PM +0200, Erik Rijkers wrote:
> > Recent typos...
>
> LGTM, thanks.
>
> Here are some others I've been sitting on, mostly in .c files.
I pushed Robert's suggestion, then pushed the rest of Erik's changes and
t
Thank you for your reply.
SQLServer supports Unicode Variation Selector, so I would like PostgreSQL to
support them as well.
Regards.
--
Motonari Arai
-Original Message-
From: Kyotaro Horiguchi
Sent: Thursday, August 4, 2022 5:24 PM
To: n2...@ndensan.co.jp
Cc: thomas.mu...@gmail.com; t
On Mon, Jul 25, 2022 at 2:40 PM Michael Paquier wrote:
>
> On Mon, Jul 25, 2022 at 12:19:40PM +0530, Bharath Rupireddy wrote:
> > Thanks a lot Cary for reviewing. It will be great if you can add
> > yourself as a reviewer and set the status accordingly in the CF entry
> > here - https://commitfest
On Thu, Aug 4, 2022 2:28 PM Masahiko Sawada wrote:
>
> On Thu, Aug 4, 2022 at 10:37 AM Amit Kapila
> wrote:
> >
> > On Wed, Aug 3, 2022 at 10:21 AM Amit Kapila
> wrote:
> > >
> > > Pushed this one and now I'll look at your other patch.
> > >
> >
> > I have pushed the second patch as well after
Hi Tom,
On Wed, Jul 27, 2022 at 6:39 PM Tom Lane wrote:
> David Geier writes:
> > We tracked down the root cause of this slowdown to lock contention in
> > 'get_relation_info()'. The index lock of every single index of every
> single
> > table used in that query is acquired. We attempted a fix
On Wed, Aug 11, 2021 at 1:37 PM Amit Kapila wrote:
> I think it is and the context is generated via
> output_plugin_error_callback. Is this reproducible for you and if so,
> can you share a test case or some steps to reproduce this? Does this
> work and suddenly start giving errors or it happens t
On Thu, Aug 4, 2022 at 2:04 PM Thomas Munro wrote:
> I noticed that this says:
>
> [01:01:45.657] sqlda.pgc: In function 'dump_sqlda':
> [01:01:45.657] sqlda.pgc:45:33: warning: format '%d' expects argument
> of type 'int', but argument 3 has type 'long long int' [-Wformat=]
> [01:01:45.657] 45 |
On Tue, Aug 02, 2022 at 07:25:49PM +0900, Michael Paquier wrote:
> These declarations are linked to comments with their file paths, so
> making that automated looks rather complicated to me. I have looked
> at the surroundings without noticing anything obvious, so what you
> have caught here sound
On Thu, Aug 4, 2022 at 1:42 PM Bharath Rupireddy
wrote:
>
> On Mon, Jul 25, 2022 at 4:20 PM Andrey Borodin wrote:
> >
> > > 25 июля 2022 г., в 14:29, Bharath Rupireddy
> > > написал(а):
> > >
> > > Hm, after thinking for a while, I tend to agree with the above
> > > approach - meaning, query ca
At Wed, 3 Aug 2022 20:12:53 +0900, 荒井元成 wrote in
> Thank you for your reply.
>
> About 60,000 characters are registered in the IPAmj Mincho font designated by
> the national specifications.
> It should be able to handle all characters.
Yeah, it is one of that fonts. But I didn't know that MS-
On Mon, Jul 25, 2022 at 4:20 PM Andrey Borodin wrote:
>
> > 25 июля 2022 г., в 14:29, Bharath Rupireddy
> > написал(а):
> >
> > Hm, after thinking for a while, I tend to agree with the above
> > approach - meaning, query cancel interrupt processing can completely
> > be disabled in SyncRepWaitFo
On Wed, Aug 3, 2022 at 11:41 PM Robert Haas wrote:
>
> I think that it's talking about this (documented) syntax:
>
> ALTER ROUTINE name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ]
> [ NO ] DEPENDS ON EXTENSION extension_name
>
> So the change from "depends" to "depend" here is incorrec
At Wed, 3 Aug 2022 23:24:56 -0700, Noah Misch wrote in
> > > I think in this case a HINT might be sufficient to at least keep people
> > > from
> > > wasting time tracking down a problem that has already been fixed.
>
> Here's a patch to add that HINT. I figure it's better to do this before ne
On Thu, Aug 4, 2022 at 11:30 AM Kyotaro Horiguchi
wrote:
> At Wed, 3 Aug 2022 18:16:33 +0530, Ashutosh Sharma
> wrote in
> > Following comment in RemoveNonParentXlogFiles() says that we are trying
> to
> > remove any WAL file whose segment number is >= the segment number of the
> > first WAL fil
Hi,
On Wed, Aug 3, 2022 at 12:00 AM Andres Freund wrote:
> On 2022-08-02 12:05:55 +0900, Amit Langote wrote:
> > On Tue, Aug 2, 2022 at 9:39 AM Andres Freund wrote:
> > > On 2022-07-27 17:01:13 +0900, Amit Langote wrote:
> > > > Here's an updated version of the patch, with mostly cosmetic change
On Thu, Aug 4, 2022 at 3:25 AM Nathan Bossart
wrote:
> Here is a new patch set without the annotation.
Were you considering adding the new function to simd.h now that that's
committed? It's a bit up in the air what should go in there, but this new
function is low-level and generic enough to be a
1 - 100 of 101 matches
Mail list logo
