Re: pg_waldump error message fix

On Mon, Dec 14, 2020 at 11:34:51AM +0900, Kyotaro Horiguchi wrote: > Apart from this issue, while checking that, I noticed that if server > starts having WALs from a server of a different systemid, the server > stops with obscure messages. Wouldn't it be better to discuss that on a separate thread

Re: REINDEX backend filtering

On Thu, Dec 03, 2020 at 05:31:43PM +0800, Julien Rouhaud wrote: > Now that we have the infrastructure to track indexes that might be corrupted > due to changes in collation libraries, I think it would be a good idea to > offer > an easy way for users to reindex all indexes that might be corrupted.

Re: Asynchronous Append on postgres_fdw nodes.

At Sat, 12 Dec 2020 18:25:57 +0900, Etsuro Fujita wrote in > On Fri, Nov 20, 2020 at 3:51 PM Kyotaro Horiguchi > wrote: > > At Tue, 17 Nov 2020 18:56:02 +0900, Etsuro Fujita > > wrote in > > > * In Robert's patch [1] (and Horiguchi-san's, which was created based > > > on Robert's), ExecAppend

RE: pg_ctl.exe file deleted automatically

We can confirm that the file is not deleted by antivirus. When windows is shutdown abruptly, we are noticing this issue. We will post this query in pgsql-general and check if someone else has encountered the same issue. Regards, Joel From: Craig Ringer Sent: 03 December 2020 19:14 To: Joel Mari

Re: Rethinking plpgsql's assignment implementation

ne 13. 12. 2020 v 22:41 odesílatel Tom Lane napsal: > I wrote: > > So my idea here is to add a parsing-mode option to raw_parser(), > > which would be an enum with values like "normal SQL statement", > > "expression only", "type name", "plpgsql assignment statement". > > Here's a fleshed-out patc

Re: MultiXact\SLRU buffers configuration

> 13 дек. 2020 г., в 22:24, Andrey Borodin написал(а): > > > >> 13 дек. 2020 г., в 14:17, Gilles Darold написал(а): >> >> I've done more review on these patches. > > Thanks, Gilles! I'll incorporate all your fixes to patchset. PFA patches. Also, I've noted that patch "Add conditional vari

Re: Fail Fast In CTAS/CMV If Relation Already Exists To Avoid Unnecessary Rewrite, Planning Costs

On Mon, Dec 14, 2020 at 03:15:12PM +0900, Michael Paquier wrote: > Please note that this case fails with your patch, but the presence of > IF NOT EXISTS should ensure that we don't fail and issue a NOTICE > instead, no? Taking this case specifically (OK, I am playing with > the rules a bit to ins

Re: Fail Fast In CTAS/CMV If Relation Already Exists To Avoid Unnecessary Rewrite, Planning Costs

On Fri, Dec 11, 2020 at 03:03:46PM +0530, Bharath Rupireddy wrote: > I may not have got your above scenario correctly(it will be good if > you can provide the use case in case I want to check something there). It is possible to have DML queries in WITH clauses, as long as they use RETURNING to fee

Re: [Patch] ALTER SYSTEM READ ONLY

On Thu, Dec 10, 2020 at 6:04 AM Andres Freund wrote: > > Hi, > > On 2020-12-09 16:13:06 -0500, Robert Haas wrote: > > That's not good. On a typical busy system, a system is going to be in > > the middle of a checkpoint most of the time, and the checkpoint will > > take a long time to finish - mayb

Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit

On Mon, Dec 14, 2020 at 9:38 AM Fujii Masao wrote: > On 2020/12/12 15:05, Bharath Rupireddy wrote: > > On Sat, Dec 12, 2020 at 12:19 AM Fujii Masao < masao.fu...@oss.nttdata.com > wrote: > > > I was thinking that in the case of drop of user mapping or server, h

Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly

On Sat, Dec 12, 2020 at 01:45:26PM -0600, Justin Pryzby wrote: > On Sat, Dec 12, 2020 at 09:20:35AM +0100, Peter Eisentraut wrote: >> On 2020-12-11 21:27, Alvaro Herrera wrote: >>> By the way-- What did you think of the idea of explictly marking the >>> types used for bitmasks using types bits32 a

RE: [Patch] Optimize dropping of relation buffers using dlist

From: Jamison, Kirk/ジャミソン カーク > Attached are the final updated patches. Looks good, and the patch remains ready for committer. (Personally, I wanted the code comment to touch upon the TOAST and FSM/VM for the reader, because we couldn't think of those possibilities and took some time to find w

Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit

On 2020/12/12 15:05, Bharath Rupireddy wrote: On Sat, Dec 12, 2020 at 12:19 AM Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote: > I was thinking that in the case of drop of user mapping or server, hash_search(ConnnectionHash) in GetConnection() cannot find the cached connection entry

Movement of restart_lsn position movement of logical replication slots is very slow

Hello, We have two logical replication slots in our postgresql database (version-11) instance and we are using pgJDBC to stream data from these two slots. We are ensuring that when we regularly send feedback and update the confirmed_flush_lsn (every 10 minutes) for both the slots to the same posit

Re: please update ps display for recovery checkpoint

On Sun, Dec 13, 2020 at 09:22:24PM -0600, Justin Pryzby wrote: > I'm not sure, but we could consider backpatching something to clear the > "recovering NNN" that's currently displayed during checkpoint, even though > recovery of NNN has already completed. Possibly just calling > set_ps_display("");

Re: Some more hackery around cryptohashes (some fixes + SHA1)

On Thu, Dec 10, 2020 at 05:07:05PM +0900, Michael Paquier wrote: > - 0001 is a set of small adjustments for the existing code of > cryptohashes: some cleanup for MD5 in uuid-ossp, and more importantly > one fix to call explicit_bzero() on the context data for the fallback > implementations. With t

Re: please update ps display for recovery checkpoint

On Mon, Dec 14, 2020 at 12:01:33PM +0900, Michael Paquier wrote: > On Sat, Dec 12, 2020 at 12:41:25AM +, Bossart, Nathan wrote: > > On 12/11/20, 4:00 PM, "Michael Paquier" wrote: > >> My counter-proposal is like the attached, with the set/reset part not > >> reversed this time, and the code in

Re: please update ps display for recovery checkpoint

On Sat, Dec 12, 2020 at 12:41:25AM +, Bossart, Nathan wrote: > On 12/11/20, 4:00 PM, "Michael Paquier" wrote: >> My counter-proposal is like the attached, with the set/reset part not >> reversed this time, and the code indented :p > > Haha. LGTM. Thanks. I have applied this one, then. -- M

Re: pg_waldump error message fix

On Mon, Dec 14, 2020 at 10:26:01AM +0900, Kyotaro Horiguchi wrote: > Yeah, I had the same feeling. At least, the two LSNs in the message > under discussion are simply redundant. So +1 to just remove the LSN at > the caller site. That would mean that we are ready to accept that we will never forget

RE: [Patch] Optimize dropping of relation buffers using dlist

On Friday, December 11, 2020 10:27 AM, Amit Kapila wrote: > On Fri, Dec 11, 2020 at 5:54 AM k.jami...@fujitsu.com > wrote: > > So should I still not include that information? > > > > I think we can extend your existing comment like: "Otherwise if the size of a > relation fork is not cached, we pr

Re: pg_waldump error message fix

> At Fri, 11 Dec 2020 19:27:31 +, "Bossart, Nathan" > wrote in > > I looked through all the calls to report_invalid_record() in > > xlogreader.c and noticed that all but a few in > > XLogReaderValidatePageHeader() already report an LSN. Of the calls in > > XLogReaderValidatePageHeader() tha

Re: pg_waldump error message fix

At Fri, 11 Dec 2020 19:27:31 +, "Bossart, Nathan" wrote in > On 12/10/20, 9:23 PM, "Michael Paquier" wrote: > > Please note that this is documented in xlogreader.h. Hmm. I can see > > your point here, still I think that what both of you are suggesting > > is not completely correct. For e

Re: Rethinking plpgsql's assignment implementation

I wrote: > So my idea here is to add a parsing-mode option to raw_parser(), > which would be an enum with values like "normal SQL statement", > "expression only", "type name", "plpgsql assignment statement". Here's a fleshed-out patch series that attacks things that way. I'm a lot better pleased w

Re: HASH_BLOBS hazards (was Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions)

On Sun, Dec 13, 2020 at 11:49:31AM -0500, Tom Lane wrote: > But what jumps out at me here is that this sort of error seems way > too easy to make, and evidently way too hard to detect. What can we > do to make it more obvious if one has incorrectly used or omitted > HASH_BLOBS? Both directions of

Re: query on smallint array column

Thanks Pavel for fast response. On Sun, Dec 13, 2020 at 9:51 AM Pavel Stehule wrote: > Hi > > ne 13. 12. 2020 v 18:42 odesílatel Zhihong Yu napsal: > >> Hi, >> I was experimenting with the following query. >> >> create table sint1(k int primary key, arr smallint[]); >> create index s1 on sint1(

Re: query on smallint array column

Hi ne 13. 12. 2020 v 18:42 odesílatel Zhihong Yu napsal: > Hi, > I was experimenting with the following query. > > create table sint1(k int primary key, arr smallint[]); > create index s1 on sint1(arr); > insert into sint1 select s, array[s*s, s] FROM generate_series(1, 10) AS s; > select * from

query on smallint array column

Hi, I was experimenting with the following query. create table sint1(k int primary key, arr smallint[]); create index s1 on sint1(arr); insert into sint1 select s, array[s*s, s] FROM generate_series(1, 10) AS s; select * from sint1 where arr @> array[4]; ERROR: operator does not exist: smallint[]

Re: MultiXact\SLRU buffers configuration

> 13 дек. 2020 г., в 14:17, Gilles Darold написал(а): > > I've done more review on these patches. Thanks, Gilles! I'll incorporate all your fixes to patchset. Can you also benchmark conditional variable sleep? The patch "Add conditional variable to wait for next MultXact offset in corner cas

Re: Add session statistics to pg_stat_database

On Sat, Dec 5, 2020 at 1:04 PM Laurenz Albe wrote: > On Fri, 2020-12-04 at 16:55 +0100, I wrote: > > > > Basically, that would change pgStatSessionDisconnectedNormally into > instead being an > > > > enum of reasons, which could be normal disconnect, abnormal > disconnect and admin. > > > > And w

HASH_BLOBS hazards (was Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions)

Amit Kapila writes: > On Wed, Dec 9, 2020 at 2:56 PM Noah Misch wrote: >> The problem is xidhash using strcmp() to compare keys; it needs memcmp(). > Your analysis is correct. Sorry for not having noticed this thread before. Noah's fix is clearly correct, and I have no objection to the added t

Re: Speeding up GIST index creation for tsvectors

> 13 дек. 2020 г., в 17:46, Amit Khandekar написал(а): > > On Thu, 10 Dec 2020 at 20:43, Pavel Borisov wrote: >> >> Hi, Amit! >> It's really cool to hear about another GiST improvement proposal. I'd like >> to connect recently committed GiST ordered build discussion here [1] and >> further

Re: Speeding up GIST index creation for tsvectors

On Thu, 10 Dec 2020 at 20:43, Pavel Borisov wrote: > > Hi, Amit! > It's really cool to hear about another GiST improvement proposal. I'd like to > connect recently committed GiST ordered build discussion here [1] and further > improvement proposed [2] > > I've tested feature [1] and got 2.5-3 ti

Re: MultiXact\SLRU buffers configuration

Le 11/12/2020 à 18:50, Gilles Darold a écrit : > Le 10/12/2020 à 15:45, Gilles Darold a écrit : >> Le 08/12/2020 à 18:52, Andrey Borodin a écrit : >>> Hi Gilles! >>> >>> Many thanks for your message! >>> 8 дек. 2020 г., в 21:05, Gilles Darold написал(а): I know that this report is n