Re: POC and rebased patch for CSN based snapshots

On 2020/06/19 13:36, movead...@highgo.ca wrote: >You mean that the last generated CSN needs to be WAL-logged because any smaller CSN than the last one should not be reused after crash recovery. Right? Yes that's it. If right, that WAL-logging seems not necessary because CSN mechanism

Re: Fast DSM segments

On Thu, Jun 18, 2020 at 6:05 PM Thomas Munro wrote: > Here's a version that adds some documentation. I jumped on a dual socket machine with 36 cores/72 threads and 144GB of RAM (Azure F72s_v2) running Linux, configured with 50GB of huge pages available, and I ran a very simple test: select

Re: min_safe_lsn column in pg_replication_slots view

At Fri, 19 Jun 2020 08:59:48 +0530, Amit Kapila wrote in > > > > Mmm. pg_walfile_name seems too specialize to > > > > pg_stop_backup(). (pg_walfile_name_offset() returns wrong result for > > > > segment boundaries.) I'm not willing to do that only to follow such > > > > suspicious(?)

Re: min_safe_lsn column in pg_replication_slots view

At Fri, 19 Jun 2020 09:09:03 +0530, Amit Kapila wrote in > On Fri, Jun 19, 2020 at 8:44 AM Kyotaro Horiguchi > wrote: > > > > At Fri, 19 Jun 2020 10:39:58 +0900, Michael Paquier > > wrote in > > > Honestly, I find a bit silly the design to compute and use the same > > > minimum LSN value for

Re: Cleanup - Removal of unused function parameter from CopyReadBinaryAttribute

> > > I don't see any problem in removing this extra parameter. > > > > > > However another thought, can it be used to report a bit meaningful > > > error for field size < 0 check? > > > > column_no was used for that purpose in the past, but commit 0e319c7ad7 > > changed that. If we want to use

Re: Missing HashAgg EXPLAIN ANALYZE details for parallel plans

On Fri, 19 Jun 2020 at 15:28, Jeff Davis wrote: > > On Thu, 2020-06-18 at 15:37 +1200, David Rowley wrote: > > The attached patch fixes both the missing parallel worker information > > and puts the properties on a single line for format=text. > > Thank you. > > I noticed some strange results in

missing support for Microsoft VSS Writer

Hi some czech user reported a broken database when he used a repair point on Microsoft Windows. The reply from Microsoft was, so it is not a Microsoft issue, but Postgres issue, because Postgres doesn't handle VSS process correctly, and then restore point can restore some parts of Postgres's

Re: Cleanup - Removal of unused function parameter from CopyReadBinaryAttribute

On Thu, Jun 18, 2020 at 10:05 PM Fujii Masao wrote: > > > > On 2020/06/18 23:09, Bharath Rupireddy wrote: > > On Thu, Jun 18, 2020 at 7:01 PM vignesh C wrote: > >> > >> Hi, > >> > >> While checking copy from code I found that the function parameter > >> column_no is not used in

Re: POC and rebased patch for CSN based snapshots

>You mean that the last generated CSN needs to be WAL-logged because any smaller >CSN than the last one should not be reused after crash recovery. Right? Yes that's it. >If right, that WAL-logging seems not necessary because CSN mechanism assumes >CSN is increased monotonically. IOW, even

Re: Missing HashAgg EXPLAIN ANALYZE details for parallel plans

On Fri, 19 Jun 2020 at 16:06, Justin Pryzby wrote: > > On Fri, Jun 19, 2020 at 03:03:41PM +1200, David Rowley wrote: > > On Fri, 19 Jun 2020 at 14:20, Justin Pryzby wrote: > > > Please be sure to use two spaces between each field ! > > > > > > See earlier discussions (and commits referenced by

Re: Missing HashAgg EXPLAIN ANALYZE details for parallel plans

On Fri, Jun 19, 2020 at 03:03:41PM +1200, David Rowley wrote: > On Fri, 19 Jun 2020 at 14:20, Justin Pryzby wrote: > > Please be sure to use two spaces between each field ! > > > > See earlier discussions (and commits referenced by the Opened Items page). > >

Re: Cleanup - Removal of unused function parameter from CopyReadBinaryAttribute

On Fri, Jun 19, 2020 at 9:18 AM Tom Lane wrote: > > Amit Kapila writes: > > On Thu, Jun 18, 2020 at 10:05 PM Fujii Masao > > wrote: > >> column_no was used for that purpose in the past, but commit 0e319c7ad7 > >> changed that. > > > Yeah, but not sure why? By looking at the commit message and

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Tue, Apr 07, 2020 at 08:40:30AM -0400, James Coleman wrote: > On Tue, Apr 7, 2020 at 12:25 AM Justin Pryzby wrote: > > On Mon, Apr 06, 2020 at 09:57:22PM +0200, Tomas Vondra wrote: > > > I've pushed the fist part of this patch series - I've reorganized it a > > > > I scanned through this again

Re: [Patch] ALTER SYSTEM READ ONLY

On Thu, Jun 18, 2020 at 8:23 PM Robert Haas wrote: > > On Thu, Jun 18, 2020 at 5:55 AM Amit Kapila wrote: > > For buffer replacement, many-a-times we have to also perform > > XLogFlush, what do we do for that? We can't proceed without doing > > that and erroring out from there means stopping

Re: POC and rebased patch for CSN based snapshots

On 2020/06/19 12:12, movead...@highgo.ca wrote: Thanks for reply. >Probably it's not time to do the code review yet, but when I glanced the patch, I came up with one question. 0002 patch changes GenerateCSN() so that it generates CSN-related WAL records (and inserts it into WAL buffers).

Re: Cleanup - Removal of unused function parameter from CopyReadBinaryAttribute

Amit Kapila writes: > On Thu, Jun 18, 2020 at 10:05 PM Fujii Masao > wrote: >> column_no was used for that purpose in the past, but commit 0e319c7ad7 >> changed that. > Yeah, but not sure why? By looking at the commit message and change > it is difficult to say why it has been removed? Tom

Re: min_safe_lsn column in pg_replication_slots view

On Fri, Jun 19, 2020 at 8:44 AM Kyotaro Horiguchi wrote: > > At Fri, 19 Jun 2020 10:39:58 +0900, Michael Paquier > wrote in > > Honestly, I find a bit silly the design to compute and use the same > > minimum LSN value for all the tuples returned by > > pg_get_replication_slots, and you can

Re: min_safe_lsn column in pg_replication_slots view

On Fri, Jun 19, 2020 at 6:32 AM Kyotaro Horiguchi wrote: > > At Thu, 18 Jun 2020 18:18:37 +0530, Amit Kapila > wrote in > > On Thu, Jun 18, 2020 at 11:52 AM Kyotaro Horiguchi > > wrote: > > > > > > At Wed, 17 Jun 2020 21:37:55 +0900, Fujii Masao > > > wrote in > > > > On 2020/06/15 16:35,

Re: POC and rebased patch for CSN based snapshots

Thanks for reply. >AFAIU, this patch is to improve scalability and also will be helpful >for Global Snapshots stuff, is that right? If so, how much >performance/scalability benefit this patch will have after Andres's >recent work on scalability [1]? The patch focus on to be an infrastructure of

Re: Missing HashAgg EXPLAIN ANALYZE details for parallel plans

On Thu, 2020-06-18 at 15:37 +1200, David Rowley wrote: > The attached patch fixes both the missing parallel worker information > and puts the properties on a single line for format=text. Thank you. I noticed some strange results in one case where one worker had a lot more batches than another.

Re: min_safe_lsn column in pg_replication_slots view

At Fri, 19 Jun 2020 10:39:58 +0900, Michael Paquier wrote in > On Fri, Jun 19, 2020 at 10:02:54AM +0900, Kyotaro Horiguchi wrote: > > At Thu, 18 Jun 2020 18:18:37 +0530, Amit Kapila > > wrote in > >> It is a little unclear to me how this or any proposed patch will solve > >> the original

Re: POC and rebased patch for CSN based snapshots

Thanks for reply. >Probably it's not time to do the code review yet, but when I glanced the patch, >I came up with one question. >0002 patch changes GenerateCSN() so that it generates CSN-related WAL records >(and inserts it into WAL buffers). Which means that new WAL record is generated

Re: Asynchronous Append on postgres_fdw nodes.

At Wed, 17 Jun 2020 15:01:08 +0500, "Andrey V. Lepikhov" wrote in > On 6/16/20 1:30 PM, Kyotaro Horiguchi wrote: > > They return 25056 rows, which is far more than 9741 rows. So remote > > join won. > > Of course the number of returning rows is not the only factor of the > > cost change but is

Re: Missing HashAgg EXPLAIN ANALYZE details for parallel plans

On Fri, 19 Jun 2020 at 14:20, Justin Pryzby wrote: > Please be sure to use two spaces between each field ! > > See earlier discussions (and commits referenced by the Opened Items page). > https://www.postgresql.org/message-id/20200402054120.gc14...@telsasoft.com >

Re: Cleanup - Removal of unused function parameter from CopyReadBinaryAttribute

On Thu, Jun 18, 2020 at 10:05 PM Fujii Masao wrote: > > > On 2020/06/18 23:09, Bharath Rupireddy wrote: > > On Thu, Jun 18, 2020 at 7:01 PM vignesh C wrote: > >> > >> Hi, > >> > >> While checking copy from code I found that the function parameter > >> column_no is not used in

Re: Missing HashAgg EXPLAIN ANALYZE details for parallel plans

On Fri, Jun 19, 2020 at 02:02:29PM +1200, David Rowley wrote: > On Fri, 19 Jun 2020 at 01:45, Justin Pryzby wrote: > > Note that "incremental sort" is also new, and splits things up more than > > sort. > > > > See in particular 6a918c3ac8a6b1d8b53cead6fcb7cbd84eee5750, which splits > > things >

Re: Parallel Seq Scan vs kernel read ahead

On Fri, 19 Jun 2020 at 11:34, David Rowley wrote: > > On Fri, 19 Jun 2020 at 03:26, Robert Haas wrote: > > > > On Thu, Jun 18, 2020 at 6:15 AM David Rowley wrote: > > > With a 32TB relation, the code will make the chunk size 16GB. Perhaps > > > I should change the code to cap that at 1GB. > >

Re: Missing HashAgg EXPLAIN ANALYZE details for parallel plans

On Fri, 19 Jun 2020 at 01:45, Justin Pryzby wrote: > Note that "incremental sort" is also new, and splits things up more than sort. > > See in particular 6a918c3ac8a6b1d8b53cead6fcb7cbd84eee5750, which splits > things > up even more. > > -> Incremental Sort (actual rows=70 loops=1) >

Re: Add support for INDEX_CLEANUP and TRUNCATE to vacuumdb

On Thu, Jun 18, 2020 at 09:26:50PM +, Bossart, Nathan wrote: > It looks like I missed a couple of tags in the documentation changes. > That should be fixed in v3. Thanks. This flavor looks good to me in terms of code, and the test coverage is what's needed for all the code paths added. This

Re: min_safe_lsn column in pg_replication_slots view

On Fri, Jun 19, 2020 at 10:02:54AM +0900, Kyotaro Horiguchi wrote: > At Thu, 18 Jun 2020 18:18:37 +0530, Amit Kapila > wrote in >> It is a little unclear to me how this or any proposed patch will solve >> the original problem reported by Fujii-San? Basically, the problem >> arises because we

Re: min_safe_lsn column in pg_replication_slots view

At Thu, 18 Jun 2020 18:18:37 +0530, Amit Kapila wrote in > On Thu, Jun 18, 2020 at 11:52 AM Kyotaro Horiguchi > wrote: > > > > At Wed, 17 Jun 2020 21:37:55 +0900, Fujii Masao > > wrote in > > > On 2020/06/15 16:35, Kyotaro Horiguchi wrote: > > > Isn't it better to use 1 as the second

Re: [PATCH] Allow to specify restart_lsn in pg_create_physical_replication_slot()

On Thu, Jun 18, 2020 at 03:39:09PM +0300, Vyacheslav Makarov wrote: > If the WAL segment for the specified restart_lsn (STOP_LSN of the backup) > exists, then the function will create a physical replication slot and will > keep all the WAL segments required by the replica to catch up with the >

Re: Extracting only the columns needed for a query

On Fri, Mar 13, 2020 at 12:09 PM Dmitry Dolgov <9erthali...@gmail.com> wrote: > In general implemented functionality looks good. I've checked how it > works on the existing tests, almost everywhere required columns were not > missing in scanCols (which is probably the most important part). >

Re: Add A Glossary

On 2020-Jun-16, Justin Pryzby wrote: > On Tue, Jun 16, 2020 at 08:09:26PM -0400, Alvaro Herrera wrote: Thanks for the review. I merged all your suggestions. This one: > >Most local objects belong to a specific > > + schema in their > > + containing database, such as > > +

Re: Parallel Seq Scan vs kernel read ahead

On Fri, 19 Jun 2020 at 03:26, Robert Haas wrote: > > On Thu, Jun 18, 2020 at 6:15 AM David Rowley wrote: > > With a 32TB relation, the code will make the chunk size 16GB. Perhaps > > I should change the code to cap that at 1GB. > > It seems pretty hard to believe there's any significant

Re: More tzdb fun: POSIXRULES is being deprecated upstream

I wrote: > ... We should expect that, starting probably this fall, there > will be installations with no posixrules file. > The minimum thing that we have to do, I'd say, is to change the > documentation to explain what happens if there's no posixrules file. > However, in view of the fact that

Re: global barrier & atomics in signal handlers (Re: Atomic operations within spinlocks)

Hi, On 2020-06-16 15:20:11 -0400, Alvaro Herrera wrote: > On 2020-Jun-15, Andres Freund wrote: > > > > Also, I wonder if someone would be willing to set up a BF animal for this. > > > > FWIW, I've requested a buildfarm animal id for this a few days ago, but > > haven't received a response

Re: pg_dump, gzwrite, and errno

Alvaro Herrera writes: > On 2020-Jun-11, Justin Pryzby wrote: >> --- a/src/bin/pg_dump/pg_backup_directory.c >> +++ b/src/bin/pg_dump/pg_backup_directory.c >> @@ -347,8 +347,12 @@ _WriteData(ArchiveHandle *AH, const void *data, size_t >> dLen) >> lclContext *ctx = (lclContext *)

Re: pg_dump, gzwrite, and errno

On 2020-Jun-11, Justin Pryzby wrote: > --- a/src/bin/pg_dump/pg_backup_directory.c > +++ b/src/bin/pg_dump/pg_backup_directory.c > @@ -347,8 +347,12 @@ _WriteData(ArchiveHandle *AH, const void *data, size_t > dLen) > lclContext *ctx = (lclContext *) AH->formatData; > > if (dLen

Re: jsonpath versus NaN

On 6/18/20 12:35 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Jun 18, 2020 at 11:51 AM Oleg Bartunov >> wrote: >>> The problem is that we tried to find a trade-off between standard and >>> postgres >>> implementation, for example, in postgres CAST allows NaN and Inf, and SQL >>>

Re: More tzdb fun: POSIXRULES is being deprecated upstream

Robert Haas writes: > You could consider something along the lines of: > This form specifies a transition that always happens during the same > month and on the same day of the week. m identifies the month, from 1 > to 12. n specifies the n'th occurrence of the day number identified by > d. n is

re: BUG #14053: postgres crashes in plpgsql under load of concurrent transactions

Hi Maxim, Coverity show that trap (1), still persists, even in HEAD. CID 1425439 (#1 of 1): Explicit null dereferenced (FORWARD_NULL) 15. var_deref_model: Passing null pointer expr->expr_simple_state to ExecEvalExpr, which dereferences it. [show details

Re: Physical replication slot advance is not persistent

On 2020-06-16 10:27, Michael Paquier wrote: On Wed, Jun 10, 2020 at 08:57:17PM +0300, Alexey Kondratov wrote: New test reproduces this issue well. Left it running for a couple of hours in repeat and it seems to be stable. Thanks for testing. I have been thinking about the minimum xmin and

Re: [patch] demote

On Thu, Jun 18, 2020 at 1:24 PM Tom Lane wrote: > It seems like this is the core decision that needs to be taken. If > we're willing to have these state transitions include a server restart, > then many things get simpler. If we're not, it's gonna cost us in > code complexity and hence bugs.

Re: global barrier & atomics in signal handlers (Re: Atomic operations within spinlocks)

Hi, On 2020-06-18 12:29:40 -0400, Tom Lane wrote: > Robert Haas writes: > > On Thu, Jun 18, 2020 at 11:59 AM Tom Lane wrote: > >> Sure, but wouldn't making the SpinLockAcquire layer into static inlines be > >> sufficient to address that point, with no need to touch s_lock.h at all? > > > I

Re: Internal key management system

On 18/6/20 19:41, Cary Huang wrote: Hi all Having read through the discussion, I have some comments and suggestions that I would like to share. I think it is still quite early to even talk about external key management system even if it is running on the same host as PG. This is most

Re: More tzdb fun: POSIXRULES is being deprecated upstream

On Thu, Jun 18, 2020 at 1:05 PM Tom Lane wrote: > Robert Haas writes: > > It's a little confusing, though, that you documented it as Mm.n.d but > > then in the text the order of explanation is d then m then n. Maybe > > switch the text around so the order matches, or even use something > > like

Re: [patch] demote

Hi, On 2020-06-18 13:24:38 -0400, Tom Lane wrote: > Robert Haas writes: > > ... To go back to recovery rather than just to a read-only > > state, I think you'd need to grapple with some additional issues that > > patch doesn't touch, like some of the snapshot-taking stuff, but I > > think you

Re: Internal key management system

Hi all Having read through the discussion, I have some comments and suggestions that I would like to share.  I think it is still quite early to even talk about external key management system even if it is running on the same host as PG. This is most likely achieved as an extension that

Re: [patch] demote

Robert Haas writes: > ... To go back to recovery rather than just to a read-only > state, I think you'd need to grapple with some additional issues that > patch doesn't touch, like some of the snapshot-taking stuff, but I > think you still need to solve all of the problems that it does deal >

Re: [patch] demote

On Thu, Jun 18, 2020 at 12:55 PM Fujii Masao wrote: > Even with ASRO, the server restart is necessary and RO sessions are > kicked out when demoting RO primary to a standby, i.e., during a clean > switchover? The ASRO patch doesn't provide a way to put a running server to be put back into

Re: [patch] demote

Hi, On 2020-06-18 21:41:45 +0900, Fujii Masao wrote: > ISTM that a clean switchover is possible without "ALTER SYSTEM READ ONLY". > What about the following procedure? > > 1. Demote the primary to a standby. Then this demoted standby is read-only. As far as I can tell this step includes ALTER

Re: [patch] demote

Hi, On 2020-06-18 12:16:27 +0200, Jehan-Guillaume de Rorthais wrote: > On Wed, 17 Jun 2020 11:14:47 -0700 > > I don't think there's a fundamental issue, but I think it needs to deal > > with a lot more things than it does right now. StartupXLOG doesn't > > currently deal correctly with subsystems

Re: Operator class parameters and sgml docs

On Wed, Jun 17, 2020 at 2:00 PM Alexander Korotkov wrote: > On Wed, Jun 17, 2020 at 2:50 AM Peter Geoghegan wrote: > > On Tue, Jun 16, 2020 at 4:24 AM Alexander Korotkov > > wrote: > > > Thank you for patience. The documentation patch is attached. I think > > > it requires review by native

Re: More tzdb fun: POSIXRULES is being deprecated upstream

Robert Haas writes: > It's a little confusing, though, that you documented it as Mm.n.d but > then in the text the order of explanation is d then m then n. Maybe > switch the text around so the order matches, or even use something > like Mmonth.occurrence.day. Yeah, I struggled with that text

Re: jsonpath versus NaN

On Thu, Jun 18, 2020 at 7:45 PM Tom Lane wrote: > Alexander Korotkov writes: > > Thank you for your answer. I'm trying to understand your point. > > Standard claims that .double() method should behave the same way as > > CAST to double. However, standard references the standard behavior of > >

Re: [patch] demote

On 2020/06/19 0:22, Robert Haas wrote: On Thu, Jun 18, 2020 at 8:41 AM Fujii Masao wrote: ISTM that a clean switchover is possible without "ALTER SYSTEM READ ONLY". What about the following procedure? 1. Demote the primary to a standby. Then this demoted standby is read-only. 2. The

Re: Mark btree_gist functions as PARALLEL SAFE

Done - thanks again. Steven. From: Tom Lane Sent: 18 June 2020 16:28 To: Winfield, Steven Cc: pgsql-hackers@lists.postgresql.org Subject: Re: Mark btree_gist functions as PARALLEL SAFE "Winfield, Steven" writes: > On the back of this thread[1] over at

Re: jsonpath versus NaN

Alexander Korotkov writes: > Thank you for your answer. I'm trying to understand your point. > Standard claims that .double() method should behave the same way as > CAST to double. However, standard references the standard behavior of > CAST here, not behavior of your implementation of CAST.

Re: More tzdb fun: POSIXRULES is being deprecated upstream

On Thu, Jun 18, 2020 at 12:26 AM Tom Lane wrote: > Here's a proposed patch to do that. To explain this, we more or less > have to fully document the POSIX timezone string format (otherwise > nobody's gonna understand what "M3.2.0,M11.1.0" means). That's something > we've glossed over for many

Re: jsonpath versus NaN

On Thu, Jun 18, 2020 at 7:34 PM Alexander Korotkov wrote: > Thank you for your answer. I'm trying to understand your point. > Standard claims that .double() method should behave the same way as > CAST to double. However, standard references the standard behavior of > CAST here, not behavior of

Re: jsonpath versus NaN

Robert Haas writes: > On Thu, Jun 18, 2020 at 11:51 AM Oleg Bartunov > wrote: >> The problem is that we tried to find a trade-off between standard and >> postgres >> implementation, for example, in postgres CAST allows NaN and Inf, and SQL >> Standard >> requires .double should works as

Re: Cleanup - Removal of unused function parameter from CopyReadBinaryAttribute

On 2020/06/18 23:09, Bharath Rupireddy wrote: On Thu, Jun 18, 2020 at 7:01 PM vignesh C wrote: Hi, While checking copy from code I found that the function parameter column_no is not used in CopyReadBinaryAttribute. I felt this could be removed. Attached patch contains the changes for the

Re: jsonpath versus NaN

Tom, On Thu, Jun 18, 2020 at 7:07 PM Tom Lane wrote: > Oleg Bartunov writes: > > The problem is that we tried to find a trade-off between standard and > > postgres implementation, for example, in postgres CAST allows NaN and > > Inf, and SQL Standard requires .double should works as CAST. > >

Re: [patch] demote

On Thu, Jun 18, 2020 at 11:56 AM Jehan-Guillaume de Rorthais wrote: > Considering the current demote patch improvement. I was considering to digg in > the following direction: > > * add a new state in the state machine where all backends are idle > * this new state forbid any new writes, the same

Re: global barrier & atomics in signal handlers (Re: Atomic operations within spinlocks)

Robert Haas writes: > On Thu, Jun 18, 2020 at 11:59 AM Tom Lane wrote: >> Sure, but wouldn't making the SpinLockAcquire layer into static inlines be >> sufficient to address that point, with no need to touch s_lock.h at all? > I mean, wouldn't you then end up with a bunch of 1-line functions >

Re: jsonpath versus NaN

On Thu, Jun 18, 2020 at 11:51 AM Oleg Bartunov wrote: > The problem is that we tried to find a trade-off between standard and > postgres > implementation, for example, in postgres CAST allows NaN and Inf, and SQL > Standard > requires .double should works as CAST. It seems like the right

Re: global barrier & atomics in signal handlers (Re: Atomic operations within spinlocks)

On Thu, Jun 18, 2020 at 11:59 AM Tom Lane wrote: > Sure, but wouldn't making the SpinLockAcquire layer into static inlines be > sufficient to address that point, with no need to touch s_lock.h at all? I mean, wouldn't you then end up with a bunch of 1-line functions where you can step into the

Re: jsonpath versus NaN

Oleg Bartunov writes: > The problem is that we tried to find a trade-off between standard and > postgres implementation, for example, in postgres CAST allows NaN and > Inf, and SQL Standard requires .double should works as CAST. As I said, I think this is a fundamental misreading of the

Re: global barrier & atomics in signal handlers (Re: Atomic operations within spinlocks)

Robert Haas writes: > On Wed, Jun 17, 2020 at 5:29 PM Tom Lane wrote: >> I wouldn't object to making the outer-layer macros in spin.h into static >> inlines; as mentioned, that might have some debugging benefits. But I >> think messing with s_lock.h for marginal cosmetic reasons is a foolish >>

Re: [patch] demote

On Thu, 18 Jun 2020 11:22:47 -0400 Robert Haas wrote: > On Thu, Jun 18, 2020 at 8:41 AM Fujii Masao > wrote: > > ISTM that a clean switchover is possible without "ALTER SYSTEM READ ONLY". > > What about the following procedure? > > > > 1. Demote the primary to a standby. Then this demoted

Re: jsonpath versus NaN

On Wed, Jun 17, 2020 at 6:33 PM Tom Lane wrote: > Alexander Korotkov writes: > > On Thu, Jun 11, 2020 at 10:00 PM Tom Lane wrote: > >> I don't think this is very relevant. The SQL standard has not got the > >> concepts of Inf or NaN either (see 4.4.2 Characteristics of numbers), > >>

Re: global barrier & atomics in signal handlers (Re: Atomic operations within spinlocks)

On Wed, Jun 17, 2020 at 5:29 PM Tom Lane wrote: > See the "Default Definitions", down near the end. Oh, yeah. I didn't realize you meant just inside this file itself. That is slightly awkward. I initially thought there was no problem because there seem to be no remaining non-default definitions

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Tue, Jun 9, 2020 at 3:04 PM Amit Kapila wrote: > > On Mon, Jun 8, 2020 at 11:53 AM Amit Kapila wrote: > > > > I think one of the usages we still need is in ReorderBufferForget > > because it can be called when we skip processing the txn. See the > > comments in DecodeCommit where we call

Re: Mark btree_gist functions as PARALLEL SAFE

"Winfield, Steven" writes: > On the back of this thread[1] over at pgsql-general, I've attached a patch > that marks the functions in btree_gist as PARALLEL SAFE. Cool, please add this patch to the commitfest queue to make sure we don't lose track of it: https://commitfest.postgresql.org/28/

Re: [patch] demote

On Thu, 18 Jun 2020 11:15:02 -0400 Robert Haas wrote: > On Thu, Jun 18, 2020 at 6:02 AM Jehan-Guillaume de Rorthais > wrote: > > At some expense, Admin can already set the system as readonly from the > > application point of view, using: > > > > alter system set default_transaction_read_only

Re: Parallel Seq Scan vs kernel read ahead

On Thu, Jun 18, 2020 at 6:15 AM David Rowley wrote: > With a 32TB relation, the code will make the chunk size 16GB. Perhaps > I should change the code to cap that at 1GB. It seems pretty hard to believe there's any significant advantage to a chunk size >1GB, so I would be in favor of that

Re: [Patch] ALTER SYSTEM READ ONLY

On Thu, Jun 18, 2020 at 11:08 AM Jehan-Guillaume de Rorthais wrote: > Thanks to cascading replication, it could be very possible without this READ > ONLY mode, just in recovery mode, isn't it? Yeah, perhaps. I just wrote an email about that over on the demote thread, so I won't repeat it here.

Re: [patch] demote

On Thu, Jun 18, 2020 at 8:41 AM Fujii Masao wrote: > ISTM that a clean switchover is possible without "ALTER SYSTEM READ ONLY". > What about the following procedure? > > 1. Demote the primary to a standby. Then this demoted standby is read-only. > 2. The orignal standby automatically establishes

Re: [patch] demote

On Thu, Jun 18, 2020 at 6:02 AM Jehan-Guillaume de Rorthais wrote: > At some expense, Admin can already set the system as readonly from the > application point of view, using: > > alter system set default_transaction_read_only TO on; > select pg_reload_conf(); > > Current RW xact will finish,

Re: [Patch] ALTER SYSTEM READ ONLY

On Thu, 18 Jun 2020 10:52:49 -0400 Robert Haas wrote: [...] > But what you want is that if it does happen to go down for some reason before > all the WAL is streamed, you can bring it back up and finish streaming the > WAL without generating any new WAL. Thanks to cascading replication, it

Re: [Patch] ALTER SYSTEM READ ONLY

On Thu, Jun 18, 2020 at 6:39 AM Simon Riggs wrote: > That doesn't appear to be very graceful. Perhaps objections could be assuaged > by having a smoother transition and perhaps not even a full barrier, > initially. Yeah, it's not ideal, though still better than what we have now. What do you

Re: [Patch] ALTER SYSTEM READ ONLY

On Thu, Jun 18, 2020 at 7:19 AM amul sul wrote: > Let me explain the case, if we do skip the end-of-recovery checkpoint while > starting the system in read-only mode and then later changing the state to > read-write and do a few write operations and online checkpoints, that will be > fine? I am

Re: [Patch] ALTER SYSTEM READ ONLY

On Thu, Jun 18, 2020 at 5:55 AM Amit Kapila wrote: > For buffer replacement, many-a-times we have to also perform > XLogFlush, what do we do for that? We can't proceed without doing > that and erroring out from there means stopping read-only query from > the user perspective. I think we should

Mark btree_gist functions as PARALLEL SAFE

Hi, On the back of this thread[1] over at pgsql-general, I've attached a patch that marks the functions in btree_gist as PARALLEL SAFE. This is primarily to allow parallel plans to be considered when btree_gist's <-> operator is used in any context; for example in an expression that will be

Re: Cleanup - Removal of unused function parameter from CopyReadBinaryAttribute

On Thu, Jun 18, 2020 at 7:01 PM vignesh C wrote: > > Hi, > > While checking copy from code I found that the function parameter > column_no is not used in CopyReadBinaryAttribute. I felt this could be > removed. > Attached patch contains the changes for the same. > Thoughts? > I don't see any

Re: Missing HashAgg EXPLAIN ANALYZE details for parallel plans

On Thu, Jun 18, 2020 at 03:37:21PM +1200, David Rowley wrote: > Now that HashAgg can spill to disk, we see a few more details in > EXPLAIN ANALYZE than we did previously, e.g. Peak Memory Usage, Disk > Usage. However, the new code neglected to make EXPLAIN ANALYZE show > these new details for

Cleanup - Removal of unused function parameter from CopyReadBinaryAttribute

Hi, While checking copy from code I found that the function parameter column_no is not used in CopyReadBinaryAttribute. I felt this could be removed. Attached patch contains the changes for the same. Thoughts? Regards, Vignesh EnterpriseDB: http://www.enterprisedb.com From

Re: Transactions involving multiple postgres foreign servers, take 2

On Thu, Jun 18, 2020 at 04:09:56PM +0530, Amit Kapila wrote: > You are right and we are not going to claim that after this feature is > committed. This feature has independent use cases like it can allow > parallel copy when foreign tables are involved once we have parallel > copy and surely

Re: Parallel copy

On Mon, Jun 15, 2020 at 4:39 PM Bharath Rupireddy wrote: > > The above tests were run with the configuration attached config.txt, which is > the same used for performance tests of csv/text files posted earlier in this > mail chain. > > Request the community to take this patch up for review

Re: min_safe_lsn column in pg_replication_slots view

On Thu, Jun 18, 2020 at 11:52 AM Kyotaro Horiguchi wrote: > > At Wed, 17 Jun 2020 21:37:55 +0900, Fujii Masao > wrote in > > On 2020/06/15 16:35, Kyotaro Horiguchi wrote: > > Isn't it better to use 1 as the second argument of the above, > > in order to address the issue that I reported

Re: [patch] demote

On 2020/06/18 1:29, Robert Haas wrote: On Wed, Jun 17, 2020 at 11:45 AM Jehan-Guillaume de Rorthais wrote: As Amul sent a patch about "ALTER SYSTEM READ ONLY"[1], with similar futur objectives than mine, I decided to share the humble patch I am playing with to step down an instance from

[PATCH] Allow to specify restart_lsn in pg_create_physical_replication_slot()

Hello, hackers. I would like to propose a patch, which allows passing one extra parameter to pg_create_physical_replication_slot() — restart_lsn. It could be very helpful if we already have some backup with STOP_LSN from a couple of hours in the past and we want to quickly verify wether it is

Re: factorial of negative numbers

On Thu, Jun 18, 2020 at 1:57 PM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2020-06-18 09:43, Juan José Santamaría Flecha wrote: > > The gamma function from math.h returns a NaN for negative integer > > values, the postgres factorial function returns a numeric, which allows >

Re: factorial of negative numbers

On 2020-06-18 09:43, Juan José Santamaría Flecha wrote: On Thu, Jun 18, 2020 at 9:13 AM Peter Eisentraut > wrote: On 2020-06-16 14:17, Dean Rasheed wrote: > I think you're probably right though. Raising an out-of-range error > seems like

Re: POC and rebased patch for CSN based snapshots

On 2020/06/15 16:48, Fujii Masao wrote: On 2020/06/12 18:41, movead...@highgo.ca wrote: Hello hackers, Currently, I do some changes based on the last version: 1. Catch up to the current  commit (c2bd1fec32ab54). 2. Add regression and document. 3. Add support to switch from xid-base

Re: [Patch] ALTER SYSTEM READ ONLY

On Thu, Jun 18, 2020 at 3:25 PM Amit Kapila wrote: > > On Wed, Jun 17, 2020 at 8:12 PM Robert Haas wrote: > > > > On Wed, Jun 17, 2020 at 9:02 AM Amit Kapila wrote: > > > Do we prohibit the checkpointer to write dirty pages and write a > > > checkpoint record as well? If so, will the

Re: [Patch] ALTER SYSTEM READ ONLY

On Wed, Jun 17, 2020 at 9:37 PM Robert Haas wrote: > > On Wed, Jun 17, 2020 at 10:58 AM Tom Lane wrote: > > > Lastly, the arguments in favor seem pretty bogus. HA switchover normally > > involves just killing the primary server, not expecting that you can > > leisurely issue some commands to it

Re: Transactions involving multiple postgres foreign servers, take 2

On Thu, Jun 18, 2020 at 5:01 AM Tatsuo Ishii wrote: > > > Another point is that > > do we want some middleware involved in the solution? The main thing > > I was looking into at this stage is do we think that the current > > implementation proposed by the patch for 2PC is generic enough that we

Re: [Patch] ALTER SYSTEM READ ONLY

On Tue, 16 Jun 2020 at 14:56, amul sul wrote: > The high-level goal is to make the availability/scale-out situation > better. The feature > will help HA setup where the master server needs to stop accepting WAL > writes > immediately and kick out any transaction expecting WAL writes at the

  1   2   >