Re: Optimising compactify_tuples()

On Thu, Sep 10, 2020 at 2:34 AM David Rowley wrote: > I think you were adequately caffeinated. You're right that this is > fairly simple to do, but it looks even more simple than looping twice > of the array. I think it's just a matter of looping over the > itemidbase backwards and putting the h

Re: v13: show extended stats target in \d

On Wed, Sep 09, 2020 at 07:22:30PM -0300, Alvaro Herrera wrote: > On 2020-Sep-09, Justin Pryzby wrote: > > > As for the discussion about a separator, I think maybe a comma is enough. I > > doubt anyone is going to think that you can get a valid command by prefixing > > this by "CREATE STATISTICS"

Re: SIGQUIT handling, redux

Here's a draft patch that I think would be reasonable to back-patch. (Before v13, we'd need a bespoke SIGQUIT handler to substitute for SignalHandlerForCrashExit, but that's easy enough.) Aside from comment updates, this * uses SignalHandlerForCrashExit for SIGQUIT * renames startup_die per your

RE: Transactions involving multiple postgres foreign servers, take 2

Alexey-san, Sawada-san, cc: Fujii-san, From: Fujii Masao > But if we > implement 2PC as the improvement on FDW independently from PostgreSQL > sharding, I think that it's necessary to support other FDW. And this is our > direction, isn't it? I understand the same way as Fujii san. 2PC FDW is i

Re: extension patch of CREATE OR REPLACE TRIGGER

On Wed, Sep 9, 2020 at 11:28 PM osumi.takami...@fujitsu.com wrote: > That's a great idea. I've applied this idea to the latest patch v10. COMMENT create_trigger.sgml (typo/wording) "vise versa" -> "vice versa" BEFORE You cannot replace triggers with a different type of trigger, that means

RE: Global snapshots

Hi Andrey san, From: Andrey V. Lepikhov > > From: tsunakawa.ta...@fujitsu.com > >> While Clock-SI seems to be considered the best promising for global > >>> > Could you take a look at this patent? I'm afraid this is the Clock-SI > >>> > for MVCC. > Microsoft holds this until 2031. I couldn't

Re: please update ps display for recovery checkpoint

On Mon, Aug 31, 2020 at 03:52:44PM +0900, Michael Paquier wrote: > On Thu, Aug 20, 2020 at 05:09:05PM +0900, Michael Paquier wrote: > > That could be helpful. Wouldn't it be better to use "end-of-recovery > > checkpoint" instead? That's the common wording in the code comments. > > > > I don't se

Re: SIGQUIT handling, redux

I wrote: > Of course, this is only safe if the SIGQUIT handler is safe to be invoked > anywhere, so I did a quick survey of backend signal handlers to see if > that is true. This is straying a bit from the stated topic of this thread, but ... I did some further looking around to see whether there

RE: extension patch of CREATE OR REPLACE TRIGGER

Hello, Peter-San > > That's a great idea. I've applied this idea to the latest patch v10. > > > > COMMENT create_trigger.sgml (typo/wording) > > "vise versa" -> "vice versa" Sorry and thank you for all your pointing out. > BEFORE > You cannot replace triggers with a different type of tri

Re: Division in dynahash.c due to HASH_FFACTOR

On Tue, Sep 8, 2020 at 11:17 PM Jakub Wartak wrote: > I agree with both, I just thought it might be interesting finding as this > idiv might be (?) present in other common paths like ReadBuffer*() / > PinBuffer() (some recent discussions, maybe on NUMA boxes), not just WAL > recovery as it seem

RE: SIGQUIT handling, redux

From: Tom Lane > This is straying a bit from the stated topic of this thread, but ... > I did some further looking around to see whether there were any > unsafe signal handlers besides SIGQUIT ones. The situation is not > too awful, but I did find several issues not already mentioned > in this th

Proposals for making it easier to write correct bgworkers

Hi all As I've gained experience working on background workers, it's become increasingly clear that they're a bit too different to normal backends for many nontrivial uses. I thought I'd take a moment to note some of it here, along with some proposals for things we could potentially do to make it

Re: Resetting spilled txn statistics in pg_stat_replication

On Wed, Sep 9, 2020 at 3:20 PM Amit Kapila wrote: > > On Tue, Sep 8, 2020 at 7:02 PM Amit Kapila wrote: > > > > Comments on the latest patch: > > = > > > > Apart from the comments I gave yesterday, another thing I was > wondering is how to write some tests for this pat

Re: Proposals for making it easier to write correct bgworkers

čt 10. 9. 2020 v 5:02 odesílatel Craig Ringer napsal: > Hi all > > As I've gained experience working on background workers, it's become > increasingly clear that they're a bit too different to normal backends for > many nontrivial uses. > > I thought I'd take a moment to note some of it here, alo

Re: Fix for parallel BTree initialization bug

On Tue, Sep 08, 2020 at 06:25:03PM +, Jameson, Hunter 'James' wrote: > Hi, I ran across a small (but annoying) bug in initializing parallel BTree > scans, which causes the parallel-scan state machine to get confused. The fix > is one line; the description is a bit longer— What postgres versi

Re: please update ps display for recovery checkpoint

On Wed, Sep 09, 2020 at 09:00:50PM -0500, Justin Pryzby wrote: > What would you want the checkpointer's ps to say ? > > Normally it just says: > postgres 3468 3151 0 Aug27 ?00:20:57 postgres: checkpointer > Note that CreateCheckPoint() can also be calle

Re: extension patch of CREATE OR REPLACE TRIGGER

On Thu, Sep 10, 2020 at 12:34 PM osumi.takami...@fujitsu.com wrote: > I attached the v11 patch. The v11 patch looked OK to me. Since I have no more review comments I am marking this as "ready for committer". Kind Regards, Peter Smith. Fujitsu Australia

Re: Inconsistency in determining the timestamp of the db statfile.

On Wed, Sep 9, 2020 at 9:37 PM Fujii Masao wrote: > > On 2020/09/09 22:57, Magnus Hagander wrote: > > On Wed, Sep 9, 2020 at 3:56 PM Tomas Vondra > > wrote: > > > > On Wed, Sep 09, 2020 at 03:53:40PM +0530, Amit Kapila wrote: > > >On Wed, Sep 9, 2020

Re: PATCH: Attempt to make dbsize a bit more consistent

On 2020-09-09 12:41 a.m., gkokola...@pm.me wrote: ‐‐‐ Original Message ‐‐‐ On Tuesday, 8 September 2020 22:26, David Zhang wrote: I found the function "table_relation_size" is only used by buffer manager for "RELKIND_RELATION", "RELKIND_TOASTVALUE" and "RELKIND_MATVIEW", i.e.    

Proposal of new PostgreSQL Extension - PGSpiderExt

I would like to propose new PostgreSQL Extension - PGSpiderExt. * What is PGSpiderExt This extension makes it possible to treat multiple tables having the same schema as a single virtual table. We call this table as a multi-tenant table. If a foreign table has a key column identifying a table, y

Bug in logical decoding of in-progress transactions

Hi, There is a recent build farm failure [1] in one of the test_decoding tests as pointed by Tom Lane [2]. The failure report is shown below: @@ -71,6 +71,8 @@ data -- opening a streamed block for transaction + closing a streamed bloc

Re: Bug in logical decoding of in-progress transactions

On Thu, Sep 10, 2020 at 11:29 AM Amit Kapila wrote: > Hi, > > There is a recent build farm failure [1] in one of the test_decoding > tests as pointed by Tom Lane [2]. The failure report is shown below: > > @@ -71,6 +71,8 @@ > data > --

Re: Bug in logical decoding of in-progress transactions

On Thu, Sep 10, 2020 at 11:42 AM Dilip Kumar wrote: > > On Thu, Sep 10, 2020 at 11:29 AM Amit Kapila wrote: >> >> Hi, >> >> There is a recent build farm failure [1] in one of the test_decoding >> tests as pointed by Tom Lane [2]. The failure report is shown below: >> >> @@ -71,6 +71,8 @@ >>

Re: Inconsistency in determining the timestamp of the db statfile.

On Thu, 10 Sep 2020 at 14:24, Amit Kapila wrote: > > On Wed, Sep 9, 2020 at 9:37 PM Fujii Masao > wrote: > > > > On 2020/09/09 22:57, Magnus Hagander wrote: > > > On Wed, Sep 9, 2020 at 3:56 PM Tomas Vondra > > > wrote: > > > > > > On Wed, Sep 09, 2020 a

Re: Bug in logical decoding of in-progress transactions

On Thu, Sep 10, 2020 at 11:47 AM Amit Kapila wrote: > On Thu, Sep 10, 2020 at 11:42 AM Dilip Kumar > wrote: > > > > On Thu, Sep 10, 2020 at 11:29 AM Amit Kapila > wrote: > >> > >> Hi, > >> > >> There is a recent build farm failure [1] in one of the test_decoding > >> tests as pointed by Tom Lan

Re: Bug in logical decoding of in-progress transactions

On Thu, Sep 10, 2020 at 11:53 AM Dilip Kumar wrote: > On Thu, Sep 10, 2020 at 11:47 AM Amit Kapila > wrote: > >> On Thu, Sep 10, 2020 at 11:42 AM Dilip Kumar >> wrote: >> > >> > On Thu, Sep 10, 2020 at 11:29 AM Amit Kapila >> wrote: >> >> >> >> Hi, >> >> >> >> There is a recent build farm fail

Re: Implement UNLOGGED clause for COPY FROM

Hi. I expect I have some basic misunderstanding because IMO now this thread seems to have come full circle. Earlier, Osumi-san was rejecting the idea of using ALTER TABLE tbl SET UNLOGGED on basis that it is too time consuming for large data to switch the table modes [1]. Now the latest idea is

Re: doc review for v13

On Wed, Sep 09, 2020 at 09:37:42AM -0500, Justin Pryzby wrote: > I've added a few more. I have done an extra round of review on this patch series, and applied what looked obvious to me (basically the points already discussed upthread). Some parts applied down to 9.6 for the docs. -- Michael sig

<    1   2