Re: Parallel INSERT (INTO ... SELECT ...)

On Fri, Feb 5, 2021 at 5:21 PM Amit Langote wrote: > > > BTW, the original query's cteList is copied into sub_action query but > not into rule_action for reasons I haven't looked very closely into, > even though we'd like to ultimately set the latter's hasModifyingCTE > to reflect the original que

There doesn't seem to be any case where PQputCopyEnd() returns 0

Hi, The following is written in the comments of PQputCopyEnd(). (snip) * Returns 1 if successful, 0 if data could not be sent (only possible * in nonblock mode), or -1 if an error occurs. (snip) The PQputCopyEnd() section of the manual (libpq.sgml) describes the following. The result

Re: Preserve attstattarget on REINDEX CONCURRENTLY

On Fri, Feb 05, 2021 at 08:22:17AM +0100, Ronan Dunklau wrote: > I'm not surprised by this answer, the good news is it's being back-patched. Yes, I have no problem with that. Until this gets fixed, the damage can be limited with an extra ALTER INDEX, that takes a ShareUpdateExclusiveLock so ther

Re: Preserve attstattarget on REINDEX CONCURRENTLY

Le vendredi 5 février 2021, 03:17:48 CET Michael Paquier a écrit : > ConstructTupleDescriptor() does not matter much, but this patch is not > acceptable to me as it touches the area of the index creation while > statistics on an index expression can only be changed with a special > flavor of ALTER

RE: Single transaction in the tablesync worker?

Hello On Friday, February 5, 2021 2:23 PM Amit Kapila > On Fri, Feb 5, 2021 at 7:09 AM Peter Smith wrote: > > > > On Thu, Feb 4, 2021 at 8:33 PM Amit Kapila > wrote: > > > > > ... > > > > > Thanks. I have fixed one of the issues reported by me earlier [1] > > > wherein the tablesync worker ca

Re: pg_replication_origin_drop API potential race condition

On Fri, Feb 5, 2021 at 9:46 AM Peter Smith wrote: > > PSA patch updated per above suggestions. > Thanks, I have tested your patch and before the patch, I was getting errors like "tuple concurrently deleted" or "cache lookup failed for replication origin with oid 1" and after the patch, I am getti

Re: logical replication worker accesses catalogs in error context callback

On Thu, Feb 4, 2021 at 5:42 PM Amit Kapila wrote: > > Thanks Amit. I verified it with gdb. I attached gdb to the logical > > replication worker. In slot_store_data's for loop, I intentionally set > > CurrentTransactionState->state = TRANS_DEFAULT, > > > > What happens if you don't change CurrentTr

Re: Support for NSS as a libpq TLS backend

On Thu, Feb 04, 2021 at 06:35:28PM +, Jacob Champion wrote: > Ah, sorry about that. Is there an extension I can use (or lack thereof) > that the CF bot will ignore, or does it scan the attachment contents? The thing is smart, but there are ways to bypass it. Here is the code: https://github.c

Re: Correct comment in StartupXLOG().

On Thu, Feb 04, 2021 at 12:58:29PM +0530, Dilip Kumar wrote: > Looks good to me. Rather than using the term "recovery state", I would just use SharedRecoveryState. This leads me to the attached. -- Michael diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c index f0

Re: Parallel INSERT (INTO ... SELECT ...)

On Fri, Feb 5, 2021 at 2:55 PM Greg Nancarrow wrote: > On Fri, Feb 5, 2021 at 4:25 PM Hou, Zhijie wrote: > > > > That is very close to what I was going to suggest, which is this: > > > > > > > > diff --git a/src/backend/rewrite/rewriteHandler.c > > > > b/src/backend/rewrite/rewriteHandler.c > > >

Re: Parallel INSERT (INTO ... SELECT ...)

On Fri, Feb 5, 2021 at 4:25 PM Hou, Zhijie wrote: > > > > > > > That is very close to what I was going to suggest, which is this: > > > > > > diff --git a/src/backend/rewrite/rewriteHandler.c > > > b/src/backend/rewrite/rewriteHandler.c > > > index 0672f497c6..3c4417af98 100644 > > > --- a/src/bac

Re: Transactions involving multiple postgres foreign servers, take 2

On Tue, Feb 2, 2021 at 5:18 PM Fujii Masao wrote: > > > > On 2021/01/27 14:08, Masahiko Sawada wrote: > > On Wed, Jan 27, 2021 at 10:29 AM Fujii Masao > > wrote: > >> > >> > >> You fixed some issues. But maybe you forgot to attach the latest patches? > > > > Yes, I've attached the updated patches

Re: [HACKERS] Custom compression methods

On Fri, Feb 5, 2021 at 3:51 AM Robert Haas wrote: > > On Thu, Feb 4, 2021 at 11:39 AM Dilip Kumar wrote: > > Yeah, actually, I thought I would avoid calling slot_getallattrs if > > none of the attributes got decompress. I agree if we call this before > > we can avoid calling slot_getattr but slo

RE: Parallel INSERT (INTO ... SELECT ...)

> > > > > > static Query * > > > rewriteRuleAction(Query *parsetree, > > > ... > > > if (sub_action_ptr) > > > + { > > > *sub_action_ptr = sub_action; > > > + rule_action->hasModifyingCTE |= > > parsetree->hasModif

RE: Parallel INSERT (INTO ... SELECT ...)

> > > > static Query * > > rewriteRuleAction(Query *parsetree, > > ... > > if (sub_action_ptr) > > + { > > *sub_action_ptr = sub_action; > > + rule_action->hasModifyingCTE |= > parsetree->hasModifyingCTE; > > +

Re: Single transaction in the tablesync worker?

On Fri, Feb 5, 2021 at 7:09 AM Peter Smith wrote: > > On Thu, Feb 4, 2021 at 8:33 PM Amit Kapila wrote: > > > ... > > > Thanks. I have fixed one of the issues reported by me earlier [1] > > wherein the tablesync worker can repeatedly fail if after dropping the > > slot there is an error while upd

Re: Parallel INSERT (INTO ... SELECT ...)

Hi, While reviewing the v14 set of patches (will send my comments shortly), I too had some reservations on how 0001 decided to go about setting hasModifyingCTE. On Fri, Feb 5, 2021 at 1:51 PM Hou, Zhijie wrote: > > > I took a look into the hasModifyingCTE bugfix recently, and found a > > > possi

RE: Parallel INSERT (INTO ... SELECT ...)

> > I took a look into the hasModifyingCTE bugfix recently, and found a > > possible bug case without the parallel insert patch. > > > > - > > drop table if exists test_data1; > > create table test_data1(a int, b int) ; insert into test_data1 select > > generate_seri

Re: shared tempfile was not removed on statement_timeout

On Sun, Jan 31, 2021 at 6:07 PM Tom Lane wrote: > Thomas Munro writes: > > So that gives a very simple back-patchable patch. > > Hmm, so is the *rest* of that function perfectly okay with being > interrupted? It looks OK to me. There aren't any CFI()s in there.

Re: Parallel INSERT (INTO ... SELECT ...)

On Fri, Feb 5, 2021 at 2:58 PM Hou, Zhijie wrote: > > Hi, > > I took a look into the hasModifyingCTE bugfix recently, > and found a possible bug case without the parallel insert patch. > > - > drop table if exists test_data1; > create table test_data1(a int, b int)

Re: Is Recovery actually paused?

On Fri, Feb 5, 2021 at 10:06 AM Dilip Kumar wrote: > > On Fri, Feb 5, 2021 at 6:22 AM Bharath Rupireddy > wrote: > > > > On Thu, Feb 4, 2021 at 7:20 PM Dilip Kumar wrote: > > > > How can we do that this is not a 1 byte flag this is enum so I don't > > > > think we can read any atomic state witho

Re: Is Recovery actually paused?

On Fri, Feb 5, 2021 at 6:22 AM Bharath Rupireddy wrote: > > On Thu, Feb 4, 2021 at 7:20 PM Dilip Kumar wrote: > > > How can we do that this is not a 1 byte flag this is enum so I don't > > > think we can read any atomic state without a spin lock here. > > > > I have fixed the other comments and t

Re: Is Recovery actually paused?

On Thu, Feb 4, 2021 at 10:19 PM Robert Haas wrote: > > On Thu, Feb 4, 2021 at 7:46 AM Dilip Kumar wrote: > > How can we do that this is not a 1 byte flag this is enum so I don't > > think we can read any atomic state without a spin lock here. > > I think this discussion of atomics is confused. Le

Re: pg_replication_origin_drop API potential race condition

On Thu, Feb 4, 2021 at 9:20 PM Amit Kapila wrote: > > On Thu, Feb 4, 2021 at 1:31 PM Peter Smith wrote: > > > > PSA a patch which I think implements what we are talking about. > > > > This doesn't seem correct to me. Have you tested that the patch > resolves the problem reported originally? Becau

RE: POC: postgres_fdw insert batching

From: Amit Langote > It appears I had missed your reply, sorry. > > > + PgFdwModifyState *fmstate = resultRelInfo->ri_FdwState ? > > + > (PgFdwModifyState *) resultRelInfo->ri_FdwState : > > + NULL; > > > > This can be written as: > > >

RE: Parallel INSERT (INTO ... SELECT ...)

Hi, I took a look into the hasModifyingCTE bugfix recently, and found a possible bug case without the parallel insert patch. - drop table if exists test_data1; create table test_data1(a int, b int) ; insert into test_data1 select generate_series(1,1000), generate_

Re: SPI: process exit in SPI_exec when table not exist. error code not return.

Thanks barwick, Is the process crash also expected, And dose anyone considered enhancing this API? 05.02.2021, 10:55, "Ian Lawrence Barwick" :2021年2月5日(金) 11:38 sasa su :Hi. When running a query with a not exist table in SPI_exec. the process exit with -1 in SPI_exec function.the erro

Re: making update/delete of inheritance trees scale better

On Thu, Feb 4, 2021 at 10:41 PM Robert Haas wrote: > On Thu, Feb 4, 2021 at 4:33 AM Amit Langote wrote: > > To be clear, the new refetch in ExecModifyTable() is to fill in the > > unchanged columns in the new tuple. If we rejigger the > > table_tuple_update() API to receive a partial tuple (esse

Re: psql tab completion for CREATE DATABASE ... LOCALE

2021年2月5日(金) 11:51 Thomas Munro : > On Fri, Feb 5, 2021 at 2:40 PM Ian Lawrence Barwick > wrote: > > Trivialest of trivial patches attached (will add to next CF). > > Thanks, pushed. > Oh, that was quick, thanks! I hadn't even got round to adding it to the CF. Regards Ian Barwick -- Enterpri

Re: SPI: process exit in SPI_exec when table not exist. error code not return.

2021年2月5日(金) 11:38 sasa su : > Hi. > > When running a query with a not exist table in SPI_exec. the process exit > with -1 in SPI_exec function. > the error code SPI_ERROR_REL_NOT_FOUND never return. > > I made a minimal reproduction code in > https://github.com/Sasasu/worker_spi_table_not_exist >

RE: Determine parallel-safety of partition relations for Inserts

Hi, I notice the comment 5) about is_parallel_possible_for_modify() seems to be inaccurate in clauses.c. * 5) the reloption parallel_dml_enabled is not set for the target table Because you have set parallel_dml_enabled to 'true' as default. { {

Re: POC: postgres_fdw insert batching

Tsunakwa-san, On Mon, Jan 25, 2021 at 1:21 PM tsunakawa.ta...@fujitsu.com wrote: > From: Amit Langote > > Yes, it can be simplified by using a local join to prevent the update of > > the foreign > > partition from being pushed to the remote server, for which my example in > > the > > previous

Re: psql tab completion for CREATE DATABASE ... LOCALE

On Fri, Feb 5, 2021 at 2:40 PM Ian Lawrence Barwick wrote: > Trivialest of trivial patches attached (will add to next CF). Thanks, pushed.

SPI: process exit in SPI_exec when table not exist. error code not return.

Hi. When running a query with a not exist table in SPI_exec. the process exit with -1 in SPI_exec function.the error code SPI_ERROR_REL_NOT_FOUND never return. I made a minimal reproduction code in https://github.com/Sasasu/worker_spi_table_not_exist The core code is:    int spi = SPI_exec("select

Re: Preserve attstattarget on REINDEX CONCURRENTLY

On Thu, Feb 04, 2021 at 03:52:44PM +0100, Ronan Dunklau wrote: >> Hmmm, that sure seems like a bug, or at least unexpected behavior (that >> I don't see mentioned in the docs). Yeah, per the rule of consistency, this classifies as a bug to me. > Please find attached a correct patch. ConstructTup

Re: POC: postgres_fdw insert batching

2021年1月22日(金) 14:50 Ian Lawrence Barwick : > Hi > > 2021年1月21日(木) 8:00 Tomas Vondra : > >> OK, pushed after a little bit of additional polishing (mostly comments). >> >> Thanks everyone! >> > > There's a minor typo in the doc's version of the ExecForeignBatchInsert() > declaration; > is: > > T

Re: POC: postgres_fdw insert batching

2021年1月22日(金) 14:50 Ian Lawrence Barwick : > Hi > > 2021年1月21日(木) 8:00 Tomas Vondra : > >> OK, pushed after a little bit of additional polishing (mostly comments). >> >> Thanks everyone! >> > > There's a minor typo in the doc's version of the ExecForeignBatchInsert() > declaration; > is: > > T

psql tab completion for CREATE DATABASE ... LOCALE

Greetings This morning I was overcome by an urge to create a database with a specific locale, and my insufficiently caffeinated brain reminded me there was a handy LOCALE option added not so long ago, but was confused by its stubborn absence from the list of tab completion options presented by psq

Re: Single transaction in the tablesync worker?

On Thu, Feb 4, 2021 at 8:33 PM Amit Kapila wrote: > ... > Thanks. I have fixed one of the issues reported by me earlier [1] > wherein the tablesync worker can repeatedly fail if after dropping the > slot there is an error while updating the SYNCDONE state in the > database. I have moved the drop

Re: Is Recovery actually paused?

On Thu, Feb 4, 2021 at 7:20 PM Dilip Kumar wrote: > > How can we do that this is not a 1 byte flag this is enum so I don't > > think we can read any atomic state without a spin lock here. > > I have fixed the other comments and the updated patch is attached. Can we just do like below so that we c

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

Hi, For Array-containselem-gin-v4.patch , one small comment: + * array_contains_elem : checks an array for a spefific element typo: specific Cheers On Thu, Feb 4, 2021 at 4:03 PM Mark Rofail wrote: > Hello Joel, > > No error, even though bigint[] isn't compatible with smallint. >> > I added a

Re: About to add WAL write/fsync statistics to pg_stat_wal view

I pgindented the patches. Regards -- Masahiro Ikeda NTT DATA CORPORATIONFrom 47f436d7e423ece33a25adebf4265eac02e575f3 Mon Sep 17 00:00:00 2001 From: Masahiro Ikeda Date: Fri, 29 Jan 2021 16:41:34 +0900 Subject: [PATCH 1/2] Add statistics related to write/sync wal records. This patch adds follow

Re: [HACKERS] Custom compression methods

On Thu, Feb 4, 2021 at 11:39 AM Dilip Kumar wrote: > Yeah, actually, I thought I would avoid calling slot_getallattrs if > none of the attributes got decompress. I agree if we call this before > we can avoid calling slot_getattr but slot_getattr > is only called for the attribute which has attlen

Re: fdatasync(2) on macOS

On Mon, Jan 18, 2021 at 4:39 PM Thomas Munro wrote: > On Sat, Jan 16, 2021 at 6:55 AM Tom Lane wrote: > > So it's not a no-op, but on the other hand it's not succeeding in getting > > bits down to the platter. I'm not inclined to dike it out, but it does > > seem problematic that we're defaultin

Re: [POC] verifying UTF-8 using SIMD instructions

On Mon, Feb 1, 2021 at 2:01 PM Heikki Linnakangas wrote: > > On 01/02/2021 19:32, John Naylor wrote: > > It makes sense to start with the ascii subset of UTF-8 for a couple > > reasons. First, ascii is very widespread in database content, > > particularly in bulk loads. Second, ascii can be valida

Re: new heapcheck contrib module

On Thu, Feb 4, 2021 at 11:10 AM Mark Dilger wrote: > I also made changes to clean up 0003 (formerly numbered 0004) "deduplice" is a typo. I'm not sure that I agree with check_each_database()'s commentary about why it doesn't make sense to optimize the resolve-the-databases step. Like, suppose I

Re: logical replication worker accesses catalogs in error context callback

Hi, On 2021-02-04 15:08:42 +0530, Bharath Rupireddy wrote: > On Thu, Feb 4, 2021 at 5:16 AM Andres Freund wrote: > > > > > About 0001, have we tried to reproduce the actual bug here which means > > > > > when the error_callback is called we should face some problem? I feel > > > > > with the corr

Re: Bug in COPY FROM backslash escaping multi-byte chars

On 04/02/2021 03:50, Kyotaro Horiguchi wrote: At Wed, 3 Feb 2021 15:46:30 +0200, Heikki Linnakangas wrote in On 03/02/2021 15:38, John Naylor wrote: On Wed, Feb 3, 2021 at 8:08 AM Heikki Linnakangas mailto:hlinn...@iki.fi>> wrote: > > Hi, > > While playing with COPY FROM refactorings i

Re: Multiple full page writes in a single checkpoint?

On Wed, Feb 3, 2021 at 08:07:16PM -0500, Bruce Momjian wrote: > > > I can try to add a hint-bit-page-write page counter, but that might > > > overflow, and then we will need a way to change the LSN anyway. > > > > That's just a question of width... > > Yeah, the hint bit counter is just delaying

Re: Support for NSS as a libpq TLS backend

On Thu, 2021-02-04 at 16:30 +0900, Michael Paquier wrote: > On Tue, Feb 02, 2021 at 08:33:35PM +, Jacob Champion wrote: > > Note that this changes the error message printed during the invalid- > > root tests, because NSS is now sending the root of the chain. So the > > server's issuer is consid

Re: Faulty HEAP_XMAX_LOCK_ONLY & HEAP_KEYS_UPDATED hintbit combination

On 2021-Feb-05, Julien Rouhaud wrote: > Thanks, that's way better, copied in v3. I'm still a bit worried about that > description though, as that flag isn't consistently set for the FOR UPDATE > case. Well, to be more precise it's maybe consistently set when the hint bits > are computed, but in

Re: Minimal logical decoding on standbys

On Thu, Feb 4, 2021 at 1:49 PM Drouvot, Bertrand wrote: > > Had to do a little change to make it compiling again (re-add the heapRel argument in _bt_delitems_delete() that was removed by commit dc43492e46c7145a476cb8ca6200fc8eefe673ef). > > Given that this attached v9 version: > > compiles success

Re: Is Recovery actually paused?

On Thu, Feb 4, 2021 at 7:46 AM Dilip Kumar wrote: > How can we do that this is not a 1 byte flag this is enum so I don't > think we can read any atomic state without a spin lock here. I think this discussion of atomics is confused. Let's talk about what atomic reads and writes mean. Imagine that

Re: [HACKERS] Custom compression methods

On Wed, Feb 3, 2021 at 2:07 AM Robert Haas wrote: While going through your comments, I need some suggestions about the one except this all other comments looks fine to me. > > It puzzles me that CompareCompressionMethodAndDecompress() calls > slot_getallattrs() just before clearing the slot. It s

Re: Faulty HEAP_XMAX_LOCK_ONLY & HEAP_KEYS_UPDATED hintbit combination

On Thu, Feb 04, 2021 at 01:22:35PM -0300, Alvaro Herrera wrote: > On 2021-Feb-05, Julien Rouhaud wrote: > > > - HEAP_KEYS_UPDATED > >This bit lives in t_infomask2. If set, indicates that the XMAX updated > > - this tuple and changed the key values, or it deleted the tuple. > > - It's set r

Re: Faulty HEAP_XMAX_LOCK_ONLY & HEAP_KEYS_UPDATED hintbit combination

On 2021-Feb-05, Julien Rouhaud wrote: > - HEAP_KEYS_UPDATED >This bit lives in t_infomask2. If set, indicates that the XMAX updated > - this tuple and changed the key values, or it deleted the tuple. > - It's set regardless of whether the XMAX is a TransactionId or a > MultiXactId. > + t

Re: Faulty HEAP_XMAX_LOCK_ONLY & HEAP_KEYS_UPDATED hintbit combination

On Thu, Feb 04, 2021 at 08:34:13PM +0530, Mahendra Singh Thalor wrote: > On Tue, 2 Feb 2021 at 09:51, Julien Rouhaud wrote: > > > > On Mon, Feb 01, 2021 at 02:00:48PM -0300, Alvaro Herrera wrote: > > > So I think that I misspoke earlier in this thread when I said this is a > > > bug, and that the

Re: Removing support for COPY FROM STDIN in protocol version 2

On 04/02/2021 17:35, Tom Lane wrote: Alvaro Herrera writes: Yeah, the changes I was thinking about are all in libpq-int.h so that's not really a problem. But one enum in libpq-fe.h renumbers values, and I think it's better to keep the old value labelled as "unused" to avoid any changes. Oh,

Re: Removing support for COPY FROM STDIN in protocol version 2

Alvaro Herrera writes: > Yeah, the changes I was thinking about are all in libpq-int.h so that's > not really a problem. But one enum in libpq-fe.h renumbers values, and > I think it's better to keep the old value labelled as "unused" to avoid > any changes. Oh, yeah, can't do that. libpq-fe.h

Re: get rid of tags in the docs?

John Naylor writes: > While looking at the proposed removal of the v2 protocol, I noticed that we > italicize some, but not all, instances of 'per se', 'pro forma', and 'ad > hoc'. I'd say these are widespread enough in formal registers of English > that they hardly need to be called out as foreig

Re: Removing support for COPY FROM STDIN in protocol version 2

On 2021-Feb-04, Tom Lane wrote: > Alvaro Herrera writes: > > On 2021-Feb-04, Heikki Linnakangas wrote: > >> Ok, here we go. > > > Are you going to bump the .so version for this? I think that should be > > done, since some functions disappear and there are struct changes. It > > is curious, tho

Re: Snapbuild woes followup

On 2021-Jan-25, Andres Freund wrote: > See attached patch... Looks good to me. I was wondering if there would be a point in using a FullTransactionId instead of an unadorned one. I don't know what's the true risk of an Xid wraparound occurring here, but it seems easier to reason about. But then

Re: Removing support for COPY FROM STDIN in protocol version 2

Alvaro Herrera writes: > On 2021-Feb-04, Heikki Linnakangas wrote: >> Ok, here we go. > Are you going to bump the .so version for this? I think that should be > done, since some functions disappear and there are struct changes. It > is curious, though, to see that exports.txt needs no changes.

Re: Is MaxHeapAttributeNumber a reasonable restriction for foreign-tables?

2021年2月4日(木) 23:45 Tom Lane : > > Amit Langote writes: > > On Thu, Feb 4, 2021 at 4:24 PM Kohei KaiGai wrote: > >> I think that MaxHeapAttributeNumber is a senseless restriction for foreign- > >> tables. How about your opinions? > > > My first reaction to this was a suspicion that the > > MaxHeap

Re: Is MaxHeapAttributeNumber a reasonable restriction for foreign-tables?

On Thu, Feb 4, 2021 at 11:45 PM Tom Lane wrote: > Amit Langote writes: > > On Thu, Feb 4, 2021 at 4:24 PM Kohei KaiGai wrote: > >> I think that MaxHeapAttributeNumber is a senseless restriction for foreign- > >> tables. How about your opinions? > > > My first reaction to this was a suspicion tha

Re: Removing support for COPY FROM STDIN in protocol version 2

On 2021-Feb-04, Heikki Linnakangas wrote: > On 04/02/2021 08:54, Michael Paquier wrote: > > On Wed, Feb 03, 2021 at 11:29:37AM -0500, Tom Lane wrote: > > > Then let's kill it dead, server and libpq both. > > > > Yeah. > > Ok, here we go. Are you going to bump the .so version for this? I think

Re: Faulty HEAP_XMAX_LOCK_ONLY & HEAP_KEYS_UPDATED hintbit combination

On Tue, 2 Feb 2021 at 09:51, Julien Rouhaud wrote: > > On Mon, Feb 01, 2021 at 02:00:48PM -0300, Alvaro Herrera wrote: > > On 2021-Jan-24, Julien Rouhaud wrote: > > > > > While working on pg14 compatibility for an extension relying on an > > > apparently > > > uncommon combination of FOR UPDATE a

Re: adding wait_start column to pg_locks

On 2021-02-03 11:23, Fujii Masao wrote: 64-bit fetches are not atomic on some platforms. So spinlock is necessary when updating "waitStart" without holding the partition lock? Also GetLockStatusData() needs spinlock when reading "waitStart"? Also it might be worth thinking to use 64-bit atomi

get rid of tags in the docs?

Hi, While looking at the proposed removal of the v2 protocol, I noticed that we italicize some, but not all, instances of 'per se', 'pro forma', and 'ad hoc'. I'd say these are widespread enough in formal registers of English that they hardly need to be called out as foreign, so I propose removing

Re: Preserve attstattarget on REINDEX CONCURRENTLY

Hmmm, that sure seems like a bug, or at least unexpected behavior (that I don't see mentioned in the docs). But the patch seems borked in some way: $ patch -p1 < ~/keep_attstattargets_on_reindex_concurrently.patch patch: Only garbage was found in the patch input. There seem to be strange

Re: Preserve attstattarget on REINDEX CONCURRENTLY

On 2/4/21 11:04 AM, Ronan Dunklau wrote: > Hello ! > > ... > > junk=# REINDEX INDEX CONCURRENTLY t1_date_trunc_idx; > REINDEX > junk=# \d+ t1_date_trunc_idx > Index "public.t1_date_trunc_idx" >Column |Type | Key? | Definit

Re: Is MaxHeapAttributeNumber a reasonable restriction for foreign-tables?

Amit Langote writes: > On Thu, Feb 4, 2021 at 4:24 PM Kohei KaiGai wrote: >> I think that MaxHeapAttributeNumber is a senseless restriction for foreign- >> tables. How about your opinions? > My first reaction to this was a suspicion that the > MaxHeapAttributeNumber limit would be too ingrained

Re: Is Recovery actually paused?

On Thu, Feb 4, 2021 at 6:16 PM Dilip Kumar wrote: > > On Thu, Feb 4, 2021 at 4:58 PM Bharath Rupireddy > wrote: > > > > On Thu, Feb 4, 2021 at 10:28 AM Dilip Kumar wrote: > > > Please find an updated patch which addresses these comments. > > > > Thanks for the patch. I tested the new function >

Re: making update/delete of inheritance trees scale better

On Thu, Feb 4, 2021 at 4:33 AM Amit Langote wrote: > So would zheap refetch a tuple using the "ctid" column in the plan's > output tuple and then use some other columns from the fetched tuple to > actually do the update? Yes. > To be clear, the new refetch in ExecModifyTable() is to fill in the

Re: Is Recovery actually paused?

On Thu, Feb 4, 2021 at 4:58 PM Bharath Rupireddy wrote: > > On Thu, Feb 4, 2021 at 10:28 AM Dilip Kumar wrote: > > Please find an updated patch which addresses these comments. > > Thanks for the patch. I tested the new function pg_get_wal_replay_pause_state: > > postgres=# select pg_get_wal_repla

RE: WIP: System Versioned Temporal Table

hi, i tested the temporal patch ( https://commitfest.postgresql.org/26/2316/ ) with the current 14devel applied ontop of ef3d461 without any conflicts. i build with no special options passed to ./configure and noticed, that the postgresql-client-13 from the debian repositories crashes with the \

Re: Is MaxHeapAttributeNumber a reasonable restriction for foreign-tables?

Hello, On Thu, Feb 4, 2021 at 4:24 PM Kohei KaiGai wrote: > I noticed that CheckAttributeNamesTypes() prevents to create a table that has > more than MaxHeapAttributeNumber (1600) columns, for foreign-table also. > IIUC, this magic number comes from length of the null-bitmap can be covered > with

Re: logical replication worker accesses catalogs in error context callback

On Thu, Feb 4, 2021 at 5:38 PM Bharath Rupireddy wrote: > > On Thu, Feb 4, 2021 at 4:00 PM Amit Kapila wrote: > > > > About 0001, have we tried to reproduce the actual bug here which means > > > > when the error_callback is called we should face some problem? I feel > > > > with the correct testc

Re: logical replication worker accesses catalogs in error context callback

On Thu, Feb 4, 2021 at 4:00 PM Amit Kapila wrote: > > > About 0001, have we tried to reproduce the actual bug here which means > > > when the error_callback is called we should face some problem? I feel > > > with the correct testcase we should hit the Assert > > > (Assert(IsTransactionState());)

Re: Is Recovery actually paused?

On Thu, Feb 4, 2021 at 4:58 PM Bharath Rupireddy wrote: > > On Thu, Feb 4, 2021 at 10:28 AM Dilip Kumar wrote: > > Please find an updated patch which addresses these comments. > > Thanks for the patch. I tested the new function pg_get_wal_replay_pause_state: > > postgres=# select pg_get_wal_repla

Re: Parallel INSERT (INTO ... SELECT ...)

On Thu, Feb 4, 2021 at 11:56 AM tsunakawa.ta...@fujitsu.com wrote: > > > > > So, the results indicate that after the patch we touch more buffers > > during planning which I think is because of accessing the partition > > information, and during execution, the patch touches fewer buffers for > > th

Re: DROP TABLE can crash the replication sync worker

On Thu, Feb 4, 2021 at 5:31 AM Peter Smith wrote: > > On Wed, Feb 3, 2021 at 11:49 PM Amit Kapila wrote: > > > > On Wed, Feb 3, 2021 at 2:53 PM Peter Smith wrote: > > > > > > Hi Hackers. > > > > > > As discovered in another thread [master] there is an *existing* bug in > > > the PG HEAD code whi

Re: Is Recovery actually paused?

On Thu, Feb 4, 2021 at 10:28 AM Dilip Kumar wrote: > Please find an updated patch which addresses these comments. Thanks for the patch. I tested the new function pg_get_wal_replay_pause_state: postgres=# select pg_get_wal_replay_pause_state(); pg_get_wal_replay_pause_state -

Re: Tid scan improvements

On Thu, 4 Feb 2021 at 10:31, David Rowley wrote: > > Thanks for looking at this. > > On Thu, 4 Feb 2021 at 10:19, Andres Freund wrote: > > Perhaps something like > > > > typedef struct TableScanTidRange TableScanTidRange; > > > > TableScanTidRange* table_scan_tid_range_start(TableScanDesc sscan,

Re: Parallel INSERT (INTO ... SELECT ...)

On Thu, Feb 4, 2021 at 6:26 AM tsunakawa.ta...@fujitsu.com wrote: > > From: Amit Kapila > > On Mon, Jan 18, 2021 at 2:40 PM Tang, Haiying > > wrote: > > > Execute EXPLAIN on Patched: > > > postgres=# explain (ANALYZE, BUFFERS, VERBOSE) insert into test_part > > select * from test_data1;

Re: logical replication worker accesses catalogs in error context callback

On Wed, Feb 3, 2021 at 4:31 PM Bharath Rupireddy wrote: > > On Thu, Jan 28, 2021 at 11:14 AM Amit Kapila wrote: > > > > On Wed, Jan 27, 2021 at 9:38 AM Bharath Rupireddy > > wrote: > > > > > > On Wed, Jan 27, 2021 at 7:48 AM Zhihong Yu wrote: > > > > > > Thanks for pointing to the changes in th

Re: Asynchronous Append on postgres_fdw nodes.

On Mon, Feb 1, 2021 at 12:06 PM Etsuro Fujita wrote: > On Tue, Nov 17, 2020 at 6:56 PM Etsuro Fujita wrote: > > * I haven't yet done anything about the issue on postgres_fdw's > > handling of concurrent data fetches by multiple ForeignScan nodes > > (below *different* Append nodes in the query) u

Re: pg_replication_origin_drop API potential race condition

On Thu, Feb 4, 2021 at 1:31 PM Peter Smith wrote: > > PSA a patch which I think implements what we are talking about. > This doesn't seem correct to me. Have you tested that the patch resolves the problem reported originally? Because the lockmode (RowExclusiveLock) you have used in the patch will

Re: Next Commitfest Manager.

On Thu, Feb 4, 2021 at 2:00 AM David Steele wrote: > On 2/3/21 3:13 PM, Stephen Frost wrote: > > Greetings, > > > > * Ibrar Ahmed (ibrar.ah...@gmail.com) wrote: > >> Anyone else already volunteers that? It is my first time so need some > >> access, if all agree. > > > > Thanks for volunteering! >

Preserve attstattarget on REINDEX CONCURRENTLY

Hello ! We encountered the following bug recently in production: when running REINDEX CONCURRENTLY on an index, the attstattarget is reset to 0. Consider the following example: junk=# \d+ t1_date_trunc_idx Index "public.t1_date_trunc_idx" Column |

Re: logical replication worker accesses catalogs in error context callback

On Thu, Feb 4, 2021 at 5:16 AM Andres Freund wrote: > > > > About 0001, have we tried to reproduce the actual bug here which means > > > > when the error_callback is called we should face some problem? I feel > > > > with the correct testcase we should hit the Assert > > > > (Assert(IsTransactionS

Re: Single transaction in the tablesync worker?

On Thu, Feb 4, 2021 at 9:55 AM Ajin Cherian wrote: > > On Wed, Feb 3, 2021 at 11:38 PM Amit Kapila wrote: > > > Thanks for the report. The problem here was that the error occurred > > when we were trying to copy the large data. Now, before fetching the > > entire data we issued a rollback that le

Re: making update/delete of inheritance trees scale better

On Wed, Jan 27, 2021 at 4:42 AM Robert Haas wrote: > On Fri, Oct 30, 2020 at 6:26 PM Heikki Linnakangas wrote: > > Yeah, you need to access the old tuple to update its t_ctid, but > > accessing it twice is still more expensive than accessing it once. Maybe > > you could optimize it somewhat by ke

parse mistake in ecpg connect string

Hi, hacker I found in function ECPGconnect, the connect string in comment is written as: /*-- * new style: * :postgresql://server[:port|:/unixsocket/path:] * [/db-name][?options] *-- */ But, the parse logical seems wrong, like: tmp = strrchr(dbname + offset, ':'); tmp2 = s

Re: pg_replication_origin_drop API potential race condition

On Thu, Feb 4, 2021 at 4:43 PM Amit Kapila wrote: > > On Thu, Feb 4, 2021 at 9:57 AM Peter Smith wrote: > > > > On Wed, Feb 3, 2021 at 11:17 PM Amit Kapila wrote: > > > > > > > > How about if we call replorigin_by_name() inside replorigin_drop after > > > acquiring the lock? Wouldn't that close