dropping column prevented due to inherited index

Hi, Maybe I'm forgetting some dependency management discussion that I was part of recently, but is the following behavior unintentional? create table p (a int, b int, c int) partition by list (a); create table p1 partition of p for values in (1) partition by list (b); create table p11 partition

Re: Proposal: roll pg_stat_statements into core

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > >> I think there is a false dichotomy here. Migrating an extension out of > >> contrib doesn't have to equate making it no longer an extension. We > >> could,

Re: WIP: Data at rest encryption

Alvaro Herrera wrote: > On 2019-Aug-02, Shawn Wang wrote: > > > Hi Antonin, > > It is very glad to see the new patch. I used the public patches a long time > > ago. > > I did some tests like the stream replication, much data running, temporary > > files encryption. > > I found that there is

Re: Re: Email to hackers for test coverage

On Wed, Aug 28, 2019 at 11:27:15AM -0700, Peter Geoghegan wrote: > Movead is correct -- the NULL handling within > ApplySortAbbrevFullComparator() cannot actually be used currently. I > wouldn't change anything about the code, though, since it's useful to > defensively handle NULLs. No objections

Re: pg_basebackup -F t fails when fsync spends more time than tcp_user_timeout

On Tue, Sep 03, 2019 at 10:58:18AM +0900, Michael Paquier wrote: > Attached is an updated patch, which needs to go down to v10. Committed, after doing more double-checks on it. Thanks for the report, Takahashi-san. -- Michael signature.asc Description: PGP signature

Re: Proposal: roll pg_stat_statements into core

Stephen Frost writes: > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: >> I think there is a false dichotomy here. Migrating an extension out of >> contrib doesn't have to equate making it no longer an extension. We >> could, instead, keep it being an extension, but move it out of contrib

Re: pg_get_databasebyid(oid)

On Thu, Aug 29, 2019 at 03:47:40PM +0500, Ibrar Ahmed wrote: > I think its a user request and don't require to be in the core of > PostgreSQL. > A simple SQL function can fulfill the requirement of the user. > > CREATE OR REPLACE FUNCTION pg_get_databasebyid(dboid integer) RETURNS name > AS $$ >

Re: [PATCH] Connection time for \conninfo

On Tue, Sep 03, 2019 at 10:13:57PM -0400, Rodrigo Ramírez Norambuena wrote: > I've work in the a little patch to add into the \conninfo of psql > command the connection time against a server backend > > Maybe could add after, the precheck to if the connection is alive. > I've take first look to

[PATCH] Connection time for \conninfo

I've work in the a little patch to add into the \conninfo of psql command the connection time against a server backend Maybe could add after, the precheck to if the connection is alive. I've take first look to the pqPacketSend, my idea is send a ECHO packet over to the database connection. If

Re: Proposal: roll pg_stat_statements into core

Greetings, * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > On 2019-Sep-03, Stephen Frost wrote: > > * David Fetter (da...@fetter.org) wrote: > > > I'd like to $Subject, on by default, with a switch to turn it off for > > > those really at the outer edges of performance. Some reasons include:

Re: d25ea01275 and partitionwise join

Fujita-san, On Thu, Jul 18, 2019 at 8:10 PM Etsuro Fujita wrote: > > On Thu, Jul 18, 2019 at 11:18 AM Amit Langote wrote: > > On Tue, Jul 16, 2019 at 8:22 PM Etsuro Fujita > > wrote: > > > On Tue, Jul 2, 2019 at 6:29 PM Amit Langote > > > wrote: > > > > 0001 - fix partitionwise join to work

Re: remove "msg" parameter from convert_tuples_by_name

On Wed, Sep 4, 2019 at 3:52 AM Alvaro Herrera wrote: > > On 2019-Aug-07, Amit Langote wrote: > > > If we're reducing the message string to occur only once in the source > > code, can we maybe write it to be more informative? I wonder if users > > aren't normally supposed to see this message? > >

Re: partition routing layering in nodeModifyTable.c

On Fri, Aug 9, 2019 at 10:51 AM Amit Langote wrote: > > Fujita-san, > > On Thu, Aug 8, 2019 at 9:49 PM Etsuro Fujita wrote: > > On Thu, Aug 8, 2019 at 10:10 AM Amit Langote > > wrote: > > > Attached updated patches; only 0001 changed in this version. > > > > Thanks for the updated version,

Re: remove "msg" parameter from convert_tuples_by_name

On 2019-Sep-04, Amit Langote wrote: > On Wed, Sep 4, 2019 at 3:52 AM Alvaro Herrera > wrote: > > > > On 2019-Aug-07, Amit Langote wrote: > > > > > If we're reducing the message string to occur only once in the source > > > code, can we maybe write it to be more informative? I wonder if users >

Re: Proposal: roll pg_stat_statements into core

On 2019-Sep-03, Stephen Frost wrote: > Greetings, > > * David Fetter (da...@fetter.org) wrote: > > I'd like to $Subject, on by default, with a switch to turn it off for > > those really at the outer edges of performance. Some reasons include: > > Sure, half of contrib should really be in core

Re: row filtering for logical replication

> OK, I'll consider Alexey Kondratov's set of patches as the current > state-of-the-art then. (They still apply.) Alexey's patch is the rebased version of previous Euler's patch set, with slot type mistake fixed, and adapted to current changes in the master branch. It also has testing

Re: Proposal: roll pg_stat_statements into core

Greetings, On Tue, Sep 3, 2019 at 19:38 David Fetter wrote: > On Tue, Sep 03, 2019 at 03:56:28PM -0400, Stephen Frost wrote: > > Greetings, > > > > * David Fetter (da...@fetter.org) wrote: > > > I'd like to $Subject, on by default, with a switch to turn it off for > > > those really at the

Re: Commit fest 2019-09

Hi Ibrar On 2019-Sep-04, Ibrar Ahmed wrote: > On Mon, Sep 2, 2019 at 6:47 PM Alvaro Herrera > wrote: > > There's an embarrasingly large number of patches in the "Bug Fixes" > > section. I encourage reviewers to look at those that "Need Review" so > > that they can set "Ready for Committer"

Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?

Amit Langote writes: > [ v2-0001-Use-root-parent-s-permissions-when-read-child-tab.patch ] I took a quick look through this. I have some cosmetic thoughts and also a couple of substantive concerns: * As a rule, patches that add fields at the end of a struct are wrong. There is almost always

Re: Proposal: roll pg_stat_statements into core

On Tue, Sep 03, 2019 at 07:41:00PM -0400, Stephen Frost wrote: > Greetings, > > On Tue, Sep 3, 2019 at 19:38 David Fetter wrote: > > > On Tue, Sep 03, 2019 at 03:56:28PM -0400, Stephen Frost wrote: > > > Greetings, > > > > > > * David Fetter (da...@fetter.org) wrote: > > > > I'd like to

Re: Proposal: roll pg_stat_statements into core

On Tue, Sep 03, 2019 at 03:56:28PM -0400, Stephen Frost wrote: > Greetings, > > * David Fetter (da...@fetter.org) wrote: > > I'd like to $Subject, on by default, with a switch to turn it off for > > those really at the outer edges of performance. Some reasons include: > > Sure, half of contrib

Re: Proposal to suppress errors thrown by to_reg*()

Thomas Munro writes: > On Thu, Aug 1, 2019 at 8:41 PM Takuma Hoshiai wrote: >> On Thu, 1 Aug 2019 20:21:57 +1200 >> Thomas Munro wrote: >>> Based on the above review, I have set this to 'Returned with >>> feedback'. If you plan to produce a new patch in time for the next >>> Commitfest in

Re: [PATCH] Race condition in logical walsender causes long postgresql shutdown delay

On 2019-Jul-25, Craig Ringer wrote: > Patch attached. Here's a non-broken version of this patch. I have not done anything other than reflowing the new comment. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Two pg_rewind patches (auto generate recovery conf and ensure clean shutdown)

On 2019-Jul-15, Paul Guo wrote: > Thanks. Both Mkvcbuild.pm and pg_rewind/Makefile are modified to make > Windows build pass in a > local environment (Hopefully this passes the CI testing), also now > pg_rewind/Makefile does not > create soft link for backup_common.h anymore. Instead -I is used

Re: [HACKERS] Transactions involving multiple postgres foreign servers, take 2

Hello Sawada-san, On 2019-Jul-02, Masahiko Sawada wrote: > On Mon, Jul 1, 2019 at 8:32 PM Thomas Munro wrote: > > Can we please have a fresh rebase? > > Thank you for the notice. Attached rebased patches. ... and again? -- Álvaro Herrerahttps://www.2ndQuadrant.com/

Re: Tid scan improvements

On 2019-Aug-01, Edmund Horner wrote: > Hi everyone, > > Sadly it is the end of the CF and I have not had much time to work on > this. I'll probably get some time in the next month to look at the > heapam changes. > > Should we move to CF? We have been in the CF cycle for almost a year now...

Re: shared-memory based stats collector

On 2019-Jul-11, Kyotaro Horiguchi wrote: > Hello. This is v21 of the patch. > > > CF-bot warned that it doesn't work on Windows. I'm experiencing > > an very painful time to wait for tortoise git is walking slowly > > as its name suggests. It would be fixed in the next version. > > Found a bug

Re: Patch: New GUC prepared_statement_limit to limit memory used by prepared statements

I wrote: > As far as the crash issue is concerned, I notice that right now the > cfbot is showing green for this patch, but that seems to just be because > the behavior is unstable. I see crashes in "make installcheck-parallel" > about 50% of the time with this patch applied. Since, in fact, >

Re: Shared Memory: How to use SYSV rather than MMAP ?

On 2019-Feb-03, Thomas Munro wrote: > On Sat, Feb 2, 2019 at 12:49 AM Thomas Munro > wrote: > > I am planning to commit the 0001 patch shortly, unless there are > > objections. I attach a new version, which improves the documentation > > a bit (cross-referencing the new GUC and the section on

Re: SQL/JSON: functions

On 2019-Jul-16, Nikita Glukhov wrote: > Attached 37th version of the patches rebased onto current master. > > Preliminary patch #1 contains: >  - implementation of jsonpath .datetime() method (see [1]) >  - jsonpath support for json type (should be posted later in a separate > thread) 0001

Re: Attempt to consolidate reading of XLOG page

Hi Antonin, could you please rebase again? Thanks -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Replication & recovery_min_apply_delay

On 2019-Aug-02, Michael Paquier wrote: > On Wed, Jul 31, 2019 at 04:43:26PM -0400, Alvaro Herrera wrote: > > As for the test module, the one I submitted takes a lot of time to run > > (well, 60s) and I don't think it's a good idea to include it as > > something to be run all the time by every

Re: WIP: BRIN multi-range indexes

On 2019-Jun-11, Tomas Vondra wrote: > Attached is this patch series, rebased on top of current master and the > opclass parameters patch [1]. I previously planned to keep those two > efforts separate for a while, but I decided to give it a try and the > breakage is fairly minor so I'll keep it

Re: [PATCH] Opclass parameters

On 2019-Jun-11, Tomas Vondra wrote: > 1) We need a better infrastructure to parse opclass parameters. For > example the gtsvector_options does this: I think this is part of what Nikolay's patch series was supposed to address. But that one has been going way too slow. I agree we need something

Re: Attempt to consolidate reading of XLOG page

Pushed 0001. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Patch: New GUC prepared_statement_limit to limit memory used by prepared statements

Alvaro Herrera writes: > On this patch, beyond the fact that it's causing a crash in the > regression tests as evidenced by the CFbot, we seem to be waiting on the > input of the larger community on whether it's a desired feature or not. > We have Kyotaro's vote for it, but it would be good to

Re: amcheck verification for GiST

On 2019-Mar-29, Andrey Borodin wrote: > Here's updated patch with AccessShareLock. > I've tried to stress this with combination of random inserts, vaccuums and > checks. This process neither failed, nor deadlocked. > The patch intentionally contains one superflous line to make gist logically >

Re: Commit fest 2019-09

Hi Alvaro, On Mon, Sep 2, 2019 at 6:47 PM Alvaro Herrera wrote: > On 2019-Sep-01, Michael Paquier wrote: > > > I am not sure if somebody would like to volunteer, but I propose > > myself as commit fest manager for the next session. Feel free to > > reply to this thread if you feel that you

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

Fujita-san, amul, CFbot complains that Fujita-san submitted a patch that doesn't apply, which makes sense since the necessary previous patch was only referred to without being resubmitted. I suggest to always post all patches together with each resubmission so that it can be checked

Re: Adding column "mem_usage" to view pg_prepared_statements

Hello Daniel, This patch no longer applies. Please submit an updated version. Also, there's voluminous discussion that doesn't seem to have resulted in any revision of the code. Please fix that too. Thanks, -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL

Re: [Patch] Add a reset_computed_values function in pg_stat_statements

On Monday, September 2, 2019 3:25:00 AM CEST Euler Taveira wrote: > Em dom, 1 de set de 2019 às 06:04, Pierre Ducroquet > > escreveu: > > Hello > > > > pg_stat_statements is a great tool to track performance issue in live > > databases, especially when adding interfaces like PoWA on top of it.

Re: [proposal] de-TOAST'ing using a iterator

> +static void > +init_toast_buffer(ToastBuffer *buf, int32 size, bool compressed) > +{ > + buf->buf = (const char *) palloc0(size); This API is weird -- you always palloc the ToastBuffer first, then call init_toast_bufer on it. Why not palloc the ToastBuffer struct in init_toast_buffer and

Re: Proposal: roll pg_stat_statements into core

Greetings, * David Fetter (da...@fetter.org) wrote: > I'd like to $Subject, on by default, with a switch to turn it off for > those really at the outer edges of performance. Some reasons include: Sure, half of contrib should really be in core (amcheck, file_fdw, postgres_fdw, maybe dblink,

Re: SIGQUIT on archiver child processes maybe not such a hot idea?

Greetings, * David Steele (da...@pgmasters.net) wrote: > On 9/3/19 12:04 PM, Tom Lane wrote: > > Kyotaro Horiguchi writes: > >> But now we know that sending it to grand-children is wrong in a > >> sense that that leads to left-alone unwanted core files. But the > >> behavior is already knwon at

Re: SIGQUIT on archiver child processes maybe not such a hot idea?

Greetings, * Michael Paquier (mich...@paquier.xyz) wrote: > On Mon, Sep 02, 2019 at 12:27:09AM +, Tsunakawa, Takayuki wrote: > > From: Tom Lane [mailto:t...@sss.pgh.pa.us] > >> After investigation, the mechanism that's causing that is that the > >>

Re: add a MAC check for TRUNCATE

Greetings, * Kohei KaiGai (kai...@heterodb.com) wrote: > 2019年7月25日(木) 3:52 Yuli Khodorkovskiy : > > Since all DAC checks should have corresponding MAC, this patch adds a > > hook to allow extensions to implement a MAC check on TRUNCATE. I have > > also implemented this access check in the

Re: remove "msg" parameter from convert_tuples_by_name

On 2019-Aug-07, Amit Langote wrote: > If we're reducing the message string to occur only once in the source > code, can we maybe write it to be more informative? I wonder if users > aren't normally supposed to see this message? Grepping for the messages given to convert_tuples_by_position

Re: [Patch] Invalid permission check in pg_stats for functional indexes

On Tuesday, September 3, 2019 12:39:51 PM CEST Kuntal Ghosh wrote: > Hello Pierre, Hello Kuntal > > > When using a functional index on a table, we realized that the permission > > check done in pg_stats was incorrect and thus preventing valid access to > > the statistics from users. > > > > The

Re: Change ereport level for QueuePartitionConstraintValidation

Sergei Kornilov writes: > Thank you! It seems the most appropriate option for this test is to change > @contrib_excludes > Done in attached patch, will check appveyor reaction. Appveyor seems happy, so I took a look through this. There's little to say about 0001: if we're going to drop the

Re: Multivariate MCV list vs. statistics target

On 2019-Aug-01, Tomas Vondra wrote: > I'll move it to the next CF. Aside from the issues pointed by Kyotaro-san > in his review, I still haven't made my mind about whether to base the use > statistics targets set for the attributes. That's what we're doing now, > but I'm not sure it's a good idea

Re: \describe*

On 2019-Aug-01, Corey Huinker wrote: > From all this, I have so far concluded: > > 1. There is real demand to be able to easily see the basic structure of > tables, views, and indexes in a way that strikes a balance between detail > and clutter. That's great. That said, I'm not opposed to a

Re: refactoring - share str2*int64 functions

This part has been committed, now let's move to the next parts of your patch. Attached a rebased version which implements the int64/uint64 stuff. It is basically the previous patch without the overflow inlined functions. -- Fabien Coelho - CRI, MINES ParisTechdiff --git

Re: SIGQUIT on archiver child processes maybe not such a hot idea?

On 9/3/19 12:04 PM, Tom Lane wrote: > Kyotaro Horiguchi writes: >> But now we know that sending it to grand-children is wrong in a >> sense that that leads to left-alone unwanted core files. But the >> behavior is already knwon at the time. > >> So, Now I know that we need to revert that in

Re: Minimal logical decoding on standbys

On 2019-Jul-19, Amit Khandekar wrote: > Attached are the split patches. Included is an additional patch that > has doc changes. Here is what I have added in the docs. Pasting it > here so that all can easily spot how it is supposed to behave, and to > confirm that we are all on the same page :

Re: WIP: Data at rest encryption

On Tue, Sep 3, 2019 at 10:21 PM Alvaro Herrera wrote: > On 2019-Aug-02, Shawn Wang wrote: > > > Hi Antonin, > > It is very glad to see the new patch. I used the public patches a long > time ago. > > I did some tests like the stream replication, much data running, > temporary files encryption. >

Re: How to estimate the shared memory size required for parallel scan?

On 2019-Jul-08, Daniel Gustafsson wrote: > Below is a review of this patch. Any chance for a version addressing Daniel's comments? -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: SQL/JSON: JSON_TABLE

Now this is one giant patchset ... and at least the first patch seems to have more than one thing within -- even the commit message says so. It seems clear that this is going to take a long time to digest; maybe if we can get it in smaller pieces we can try to have a little at a time? In other

Re: WIP: Data at rest encryption

On 2019-Aug-02, Shawn Wang wrote: > Hi Antonin, > It is very glad to see the new patch. I used the public patches a long time > ago. > I did some tests like the stream replication, much data running, temporary > files encryption. > I found that there is an issue in the

Re: extension patch of CREATE OR REPLACE TRIGGER

On 2019-Jul-22, osumi.takami...@fujitsu.com wrote: > Dear Surafel > > Thank you for your check of my patch. > I’ve made the version 03 to > fix what you mentioned about my patch. > > I corrected my wrong bracing styles and > also reduced the amount of my regression test. > Off course, I erased

Re: Proposal: roll pg_stat_statements into core

On Tue, Sep 3, 2019 at 11:37 AM Michael Paquier wrote: > grOn Mon, Sep 02, 2019 at 12:07:17PM -0400, Tom Lane wrote: > > Euler Taveira writes: > >> At least if pg_stat_statements > >> was in core you could load it by default and have a GUC to turn it > >> on/off without restarting the server

Re: dropdb --force

út 3. 9. 2019 v 18:46 odesílatel Alvaro Herrera napsal: > On 2019-Jul-25, Pavel Stehule wrote: > > > čt 25. 7. 2019 v 5:11 odesílatel Tom Lane napsal: > > > > > Pavel Stehule writes: > > > > * I'm concerned that the proposed syntax is not future-proof. > > > > Can be > > > > DROP DATABASE '('

Re: block-level incremental backup

On Tue, Sep 3, 2019 at 7:39 PM Robert Haas wrote: > On Tue, Sep 3, 2019 at 10:05 AM Ibrar Ahmed wrote: > > +1 using the library to tar. But I think reason not using tar library is > TAR is > > one of the most simple file format. What is the best/newest format of > TAR? > > So, I don't really

Re: dropdb --force

On 2019-Jul-25, Pavel Stehule wrote: > čt 25. 7. 2019 v 5:11 odesílatel Tom Lane napsal: > > > Pavel Stehule writes: > > * I'm concerned that the proposed syntax is not future-proof. > > Can be > > DROP DATABASE '(' options ...) [IF EXISTS] name > > ok? Seems weird to me. I'd rather have

Re: block-level incremental backup

On Tue, Sep 3, 2019 at 8:00 PM Tom Lane wrote: > Ibrar Ahmed writes: > > +1 using the library to tar. > > Uh, *what* library? > I was just replying the Robert that he said "But I think there must be a reason why tar libraries exist, and I don't want to write a new one." I said I am ok to use

Re: pg11.5: ExecHashJoinNewBatch: glibc detected...double free or corruption (!prev)

On Tue, Aug 27, 2019 at 5:52 PM Merlin Moncure wrote: > > On Mon, Aug 26, 2019 at 12:01 PM Tom Lane wrote: > > > > Justin Pryzby writes: > > > On Mon, Aug 26, 2019 at 12:45:24PM -0400, Tom Lane wrote: > > >> However ... there is some pretty interesting info at > > >>

Re: accounting for memory used for BufFile during hash joins

On 2019-Jul-11, Tomas Vondra wrote: > On Wed, Jul 10, 2019 at 04:51:02PM -0700, Melanie Plageman wrote: > > I think implementing support for parallel hashjoin or explicitly > > disabling it would be the bare minimum for this patch, which is why I > > made 2 its own item. I've marked it as

Re: Patch: New GUC prepared_statement_limit to limit memory used by prepared statements

On 2019-Aug-18, Daniel Migowski wrote: > >  - Is this a WIP patch or the final patch? Because I can see TODO > > and non-standard comments in the patch. > > Definitely work in progress! The current implementation seems to work for > me, but might be improved, but I wanted some input from the

Re: Rearranging ALTER TABLE to avoid multi-operations bugs

Alvaro Herrera writes: > Tom: CFbot says this patch doesn't apply anymore. Could you please > rebase? Robert doesn't like the whole approach [1], so I'm not seeing much point in rebasing the current patch. The idea I'd been thinking about instead was to invent a new AlterTableType enum value

Re: Rearranging ALTER TABLE to avoid multi-operations bugs

On 2019-Aug-01, Thomas Munro wrote: > With my hacker hat: Hmm. I haven't looked at the patch, but not > passing down the QueryEnvironment when recursing is probably my fault, > and folding all such things into a new mechanism that would avoid such > bugs in the future sounds like a reasonable

Re: SIGQUIT on archiver child processes maybe not such a hot idea?

Kyotaro Horiguchi writes: > But now we know that sending it to grand-children is wrong in a > sense that that leads to left-alone unwanted core files. But the > behavior is already knwon at the time. > So, Now I know that we need to revert that in certain extent if > we want to stop the

Re: standby recovery fails (tablespace related) (tentative patch and discussion)

On 2019-Aug-22, Anastasia Lubennikova wrote: > 22.08.2019 16:13, Paul Guo wrote: > > Thanks. I updated the patch to v5. It passes install-check testing and > > recovery testing. > Hi, > Thank you for working on this fix. > The overall design of the latest version looks good to me. > But during

Re: Fetching timeline during recovery

On Mon, Jul 29, 2019 at 7:26 PM Jehan-Guillaume de Rorthais wrote: > > On Fri, 26 Jul 2019 18:22:25 +0200 > Jehan-Guillaume de Rorthais wrote: > > > On Fri, 26 Jul 2019 10:02:58 +0200 > > Jehan-Guillaume de Rorthais wrote: > > > > > On Fri, 26 Jul 2019 16:49:53 +0900 (Tokyo Standard Time) > > >

Got "FATAL: could not access status of transaction" in PG 11.2

Shutdown postgres server immediately with pg_ctl stop -m immediate command. When I restart the server got following fatal message: --- 126690 2019-09-03 14:06:52 UTC XX000 FATAL: could not

Re: block-level incremental backup

Ibrar Ahmed writes: > +1 using the library to tar. Uh, *what* library? pg_dump's pg_backup_tar.c is about 1300 lines, a very large fraction of which is boilerplate for interfacing to pg_backup_archiver's APIs. The stuff that actually knows specifically about tar looks to be maybe a couple

Re: block-level incremental backup

On Tue, Sep 3, 2019 at 10:05 AM Ibrar Ahmed wrote: > +1 using the library to tar. But I think reason not using tar library is TAR > is > one of the most simple file format. What is the best/newest format of TAR? So, I don't really want to go down this path at all, as I already said. You can

Re: [PATCH] Tab completion for CREATE OR REPLACE

On Thu, Aug 22, 2019 at 3:06 PM Wang, Shenhao wrote: > > Hello, hackers: > > I created a patch about tab completion for command CREATE OR REPLACE in psql > includes: > CREATE [ OR REPLACE ] FUNCTION > CREATE [ OR REPLACE ] PROCEDURE > CREATE [ OR REPLACE ] LANGUAGE >

Re: Locking a row with KEY SHARE NOWAIT blocks

On 03/09/2019 16:31, Tom Lane wrote: Heikki Linnakangas writes: When you lock a row with FOR KEY SHARE, and the row's non-key columns have been updated, heap_lock_tuple() walks the update chain to mark all the in-progress tuple versions also as locked. But it doesn't pay attention to the

Re: block-level incremental backup

On Tue, Sep 3, 2019 at 6:00 PM Robert Haas wrote: > On Sat, Aug 31, 2019 at 3:41 PM Ibrar Ahmed wrote: > > Are we using any tar library in pg_basebackup.c? We already have the > capability > > in pg_basebackup to do that. > > I think pg_basebackup is using homebrew code to generate tar files, >

Re: Locking a row with KEY SHARE NOWAIT blocks

Heikki Linnakangas writes: > When you lock a row with FOR KEY SHARE, and the row's non-key columns > have been updated, heap_lock_tuple() walks the update chain to mark all > the in-progress tuple versions also as locked. But it doesn't pay > attention to the NOWAIT or SKIP LOCKED flags when

Locking a row with KEY SHARE NOWAIT blocks

When you lock a row with FOR KEY SHARE, and the row's non-key columns have been updated, heap_lock_tuple() walks the update chain to mark all the in-progress tuple versions also as locked. But it doesn't pay attention to the NOWAIT or SKIP LOCKED flags when doing so. The

Re: BUG #15977: Inconsistent behavior in chained transactions

We have three options: 1. Prohibit AND CHAIN outside a transaction block, but do nothing in plain COMMIT/ROLLBACK or AND NO CHAIN. 2. Deal "there is no transaction in progress" (and "there is already a transaction in progress" if needed) as an error. 3. Leave as it is. Option 1 makes

Re: block-level incremental backup

On Sat, Aug 31, 2019 at 3:41 PM Ibrar Ahmed wrote: > Are we using any tar library in pg_basebackup.c? We already have the > capability > in pg_basebackup to do that. I think pg_basebackup is using homebrew code to generate tar files, but I'm reluctant to do that for reading tar files. For

unexpected rowlock mode when trigger is on the table

Hi pgsql hackers, I'd like to ask you for kind advice with problem I'm pretty long stuck on. I simplified it just to two tables and trigger. I described it thoroughly on Stack Overflow a week ago but nobody responded so far, so I was advised by Czech PG expert Pavel Stěhule to use this forum.

Re: [PATCH] Speedup truncates of relation forks

On Wed, Jul 24, 2019 at 9:58 AM Jamison, Kirk wrote: > > Hi, > > I repeated the recovery performance test before, and found out that I made a > wrong measurement. > Using the same steps indicated in the previous email (24GB shared_buffers for > my case), > the recovery time still significantly

Re: pg_dump --exclude-* options documentation

On 2019-09-02 16:55, Tom Lane wrote: > Fabien COELHO writes: >>> Should we change the documentation of the old pg_dump options to also >>> take a "pattern", or change the documentation of the new pg_dumpall >>> option to read "database"? > >> My 0.02€: we should use the more general and precise,

Re: pgbench - rework variable management

Hello Thomas, I noticed, but I do not have any windows host so I cannot test locally. The issue is how to do a mutex on Windows, which does not have pthread so it has to be emulated. I'll try again by sending a blind update to the patch and see how it goes. If you have the patience and a

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

On Mon, Sep 02, 2019 at 06:06:50PM -0400, Alvaro Herrera wrote: In the interest of moving things forward, how far are we from making 0001 committable? If I understand correctly, the rest of this patchset depends on https://commitfest.postgresql.org/24/944/ which seems to be moving at a glacial

Re: [Patch] Invalid permission check in pg_stats for functional indexes

Hello Pierre, > When using a functional index on a table, we realized that the permission > check done in pg_stats was incorrect and thus preventing valid access to the > statistics from users. > > The attached patch fixes this by introducing a second path in privilege check > in pg_stats view.

Re: XPRS

On Tue, Sep 03, 2019 at 11:04:43AM +1200, Thomas Munro wrote: On Tue, Sep 3, 2019 at 5:20 AM Tomas Vondra wrote: FWIW it's not clear to me why the cost would need to be recomputed after constructing the parallel version of the plan? My understanding is that the idea is to do cost-based

Re: Improve base backup protocol documentation

On 2019-09-03 09:50, Magnus Hagander wrote: > On Wed, Aug 28, 2019 at 4:58 PM Peter Eisentraut > > wrote: > > It was apparently entirely undocumented that the tablespace size > estimates sent by the base backup protocol are in kilobytes.  Here is

Re: BUG #15977: Inconsistent behavior in chained transactions

v3 applies, compiles, "make check" ok. I turned it ready on the app. Should we make it an error instead of a warning? ISTM that it made sense to have the same behavior as out of transaction COMMIT or ROLLBACK. -- Fabien.

Re: BUG #15977: Inconsistent behavior in chained transactions

On 2019-08-29 16:58, Fabien COELHO wrote: > >> Thanks, I got it. I have never made a patch before so I'll keep it in my >> mind. Self-contained patch is now attached. > > v3 applies, compiles, "make check" ok. > > I turned it ready on the app. Should we make it an error instead of a warning?

Re: Patch to add hook to copydir()

I read two previous proposals for something similar. First one is from 2013 [0]. It proposed a OS and filesystem specific implementation. Which was then changed to a patch that adds a config option to specify shell commands that postgres should use for copying files and dirs. This was after

Re: Improve base backup protocol documentation

On Wed, Aug 28, 2019 at 4:58 PM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > It was apparently entirely undocumented that the tablespace size > estimates sent by the base backup protocol are in kilobytes. Here is a > patch to document that. Also, a related clarification in the

Const version of castNode()

Hi, Right now, when assertions are enabled, using castNode() on a pointer to const triggers a warning for my compilers: warning: passing argument 2 of ‘castNodeImpl’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] which seems appropriate. Obviously we could easily

Re: Unix-domain socket support on Windows

On 2019-09-03 01:45, Thomas Munro wrote: > fe-connect.obj : error LNK2019: unresolved external symbol getpeereid > referenced in function PQconnectPoll > [C:\projects\postgresql\libpq.vcxproj] This should be fixed in the attached patches. -- Peter Eisentraut

Re: pgbench - rework variable management

On Tue, Sep 3, 2019 at 4:57 PM Fabien COELHO wrote: > I noticed, but I do not have any windows host so I cannot test locally. > > The issue is how to do a mutex on Windows, which does not have pthread so > it has to be emulated. I'll try again by sending a blind update to the > patch and see how

Re: block-level incremental backup

On Fri, Aug 16, 2019 at 3:54 PM Jeevan Chalke wrote: > 0003: +/* + * When to send the whole file, % blocks modified (90%) + */ +#define WHOLE_FILE_THRESHOLD 0.9 How this threshold is selected. Is it by some test? - magic number, currently 0 (4 bytes) I think in the patch we are using

Re: Patch to add hook to copydir()

On 2019-09-02 22:16, Swen Kooij wrote: > Is there anything that I am missing? My early experiments have been > very promising but my experience with Postgres internals is limited. Any > help or feedback would be much appreciated. You might want to review several previous threads that were

Re: fix "Success" error messages

On 2019-08-27 08:27, Michael Paquier wrote: > Thanks for the new patch, and you are right that pg_checksums has been > slacking here. There is the same issue with pg_verify_checksums in > 11. Not sure that's worth a back-patch though. Those parts could > find their way to v12 easily. Committed

  1   2   >