Re: In-placre persistance change of a relation

At Fri, 13 Nov 2020 06:43:13 +, "tsunakawa.ta...@fujitsu.com" wrote in > Hi Horiguchi-san, > > > Thank you for making a patch so quickly. I've started looking at it. > > What makes you think this is a PoC? Documentation and test cases? If > there's something you think that doesn't

Re: Skip ExecCheckRTPerms in CTAS with no data

Thanks for the comments. On Fri, Nov 13, 2020 at 9:19 AM Michael Paquier wrote: > > Let's move any tests related to matviews to matviews.sql. It does not > seem consistent to me to have those tests in a test path reserved to > CTAS, though I agree that there is some overlap and that setting up

Re: [PATCH] remove deprecated v8.2 containment operators

On 2020-11-12 23:28, Tom Lane wrote: I'm on board with pulling these now --- 8.2 to v14 is plenty of deprecation notice. However, the patch seems incomplete in that the code support for these is still there -- look for RTOldContainedByStrategyNumber and RTOldContainsStrategyNumber. Admittedly,

RE: In-placre persistance change of a relation

Hello, Tsunakawa-San > Do you know the reason why data copy was done before? And, it may be > odd for me to ask this, but I think I saw someone referred to the past > discussion that eliminating data copy is difficult due to some processing at > commit. I can't find it. I can share 2 sources

Re: POC: Cleaning up orphaned files using undo logs

On Thu, Nov 12, 2020 at 2:45 PM Antonin Houska wrote: > > > No background undo > -- > > Reduced complexity of the patch seems to be the priority at the moment. Amit > suggested that cleanup of an orphaned relation file is simple enough to be > done on foreground and I agree. >

RE: In-placre persistance change of a relation

Hi Horiguchi-san, Thank you for making a patch so quickly. I've started looking at it. What makes you think this is a PoC? Documentation and test cases? If there's something you think that doesn't work or are concerned about, can you share it? Do you know the reason why data copy was done

Re: Strange behavior with polygon and NaN

At Fri, 13 Nov 2020 15:35:58 +0900 (JST), Kyotaro Horiguchi wrote in > Thank you for the review, Georgios and Tom. > > At Tue, 10 Nov 2020 14:30:08 -0500, Tom Lane wrote in > > I spent some time looking this over, and have a few thoughts: > > > > 1. I think it's useful to split the test

Re: Strange behavior with polygon and NaN

Thank you for the review, Georgios and Tom. At Tue, 10 Nov 2020 14:30:08 -0500, Tom Lane wrote in > I spent some time looking this over, and have a few thoughts: > > 1. I think it's useful to split the test changes into two patches, > as I've done below: first, just add the additional row in

RE: pgbench: option delaying queries till connections establishment?

Dear Fabien, > and this will wait till its time comes. In the mean time, I think that you > should put the patch status as you see fit, independently of the other > patch: it seems unlikely that they would be committed together, and I'll > have to merge the remaining one anyway. OK. I found

Re: Add docs stub for recovery.conf

On Fri, Nov 13, 2020 at 11:50 AM Bruce Momjian wrote: > > So you are saying you don't think you are getting sufficient thought > > into your proposal, and getting just a reflex? Just because we don't > > agree with you don't mean we didn't think about it. In fact, we have > > thought about it

Re: POC: Cleaning up orphaned files using undo logs

On Thu, Nov 12, 2020 at 10:15 PM Antonin Houska wrote: > Thomas Munro wrote: > > Thanks. We decided to redesign a couple of aspects of the undo > > storage and record layers that this patch was intended to demonstrate, > > and work on that is underway. More on that soon. > > As my boss

Re: In-placre persistance change of a relation

Hello. Before posting the next version, I'd like to explain what this patch is. 1. The Issue Bulk data loading is a long-time taking, I/O consuming task. Many DBAs want that task is faster, even at the cost of increasing risk of data-loss. wal_level=minimal is an answer to such a request.

Re: Add docs stub for recovery.conf

On Thu, Nov 12, 2020 at 10:41:49PM -0500, Bruce Momjian wrote: > On Fri, Nov 13, 2020 at 11:37:16AM +0800, Craig Ringer wrote: > > I have a draft patch that adds them and various related index > > cross-referencing > > in my tree to submit after the recovery.conf docs patch. Let me know if you >

Re: Skip ExecCheckRTPerms in CTAS with no data

On Thu, Nov 12, 2020 at 04:17:43PM +0530, Bharath Rupireddy wrote: > On HEAD/master, the behaviour is as follows: a) for plain CTAS WITH NO > DATA, ExecCheckRTPerms() will not be called. b) for explain analyze > CTAS WITH NO DATA, ExecCheckRTPerms() will be called. So, we need a). > This is what

Re: Add docs stub for recovery.conf

On Thu, 12 Nov 2020 at 22:40, Bruce Momjian wrote: Because at a certain point the number of _old_ names in the docs > obscures exactly how to operate the current software. We have tried > keeping stuff around, and we are very bad at removing stuff. > This is a good point, but does not attempt

Re: Add docs stub for recovery.conf

On Fri, Nov 13, 2020 at 11:37:16AM +0800, Craig Ringer wrote: > I have a draft patch that adds them and various related index > cross-referencing > in my tree to submit after the recovery.conf docs patch. Let me know if you > think that might be worthwhile, 'cos I won't invest time in it if it's

Re: Add docs stub for recovery.conf

On Thu, 12 Nov 2020 at 22:31, Craig Ringer wrote: > I maintain that simply vanishing terms from the docs without any sort of > explanation is a user-hostile action that we should fix and stop doing If > we had something in the docs and we remove it, it's not unduly burdensome > to have some

Re: Add docs stub for recovery.conf

On Fri, Nov 13, 2020 at 11:31:24AM +0800, Craig Ringer wrote: > Can anyone tell me why the solution I proposed is not acceptable, and why we > have to invent a different one instead? The website  redirect is good and all, > but doesn't really solve the problem, and I still don't know what's wrong

Re: Add docs stub for recovery.conf

On Fri, Nov 13, 2020 at 11:31 AM Craig Ringer wrote: > > Can anyone tell me why the solution I proposed is not acceptable, and why > we have to invent a different one instead? The website redirect is good > and all, but doesn't really solve the problem, and I still don't know > what's wrong

Re: Add statistics to pg_stat_wal view for wal related parameter tuning

>Now, pg_stat_wal supports reset all informantion in WalStats >using pg_stat_reset_shared('wal') function. >Isn't it enough? Yes it ok, sorry I miss this infomation. >> 3. I do not think it's a correct describe in document for >> 'wal_buffers_full'. >Where should I rewrite the description? If

Re: Add docs stub for recovery.conf

On Thu, Nov 12, 2020 at 11:25 PM Stephen Frost wrote: > > > Now, the pgweb feature that Jonathan wrote recently might actually be > > exactly what we need to fix that, and to address the issue with > > recovery config documentation that Craig raises. > > After chatting with Jonathan about this

Re: public schema default ACL

On Thu, Nov 12, 2020 at 06:36:39PM -0800, Noah Misch wrote: > On Mon, Nov 09, 2020 at 02:56:53PM -0500, Bruce Momjian wrote: > > On Mon, Nov 2, 2020 at 11:05:15PM -0800, Noah Misch wrote: > > > My plan is for the default to become: > > > > > > GRANT USAGE ON SCHEMA public TO PUBLIC; > > >

Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2

On Thu, Nov 05, 2020 at 03:41:23PM +0900, Michael Paquier wrote: > This conflicted on HEAD with pgcrypto. Please find attached a rebased > set. I got to think more about this stuff and attached is a new patch set that redesigns the generic interface used for the crypto hash functions, in order

Re: public schema default ACL

On Mon, Nov 09, 2020 at 02:56:53PM -0500, Bruce Momjian wrote: > On Mon, Nov 2, 2020 at 11:05:15PM -0800, Noah Misch wrote: > > My plan is for the default to become: > > > > GRANT USAGE ON SCHEMA public TO PUBLIC; > > ALTER SCHEMA public OWNER TO DATABASE_OWNER; -- new syntax > > Seems it

Use extended statistics to estimate (Var op Var) clauses

Hi, Attached is a patch to allow estimation of (Var op Var) clauses using extended statistics. Currently we only use extended stats to estimate (Var op Const) clauses, which is sufficient for most cases, but it's not very hard to support this second type of clauses. This is not an entirely new

RE: Detecting File Damage & Inconsistencies

From: Simon Riggs > If a rogue user/process is suspected, this would allow you to identify > more easily the changes made by specific sessions/users. Isn't that kind of auditing a job of pgAudit or log_statement = mod? Or, does "more easily" mean that you find pgAudit complex to use and/or

Re: remove spurious CREATE INDEX CONCURRENTLY wait

On Thu, Nov 12, 2020 at 04:36:32PM +0100, Dmitry Dolgov wrote: > Interesting enough, similar discussion happened about vaccumFlags before > with the same conclusion that theoretically it's fine to update without > holding the lock, but this assumption could change one day and it's > better to

Re: Optimising latch signals

On Sun, Aug 9, 2020 at 11:48 PM Thomas Munro wrote: > Here are some more experimental patches to reduce system calls. > > 0001 skips sending signals when the recipient definitely isn't > waiting, using a new flag-and-memory-barrier dance. This seems to > skip around 12% of the kill() calls for

Re: recovery_target immediate timestamp

On Wed, 11 Nov 2020 at 22:40, Fujii Masao wrote: > > On 2020/11/12 6:00, Euler Taveira wrote: > > > The first patch adds a new message that prints the latest completed > checkpoint > > when the consistent state is reached. > > I'm not sure how useful this information is in practice. > > Fujii,

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

On Thu, Nov 12, 2020 at 3:00 PM Peter Geoghegan wrote: > Attached is v8, which has the enhancements for low cardinality data > that I mentioned earlier today. It also simplifies the logic for > dealing with posting lists that we need to delete some TIDs from. > These posting list simplifications

Re: Add important info about ANALYZE after create Functional Index

On Thu, Nov 12, 2020 at 03:11:43PM -0600, Justin Pryzby wrote: > I guess it should say "The system regularly ..." > > Also, the last sentence begins "For new expression indexes" and ends with > "about new expression indexes", which I guess could instead say "about the > expressions". How is this

Re: Implement for window functions

On 11/12/20 11:35 PM, Krasiyan Andreev wrote: > Hi, it looks like Vik Fearing's patch does not apply anymore, because there > are many conflicts with recent changes, fixed patch attached. Thanks! I've been away from this list for a while and I have some catching up to do. -- Vik Fearing

Re: Zedstore - compressed in-core columnar storage

Hi, Thanks for the updated patch. It's a quite massive amount of code - I I don't think we had many 2MB patches in the past, so this is by no means a full review. 1) the psql_1.out is missing a bit of expected output (due to 098fb0079) 2) I'm getting crashes in intarray contrib, due to hitting

Re: Implement for window functions

Hi, it looks like Vik Fearing's patch does not apply anymore, because there are many conflicts with recent changes, fixed patch attached. I am interested in reviewing and testing it for the next commitfest, if it's design and implementation is found to be acceptable. Additionally, if it is also

Re: [PATCH] remove deprecated v8.2 containment operators

Peter Eisentraut writes: > On 2020-10-27 04:25, Justin Pryzby wrote: >> They have been deprecated for a Long Time, so finally remove them for v14. >> Four fewer exclamation marks makes the documentation less exciting, which is >> a >> good thing. > I have committed the parts that remove the

Re: Bogus documentation for bogus geometric operators

Pavel Borisov writes: > [ v4-0001-Deprecate-and-replace-and-operators-for-points.patch ] I made a cursory pass over this, and two things stood out to me: 1. The patch removes <^ and >^ from func.sgml, which is fine, but shouldn't there be an addition for the new operators? (I think probably

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

On Wed, Nov 11, 2020 at 6:17 AM Victor Yegorov wrote: > I've looked at the latest (v7) patchset. > I've decided to use a quite common (in my practice) setup with an indexed > mtime column over scale 1000 set: Thanks for testing! > We can see that: > - unused index is not suffering from not-HOT

Re: Proposition for autoname columns

> On 2020-Nov-12, Tom Lane wrote: >> On the whole, I'm on the side of the people who don't want to change this. >> The implementation cost seems likely to greatly outweigh the value, plus >> it feels more like a wart than a feature. > I think if Eugen wants to spend some time with it and see

Re: Allow matching whole DN from a client certificate

On 11/12/20 8:37 AM, Daniel Gustafsson wrote: >> On 11 Nov 2020, at 21:44, Andrew Dunstan wrote: >> If people like this idea I'll add tests and docco and add it to the next CF. > Sounds like a good idea, please do. > > Can this case really happen in non-ancient OpenSSL version? > +

Re: Add important info about ANALYZE after create Functional Index

On Mon, Nov 09, 2020 at 06:27:20PM -0500, Bruce Momjian wrote: > On Tue, Oct 27, 2020 at 12:12:00AM -0700, Nikolay Samokhvalov wrote: > > On Mon, Oct 26, 2020 at 3:08 PM Fabrízio de Royes Mello > > wrote: > > > > Would be nice if add some information about it into our docs but not > > sure

Re: avoid bitmapOR-ing indexes with scan condition inconsistent with partition constraint

I started looking through this patch. I really quite dislike solving this via a kluge in indxpath.c. There are multiple disadvantages to that: * It only helps for the very specific problem of redundant bitmap index scans, whereas the problem of applying redundant qual checks in partition scans

Re: Add important info about ANALYZE after create Functional Index

On Mon, Nov 9, 2020 at 08:35:46PM -0300, Fabrízio de Royes Mello wrote: > > > On Mon, 9 Nov 2020 at 20:27 Bruce Momjian wrote: > > > I see REINDEX CONCURRENTLY was fixed in head, but the docs didn't get > updated to mention the need to run ANALYZE or wait for autovacuum before >

Re: Aw: Re: Minor documentation error regarding streaming replication protocol

On Thu, Oct 15, 2020 at 12:43:22PM -0400, Bruce Momjian wrote: > On Thu, Oct 15, 2020 at 12:01:21PM -0400, Tom Lane wrote: > > Bruce Momjian writes: > > > We would want the timeline history file contents label changed from > > > BYTEA to TEXT in the docs changed for all supported versions, add a

Re: Proposition for autoname columns

On Thu, Nov 12, 2020 at 04:30:15PM -0300, Álvaro Herrera wrote: > On 2020-Nov-12, Tom Lane wrote: > > > On the whole, I'm on the side of the people who don't want to change this. > > The implementation cost seems likely to greatly outweigh the value, plus > > it feels more like a wart than a

Re: Proposition for autoname columns

On 2020-Nov-12, Tom Lane wrote: > On the whole, I'm on the side of the people who don't want to change this. > The implementation cost seems likely to greatly outweigh the value, plus > it feels more like a wart than a feature. I think if Eugen wants to spend some time with it and see how it

Re: Proposition for autoname columns

On Thursday, November 12, 2020, Bruce Momjian wrote: > On Thu, Nov 12, 2020 at 01:52:11PM -0500, Tom Lane wrote: > > On the whole, I'm on the side of the people who don't want to change > this. > > The implementation cost seems likely to greatly outweigh the value, plus > > it feels more like a

Re: Proposition for autoname columns

On Thu, Nov 12, 2020 at 01:52:11PM -0500, Tom Lane wrote: > On the whole, I'm on the side of the people who don't want to change this. > The implementation cost seems likely to greatly outweigh the value, plus > it feels more like a wart than a feature. I think we can mark this as, "We thought

Re: Proposition for autoname columns

"David G. Johnston" writes: > The query rewriter would only rewrite these expressions and provide an > expression-related explicit alias clause if the expression is a single > operator (same as single function today) and the right-hand side of the > operator is a constant (meaning the constant is

Re: Delay of standby shutdown

Thanks! Marking this as ready for committer. Regards, Soumyadeep (VMware)

Re: Proposition for autoname columns

On Thu, Nov 12, 2020 at 9:32 AM Andrew Dunstan wrote: > > On 11/12/20 11:12 AM, David G. Johnston wrote: > > On Thu, Nov 12, 2020 at 8:59 AM Andrew Dunstan > > wrote: > > > > > > > > So if we then say: > > > > > > select x, j->>x from mytable; > > > > > >

Re: Proposition for autoname columns

On Thu, Nov 12, 2020 at 11:32:49AM -0500, Andrew Dunstan wrote: > On 11/12/20 11:12 AM, David G. Johnston wrote: > > IMO It no worse than today's: > > > > select count(*), count(*) from (values (1), (2)) vals (v); > > count | count > > 2 | 2 > > > > > I guess the difference here is that there's

Re: Proposition for autoname columns

On 11/12/20 11:12 AM, David G. Johnston wrote: > On Thu, Nov 12, 2020 at 8:59 AM Andrew Dunstan > wrote: > > > > So if we then say: > > >     select x, j->>x from mytable; > > > you want both result columns named x? That seems like a recipe for >

Re: Proposition for autoname columns

On Thu, Nov 12, 2020 at 8:59 AM Andrew Dunstan wrote: > > > So if we then say: > > > select x, j->>x from mytable; > > > you want both result columns named x? That seems like a recipe for > serious confusion. I really don't think this proposal has been properly > thought through. > > IMO It

Re: Proposition for autoname columns

čt 12. 11. 2020 v 16:59 odesílatel Andrew Dunstan napsal: > > On 11/12/20 9:14 AM, Eugen Konkov wrote: > > Hello Andrew, > > > > Thursday, November 12, 2020, 3:19:39 PM, you wrote: > > > > > >> On 11/11/20 7:55 PM, Bruce Momjian wrote: > >>> On Thu, Nov 12, 2020 at 12:18:49AM +, Dagfinn

Re: Proposition for autoname columns

On 11/12/20 9:14 AM, Eugen Konkov wrote: > Hello Andrew, > > Thursday, November 12, 2020, 3:19:39 PM, you wrote: > > >> On 11/11/20 7:55 PM, Bruce Momjian wrote: >>> On Thu, Nov 12, 2020 at 12:18:49AM +, Dagfinn Ilmari Mannsåker wrote: Bruce Momjian writes: > I think we could do

Re: remove spurious CREATE INDEX CONCURRENTLY wait

> On Mon, Nov 09, 2020 at 10:02:27PM -0500, Tom Lane wrote: > > Alvaro Herrera writes: > > Yeah ... it would be much better if we can make it use atomics instead. > > I was thinking more like "do we need any locking at all". > > Assuming that a proc's vacuumFlags can be set by only the process

Re: Add docs stub for recovery.conf

On Thu, Nov 12, 2020 at 09:47:42AM -0500, Stephen Frost wrote: > > Fortunately, this has already been discussed in the renaming of default > > roles to predefined roles: > > > > > > https://www.postgresql.org/message-id/flat/157742545062.1149.11052653770497832538%40wrigleys.postgresql.org >

Re: Add docs stub for recovery.conf

Greetings, * Stephen Frost (sfr...@snowman.net) wrote: > * Bruce Momjian (br...@momjian.us) wrote: > > On Thu, Nov 12, 2020 at 10:21:02AM +0800, Craig Ringer wrote: > > > Here's how the rendered docs look: https://imgur.com/a/VyjzEw5 > > > > > > Think. You're used to recovery.conf. You've

Re: Proposition for autoname columns

On Thu, Nov 12, 2020 at 7:18 AM Eugen Konkov wrote: > Hello Andrew, > > Thursday, November 12, 2020, 3:19:39 PM, you wrote: > > > > On 11/11/20 7:55 PM, Bruce Momjian wrote: > > > select j->>x from mytable; > > What should the column be named? > > Suppose it should be named 'as x' > +1 > > >

Re: [HACKERS] xlog min recovery request ... is past current point ...

[ blast-from-the-past department ] On Fri, Feb 3, 2012 at 11:33 AM Christophe Pettus wrote: > While bringing up a streaming replica, and while it is working its way > through the WAL segments before connecting to the primary, I see a lot of > messages of the form: > > 2012-02-01 21:26:13.978

Re: Add docs stub for recovery.conf

Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Thu, Nov 12, 2020 at 10:21:02AM +0800, Craig Ringer wrote: > > Here's how the rendered docs look: https://imgur.com/a/VyjzEw5 > > > > Think. You're used to recovery.conf. You've recently switched to pg 12. You > > search for

Re: Add docs stub for recovery.conf

On Thu, Nov 12, 2020 at 10:21:02AM +0800, Craig Ringer wrote: > Here's how the rendered docs look: https://imgur.com/a/VyjzEw5 > > Think. You're used to recovery.conf. You've recently switched to pg 12. You > search for "recovery.conf" or "primary_slot_name" or "standby_mode" or > something. You

Re: Additional improvements to extended statistics

On Thu, 12 Nov 2020 at 14:18, Tomas Vondra wrote: > > Here is an improved WIP version of the patch series, modified to address > the issue with repeatedly applying the extended statistics, as discussed > with Dean in this thread. It's a bit rough and not committable, but I > need some feedback so

Re: Additional improvements to extended statistics

Hi, Here is an improved WIP version of the patch series, modified to address the issue with repeatedly applying the extended statistics, as discussed with Dean in this thread. It's a bit rough and not committable, but I need some feedback so I'm posting it in this state. (Note: The WIP patch is

Re: Proposition for autoname columns

Hello Andrew, Thursday, November 12, 2020, 3:19:39 PM, you wrote: > On 11/11/20 7:55 PM, Bruce Momjian wrote: >> On Thu, Nov 12, 2020 at 12:18:49AM +, Dagfinn Ilmari Mannsåker wrote: >>> Bruce Momjian writes: I think we could do it, but it would only work if the column was output

Re: truncating timestamps on arbitrary intervals

On 2020-06-30 06:34, John Naylor wrote: In v9, I've simplified the patch somewhat to make it easier for future work to build on. - When truncating on month-or-greater intervals, require the origin to align on month. This removes the need to handle weird corner cases that have no straightforward

Re: PATCH: Batch/pipelining support for libpq

(Adding previous reviewers to CC) On 2020-Nov-03, David G. Johnston wrote: > Given the caveats around blocking mode connections why not just require > non-blocking mode, in a similar fashion to how synchronous functions are > disallowed? This is a very good question. Why indeed? Does anybody

Re: Allow matching whole DN from a client certificate

> On 11 Nov 2020, at 21:44, Andrew Dunstan wrote: > If people like this idea I'll add tests and docco and add it to the next CF. Sounds like a good idea, please do. Can this case really happen in non-ancient OpenSSL version? + if (!x509name) Doesn't this returnpath need a

Re: Strange GiST logic leading to uninitialized memory access in pg_trgm gist code

> "Alexander" == Alexander Korotkov writes: >> Another issue I don't understand yet is that even though this code >> is largely unchanged since 8.x, the original reporter could not >> reproduce the crash on any version before 13.0. Alexander> I think this is related to my commit

Re: Proposition for autoname columns

On 11/11/20 7:55 PM, Bruce Momjian wrote: > On Thu, Nov 12, 2020 at 12:18:49AM +, Dagfinn Ilmari Mannsåker wrote: >> Bruce Momjian writes: >>> I think we could do it, but it would only work if the column was output >>> as a single json value, and not a multi-key/value field. I am afraid if

Re: Online checksums patch - once again

> On 5 Oct 2020, at 14:14, Heikki Linnakangas wrote: > > Replying to an older message in this thread: > >>> + /* >>> + * If we reach this point with checksums in inprogress state, we notify >>> + * the user that they need to manually restart the process to enable >>> + * checksums. This is

Phrase search vs. multi-lexeme tokens

Hackers, I'm investigating the bug report [1] about the behavior of websearch_to_tsquery() with quotes and multi-lexeme tokens. See the example below. # select to_tsvector('pg_class foo') @@ websearch_to_tsquery('"pg_class foo"'); ?column? -- f So, tsvector doesn't match tsquery,

Re: Refactor pg_rewind code and make it work against a standby

On 04/11/2020 11:23, Heikki Linnakangas wrote: I read through the patches one more time, fixed a bunch of typos and such, and pushed patches 1-4. I'm going to spend some more time on testing the last patch. It allows using a standby server as the source, and we don't have any tests for that yet.

Remove unused variable from SharedSort

While going through the code I noticed that the nTapes member in SharedSort is unused. This is just initialized with nworkers but never used. The attached patch removes this variable. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com

Re: Implementing Incremental View Maintenance

> 1. Create pgbench database with scale 100. > pgbench speed at my desktop is about 10k TPS: > > pgbench -M prepared -N -c 10 -j 4 -T 30 -P 1 postgres > tps = 10194.951827 (including connections establishing) > > 2. Then I created incremental materialized view: > > create incremental

Re: Skip ExecCheckRTPerms in CTAS with no data

Thanks for the comments. On Thu, Nov 12, 2020 at 2:36 PM Michael Paquier wrote: > > On Wed, Nov 11, 2020 at 07:31:49PM +0530, Bharath Rupireddy wrote: > > Yes we do not have anything related to permissions mentioned in the > > documentation. So, I'm not adding it now. > > It would be good to

Re: Misuse of TimestampDifference() in the autoprewarm feature of pg_prewarm

On 2020-11-11 06:59, Tom Lane wrote: Alexey Kondratov writes: After looking on the autoprewarm code more closely I have realised that this 'double dump' issues was not an issues at all. I have just misplaced a debug elog(), so its second output in the log was only indicating that we

Issue with server side statement-level rollback

Hi, We're facing some issue in a new extension we use at LzLabs to emulate server side rollback at statement level in PostgreSQL, see for full detail https://github.com/lzlabs/pg_statement_rollback/ The problem we are encountering is when PostgreSQL is compiled in debug mode with

​generated columns in MergeAttributesIntoExisting

Hello I found a simple test case: CREATE TABLE test(id int NOT NULL, gen int GENERATED ALWAYS AS (id + 1) STORED) partition by range (id); create table test_part_create partition of test for values from ( 0) to (10); create table test_part_attach (id int NOT NULL, gen int); alter table test

Re: Asynchronous Append on postgres_fdw nodes.

On Thu, Oct 8, 2020 at 8:40 PM Andrey Lepikhov wrote: > I want to suggest one more improvement. Currently the > is_async_capable_path() routine allow only ForeignPath nodes as async > capable path. But in some cases we can allow SubqueryScanPath as async > capable too. > The patch in attachment

Re: Asynchronous Append on postgres_fdw nodes.

On Thu, Oct 8, 2020 at 6:39 PM Andrey V. Lepikhov wrote: > I found a small problem. If we have a mix of async and sync subplans > when we catch an assertion on a busy connection. Just for example: > > PLAN > > Nested Loop (cost=100.00..174316.95 rows=975 width=8) (actual > time=5.191..9.262

Re: logical streaming of xacts via test_decoding is broken

On Tue, Nov 10, 2020 at 7:20 PM Amit Kapila wrote: > > On Tue, Nov 10, 2020 at 2:25 PM Dilip Kumar wrote: > > > > On Tue, Nov 10, 2020 at 11:18 AM Dilip Kumar wrote: > > > > > > On Tue, Nov 10, 2020 at 10:52 AM Amit Kapila > > > wrote: > > > > For this case, users can use skip_empty_xacts =

Re: PATCH: Batch/pipelining support for libpq

Hi David, Thanks for the feedback. I did rework a bit the doc based on your remarks. Here is the v24 patch. Matthieu Garrigues On Tue, Nov 3, 2020 at 6:21 PM David G. Johnston wrote: > > On Mon, Nov 2, 2020 at 8:58 AM Alvaro Herrera wrote: >> >> On 2020-Nov-02, Alvaro Herrera wrote: >> >> >

Re: Feature request: Improve allowed values for generate series

Title: Re: Feature request: Improve allowed values for generate series Hello David, I have a table with services, each service have a period. After which service is auto renewal Services also could be one-time. At this case its interval is '00:00:00' The renewal is calculated via

Re: Skip ExecCheckRTPerms in CTAS with no data

On Wed, Nov 11, 2020 at 07:31:49PM +0530, Bharath Rupireddy wrote: > Yes we do not have anything related to permissions mentioned in the > documentation. So, I'm not adding it now. It would be good to clarify that in the docs while we are on it. > Apart from the above, I also noticed that we

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

On Wed, Nov 11, 2020 at 12:35 AM Amit Kapila wrote: I have rearranged the code in DecodeCommit/Abort/Prepare so > that it does only the required things (like in DecodeCommit was still > processing subtxns even when it has to just perform FinishPrepared, > also the stats were not updated properly

Re: Implementing Incremental View Maintenance

On Thu, 5 Nov 2020 22:58:25 -0600 Justin Pryzby wrote: > On Mon, Oct 05, 2020 at 06:16:18PM +0900, Yugo NAGATA wrote: > This needs to be rebased again - the last version doesn't apply anymore. > http://cfbot.cputube.org/yugo-nagata.html I attached the rebased patch (v19). > I looked though it

Re: Add session statistics to pg_stat_database

‐‐‐ Original Message ‐‐‐ On Thursday, November 12, 2020 9:31 AM, Laurenz Albe wrote: > I wrote: > > > On Tue, 2020-11-10 at 15:03 +, Georgios Kokolatos wrote: > > > > > I noticed that the cfbot fails for this patch. > > > For this, I am setting the status to: 'Waiting on Author'.

Re: Add session statistics to pg_stat_database

I wrote: > On Tue, 2020-11-10 at 15:03 +, Georgios Kokolatos wrote: > > I noticed that the cfbot fails for this patch. > > > > For this, I am setting the status to: 'Waiting on Author'. > > Thanks for noticing, it was only the documentation build. > > Version 5 attached, status changed back

Re: Skip ExecCheckRTPerms in CTAS with no data

On Wed, Nov 11, 2020 at 01:34:05PM +0530, Bharath Rupireddy wrote: > The ExecCheckRTPerms() with ACL_INSERT permission will be called > before inserting the data to the table that's created with CREATE AS > WITH NO DATA. Perhaps you meant s/WITH NO DATA/WITH DATA/ here? > The insertion into the

Re: ModifyTable overheads in generic plans

On Wed, Nov 11, 2020 at 10:14 PM Heikki Linnakangas wrote: > I'm still a bit confused and unhappy about the initialization of > ResultRelInfos and the various fields in them. We've made progress in > the previous patches, but it's still a bit messy. > > > /* > >* If