Re: abstract Unix-domain sockets

On 2020-11-24 16:49, David G. Johnston wrote: On Tue, Nov 24, 2020 at 8:45 AM Peter Eisentraut > wrote: We're subject to whatever the kernel behavior is.  If the kernel doesn't report address conflicts for Unix-domain sockets, then we can't

Re: abstract Unix-domain sockets

On 2020-11-24 02:57, Michael Paquier wrote: On Fri, Nov 20, 2020 at 04:06:43PM +0100, Peter Eisentraut wrote: I think we are getting a bit sidetracked here with the message wording. The reason I looked at this was that "remove socket file and retry" is never an appropriate action with abstract

Re: Parallel plans and "union all" subquery

On 24-11-2020 01:44, Greg Nancarrow wrote: On Tue, Nov 24, 2020 at 2:34 AM Luc Vlaming wrote: Hi, For this problem there is a patch I created, which is registered under https://commitfest.postgresql.org/30/2787/ that should fix this without any workarounds. Maybe someone can take a look at

Re: walsender bug: stuck during shutdown

On 2020/11/25 0:07, Alvaro Herrera wrote: Hello, On 2020-Nov-24, Fujii Masao wrote: Thanks for working on this! Could you tell me the discussion thread where Chloe Dives reported the issue to? Sorry I could not find that.. It was not public -- sorry I didn't make that clear. I'd like

Re: [HACKERS] logical decoding of two-phase transactions

Hi Amit. IIUC the tablesync worker runs in a single transaction. Last week I discovered and described [1] a problem where/if (by unlucky timing) the tablesync worker gets to handle the 2PC PREPARE TRANSACTION then that whole single tx is getting committed, regardless that a COMMIT PREPARED was

Re: autovac issue with large number of tables

Hi, On Wed, Nov 25, 2020 at 2:17 PM Masahiko Sawada wrote: > > On Fri, Sep 4, 2020 at 7:50 PM Kasahara Tatsuhito > wrote: > > > > Hi, > > > > On Wed, Sep 2, 2020 at 2:10 AM Kasahara Tatsuhito > > wrote: > > > > I wonder if we could have table_recheck_autovac do two probes of the > > > > stats

Re: vac_update_datfrozenxid will raise "wrong tuple length" if pg_database tuple contains toast attribute.

On Wed, Nov 18, 2020 at 06:32:51AM +, Junfeng Yang wrote: > A path is attached co auther by Ashwin Agrawal, the solution is to > fetch the pg_database tuple from disk instead of system cache if > needed. Yeah, we had better fix and I guess backpatch something here. That's annoying. +DROP

Re: default result formats setting

On 2020-11-16 16:15, Andrew Dunstan wrote: I think this is conceptually OK, although it feels a bit odd. Might it be better to have the values as typename={binary,text} pairs instead of oid={0,1} pairs, which are fairly opaque? That might make things easier for things like UDTs where the oid

Re: Libpq support to connect to standby server as priority

On Wed, Nov 25, 2020 at 12:07 PM Tom Lane wrote: > > > Here's a v2 that does it like that. > Looks OK to me. Regards, Greg Nancarrow Fujitsu Australia

Re: [PATCH] Add features to pg_stat_statements

2020-11-25 13:13 に Fujii Masao さんは書きました: On 2020/11/25 12:02, Seino Yuki wrote: 2020-11-17 01:46 に Fujii Masao さんは書きました: On 2020/11/16 12:22, Seino Yuki wrote: Thanks for updating the patch! +    pgss_info->dealloc = 0; +    SpinLockInit(_info->mutex); +   

RE: POC: postgres_fdw insert batching

From: Craig Ringer > I suggest that when developing this, you keep in mind the ongoing work on the > libpq pipelining/batching enhancements, and also the way many interfaces to > foreign data sources support asynchronous, concurrent operations. Yes, thank you, I bear it in mind. I understand

Re: [Proposal] Global temporary tables

po 23. 11. 2020 v 10:27 odesílatel 曾文旌 napsal: > > > 2020年11月21日 02:28，Pavel Stehule 写道： > > Hi > > pá 11. 9. 2020 v 17:00 odesílatel 曾文旌 > napsal: > >> I have written the README for the GTT, which contains the GTT >> requirements and design. >> I found that compared to my first email a year

Re: [PATCH] LWLock self-deadlock detection

On Tue, Nov 24, 2020 at 10:11 PM Ashutosh Bapat < ashutosh.bapat@gmail.com> wrote: > This looks useful. LWLockCheckSelfDeadlock() could use LWLockHeldByMe > variant instead of copying that code with possibly a change in that > function to return the required information. > Yes, possibly so.

Re: Remove cache_plan argument comments to ri_PlanCheck

On Tue, Nov 24, 2020 at 7:26 PM Amit Kapila wrote: > > On Tue, Nov 24, 2020 at 4:46 PM Li Japin wrote: > > > > Hi, hackers > > > > I found that the cache_plan argument to ri_PlanCheck already been remove > > since > > 5b7ba75f7ff854003231e8099e3038c7e2eba875. I think we can remove the > >

Re: A few new options for CHECKPOINT

On 2020/11/25 13:47, Michael Paquier wrote: On Wed, Nov 25, 2020 at 01:07:47AM +, tsunakawa.ta...@fujitsu.com wrote: From: Bossart, Nathan It may be useful for backups taken with the "consistent snapshot" approach. As noted in the documentation [0], running CHECKPOINT before taking

Re: [doc] plan invalidation when statistics are update

On Wed, Nov 25, 2020 at 1:13 PM Fujii Masao wrote: > > > On 2020/11/24 23:14, Fujii Masao wrote: > > > > > > On 2020/11/19 14:33, torikoshia wrote: > >> On 2020-11-18 11:35, Fujii Masao wrote: > >> > >> Thanks for your comment! > >> > >>> On 2020/11/18 11:04, torikoshia wrote: > Hi, >

Re: autovac issue with large number of tables

On Fri, Sep 4, 2020 at 7:50 PM Kasahara Tatsuhito wrote: > > Hi, > > On Wed, Sep 2, 2020 at 2:10 AM Kasahara Tatsuhito > wrote: > > > I wonder if we could have table_recheck_autovac do two probes of the stats > > > data. First probe the existing stats data, and if it shows the table to > > > be

Re: [doc] plan invalidation when statistics are update

On 2020/11/24 23:14, Fujii Masao wrote: On 2020/11/19 14:33, torikoshia wrote: On 2020-11-18 11:35, Fujii Masao wrote: Thanks for your comment! On 2020/11/18 11:04, torikoshia wrote: Hi, AFAIU, when the planner statistics are updated, generic plans are invalidated and PostgreSQL

Re: About adding a new filed to a struct in primnodes.h

On Wed, Nov 25, 2020 at 11:54 AM Tom Lane wrote: > Andy Fan writes: > > On Wed, Nov 25, 2020 at 9:40 AM Tom Lane wrote: > >> What exactly would be the value of that? > >> ... > > > I agree with this, but I don't think there is no value in my suggestion > > unless I missed something. Per my

RE: POC: postgres_fdw insert batching

From: Tomas Vondra > On 11/24/20 9:45 AM, tsunakawa.ta...@fujitsu.com wrote: > > OTOH, as for the name GetModifyBatchSize() you suggest, I think > GetInsertBatchSize may be better. That is, this API deals with multiple > records in a single INSERT statement. Your GetModifyBatchSize will be >

Re: Dereference before NULL check (src/backend/storage/ipc/latch.c)

On Thu, Nov 5, 2020 at 10:47 AM Ranier Vilela wrote: > Em ter., 3 de nov. de 2020 às 22:09, Kyotaro Horiguchi > escreveu: >> If we call WaitLatch(OrSocket) that waits on the latch, it immediately >> returns because the latch is set. If we called ResetLatch before the >> next call to

Re: A few new options for CHECKPOINT

On Wed, Nov 25, 2020 at 01:07:47AM +, tsunakawa.ta...@fujitsu.com wrote: > From: Bossart, Nathan >> It may be useful for backups taken with the "consistent snapshot" >> approach. As noted in the documentation [0], running CHECKPOINT >> before taking the snapshot can reduce recovery time.

Re: Deleting older versions in unique indexes to avoid page splits

On Tue, Nov 17, 2020 at 12:45 PM Peter Geoghegan wrote: > > I am thinking of two more scenarios that require testing: > > - queue in the table, with a high rate of INSERTs+DELETEs and a long > > transaction. > > I see your point. This is going to be hard to make work outside of > unique indexes,

Re: [PATCH] Add features to pg_stat_statements

On 2020/11/25 12:02, Seino Yuki wrote: 2020-11-17 01:46 に Fujii Masao さんは書きました: On 2020/11/16 12:22, Seino Yuki wrote: Thanks for updating the patch! +    pgss_info->dealloc = 0; +    SpinLockInit(_info->mutex); +    Assert(pgss_info->dealloc == 0); Why is this assertion check

Re: WIP: WAL prefetch (another approach)

On Thu, Nov 19, 2020 at 10:00 AM Stephen Frost wrote: > * Thomas Munro (thomas.mu...@gmail.com) wrote: > > Hmm. Every time I try to think of a protocol change for the > > restore_command API that would be acceptable, I go around the same > > circle of thoughts about event flow and realise that

Re: About adding a new filed to a struct in primnodes.h

Andy Fan writes: > On Wed, Nov 25, 2020 at 9:40 AM Tom Lane wrote: >> What exactly would be the value of that? >> ... > I agree with this, but I don't think there is no value in my suggestion > unless I missed something. Per my current understanding, the code > is too easy to make the datadir

Re: Add table access method as an option to pgbench

On Tue, Nov 24, 2020 at 03:32:38PM -0800, David Zhang wrote: > But, providing another option for the end user may not be a bad idea, and it > might make the tests easier at some points. My first thought is that we have no need to complicate pgbench with this option because there is a GUC able to

Re: Any objections to implementing LogicalDecodeMessageCB for pgoutput?

On Wed, 18 Nov 2020 at 03:04, David Pirotte wrote: > On Fri, Nov 6, 2020 at 7:05 AM Ashutosh Bapat < > ashutosh.bapat@gmail.com> wrote: > >> +/* >> + * Write MESSAGE to stream >> + */ >> +void >> +logicalrep_write_message(StringInfo out, ReorderBufferTXN *txn, >> XLogRecPtr lsn, >> +

Re: Removal of currtid()/currtid2() and some table AM cleanup

On Sun, Nov 22, 2020 at 08:11:21PM +0900, Michael Paquier wrote: > Okay, here you go with the attached. If there are any other comments, > please feel free. Hearing nothing, applied this one after going through the ODBC driver code again this morning. Compatibility is exactly the same for

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

On Wed, Nov 25, 2020 at 7:24 AM Craig Ringer wrote: > > A quick thought here. > > Would it make sense to add a hook in the DISCARD ALL implementation that > postgres_fdw can register for? > > There's precedent here, since DISCARD ALL already has the same effect as > SELECT

Re: [PATCH] Add features to pg_stat_statements

2020-11-17 01:46 に Fujii Masao さんは書きました: On 2020/11/16 12:22, Seino Yuki wrote: Thanks for updating the patch! +    pgss_info->dealloc = 0; +    SpinLockInit(_info->mutex); +    Assert(pgss_info->dealloc == 0); Why is this assertion check necessary? It seems not necessary. +    {

Re: Parallel Inserts in CREATE TABLE AS

On Tue, Nov 24, 2020 at 4:43 PM Hou, Zhijie wrote: > > I'm very interested in this feature, > and I'm looking at the patch, here are some comments. > Thanks for the review. > > How about the following style: > > if(TupIsNull(outerTupleSlot)) > Break; > >

Re: Strange behavior with polygon and NaN

(My mailer seems to have recovered from unresponsiveness.) At Tue, 24 Nov 2020 12:29:41 -0500, Tom Lane wrote in > Kyotaro Horiguchi writes: > > At Fri, 20 Nov 2020 15:57:46 -0500, Tom Lane wrote in > >> I don't much like anything about float8_coef_mul(). > > > I have the same feeling on

Re: About adding a new filed to a struct in primnodes.h

On Wed, Nov 25, 2020 at 9:40 AM Tom Lane wrote: > Andy Fan writes: > > What I mean here is something like below. > > What exactly would be the value of that? > > There is work afoot, or at least on people's to-do lists, to mechanize > creation of the outfuncs/readfuncs/etc code directly from

Re: [PoC] Non-volatile WAL buffer

On 11/25/20 2:10 AM, Ashwin Agrawal wrote: > On Sun, Nov 22, 2020 at 5:23 PM Tomas Vondra > wrote: > >> I'm not entirely sure whether the "pmemdax" (i.e. unpatched instance >> with WAL on PMEM DAX device) is actually safe, but I included it anyway >> to see what difference is. > > I am curious

Re: Terminate the idle sessions

On Nov 24, 2020, at 11:20 PM, David G. Johnston mailto:david.g.johns...@gmail.com>> wrote: On Mon, Nov 23, 2020 at 11:22 PM Li Japin mailto:japi...@hotmail.com>> wrote: How about use “foreign-data wrapper” replace “postgres_fdw”? I don't see much value in avoiding mentioning that specific

Re: POC: postgres_fdw insert batching

On Thu, Oct 8, 2020 at 10:40 AM tsunakawa.ta...@fujitsu.com < tsunakawa.ta...@fujitsu.com> wrote: > > Thank you for picking up this. I'm interested in this topic, too. (As an > aside, we'd like to submit a bulk insert patch for ECPG in the near future.) > > As others referred, Andrey-san's fast

Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path

David Rowley writes: > So, how about the attached today and I'll email Joseph about walleye > and see if he can upgrade to a newer minGW version. WFM. (Note I already cc'd Joseph on this thread.) regards, tom lane

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

On Wed, Nov 25, 2020 at 2:43 AM Alexey Kondratov wrote: > On 2020-11-24 06:52, Bharath Rupireddy wrote: > > Thanks for the review comments. > > > > On Mon, Nov 23, 2020 at 9:57 PM Alexey Kondratov > > wrote: > >> > >> > v1-0001-postgres_fdw-function-to-discard-cached-connections.patch > >> > >>

Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path

David Rowley writes: > On Wed, 25 Nov 2020 at 14:28, Tom Lane wrote: >> So maybe, rather than hacking up the attribute stuff for >> a bug that might bite us again anyway in future, we ought >> to press walleye's owner to install a more recent compiler. > I think that seems like a better idea.

Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path

On Wed, 25 Nov 2020 at 14:35, David Rowley wrote: > > On Wed, 25 Nov 2020 at 14:28, Tom Lane wrote: > > So maybe, rather than hacking up the attribute stuff for > > a bug that might bite us again anyway in future, we ought > > to press walleye's owner to install a more recent compiler. > > I

Re: [PoC] Non-volatile WAL buffer

On 11/25/20 1:27 AM, tsunakawa.ta...@fujitsu.com wrote: > From: Tomas Vondra >> It's interesting that they only place the tail of the log on PMEM, >> i.e. the PMEM buffer has limited size, and the rest of the log is >> not on PMEM. It's a bit as if we inserted a PMEM buffer between our >> wal

Re: About adding a new filed to a struct in primnodes.h

Andy Fan writes: > What I mean here is something like below. What exactly would be the value of that? There is work afoot, or at least on people's to-do lists, to mechanize creation of the outfuncs/readfuncs/etc code directly from the Node struct declarations. So special cases for particular

Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path

On Wed, 25 Nov 2020 at 14:28, Tom Lane wrote: > So maybe, rather than hacking up the attribute stuff for > a bug that might bite us again anyway in future, we ought > to press walleye's owner to install a more recent compiler. I think that seems like a better idea. I had thoughts about

Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path

Alvaro Herrera writes: >> On Wed, 25 Nov 2020 at 04:55, Tom Lane wrote: >>> walleye's been failing since this patchset went in: >>> I have no idea what to make of that, but it looks more like a compiler bug >>> than anything else. > Apparently the bug was fixed days after it was reported, >

Re: About adding a new filed to a struct in primnodes.h

On Wed, Nov 25, 2020 at 8:10 AM Andy Fan wrote: > > > On Tue, Nov 24, 2020 at 11:11 PM Alvaro Herrera > wrote: > >> On 2020-Nov-24, Andy Fan wrote: >> >> > then we modified the copy/read/out functions for this node. In >> > _readFuncExpr, >> > we probably add something like >> >> > [ ... ] >>

Re: [PoC] Non-volatile WAL buffer

On Sun, Nov 22, 2020 at 5:23 PM Tomas Vondra wrote: > I'm not entirely sure whether the "pmemdax" (i.e. unpatched instance > with WAL on PMEM DAX device) is actually safe, but I included it anyway > to see what difference is. I am curious to learn more on this aspect. Kernels have provided

RE: A few new options for CHECKPOINT

From: Bossart, Nathan > It may be useful for backups taken with the "consistent snapshot" > approach. As noted in the documentation [0], running CHECKPOINT > before taking the snapshot can reduce recovery time. However, users > might wish to avoid the IO spike caused by an immediate checkpoint.

Re: Libpq support to connect to standby server as priority

I wrote: > Alvaro Herrera writes: >> Agreed. If this is just a few hundred bytes of server-side local memory >> per backend, it seems definitely worth it. > Yeah, given the current set of GUC_REPORT variables, it's hard to see > the storage for their last-reported values amounting to much. The

Re: A few new options for CHECKPOINT

On 11/24/20, 4:03 PM, "tsunakawa.ta...@fujitsu.com" wrote: > From: Bossart, Nathan >> The main purpose of this patch is to give users more control over their >> manually >> requested checkpoints or restartpoints. I suspect the most useful option is >> IMMEDIATE, which can help avoid

RE: A few new options for CHECKPOINT

From: Bossart, Nathan > The main purpose of this patch is to give users more control over their > manually > requested checkpoints or restartpoints. I suspect the most useful option is > IMMEDIATE, which can help avoid checkpoint- related IO spikes. However, I > didn't see any strong reason to

Add table access method as an option to pgbench

Hi Hackers, I noticed that there is a table access method API added starting from PG12. In other words, Postgresql open the door for developers to add their own access methods, for example, zheap, zedstore etc. However, the current pgbench doesn't have an option to allow user to specify which

Re: Libpq support to connect to standby server as priority

Alvaro Herrera writes: > On 2020-Nov-24, Tom Lane wrote: >>> As it stands, 0001 reduces the ParameterStatus message traffic to >>> at most one per GUC per query, but it doesn't attempt to eliminate >>> duplicate ParameterStatus messages altogether. We could do that >>> as a pretty simple

Re: Libpq support to connect to standby server as priority

On 2020-Nov-24, Tom Lane wrote: > I'm inclined to go ahead and commit the 0001 patch I posted at [1] > (ie, change the implementation of GUC_REPORT to avoid intra-query > reports), since that addresses a performance problem that's > independent of the goal here. The rest of this seems to still >

Re: remove spurious CREATE INDEX CONCURRENTLY wait

On 2020-Nov-23, Tom Lane wrote: > Alvaro Herrera writes: > > GetCurrentVirtualXIDs, ComputeXidHorizons, GetSnapshotData: > > > In these cases, what we need is that the code computes some xmin (or > > equivalent computation) based on a set of transactions that exclude > > those marked with the

Re: Libpq support to connect to standby server as priority

Anastasia Lubennikova writes: > Hi, this entry is "Waiting on Author" and the thread was inactive for a > while. As far as I see, the patch needs some further work. > Are you going to continue working on it, or should I mark it as > "returned with feedback" until a better time? I'm inclined to

Re: remove spurious CREATE INDEX CONCURRENTLY wait

On 2020-Nov-23, Andres Freund wrote: > On 2020-11-23 12:30:05 -0300, Alvaro Herrera wrote: > > PROC_IN_LOGICAL_DECODING: > > Oddly enough, I think the reset of PROC_IN_LOGICAL_DECODING in > > ReplicationSlotRelease might be the most problematic one of the lot. > > That's because a proc's xmin

Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path

Alvaro Herrera writes: > On 2020-Nov-24, Tom Lane wrote: >> I'd make any such fix as narrow as possible (ie MINGW64 only, based on >> present evidence). It'd be nice to have a compiler version upper bound >> too, in the hopes that they'd fix it in future. Maybe something like >> "#if

Re: libpq compression

On 24.11.2020 20:34, Daniil Zakhlystov wrote: The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: tested, passed Spec compliant: tested, failed Documentation:tested, failed Submission

Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path

On 2020-Nov-24, Tom Lane wrote: > David Rowley writes: > > On Wed, 25 Nov 2020 at 04:55, Tom Lane wrote: > >> walleye's been failing since this patchset went in: > >> I have no idea what to make of that, but it looks more like a compiler bug > >> than anything else. > > > I wondered if #if

Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path

David Rowley writes: > On Wed, 25 Nov 2020 at 04:55, Tom Lane wrote: >> walleye's been failing since this patchset went in: >> I have no idea what to make of that, but it looks more like a compiler bug >> than anything else. > I wondered if #if !defined(__MINGW32__) && !defined(__MINGW64__)

Re: libpq compression

On 24.11.2020 21:35, Robert Haas wrote: On Tue, Nov 24, 2020 at 12:35 PM Daniil Zakhlystov wrote: To sum up, I think that the current implementation already introduces good benefits. As I proposed in the Usability review, we may introduce the new approaches later as separate compression

Re: mark/restore failures on unsorted merge joins

Andrew Gierth writes: > "Tom" == Tom Lane writes: > Tom> Looks about right. Not sure if we need to bother with a regression > Tom> test case; once that's in, it'd be hard to break it. > We could check the EXPLAIN output (since the Materialize node would show > up), but it's not easy to get

Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path

On Wed, 25 Nov 2020 at 04:55, Tom Lane wrote: > > walleye's been failing since this patchset went in: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=walleye=2020-11-24%2000%3A25%3A31 > > ccache gcc -Wall -Wmissing-prototypes -Wpointer-arith > -Wdeclaration-after-statement

Re: mark/restore failures on unsorted merge joins

> "Tom" == Tom Lane writes: >> I guess that's close enough; this should suffice then. Tom> Looks about right. Not sure if we need to bother with a regression Tom> test case; once that's in, it'd be hard to break it. We could check the EXPLAIN output (since the Materialize node would

Re: bug in pageinspect's "tuple data" feature

On Sat, Nov 21, 2020 at 2:32 PM Alvaro Herrera wrote: > If you have a sufficiently broken data page, pageinspect throws an > error when trying to examine the page: > > ERROR: invalid memory alloc request size 18446744073709551451 > > This is pretty unhelpful; it would be better not to try to

Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path

On Wed, 25 Nov 2020 at 04:48, Peter Eisentraut wrote: > > On 2020-11-24 01:52, Dagfinn Ilmari Mannsåker wrote: > > The Clang documentation¹ suggest an even neater solution, which would > > eliminate the repetitive empty pg_attribute_foo #defines in the trailing > > #else/#endif block in commit

Ready For Committer patches (CF 2020-11)

Hi, with this message, I want to draw attention to the RFC patches on the current commitfest. It would be good if committers could take a look at them. While doing a sweep through the CF, I have kicked a couple of entries back to Waiting on author, so now the list is correct. Now we have 17

Re: mark/restore failures on unsorted merge joins

Andrew Gierth writes: > I guess that's close enough; this should suffice then. Looks about right. Not sure if we need to bother with a regression test case; once that's in, it'd be hard to break it. regards, tom lane

Re: libpq compression

I completely agree that backward-compatibility is important here. I think that it is a good idea to clarify how the compression establishment works in the current version of the patch: 1. Frontend send the startup packet which may look like this: _pq_.compression = 'zlib,zstd' (I omitted the

Re: mark/restore failures on unsorted merge joins

> "Tom" == Tom Lane writes: Tom> Oh, sorry, I misread your comment to be that you wanted to add a Tom> field to IndexAmRoutine. You're right, the real issue here is that Tom> ExecSupportsMarkRestore lacks any convenient access to the needed Tom> info, and we need to add a bool to

Re: enable_incremental_sort changes query behavior

James Coleman writes: > On Mon, Nov 23, 2020 at 2:24 PM Tom Lane wrote: >> 1. James was wondering, far upthread, why we would do projections >> pre-sort or post-sort. I think the answers can be found by studying >> planner.c's make_sort_input_target(), which separates out what we want >> to do

Re: [HACKERS] Custom compression methods

On 2020-Nov-24, Tom Lane wrote: > Robert Haas writes: > > Oh, I thought it had been suggested in previous discussions that these > > should be treated as access methods rather than inventing a whole new > > concept just for this, and it seemed like a good idea to me. I guess I > > missed the

Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:not tested Given we got two other reviews from Neil and David, I think I can

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

On 2020-11-24 06:52, Bharath Rupireddy wrote: Thanks for the review comments. On Mon, Nov 23, 2020 at 9:57 PM Alexey Kondratov wrote: > v1-0001-postgres_fdw-function-to-discard-cached-connections.patch This patch looks pretty straightforward for me, but there are some things to be addressed

Re: [HACKERS] Custom compression methods

On Tue, Nov 24, 2020 at 1:21 PM Tom Lane wrote: > FWIW, I kind of agree with Robert's take on this. Heap and index AMs > are pretty fundamentally different animals, yet we don't have a problem > sticking them in the same catalog. I think anything that is related to > storage access could

Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted

I verified the patch "v2-0001-Free-disk-space-for-dropped-relations-on-commit.patch" on master branch "0cc9932740f2bf572303b68438e4caf62de9". It works for me. Below is my test procedure and results. === Before the patch === #1 from psql console 1, create table and index then insert enough

Re: libpq compression

On Tue, Nov 24, 2020 at 12:35 PM Daniil Zakhlystov wrote: > To sum up, I think that the current implementation already introduces good > benefits. As I proposed in the Usability review, we may introduce the new > approaches later as separate compression 'algorithms'. I don't think the current

Re: mark/restore failures on unsorted merge joins

Andrew Gierth writes: > "Tom" == Tom Lane writes: > Tom> Uh, why would you not just look to see if the ammarkpos/amrestrpos > Tom> fields are non-null? > We don't (in the back branches) seem to have a pointer to the > IndexAmRoutine handy, only the oid? Oh, sorry, I misread your comment to

Re: [PoC] Non-volatile WAL buffer

On 11/24/20 7:34 AM, tsunakawa.ta...@fujitsu.com wrote: > From: Tomas Vondra >> So I wonder if using PMEM for the WAL buffer is the right way forward. >> AFAIK the WAL buffer is quite concurrent (multiple clients writing >> data), which seems to contradict the PMEM vs. DRAM trade-offs. >> >>

Re: [HACKERS] Custom compression methods

Robert Haas writes: > On Tue, Nov 24, 2020 at 10:47 AM Dilip Kumar wrote: >> For the compression routine name, I did not include "Am" because >> currently, we are storing the compression method in the new catalog >> "pg_compression" not in the pg_am. So are you suggesting that we >> should

Re: mark/restore failures on unsorted merge joins

> "Tom" == Tom Lane writes: >> The problem is that the planner calls ExecSupportsMarkRestore to >> find out whether a Materialize node is needed, and that function >> looks no further than the Path type of T_Index[Only]Path in order to >> return true, even though in this case it's a GiST

Re: Online verification of checksums

Hi Michael, On 11/23/20 8:10 PM, Michael Paquier wrote: On Mon, Nov 23, 2020 at 10:35:54AM -0500, Stephen Frost wrote: Also- what is the point of reading the page from shared buffers anyway..? All we need to do is prove that the page will be rewritten during WAL replay. If we can prove

Re: libpq compression

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: tested, passed Spec compliant: tested, failed Documentation:tested, failed Submission review -- Is the patch in a patch format which

Re: Strange behavior with polygon and NaN

Kyotaro Horiguchi writes: > At Fri, 20 Nov 2020 15:57:46 -0500, Tom Lane wrote in >> I don't much like anything about float8_coef_mul(). > I have the same feeling on the function, but I concluded that > coefficients and coordinates should be regarded as different things in > the practical

Re: PoC/WIP: Extended statistics on expressions

On 11/24/20 5:23 PM, Justin Pryzby wrote: > On Mon, Nov 23, 2020 at 04:30:26AM +0100, Tomas Vondra wrote: >> 0004 - Seems fine. IMHO not really "silly errors" but OK. > > This is one of the same issues you pointed out - shadowing a variable. > Could be backpatched. > > On Mon, Nov 23, 2020 at

Re: [HACKERS] Custom compression methods

On Tue, Nov 24, 2020 at 10:47 AM Dilip Kumar wrote: > For the compression routine name, I did not include "Am" because > currently, we are storing the compression method in the new catalog > "pg_compression" not in the pg_am. So are you suggesting that we > should store the compression methods

Re: POC: postgres_fdw insert batching

On 11/24/20 9:45 AM, tsunakawa.ta...@fujitsu.com wrote: > From: Tomas Vondra >> 1) We're calling it "batch_size" but the API function is named >> postgresGetMaxBulkInsertTuples(). Perhaps we should rename the function >> to postgresGetModifyBatchSize()? That has the advantage it'd work if we

Re: pg_ls_tmpdir to show directories and shared filesets (and pg_ls_*)

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> I took a quick look through this. This is just MHO, of course: > >> > >> * I don't think it's okay to change the existing signatures of > >> pg_ls_logdir() et al. > > > I

Re: PoC/WIP: Extended statistics on expressions

On Mon, Nov 23, 2020 at 04:30:26AM +0100, Tomas Vondra wrote: > 0004 - Seems fine. IMHO not really "silly errors" but OK. This is one of the same issues you pointed out - shadowing a variable. Could be backpatched. On Mon, Nov 23, 2020 at 04:30:26AM +0100, Tomas Vondra wrote: > > +

Re: libpq compression

On Tue, Nov 24, 2020 at 7:33 AM Konstantin Knizhnik wrote: > New version of the patch is attached. I read over the comments from Andres (and Peter) suggesting that this ought to be on-the-fly configurable. Here are some thoughts on making that work with the wire protocol: If the client

Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path

David Rowley writes: > Pushed. walleye's been failing since this patchset went in: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=walleye=2020-11-24%2000%3A25%3A31 ccache gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels

Re: abstract Unix-domain sockets

On Tue, Nov 24, 2020 at 8:45 AM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > We're subject to whatever the kernel behavior is. If the kernel doesn't > report address conflicts for Unix-domain sockets, then we can't do > anything about that. Having an error message ready in case

Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path

On 2020-11-24 01:52, Dagfinn Ilmari Mannsåker wrote: The Clang documentation¹ suggest an even neater solution, which would eliminate the repetitive empty pg_attribute_foo #defines in the trailing #else/#endif block in commit 1fa22a43a56e1fe44c7bb3a3d5ef31be5bcac41d: #ifndef __has_attribute

Re: [HACKERS] Custom compression methods

On Tue, Nov 24, 2020 at 7:14 PM Robert Haas wrote: > > On Tue, Nov 24, 2020 at 7:11 AM Dilip Kumar wrote: > > About (4), one option is that we directly call the correct handler > > function for the built-in type directly from > > toast_(de)compress(_slice) functions but in that case, we are > >

Re: abstract Unix-domain sockets

On 2020-11-23 17:00, David G. Johnston wrote: So presently there is no functioning code to prevent two PostgreSQL instances from using the same socket so long as they do not also use the same data directory?  We only handle the case of an unclean crash - where the pid and socket are both left

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

On Sat, Oct 31, 2020 at 01:36:11PM -0500, Justin Pryzby wrote: > > > From the grammar perspective ANY option is available for any command > > > that uses parenthesized option list. All the checks and validations > > > are performed at the corresponding command code. > > > This analyze_keyword is

Re: Prevent printing "next step instructions" in initdb and pg_upgrade

On Tue, Nov 24, 2020 at 04:05:26PM +0100, Magnus Hagander wrote: > pg_upgrade is a somewhat different but also interesting case. I think > the actual progress output is more interesting in pg_upgrade as it's > more likely to take measurable amounts of time. Whereas in initdb, > it's actually the

Re: abstract Unix-domain sockets

On Mon, Nov 23, 2020 at 9:00 AM David G. Johnston < david.g.johns...@gmail.com> wrote: > Or is it the case that we always attempt to bind the TCP/IP port, > regardless of the presence of a socket file, in which case the failure for > port binding does cover the socket situation as well? > This

Re: [patch] CLUSTER blocks scanned progress reporting

On Tue, 24 Nov 2020 at 15:05, Fujii Masao wrote: > > On 2020/11/21 2:32, Matthias van de Meent wrote: > > Hi, > > > > The pg_stat_progress_cluster view can report incorrect > > heap_blks_scanned values when synchronize_seqscans is enabled, because > > it allows the sequential heap scan to not

  1   2   >