Re: Yet another fast GiST build (typo)

> 10 июля 2020 г., в 10:53, Thomas Munro написал(а): > > On Tue, Jul 7, 2020 at 7:03 PM Andrey M. Borodin wrote: >> Oops. I've mismerged docs and did not notice this with check world. PFA v8 >> with fixed docs. > > It looks like point_zorder_internal() has the check for NaN in the wrong > p

Re: SQL-standard function body

On Wed, Jul 1, 2020 at 5:49 AM Peter Eisentraut wrote: > - More test coverage is needed. Surprisingly, there wasn't actually any > test AFAICT that just creates and SQL function and runs it. Most of > that code is tested incidentally, but there is very little or no > targeted testing of this fun

Re: Log the location field before any backtrace

On 2020-07-10 04:04, Michael Paquier wrote: On Thu, Jul 09, 2020 at 12:31:38PM -0400, Alvaro Herrera wrote: On 2020-Jul-09, Daniel Gustafsson wrote: On 9 Jul 2020, at 11:17, Peter Eisentraut wrote: In PG13, we added the ability to add backtraces to the log output. After some practical exper

Re: posgres 12 bug (partitioned table)

Hi Soumyadeep, On Fri, Jul 10, 2020 at 2:56 AM Soumyadeep Chakraborty wrote: > > Hey Amit, > > On Thu, Jul 9, 2020 at 12:16 AM Amit Langote wrote: > > > By the way, what happens today if you do INSERT INTO a_zedstore_table > > ... RETURNING xmin? Do you get an error "xmin is unrecognized" or >

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

On Fri, Jul 10, 2020 at 11:01 AM Ajin Cherian wrote: > > > > On Fri, Jul 10, 2020 at 3:11 PM Dilip Kumar wrote: >> >> With your changes sometimes due to incomplete toast >> changes, if it can not pick the largest top txn for streaming it will >> hang forever in the while loop, in that case, it sh

Re: Yet another fast GiST build (typo)

On Tue, Jul 7, 2020 at 7:03 PM Andrey M. Borodin wrote: > Oops. I've mismerged docs and did not notice this with check world. PFA v8 > with fixed docs. It looks like point_zorder_internal() has the check for NaN in the wrong place.

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

On Fri, Jul 10, 2020 at 3:11 PM Dilip Kumar wrote: > With your changes sometimes due to incomplete toast > changes, if it can not pick the largest top txn for streaming it will > hang forever in the while loop, in that case, it should go for > spilling. > > while (rb->size >= logical_decoding_wor

Re: Support for NSS as a libpq TLS backend

On Fri, Jul 3, 2020 at 11:51 PM Daniel Gustafsson wrote: > > On 25 Jun 2020, at 17:39, Daniel Gustafsson wrote: > >> On 15 May 2020, at 22:46, Daniel Gustafsson wrote: > >> The 0001 patch contains the full NSS support, and 0002 is a fix for the > >> pgstat > >> abstraction which IMO leaks backe

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

On Fri, Jul 10, 2020 at 9:21 AM Ajin Cherian wrote: > > > > On Thu, Jul 9, 2020 at 1:30 PM Amit Kapila wrote: >> >> >> > I think if the GUC is set then maybe we can bypass this check so that >> > it can try to stream every single change? >> > >> >> Yeah and probably we need to do something for th

Re: POC: postgres_fdw insert batching

On 6/28/20 8:10 PM, Tomas Vondra wrote: Now, the primary reason why the performance degrades like this is that while FDW has batching for SELECT queries (i.e. we read larger chunks of data from the cursors), we don't have that for INSERTs (or other DML). Every time you insert a row, it has to go

Re: Added tab completion for the missing options in copy statement

On Sat, Jun 27, 2020 at 6:52 AM vignesh C wrote: > > Hi, > > I found that tab completion for some parts of the copy statement was > missing. The Tab completion was missing for the following cases: > 1) COPY [BINARY] FROM filename -> "BINARY", "DELIMITER", "NULL", > "CSV", "ENCODING", "WITH (", "W

distribute_restrictinfo_to_rels if restrictinfo contains volatile functions

Hi all, consider the following SQL: gpadmin=# explain (verbose, costs off) select * from t, (select a from generate_series(1, 1)a)x,

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

On Thu, Jul 9, 2020 at 1:30 PM Amit Kapila wrote: > > > I think if the GUC is set then maybe we can bypass this check so that > > it can try to stream every single change? > > > > Yeah and probably we need to do something for the check "while > (rb->size >= logical_decoding_work_mem * 1024L)" as

Re: [PATCH] Performance Improvement For Copy From Binary Files

Hi Bharath, On Thu, Jul 9, 2020 at 7:33 PM Bharath Rupireddy wrote: > Thanks Amit for buying into the idea. I agree that your patch looks > clean and simple compared to mine and I'm okay with your patch. > > I reviewed and tested your patch, below are few comments: Thanks for checking it out. >

Re: Global snapshots

On Wed, 8 Jul 2020 at 21:35, Amit Kapila wrote: > > On Wed, Jul 8, 2020 at 11:16 AM Masahiko Sawada > wrote: > > > > On Tue, 7 Jul 2020 at 15:40, Amit Kapila wrote: > > > > > > > > > Okay, but isn't there some advantage with this approach (manage 2PC at > > > postgres_fdw level) as well which is

Re: expose parallel leader in CSV and log_line_prefix

On Fri, Jul 10, 2020 at 11:09:40AM +0900, Michael Paquier wrote: > On Thu, Jul 09, 2020 at 01:53:39PM +0200, Julien Rouhaud wrote: > > Sure! I've been quite busy with internal work duties recently but > > I'll review this patch shortly. Thanks for the reminder! > > Hmm. In which cases would it

RE: Postgres is not able to handle more than 4k tables!?

From: Konstantin Knizhnik > Unfortunately we have not to wait for decade or two. > Postgres is faced with multiple problems at existed multiprocessor > systems (64, 96,.. cores). > And it is not even necessary to initiate thousands of connections: just > enough to load all this cores and let them

Re: expose parallel leader in CSV and log_line_prefix

On Thu, Jul 09, 2020 at 01:53:39PM +0200, Julien Rouhaud wrote: > Sure! I've been quite busy with internal work duties recently but > I'll review this patch shortly. Thanks for the reminder! Hmm. In which cases would it be useful to have this information in the logs knowing that pg_stat_activit

RE: Performing partition pruning using row value

Amit-san Friday, July 10, 2020 10:00 AM, Amit Langote wrote: >Speaking of which, I hope that Kato-san has looked at functions >match_rowcompare_to_indexcol(), expand_indexqual_rowcompare(), etc. in >indxpath.c as starting points >for the code to match RowCompares to partition >keys. Hmm, I did

Re: Log the location field before any backtrace

On Thu, Jul 09, 2020 at 12:31:38PM -0400, Alvaro Herrera wrote: > On 2020-Jul-09, Daniel Gustafsson wrote: >> On 9 Jul 2020, at 11:17, Peter Eisentraut >> wrote: >>> >>> In PG13, we added the ability to add backtraces to the log >>> output. After some practical experience with it, I think the >>

Re: Resetting spilled txn statistics in pg_stat_replication

On Thu, 9 Jul 2020 at 12:11, Amit Kapila wrote: > > On Wed, Jul 8, 2020 at 1:14 PM Masahiko Sawada > wrote: > > > > On Wed, 8 Jul 2020 at 16:04, Amit Kapila wrote: > > > > > > On Wed, Jul 8, 2020 at 11:28 AM Masahiko Sawada > > > wrote: > > > > > > > > > > > > > > If we need them to be persiste

Re: Is it useful to record whether plans are generic or custom?

On 2020-07-08 16:41, Fujii Masao wrote: On 2020/07/08 10:14, torikoshia wrote: On 2020-07-06 22:16, Fujii Masao wrote: On 2020/06/11 14:59, torikoshia wrote: On 2020-06-10 18:00, Kyotaro Horiguchi wrote: +    TupleDescInitEntry(tupdesc, (AttrNumber) 8, "last_plan", This could be a problem

Re: Resetting spilled txn statistics in pg_stat_replication

On Thu, 9 Jul 2020 at 16:09, Amit Kapila wrote: > > On Tue, Jul 7, 2020 at 2:20 PM Magnus Hagander wrote: > > > > On Tue, Jul 7, 2020 at 5:10 AM Amit Kapila wrote: > >> > >> > > I think it depends on the final patch. My initial thought was that we > >> > > should do this for PG14 but if you are

Re: Physical replication slot advance is not persistent

On Thu, Jul 09, 2020 at 04:12:49PM +0530, Amit Kapila wrote: > On Fri, Jun 19, 2020 at 12:16 AM Alexey Kondratov > wrote: >> 1. Both ReplicationSlotsComputeRequiredXmin() and >> ReplicationSlotsComputeRequiredLSN() may have already been done in the >> LogicalConfirmReceivedLocation() if it was a l

Re: Default setting for enable_hashagg_disk

On Thu, Jul 9, 2020 at 5:08 PM Stephen Frost wrote: > I didn't, and don't, think it particularly relevant to the discussion, > but if you don't like the comparison to Sort then we could compare it to > a HashJoin instead- the point is that, yes, if you are willing to give > more memory to a given

Re: A patch for get origin from commit_ts.

On Wed, Jul 08, 2020 at 03:08:24PM +0900, Michael Paquier wrote: > There is a conflict in catversion.h. If you wish to test the patch, > please feel free to use the attached where I have updated the > attribute name to roident. Please note that I have switched the patch as ready for committer. S

Re: Performing partition pruning using row value

On Fri, Jul 10, 2020 at 9:35 AM Etsuro Fujita wrote: > On Thu, Jul 9, 2020 at 7:57 PM Fujii Masao > wrote: > > On 2020/07/09 19:45, Etsuro Fujita wrote: > > > Please add the patch to the next CF so that it does not get lost. > > > > Is this a bug rather than new feature? > > I think it's a limit

Re: Performing partition pruning using row value

Fujii-san, On Thu, Jul 9, 2020 at 7:57 PM Fujii Masao wrote: > On 2020/07/09 19:45, Etsuro Fujita wrote: > > Please add the patch to the next CF so that it does not get lost. > > Is this a bug rather than new feature? I think it's a limitation rather than a bug that partition pruning doesn't sup

Re: Expand the use of check_canonical_path() for more GUCs

On Thu, Jul 09, 2020 at 02:19:06PM +0200, Daniel Gustafsson wrote: > Re-reading this thread it seems to me that the conclusion is to mark the patch > Returned with Feedback in this commitfest, and possibly expand documentation > or > comments on path canonicalization in the code at some point. >

Re: Intermittent BRIN failures on hyrax and lousyjack

On 2020-Jul-09, Alvaro Herrera wrote: > I have a moment now, let me have a go at it. I agree with deleting the > message. I think I'll keep the comment, slightly reworded: > > /* >* Placeholder tuples only appear during unfinished summarization, and > we >* hold SUE lock,

Re: Default setting for enable_hashagg_disk

On Thu, Jul 09, 2020 at 06:58:40PM -0400, Stephen Frost wrote: > * Peter Geoghegan (p...@bowt.ie) wrote: > > On Thu, Jul 9, 2020 at 7:03 AM Stephen Frost wrote: > > It makes more sense than simply ignoring what our users will see as a > > simple regression. (Though I still lean towards fixing the

Re: Collation versioning

On Thu, Jul 9, 2020 at 11:13 PM Julien Rouhaud wrote: > On Thu, Jul 9, 2020 at 10:00 AM Peter Eisentraut > wrote: > > In order not to derail this patch set I think it would be okay for now > > to just include all index AMs in dependency tracking and invent a > > mechanism later that excludes hash

Re: Default setting for enable_hashagg_disk

Greetings, * Peter Geoghegan (p...@bowt.ie) wrote: > On Thu, Jul 9, 2020 at 3:58 PM Stephen Frost wrote: > > > That's not the only justification. The other justification is that > > > it's generally reasonable to prefer giving hash aggregate more memory. > > > > Sure, and it's generally reasonabl

Re: Stale external URL in doc?

On 2020-Jul-10, Daniel Gustafsson wrote: > Taking a look at other links to external resources, most links seemed to > resolve still (but I didn't test all of them). I did find another one on the > GEQO page which is now dead without the content available elsewhere, as well > as > a larger proble

Re: pg_dump --where option

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: tested, failed Spec compliant: tested, failed Documentation:tested, failed Hi I had a look at the patch and it cleanly applies to postg

Re: Default setting for enable_hashagg_disk

On Thu, Jul 9, 2020 at 3:58 PM Stephen Frost wrote: > > > If folks > > > want to let HashAgg use more memory then they can set work_mem higher, > > > just the same as if they want a Sort node to use more memory or a > > > HashJoin. Yes, that comes with potential knock-on effects about other > >

Re: Default setting for enable_hashagg_disk

On Thu, Jul 9, 2020 at 3:58 PM Stephen Frost wrote: > > That's not the only justification. The other justification is that > > it's generally reasonable to prefer giving hash aggregate more memory. > > Sure, and it's generally reasonably to prefer giving Sorts more memory > too... as long as you'v

Re: min_safe_lsn column in pg_replication_slots view

On 2020-Jul-09, Tom Lane wrote: > and even the most cursory look at the code confirms that there's a > real bug here. KeepLogSeg expects *logSegNo to be defined on entry, > but GetWALAvailability hasn't bothered to initialize oldestSlotSeg. > It is not clear to me which one is in the wrong; the c

Re: Intermittent BRIN failures on hyrax and lousyjack

On 2020-Jul-09, Tom Lane wrote: > Alvaro Herrera writes: > > On 2020-Jun-30, Tom Lane wrote: > >> SELECT brin_desummarize_range('brinidx', 0); > >> +WARNING: leftover placeholder tuple detected in BRIN index "brinidx", > >> deleting > > >> So (1) the comment needs to be adjusted to mention tha

Re: output columns of \dAo and \dAp

On Thu, Jul 9, 2020 at 10:03 PM Jonathan S. Katz wrote: > From the RMT perspective, if there is an agreed upon approach (which it > sounds like from the above) can someone please commit to working on > resolving this open item? I hardly can extract an approach from this thread, because for me the

Re: Default setting for enable_hashagg_disk

Greetings, * Peter Geoghegan (p...@bowt.ie) wrote: > On Thu, Jul 9, 2020 at 7:03 AM Stephen Frost wrote: > > > The one for the planner is already there, and it looks like we need one > > > for the executor as well (to tell HashAgg to ignore the memory limit > > > just like v12). > > > > No, ignor

Re: Stale external URL in doc?

Daniel Gustafsson writes: > Taking a look at other links to external resources, most links seemed to > resolve still (but I didn't test all of them). I did find another one on the > GEQO page which is now dead without the content available elsewhere, as well > as > a larger problem with the AIX

Re: Intermittent BRIN failures on hyrax and lousyjack

Alvaro Herrera writes: > On 2020-Jun-30, Tom Lane wrote: >> SELECT brin_desummarize_range('brinidx', 0); >> +WARNING: leftover placeholder tuple detected in BRIN index "brinidx", >> deleting >> So (1) the comment needs to be adjusted to mention that vacuum >> cancellation is enough to create th

Re: Default setting for enable_hashagg_disk

On Thu, Jul 9, 2020 at 7:03 AM Stephen Frost wrote: > > The one for the planner is already there, and it looks like we need one > > for the executor as well (to tell HashAgg to ignore the memory limit > > just like v12). > > No, ignoring the limit set was, as agreed above, a bug, and I don't > thi

Re: Stale external URL in doc?

> On 9 Jul 2020, at 17:54, Magnus Hagander wrote: > > On Thu, Jul 9, 2020 at 3:52 PM Tom Lane > wrote: > Daniel Gustafsson mailto:dan...@yesql.se>> writes: > > As a short term fix we should either a) remove these links completely or b) > > link to archived copies of th

Re: min_safe_lsn column in pg_replication_slots view

... or on the other hand, maybe these animals are just showing more sensitivity than others to an actual code bug. skink is showing valgrind failures in this very area, on both HEAD and v13: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2020-07-08%2021%3A13%3A02 ==3166208== VA

Re: Is this a bug in pg_current_logfile() on Windows?

Andrew Dunstan writes: > On 7/9/20 3:36 PM, Tom Lane wrote: >> Should we consider back-patching the CRLF filtering changes, ie >> 91bdf499b + ffb4cee43? It's not really necessary perhaps, but >> I dislike situations where the "same" test on different branches is >> testing different things. Seem

Re: Postgres is not able to handle more than 4k tables!?

On Thu, Jul 9, 2020 at 10:00 PM Nikolay Samokhvalov wrote: > In addition to this, it would be good to consider another optimization for > the default transaction isolation level: making autovacuum to clean dead > tuples in relations that are not currently used in any transaction and when > ther

Re: Auxiliary Processes and MyAuxProc

On Thu, Jul 2, 2020 at 11:11 AM Alvaro Herrera wrote: > > On 2020-Mar-26, Mike Palmiotto wrote: > > Regarding 0001: > > > diff --git a/src/backend/postmaster/subprocess.c > > b/src/backend/postmaster/subprocess.c > > new file mode 100644 > > index 00..3e7a45bf10 > > --- /dev/null > > +++

Re: Is this a bug in pg_current_logfile() on Windows?

On 7/9/20 3:36 PM, Tom Lane wrote: > I wrote: >> Cool, I'll go try changing all those conditions to use the msys test. > OK, that worked: all four relevant buildfarm members are now showing > the expected test failure. So I'll go fix the original bug. > > Should we consider back-patching the CRL

Re: Is this a bug in pg_current_logfile() on Windows?

I wrote: > Cool, I'll go try changing all those conditions to use the msys test. OK, that worked: all four relevant buildfarm members are now showing the expected test failure. So I'll go fix the original bug. Should we consider back-patching the CRLF filtering changes, ie 91bdf499b + ffb4cee43?

Re: Postgres is not able to handle more than 4k tables!?

On 7/8/20 11:41 PM, Konstantin Knizhnik wrote: So looks like NUM_LOCK_PARTITIONS and MAXNUMMESSAGES  constants have to be replaced with GUCs. To avoid division, we can specify log2 of this values, so shift can be used instead. And MAX_SIMUL_LWLOCKS should be defined as NUM_LOCK_PARTITIONS +

Re: Postgres is not able to handle more than 4k tables!?

Greetings, We generally prefer that you don't top-post on these lists. * Nikolay Samokhvalov (samokhva...@gmail.com) wrote: > In addition to this, it would be good to consider another optimization for > the default transaction isolation level: making autovacuum to clean dead > tuples in relations

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

On 7/2/20 11:47 AM, James Coleman wrote: > It seems like the consensus over at another discussion on this topic > [1] is that we ought to go ahead and print the zeros [for machine > readable output formats], even though that creates some interesting > scenarios like the fact that disk sorts will pr

Re: output columns of \dAo and \dAp

On 7/7/20 6:09 PM, Alexander Korotkov wrote: > On Sun, Jun 7, 2020 at 12:34 AM Tom Lane wrote: >> Peter Eisentraut writes: >>> I'm also wondering whether this is fully correct. Would it be possible for >>> the >>> argument types of the operator/function to differ from the left arg/right >>> ar

Re: Postgres is not able to handle more than 4k tables!?

Great idea. In addition to this, it would be good to consider another optimization for the default transaction isolation level: making autovacuum to clean dead tuples in relations that are not currently used in any transaction and when there are no IN_PROGRESS transactions running at RR or S level

Re: Stale external URL in doc?

On Thu, Jul 9, 2020 at 6:36 PM Alvaro Herrera wrote: > On 2020-Jul-09, Magnus Hagander wrote: > > > If we want to keep a set of such links, probably the wiki is a better > place > > as more people can easily fix them there. > > Or, since our docs have diagram capabilities now, we can make our own

Re: posgres 12 bug (partitioned table)

Hey Amit, On Thu, Jul 9, 2020 at 12:16 AM Amit Langote wrote: > By the way, what happens today if you do INSERT INTO a_zedstore_table > ... RETURNING xmin? Do you get an error "xmin is unrecognized" or > some such in slot_getsysattr() when trying to project the RETURNING > list? > We get garba

Re: some more pg_dump refactoring

On 2020-Jul-09, Peter Eisentraut wrote: > On 2020-07-08 06:42, Fabien COELHO wrote: > > > What do you think about this patch to reorganize the existing code from > > > that > > > old commit? > > > > I think it is a definite further improvement. > > > > Patch applies cleanly, compiles, global &

Re: Postgres is not able to handle more than 4k tables!?

On 09.07.2020 19:19, Nikolay Samokhvalov wrote: Hi Konstantin, a silly question: do you consider the workload you have as well-optimized? Can it be optimized further? Reading this thread I have a strong feeling that a very basic set of regular optimization actions is missing here (or not exp

Re: Postgres is not able to handle more than 4k tables!?

Greetings, * Konstantin Knizhnik (k.knizh...@postgrespro.ru) wrote: > It makes me think about two possible optimizations: > > 1. Provide separate invalidation messages for relation metadata and its > statistic. > So update of statistic should not invalidate relation cache. > The main problem with

Re: Postgres is not able to handle more than 4k tables!?

On Thu, Jul 9, 2020 at 6:57 PM Konstantin Knizhnik wrote: > 2. Remember in relation info XID of oldest active transaction at the > moment of last autovacuum. > At next autovacuum iteration we first of all compare this stored XID > with current oldest active transaction XID > and bypass vacuuming t

Re: Stale external URL in doc?

On 2020-Jul-09, Magnus Hagander wrote: > If we want to keep a set of such links, probably the wiki is a better place > as more people can easily fix them there. Or, since our docs have diagram capabilities now, we can make our own diagram. -- Álvaro Herrerahttps://www.2ndQuadran

Re: Log the location field before any backtrace

On 2020-Jul-09, Daniel Gustafsson wrote: > > On 9 Jul 2020, at 11:17, Peter Eisentraut > > wrote: > > > > In PG13, we added the ability to add backtraces to the log output. After > > some practical experience with it, I think the order in which the BACKTRACE > > and the LOCATION fields are pr

Re: Postgres is not able to handle more than 4k tables!?

Hi Konstantin, a silly question: do you consider the workload you have as well-optimized? Can it be optimized further? Reading this thread I have a strong feeling that a very basic set of regular optimization actions is missing here (or not explained): query analysis and optimization based on pg_st

Re: Postgres is not able to handle more than 4k tables!?

On 09.07.2020 18:14, Tom Lane wrote: As I understood the report, it was not "things completely fall over", it was "performance gets bad". But let's get real. Unless the OP has a machine with thousands of CPUs, trying to run this way is counterproductive. Sorry, that I was not clear. It is a

Re: Postgres is not able to handle more than 4k tables!?

Hi Stephen, Thank you for supporting an opinion that it is the problems not only of client system design (I agree it is not so good idea to have thousands tables and thousands active backends) but also of Postgres. We have made more investigation and found out one more problem in Postgres ca

Re: Stale external URL in doc?

On Thu, Jul 9, 2020 at 3:52 PM Tom Lane wrote: > Daniel Gustafsson writes: > > As a short term fix we should either a) remove these links completely or > b) > > link to archived copies of the pages on archive.org; or c) find a more > > appropriate pages to link to. A quick search didn't turn up

Re: Postgres is not able to handle more than 4k tables!?

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> So, that's really the core of your problem. We don't promise that > >> you can run several thousand backends at once. Usually it's recommended > >> that you stick a connecti

Re: Is this a bug in pg_current_logfile() on Windows?

Andrew Dunstan writes: > On 7/9/20 11:04 AM, Tom Lane wrote: >> Therefore, we either should figure out how to get msys perl to do >> that conversion (and remove it from our code altogether), or make the >> conversions conditional on "is it msys perl?". I am not quite sure >> if the existing tests

Re: Is this a bug in pg_current_logfile() on Windows?

On 7/9/20 11:04 AM, Tom Lane wrote: > Andrew Dunstan writes: >> On 7/9/20 10:44 AM, Tom Lane wrote: >>> Andrew Dunstan writes: On 7/8/20 10:40 PM, Tom Lane wrote: > The most likely theory about that, I think, is that IPC::Run::run already > translated any \r\n occurrences in the ps

Re: Postgres is not able to handle more than 4k tables!?

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> So, that's really the core of your problem. We don't promise that >> you can run several thousand backends at once. Usually it's recommended >> that you stick a connection pooler in front of a server with (at most) >> a few hundre

Re: Is this a bug in pg_current_logfile() on Windows?

Andrew Dunstan writes: > On 7/9/20 10:44 AM, Tom Lane wrote: >> Andrew Dunstan writes: >>> On 7/8/20 10:40 PM, Tom Lane wrote: The most likely theory about that, I think, is that IPC::Run::run already translated any \r\n occurrences in the psql command's output to plain \n. >> It's not

Re: Postgres is not able to handle more than 4k tables!?

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Konstantin Knizhnik writes: > > There are several thousand clients, most of which are executing complex > > queries. > > So, that's really the core of your problem. We don't promise that > you can run several thousand backends at once. Usual

Re: Is this a bug in pg_current_logfile() on Windows?

On 7/9/20 10:44 AM, Tom Lane wrote: > Andrew Dunstan writes: >> On 7/8/20 10:40 PM, Tom Lane wrote: >>> So I did that, and the first report is from bowerbird and it's still >>> green. Unless I'm completely misinterpreting what's happening (always >>> a possibility), that means we're still manag

Re: Is this a bug in pg_current_logfile() on Windows?

Andrew Dunstan writes: > On 7/8/20 10:40 PM, Tom Lane wrote: >> So I did that, and the first report is from bowerbird and it's still >> green. Unless I'm completely misinterpreting what's happening (always >> a possibility), that means we're still managing to remove "data" >> occurrences of \r. >

Re: some more pg_dump refactoring

On 2020-07-08 06:42, Fabien COELHO wrote: What do you think about this patch to reorganize the existing code from that old commit? I think it is a definite further improvement. Patch applies cleanly, compiles, global & pg_dump tap test ok, looks ok to me. Thanks. I have committed that, and

Re: Default setting for enable_hashagg_disk

Greetings, * Jeff Davis (pg...@j-davis.com) wrote: > On Wed, 2020-07-08 at 10:00 -0400, Stephen Frost wrote: > > That HashAgg previously didn't care that it was going way over > > work_mem was, if anything, a bug. > > I think we all agree about that, but some people may be depending on > that

Re: Stale external URL in doc?

Daniel Gustafsson writes: > As a short term fix we should either a) remove these links completely or b) > link to archived copies of the pages on archive.org; or c) find a more > appropriate pages to link to. A quick search didn't turn up anything I would > prefer for (c), and I'm not sure what h

Re: Is this a bug in pg_current_logfile() on Windows?

On 7/8/20 10:40 PM, Tom Lane wrote: > I wrote: >> Andrew Dunstan writes: >>> Seems reasonable. If we rip it out completely we'll have to find all the >>> places it breaks and fix them. And we'll almost certainly get new >>> breakage. If it's hiding a real bug we'll have to do that, but I'd be >>>

Re: replication_origin and replication_origin_lsn usage on subscriber

On Thu, Jul 9, 2020 at 6:14 PM Petr Jelinek wrote: > > Hi, > > On 09/07/2020 14:34, Amit Kapila wrote: > > On Thu, Jul 9, 2020 at 5:16 PM Petr Jelinek wrote: > >> > >> On 09/07/2020 13:10, Amit Kapila wrote: > >>> On Thu, Feb 6, 2020 at 2:40 PM Amit Kapila > >>> wrote: > > During logi

Re: Implement UNLOGGED clause for COPY FROM

On 2020/07/09 15:17, osumi.takami...@fujitsu.com wrote: Fujii-san Thank you for your interest in this idea. This feature can work safely with wal_level=replica or logical? Or it can work only with wal_level=minimal? If yes, what is the main difference between this method and wal_skip_thresh

Re: [doc] modifying unit from characters to bytes

On 2020-07-09 13:47, Fujii Masao wrote: On 2020/07/08 17:12, Daniel Gustafsson wrote: On 8 Jul 2020, at 10:05, Fujii Masao wrote: On 2020/07/08 16:17, Daniel Gustafsson wrote: On 8 Jul 2020, at 04:25, Fujii Masao wrote: On 2020/07/08 10:54, torikoshia wrote: Hi, The manual describes the

Re: replication_origin and replication_origin_lsn usage on subscriber

Hi, On 09/07/2020 14:34, Amit Kapila wrote: On Thu, Jul 9, 2020 at 5:16 PM Petr Jelinek wrote: On 09/07/2020 13:10, Amit Kapila wrote: On Thu, Feb 6, 2020 at 2:40 PM Amit Kapila wrote: During logical decoding, we send replication_origin and replication_origin_lsn when we decode commit. I

Re: replication_origin and replication_origin_lsn usage on subscriber

On Thu, Jul 9, 2020 at 5:16 PM Petr Jelinek wrote: > > On 09/07/2020 13:10, Amit Kapila wrote: > > On Thu, Feb 6, 2020 at 2:40 PM Amit Kapila wrote: > >> > >> During logical decoding, we send replication_origin and > >> replication_origin_lsn when we decode commit. In pgoutput_begin_txn, > >> we

Re: Implementing Incremental View Maintenance

On Tue, Jul 7, 2020 at 3:26 PM Tatsuo Ishii wrote: > >> Query checks for following restrictions are added: > > > > > > Are all known supported cases listed below? > > They are "restrictions" and are not supported. > Yes, I missed the "not" word:( > > >> - inheritance parent table > >> ... > >>

Re: Implement UNLOGGED clause for COPY FROM

On Thu, Jul 9, 2020 at 11:47 AM osumi.takami...@fujitsu.com wrote: > > > In terms of streaming replication, > I'd like to ask for advice of other members in this community. > Now, I think this feature requires to re-create standby > immediately after the COPY UNLOGGED like Oracle's clause > This

Re: Expand the use of check_canonical_path() for more GUCs

Re-reading this thread it seems to me that the conclusion is to mark the patch Returned with Feedback in this commitfest, and possibly expand documentation or comments on path canonicalization in the code at some point. Does that seem fair? cheers ./daniel

Re: expose parallel leader in CSV and log_line_prefix

On Thu, Jul 9, 2020 at 1:48 PM Daniel Gustafsson wrote: > > > On 18 Mar 2020, at 22:25, Justin Pryzby wrote: > > > This also fixes unsafe access to lockGroupLeader->pid, same issue as in the > > original v1 patch for b025f32e0b. > > Julian, having been involved in the other threads around this to

Re: expose parallel leader in CSV and log_line_prefix

> On 18 Mar 2020, at 22:25, Justin Pryzby wrote: > This also fixes unsafe access to lockGroupLeader->pid, same issue as in the > original v1 patch for b025f32e0b. Julian, having been involved in the other threads around this topic, do you have time to review this latest version during the commit

Re: replication_origin and replication_origin_lsn usage on subscriber

On 09/07/2020 13:10, Amit Kapila wrote: On Thu, Feb 6, 2020 at 2:40 PM Amit Kapila wrote: During logical decoding, we send replication_origin and replication_origin_lsn when we decode commit. In pgoutput_begin_txn, we send values for these two but never used on the subscriber side. Though we

Re: Allow an alias to be attached directly to a JOIN ... USING

> On 27 Jan 2020, at 10:19, Peter Eisentraut > wrote: > > On 2019-12-31 00:07, Vik Fearing wrote: >> One thing I notice is that the joined columns are still accessible from >> their respective table names when they should not be per spec. That >> might be one of those "silly restrictions" that

Re: Log the location field before any backtrace

> On 9 Jul 2020, at 11:17, Peter Eisentraut > wrote: > > In PG13, we added the ability to add backtraces to the log output. After some > practical experience with it, I think the order in which the BACKTRACE and > the LOCATION fields are printed is wrong. I propose we put the LOCATION > fiel

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

On Thu, Jul 9, 2020 at 2:41 PM Dilip Kumar wrote: > > On Wed, Jul 8, 2020 at 3:32 PM Amit Kapila wrote: > > > > Only replying to the replication origin point, other comment looks > fine to me so I will work on those. > > > Replication Origins > > -- > > I think we also

Re: Collation versioning

On Thu, Jul 9, 2020 at 10:00 AM Peter Eisentraut wrote: > > On 2020-07-08 08:26, Michael Paquier wrote: > > On Wed, Jul 08, 2020 at 06:12:51PM +1200, Thomas Munro wrote: > >> I still wish I had a better idea than this: > >> > >> +/* > >> + * Returns whether the given index access method depend on

Re: replication_origin and replication_origin_lsn usage on subscriber

On Thu, Feb 6, 2020 at 2:40 PM Amit Kapila wrote: > > During logical decoding, we send replication_origin and > replication_origin_lsn when we decode commit. In pgoutput_begin_txn, > we send values for these two but never used on the subscriber side. > Though we have provided a function (logicalr

Re: Performing partition pruning using row value

On 2020/07/09 19:45, Etsuro Fujita wrote: Kato-san, On Thu, Jul 9, 2020 at 5:43 PM kato-...@fujitsu.com wrote: I made a patch that enable partition pruning using row-wise comparison. Please review and comment on this patch. Thanks for the patch! Please add the patch to the next CF so t

Re: SyncRepLock acquired exclusively in default configuration

On 2020/05/19 11:41, Masahiko Sawada wrote: On Sat, 11 Apr 2020 at 09:30, Masahiko Sawada wrote: On Fri, 10 Apr 2020 at 21:52, Fujii Masao wrote: On 2020/04/10 20:56, Masahiko Sawada wrote: On Fri, 10 Apr 2020 at 18:57, Fujii Masao wrote: On 2020/04/10 14:11, Masahiko Sawada wrot

Re: Performing partition pruning using row value

Kato-san, On Thu, Jul 9, 2020 at 5:43 PM kato-...@fujitsu.com wrote: > I made a patch that enable partition pruning using row-wise comparison. > Please review and comment on this patch. Please add the patch to the next CF so that it does not get lost. Thanks! Best regards, Etsuro Fujita

Re: Physical replication slot advance is not persistent

On Fri, Jun 19, 2020 at 12:16 AM Alexey Kondratov wrote: > > 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 stab

  1   2   >