Re: [PATCH] Identify LWLocks in tracepoints

On 19.03.21 21:06, Peter Eisentraut wrote: On 18.03.21 07:34, Craig Ringer wrote:     In patch 0001, why was the TRACE_POSTGRESQL_LWLOCK_RELEASE() call     moved?   Is there some correctness issue?  If so, we should explain that (at     least in the commit message, or as a separate patch)

Re: [HACKERS] Custom compression methods (mac+lz4.h)

On Sun, Mar 21, 2021 at 7:03 AM Tom Lane wrote: > Also, I see some diffs in the > indirect_toast test, which seems perhaps worthy of investigation. > (The diffs look to be just row ordering, but why?) I have investigated that, actually in the below insert, after compression the data size of (rep

Re: Logical Replication vs. 2PC

On Sat, Mar 20, 2021 at 8:53 PM Amit Kapila wrote: > > On Sat, Mar 20, 2021 at 4:02 PM Dilip Kumar wrote: > > > > On Sat, Mar 20, 2021 at 7:50 AM Amit Kapila wrote: > > > > > > On Fri, Mar 19, 2021 at 9:22 PM Markus Wanner > > > wrote: > > > > > So, I think you are using xid of publisher and or

Re: fdatasync performance problem with large number of DB files

On Wed, 10 Mar 2021 at 20:25, Tom Lane wrote: > > So this means that in less-than-bleeding-edge kernels, syncfs can > only be regarded as a dangerous toy. If we expose an option to use > it, there had better be large blinking warnings in the docs. Isn't that true for fsync and everything else re

Re: New IndexAM API controlling index vacuum strategies

On Thu, 18 Mar 2021 at 14:37, Peter Geoghegan wrote: > They usually involve some *combination* of Postgres problems, > application code problems, and DBA error. Not any one thing. I've seen > problems with application code that runs DDL at scheduled intervals, > which interacts badly with vacuum

Re: cleaning up a few CLOG-related things

On Wed, Jan 27, 2021 at 12:35:30PM -0500, Robert Haas wrote: > On Mon, Jan 25, 2021 at 2:11 PM Heikki Linnakangas wrote: > > Having a separate FullTransactionIdToLatestPageNumber() function for > > this seems like overkill to me. > > I initially thought so too, but it turned out to be pretty usef

Re: Using COPY FREEZE in pgbench

V3 works for me and looks ok. I changed it to ready in the CF app. Thank you for your review! Unfortunately it seems cfbot is not happy with the patch. Argh. Indeed, I did not thought of testing on a partitioned table:-( ISTM I did "make check" in pgbench to trigger tap tests, but possib

Re: Logical Replication vs. 2PC

On 20.03.21 16:14, Amit Kapila wrote: Right, but I guess in our case using user-provided GID will conflict if we use multiple subscriptions on the same node. So, it is better to generate a unique identifier like we are discussing here, something like (origin_id of subscription + xid of the publis

Re: [PATCH] proposal for regexp_count, regexp_instr, regexp_substr and regexp_replace

Le 20/03/2021 à 19:48, Gilles Darold a écrit : > > Hi, > > > This is a new version of the patch that now implements all the XQUERY > regexp functions as described in the standard, minus the differences > of PostgerSQL regular expression explain in [1]. > > > The standard SQL describe functions like

Re: Using COPY FREEZE in pgbench

> The feature is a little disappointing because if someone has partition > tables then probably they have a lot of data and probably they would > like freeze to work there. Maybe freeze would work on table partitions > themselves, but I do not think it is worth the effort to do that. Agreed. > Ab

Re: proposal - psql - use pager for \watch command

ne 21. 3. 2021 v 0:42 odesílatel Thomas Munro napsal: > On Sun, Mar 21, 2021 at 11:44 AM Thomas Munro > wrote: > > [review] > > Oh, just BTW, to save confusion for others who might try this: It > seems there is something wrong with pspg --stream on macOS, at least > when using MacPorts. I assu

Re: Logical Replication vs. 2PC

On Sun, Mar 21, 2021 at 2:47 PM Markus Wanner wrote: > > On 20.03.21 16:14, Amit Kapila wrote: > > Right, but I guess in our case using user-provided GID will conflict > > if we use multiple subscriptions on the same node. So, it is better to > > generate a unique identifier like we are discussing

Re: replication cleanup code incorrect way to use of HTAB HASH_REMOVE ?

On Sat, Mar 20, 2021 at 12:54 PM Peter Smith wrote: > > PSA my patch to correct this by firstly doing a HASH_FIND, then only > HASH_REMOVE after we've finished using the ent. > Why can't we keep using HASH_REMOVE as it is but get the output (entry found or not) in the last parameter of hash_searc

Re: Replication slot stats misgivings

On Sun, Mar 21, 2021 at 2:57 AM Andres Freund wrote: > > Hi, > > On 2021-03-20 10:28:06 +0530, Amit Kapila wrote: > > On Sat, Mar 20, 2021 at 9:25 AM Amit Kapila wrote: > > > This idea is worth exploring to address the complaints but what do we > > > do when we detect that the stats are from the

Re: Replication slot stats misgivings

On Sun, Mar 21, 2021 at 2:56 AM Andres Freund wrote: > > On 2021-03-20 09:25:40 +0530, Amit Kapila wrote: > > On Sat, Mar 20, 2021 at 12:22 AM Andres Freund wrote: > > > > > > And then more generally about the feature: > > > - If a slot was used to stream out a large amount of changes (say an > >

Re: proposal - psql - use pager for \watch command

so 20. 3. 2021 v 23:45 odesílatel Thomas Munro napsal: > On Thu, Mar 4, 2021 at 11:28 PM Pavel Stehule > wrote: > > čt 4. 3. 2021 v 7:37 odesílatel Pavel Stehule > napsal: > >> Here is a little bit updated patch - detection of end of any child > process cannot be used on WIN32. > > Yeah, it's O

Re: [PATCH] Provide more information to filter_prepare

On Sat, Mar 13, 2021 at 3:43 PM Amit Kapila wrote: > > On Thu, Mar 11, 2021 at 2:44 PM Markus Wanner > wrote: > > > > On 11.03.21 04:58, Amit Kapila wrote: > > > But this happens when we are decoding prepare, so it is clear that the > > > transaction is prepared, why any additional check? > > > >

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

Hello On Sunday, March 21, 2021 4:37 PM Amit Kapila > On Sat, Mar 20, 2021 at 10:09 AM Ajin Cherian wrote: > > > > On Sat, Mar 20, 2021 at 1:35 AM Amit Kapila > wrote: > >> > >> On Fri, Mar 19, 2021 at 5:03 AM Ajin Cherian wrote: > >> > > >> > Missed the patch - 0001, resending. > >> > > >> >

Re: [PATCH] proposal for regexp_count, regexp_instr, regexp_substr and regexp_replace

> On 2021.03.20. 19:48 Gilles Darold wrote: > > This is a new version of the patch that now implements all the XQUERY > regexp functions as described in the standard, minus the differences of > PostgerSQL regular expression explain in [1]. > > The standard SQL describe functions like_regex(), o

Re: pg_upgrade failing for 200+ million Large Objects

On 3/20/21 12:55 PM, Jan Wieck wrote: > On 3/20/21 11:23 AM, Tom Lane wrote: >> Jan Wieck writes: >>> All that aside, the entire approach doesn't scale. >> >> Yeah, agreed.  When we gave large objects individual ownership and ACL >> info, it was argued that pg_dump could afford to treat each one

Re: Log message for GSS connection is missing once connection authorization is successful.

On Sat, Mar 20, 2021 at 4:59 PM Michael Paquier wrote: > > On Sat, Mar 20, 2021 at 05:37:47PM +0900, Michael Paquier wrote: > > It seems to me that this would make the tests faster, that the test > > would not need to wait for the logging collector and that the code > > could just use slurp_file($

Re: [PATCH] proposal for regexp_count, regexp_instr, regexp_substr and regexp_replace

Le 21/03/2021 à 12:07, e...@xs4all.nl a écrit : >> On 2021.03.20. 19:48 Gilles Darold wrote: >> >> This is a new version of the patch that now implements all the XQUERY >> regexp functions as described in the standard, minus the differences of >> PostgerSQL regular expression explain in [1]. >>

Re: support for MERGE

On Fri, Mar 19, 2021 at 6:03 PM Bruce Momjian wrote: > > On Fri, Mar 19, 2021 at 10:53:53AM -0400, David Steele wrote: > > On 3/19/21 10:44 AM, Alvaro Herrera wrote: > > > On 2021-Mar-19, David Steele wrote: > > > > > > > Since it does not appear this is being worked on for PG14 perhaps we > > >

Re: support for MERGE

On 2021-Mar-21, Magnus Hagander wrote: > On Fri, Mar 19, 2021 at 6:03 PM Bruce Momjian wrote: > > > > Let's get someone to go into the "database" and adjust it. ;-) > > Yeah, we probably can clean that up on the database side :) Thank you! > But what is it we *want* it to do? That is, what sh

Re: support for MERGE

On Sun, Mar 21, 2021 at 2:57 PM Alvaro Herrera wrote: > > On 2021-Mar-21, Magnus Hagander wrote: > > > On Fri, Mar 19, 2021 at 6:03 PM Bruce Momjian wrote: > > > > > > Let's get someone to go into the "database" and adjust it. ;-) > > > > Yeah, we probably can clean that up on the database side

Re: Log message for GSS connection is missing once connection authorization is successful.

Greetings, * Michael Paquier (mich...@paquier.xyz) wrote: > On Sat, Mar 20, 2021 at 05:37:47PM +0900, Michael Paquier wrote: > > It seems to me that this would make the tests faster, that the test > > would not need to wait for the logging collector and that the code > > could just use slurp_file(

Re: invalid data in file backup_label problem on windows

On Sat, Mar 20, 2021 at 3:10 AM wangsh.f...@fujitsu.com wrote: > > David Steele wrote: > > > It's not clear to me what text editors have to do with this? Are you > > editing the file manually? > > When I execute SELECT * FROM pg_stop_backup(false, true) in psql. > > The results will be shown like

Re: [PATCH] proposal for regexp_count, regexp_instr, regexp_substr and regexp_replace

On 03/21/21 09:19, Gilles Darold wrote: >>> On 2021.03.20. 19:48 Gilles Darold wrote: >>> >>> This is a new version of the patch that now implements all the XQUERY >>> regexp functions as described in the standard, minus the differences of >>> PostgerSQL regular expression explain in [1]. >>> >>

Re: [PATCH] proposal for regexp_count, regexp_instr, regexp_substr and regexp_replace

Chapman Flack writes: > If this turns out to be a case of "attached the wrong patch, here's > the one that does implement foo_regex functions!" then I reserve an > objection to that. :) +1 to that. Just to add a note, I do have some ideas about extending our regex parser so that it could duplica

Re: recovery_init_sync_method=wal

Greetings, * Thomas Munro (thomas.mu...@gmail.com) wrote: > 2. You made a file system-level copy of a cluster that you shut down > cleanly first, using cp, tar, scp, rsync, xmodem etc. Now you start > up the copy. Its checkpoint is a forgery. (Maybe our manual should > mention this problem und

Re: pl/pgsql feature request: shorthand for argument and local variable references

pá 19. 3. 2021 v 14:14 odesílatel Hannu Krosing napsal: > On Thu, Mar 18, 2021 at 4:23 PM Pavel Stehule > wrote: > > > But we don't support this feature. We are changing just a top scope's > label. So syntax "ALIAS FOR FUNCTION is not good. The user can have false > hopes > > In this case it loo

Re: shared memory stats: high level design decisions: consistency, dropping

Greetings, * Andres Freund (and...@anarazel.de) wrote: > I am working on Kyotaro Horiguchi's shared memory stats patch [1] with > the goal of getting it into a shape that I'd be happy to commit. That > thread is quite long and most are probably skipping over new messages in > it. Awesome, +1. >

Re: "has_column_privilege()" issue with attnums and non-existent columns

On 3/16/21 2:45 PM, Joe Conway wrote: Ian, or anyone else, any comments/complaints on my changes? If not I will commit and push that version sooner rather than later. Any thoughts on back-patching this? On one hand, in my view it is clearly a bug. On the other hand, no one has complained befo

Re: shared memory stats: high level design decisions: consistency, dropping

Andres Freund writes: > 1) What kind of consistency do we want from the pg_stats_* views? That's a hard choice to make. But let me set the record straight: when we did the initial implementation, the stats snapshotting behavior was considered a FEATURE, not an "efficiency hack required by the ol

Re: "has_column_privilege()" issue with attnums and non-existent columns

Joe Conway writes: > On 3/16/21 2:45 PM, Joe Conway wrote: >> Ian, or anyone else, any comments/complaints on my changes? If not I will >> commit >> and push that version sooner rather than later. I took a quick look, and I'm afraid I don't believe this: !* We have to check for dropped

Re: Using COPY FREEZE in pgbench

Attached is the v5 patch. About v5: doc gen ok, global and local make check ok. I did a few tests on my laptop. Is seems that copying takes a little more time, say about 10%, but vacuum is indeed very significantly reduced, so that the total time for copying and vacuuming is reduced by 10%

Re: [PATCH] proposal for regexp_count, regexp_instr, regexp_substr and regexp_replace

Le 21/03/2021 à 15:53, Tom Lane a écrit : > Chapman Flack writes: >> If this turns out to be a case of "attached the wrong patch, here's >> the one that does implement foo_regex functions!" then I reserve an >> objection to that. :) > +1 to that. Just to add a note, I do have some ideas about ext

Re: [PATCH] proposal for regexp_count, regexp_instr, regexp_substr and regexp_replace

Le 21/03/2021 à 15:53, Tom Lane a écrit : > Chapman Flack writes: >> If this turns out to be a case of "attached the wrong patch, here's >> the one that does implement foo_regex functions!" then I reserve an >> objection to that. :) >> And the patch renamed. diff --git a/doc/src/sgml/func.sgml b

Fix pg_upgrade to preserve datdba (was: Re: pg_upgrade failing for 200+ million Large Objects)

On 3/20/21 12:39 AM, Jan Wieck wrote: On the way pg_upgrade also mangles the pg_database.datdba (all databases are owned by postgres after an upgrade; will submit a separate patch for that as I consider that a bug by itself). Patch attached. Regards, Jan -- Jan Wieck Principle Database Engin

Re: pg_upgrade failing for 200+ million Large Objects

On 3/21/21 7:47 AM, Andrew Dunstan wrote: One possible (probable?) source is the JDBC driver, which currently treats all Blobs (and Clobs, for that matter) as LOs. I'm working on improving that some: You mean the user is using OID columns pointing to

Re: Fix pg_upgrade to preserve datdba (was: Re: pg_upgrade failing for 200+ million Large Objects)

Jan Wieck writes: > On 3/20/21 12:39 AM, Jan Wieck wrote: >> On the way pg_upgrade also mangles the pg_database.datdba >> (all databases are owned by postgres after an upgrade; will submit a >> separate patch for that as I consider that a bug by itself). > Patch attached. Hmm, doesn't this lose

Re: Fix pg_upgrade to preserve datdba

On 3/21/21 12:57 PM, Tom Lane wrote: Jan Wieck writes: On 3/20/21 12:39 AM, Jan Wieck wrote: On the way pg_upgrade also mangles the pg_database.datdba (all databases are owned by postgres after an upgrade; will submit a separate patch for that as I consider that a bug by itself). Patch atta

Re: New IndexAM API controlling index vacuum strategies

On Sun, Mar 21, 2021 at 1:24 AM Greg Stark wrote: > What I've seen is an application that regularly ran ANALYZE on a > table. This worked fine as long as vacuums took less than the interval > between analyzes (in this case 1h) but once vacuum started taking > longer than that interval autovacuum w

Re: Fix pg_upgrade to preserve datdba

On 3/21/21 1:15 PM, Jan Wieck wrote: On 3/21/21 12:57 PM, Tom Lane wrote: Jan Wieck writes: On 3/20/21 12:39 AM, Jan Wieck wrote: On the way pg_upgrade also mangles the pg_database.datdba (all databases are owned by postgres after an upgrade; will submit a separate patch for that as I conside

Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY

On Fri, Mar 19, 2021 at 10:57:37AM -0300, Alvaro Herrera wrote: > > Also, it "fails to avoid" adding duplicate constraints: > > > > Check constraints: > > "c" CHECK (i IS NOT NULL AND i > 1 AND i < 2) > > "cc" CHECK (i IS NOT NULL AND i >= 1 AND i < 2) > > "p1_check" CHECK (true) > >

Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY

On 2021-Mar-21, Justin Pryzby wrote: > On Fri, Mar 19, 2021 at 10:57:37AM -0300, Alvaro Herrera wrote: > > > Also, it "fails to avoid" adding duplicate constraints: > > > > > > Check constraints: > > > "c" CHECK (i IS NOT NULL AND i > 1 AND i < 2) > > > "cc" CHECK (i IS NOT NULL AND i >=

Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY

On 2021-Mar-19, Alvaro Herrera wrote: > diff --git a/src/backend/utils/cache/partcache.c > b/src/backend/utils/cache/partcache.c > index 0fe4f55b04..6dfa3fb4a8 100644 > --- a/src/backend/utils/cache/partcache.c > +++ b/src/backend/utils/cache/partcache.c > @@ -352,16 +352,9 @@ generate_partition_

Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY

On Sun, Mar 21, 2021 at 03:01:15PM -0300, Alvaro Herrera wrote: > > But note that it doesn't check if an existing constraint "implies" the new > > constraint - maybe it should. > > Hm, I'm not sure I want to do that, because that means that if I later > have to attach the partition again with the

Re: pg_upgrade failing for 200+ million Large Objects

On 3/21/21 12:56 PM, Jan Wieck wrote: > On 3/21/21 7:47 AM, Andrew Dunstan wrote: >> One possible (probable?) source is the JDBC driver, which currently >> treats all Blobs (and Clobs, for that matter) as LOs. I'm working on >> improving that some: > >

Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY

On 2021-Mar-21, Justin Pryzby wrote: > On Sun, Mar 21, 2021 at 03:01:15PM -0300, Alvaro Herrera wrote: > > > But note that it doesn't check if an existing constraint "implies" the new > > > constraint - maybe it should. > > > > Hm, I'm not sure I want to do that, because that means that if I late

Re: Fix pg_upgrade to preserve datdba

Jan Wieck writes: >> On 3/21/21 12:57 PM, Tom Lane wrote: >>> I think maybe what we have here is a bug in pg_restore, its >>> --create switch ought to be trying to update the database's >>> ownership. > Thanks for that. I like this patch a lot better. Needs a little more work than that --- we sh

Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY

On Sun, Mar 21, 2021 at 03:22:00PM -0300, Alvaro Herrera wrote: > On 2021-Mar-21, Justin Pryzby wrote: > > > On Sun, Mar 21, 2021 at 03:01:15PM -0300, Alvaro Herrera wrote: > > > > But note that it doesn't check if an existing constraint "implies" the > > > > new > > > > constraint - maybe it sho

Re: Built-in connection pooler

People asked me to resubmit built-in connection pooler patch to commitfest. Rebased version of connection pooler is attached. diff --git a/contrib/spi/refint.c b/contrib/spi/refint.c index 6fbfef2b12..27aa6cba8e 100644 --- a/contrib/spi/refint.c +++ b/contrib/spi/refint.c @@ -11,6 +11,7 @@ #in

Re: Fix pg_upgrade to preserve datdba

I wrote: > Needs a little more work than that --- we should allow it to respond > to the --no-owner switch, for example. But I think likely we can do > it where other object ownership is handled. I'll look in a bit. Actually ... said code already DOES do that, so now I'm confused. I tried regre

Re: default result formats setting

On 19.03.21 15:55, Emre Hasegeli wrote: I applied the patch, tried running the test and got the following: rm -rf '/Users/hasegeli/Developer/postgres/src/test/modules/libpq_extended'/tmp_check /bin/sh ../../../../config/install-sh -c -d '/Users/hasegeli/Developer/postgres/src/test/modules/li

Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY

On 2021-Mar-21, Justin Pryzby wrote: > On Sun, Mar 21, 2021 at 03:22:00PM -0300, Alvaro Herrera wrote: > > > So if we do that on DETACH, what would happen on ATTACH? > > Do you mean what happens to the constraint that was already there ? > Nothing, since it's not ours to mess with. Checking Impl

Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY

On Sun, Mar 21, 2021 at 01:14:20PM -0500, Justin Pryzby wrote: > On Sun, Mar 21, 2021 at 03:01:15PM -0300, Alvaro Herrera wrote: > > > But note that it doesn't check if an existing constraint "implies" the new > > > constraint - maybe it should. > > > > Hm, I'm not sure I want to do that, because

Re: default result formats setting

> Could you look into the log files in that test directory what is going > on? Command 'test-result-format' not found in /Users/hasegeli/Developer/postgres/tmp_install/Users/hasegeli/.local/pgsql/bin, /Users/hasegeli/.local/bin, /opt/homebrew/bin, /usr/local/bin, /usr/bin, /bin, /usr/sbin, /sbin,

Re: Fix pg_upgrade to preserve datdba

I wrote: > ... so at least in this case it's doing the right thing. We need a bit > more detail about the context in which it's doing the wrong thing > for you. Just to cross-check, I tried modifying pg_upgrade's regression test as attached, and it still passes. (And inspection of the leftover d

Re: Different compression methods for FPI

rebased to keep cfbot happy. This will run with default=zlib. On Mon, Mar 15, 2021 at 01:09:18PM -0500, Justin Pryzby wrote: > On Sun, Mar 14, 2021 at 07:31:35PM -0500, Justin Pryzby wrote: > > On Sat, Mar 13, 2021 at 08:48:33PM +0500, Andrey Borodin wrote: > > > > 13 марта 2021 г., в 06:28, Just

Re: Fix pg_upgrade to preserve datdba

On 3/21/21 2:34 PM, Tom Lane wrote: and I see -- -- Name: joe; Type: DATABASE; Schema: -; Owner: joe -- CREATE DATABASE joe WITH TEMPLATE = template0 ENCODING = 'SQL_ASCII' LOCALE = 'C'; ALTER DATABASE joe OWNER TO joe; so at least in this case it's doing the right thing. We need a bit mor

[PATCH] In psql \?, add [+] annotation where appropriate

Hi, User inoas on IRC channel #postgresql noted that \? does not describe \do as supporting the + option. It does however support this option, as do \dAp and \dy. This patch adds the annotation to the description of these commands in \?. While adding it to the translation files I noticed some

Re: Fix pg_upgrade to preserve datdba

Jan Wieck writes: > So let's focus on the actual problem of running out of XIDs and memory > while doing the upgrade involving millions of small large objects. Right. So as far as --single-transaction vs. --create goes, that's mostly a definitional problem. As long as the contents of a DB are

Re: [HACKERS] Custom compression methods (mac+lz4.h)

Dilip Kumar writes: >> Yeah, we need to set the default_toast_compression in the beginning of >> the test as attached. > In the last patch, I did not adjust the compression_1.out so fixed > that in the attached patch. Pushed that; however, while testing that it works as expected, I saw a new and

Re: [HACKERS] Custom compression methods (mac+lz4.h)

On Sun, Mar 21, 2021 at 04:32:31PM -0400, Tom Lane wrote: > This seems somewhat repeatable (three identical failures in three > attempts). Not sure why I did not see it yesterday; but anyway, > there is something wrong with partial detoasting for LZ4. With what version of LZ4 ? -- Justin

Re: Built-in connection pooler

Hi, + With load-balancing policy postmaster choose proxy with lowest load average. + Load average of proxy is estimated by number of clients connection assigned to this proxy with extra weight for SSL connections. I think 'load-balanced' may be better than 'load-balancing'. post

Re: [HACKERS] Custom compression methods (mac+lz4.h)

Justin Pryzby writes: > On Sun, Mar 21, 2021 at 04:32:31PM -0400, Tom Lane wrote: >> This seems somewhat repeatable (three identical failures in three >> attempts). Not sure why I did not see it yesterday; but anyway, >> there is something wrong with partial detoasting for LZ4. > With what versi

Re: [PATCH] Bug fix in initdb output

On 3/2/21 9:32 AM, Alvaro Herrera wrote: > On 2021-Mar-02, Nitin Jadhav wrote: > >>> FWIW, I don't think that it is a good idea to come back to this >>> decision for *nix platforms, so I would let it as-is, and use >>> relative paths if initdb is called using a relative path. >> The command to be

Re: [HACKERS] Custom compression methods

Justin Pryzby writes: > Rebased on HEAD. > 0005 forgot to update compression_1.out. > Included changes to ./configure.ac and some other patches, but not Tomas's, > since it'll make CFBOT get mad as soon as that's pushed. I pushed a version of the configure fixes that passes my own sanity checks,

Re: [HACKERS] Custom compression methods

... btw, now that I look at this, why are we expending a configure probe for ? If we need to cater for that spelling of the header name, the C code proper is not ready for it. regards, tom lane

Re: Replication slot stats misgivings

Hi, On 2021-03-21 16:08:00 +0530, Amit Kapila wrote: > On Sun, Mar 21, 2021 at 2:57 AM Andres Freund wrote: > > On 2021-03-20 10:28:06 +0530, Amit Kapila wrote: > > > On Sat, Mar 20, 2021 at 9:25 AM Amit Kapila > > > wrote: > > > > This idea is worth exploring to address the complaints but what

Re: replication cleanup code incorrect way to use of HTAB HASH_REMOVE ?

On Sun, Mar 21, 2021 at 8:54 PM Amit Kapila wrote: > > On Sat, Mar 20, 2021 at 12:54 PM Peter Smith wrote: > > > > PSA my patch to correct this by firstly doing a HASH_FIND, then only > > HASH_REMOVE after we've finished using the ent. > > > > Why can't we keep using HASH_REMOVE as it is but get

Re: shared memory stats: high level design decisions: consistency, dropping

Hi, On 2021-03-21 11:41:30 -0400, Stephen Frost wrote: > > 1.1) > > > > I hope everybody agrees with not requiring that stats don't need to be > > the way they were at the time of first stat access in a transaction, > > even if that first access was to a different stat object than the > > currentl

Re: recovery_init_sync_method=wal

On Mon, Mar 22, 2021 at 4:31 AM Stephen Frost wrote: > Presuming that we do add to the documentation the language to document > what's assumed (and already done by modern backup tools) that they're > fsync'ing everything they're restoring, do we/can we have an option > which those tools could set

Re: recovery_init_sync_method=wal

Greetings, * Thomas Munro (thomas.mu...@gmail.com) wrote: > On Mon, Mar 22, 2021 at 4:31 AM Stephen Frost wrote: > > Presuming that we do add to the documentation the language to document > > what's assumed (and already done by modern backup tools) that they're > > fsync'ing everything they're re

Re: shared memory stats: high level design decisions: consistency, dropping

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > If I understand what you are proposing, all stats views would become > completely volatile, without even within-query consistency. That really > is not gonna work. As an example, you could get not-even-self-consistent > results from a join to a

Re: replication cleanup code incorrect way to use of HTAB HASH_REMOVE ?

On Mon, Mar 22, 2021 at 10:50 AM Peter Smith wrote: > The real problem isn't the Assert. It's all those other usages of ent > disobeying the API rule: "(NB: in the case of the REMOVE action, the > result is a dangling pointer that shouldn't be dereferenced!)" I suppose the HASH_REMOVE case could

Re: 64-bit XIDs in deleted nbtree pages

On Wed, Mar 10, 2021 at 5:34 PM Peter Geoghegan wrote: > Here is another bitrot-fix-only revision, v9. Just the recycling patch again. I committed the final nbtree page deletion patch just now -- the one that attempts to make recycling happen for newly deleted pages. Thanks for all your work on p

Re: shared memory stats: high level design decisions: consistency, dropping

Hi, On 2021-03-21 12:14:35 -0400, Tom Lane wrote: > Andres Freund writes: > > 1) What kind of consistency do we want from the pg_stats_* views? > > That's a hard choice to make. But let me set the record straight: > when we did the initial implementation, the stats snapshotting behavior > was co

Re: replication cleanup code incorrect way to use of HTAB HASH_REMOVE ?

On Mon, Mar 22, 2021 at 9:21 AM Thomas Munro wrote: > > On Mon, Mar 22, 2021 at 10:50 AM Peter Smith wrote: > > The real problem isn't the Assert. It's all those other usages of ent > > disobeying the API rule: "(NB: in the case of the REMOVE action, the > > result is a dangling pointer that shou

Re: replication cleanup code incorrect way to use of HTAB HASH_REMOVE ?

Hi, On 2021-03-22 11:20:37 +1300, Thomas Munro wrote: > On Mon, Mar 22, 2021 at 10:50 AM Peter Smith wrote: > > The real problem isn't the Assert. It's all those other usages of ent > > disobeying the API rule: "(NB: in the case of the REMOVE action, the > > result is a dangling pointer that shou

Re: [HACKERS] Custom compression methods (mac+lz4.h)

I wrote: > Justin Pryzby writes: >> On Sun, Mar 21, 2021 at 04:32:31PM -0400, Tom Lane wrote: >>> This seems somewhat repeatable (three identical failures in three >>> attempts). Not sure why I did not see it yesterday; but anyway, >>> there is something wrong with partial detoasting for LZ4. >>

Re: Table AM and DDLs

Hi, On 2021-03-03 22:15:18 +0100, Mats Kindahl wrote: > On Tue, Feb 23, 2021 at 2:11 AM Andres Freund wrote: > Thanks for the answer and sorry about the late reply. Mine is even later ;) > > I don't think that's quite right. It's not exactly obvious from the > > name, but RelationDropStorage()

Re: [HACKERS] Custom compression methods (mac+lz4.h)

On Sun, Mar 21, 2021 at 07:11:50PM -0400, Tom Lane wrote: > I wrote: > > Justin Pryzby writes: > >> On Sun, Mar 21, 2021 at 04:32:31PM -0400, Tom Lane wrote: > >>> This seems somewhat repeatable (three identical failures in three > >>> attempts). Not sure why I did not see it yesterday; but anywa

Re: Support for NSS as a libpq TLS backend

Greetings, * Daniel Gustafsson (dan...@yesql.se) wrote: > Attached is a rebase which attempts to fix the cfbot Appveyor failure, there > were missing HAVE_ defines for MSVC. > Subject: [PATCH v30 1/9] nss: Support libnss as TLS library in libpq > > This commit contains the frontend and backend p

Re: [HACKERS] Custom compression methods (mac+lz4.h)

Justin Pryzby writes: > On Sun, Mar 21, 2021 at 07:11:50PM -0400, Tom Lane wrote: >> I hate to be the bearer of bad news, but this suggests that >> LZ4_decompress_safe_partial is seriously broken in 1.9.2 >> as well: >> https://github.com/lz4/lz4/issues/783 > Ouch Actually, after reading that cl

Re: [HACKERS] Custom compression methods

On Sat, Mar 20, 2021 at 06:20:39PM -0500, Justin Pryzby wrote: > Rebased on HEAD. > 0005 forgot to update compression_1.out. > Included changes to ./configure.ac and some other patches, but not Tomas's, > since it'll make CFBOT get mad as soon as that's pushed. Rebased again. Renamed "t" to a badc

Re: PITR promote bug: Checkpointer writes to older timeline

On Thu, Mar 18, 2021 at 12:56:12PM +0900, Michael Paquier wrote: > I was looking at uses of ThisTimeLineID in the wild, and could not > find it getting checked or used actually in backend-side code that > involved the WAL reader facility. Even if it brings confidence, it > does not mean that it is

Re: Log message for GSS connection is missing once connection authorization is successful.

On Sun, Mar 21, 2021 at 05:53:04PM +0530, Bharath Rupireddy wrote: > +1 from me. So, after every call to test_access, the node's current > logfile gets truncated and we don't need the logging collector process > to step in for rotation of the logfile. > > The patch looks good to me and the kerber

Why logical replication lancher exits 1?

I noticed when I execute "pg_ctl stop". 11799 2021-03-22 07:28:19 JST LOG: received fast shutdown request 11799 2021-03-22 07:28:19 JST LOG: aborting any active transactions 11799 2021-03-22 07:28:20 JST LOG: background worker "logical replication launcher" (PID 11807) exited with exit code 1

Re: Using COPY FREEZE in pgbench

> I did a few tests on my laptop. Is seems that copying takes a little > more time, say about 10%, but vacuum is indeed very significantly > reduced, so that the total time for copying and vacuuming is reduced > by 10% on overall. > > So it is okay for me. Thanks for the test. I wrote: > Curent

Re: About to add WAL write/fsync statistics to pg_stat_wal view

On 2021-03-19 16:30, Fujii Masao wrote: > On 2021/03/15 10:39, Masahiro Ikeda wrote: >> Thanks, I understood get_sync_bit() checks the sync flags and >> the write unit of generated wal data and replicated wal data is >> different. >> (It's interesting optimization whether to use kernel cache or no

Re: shared-memory based stats collector

At Thu, 18 Mar 2021 01:47:20 -0700, Andres Freund wrote in > Hi, > > On 2021-03-18 16:56:02 +0900, Kyotaro Horiguchi wrote: > > At Tue, 16 Mar 2021 10:27:55 +0900 (JST), Kyotaro Horiguchi > > wrote in > > > At Mon, 15 Mar 2021 17:49:36 +0900 (JST), Kyotaro Horiguchi > > > wrote in > > > >

PostgreSQL 14 Feature Freeze + Release Management Team (RMT)

Hi, The Release Management Team (RMT) for the PostgreSQL 14 is assembled and has determined that the feature freeze date for the PostgreSQL 11 release will be April 7, 2021. This means that any feature for the PostgreSQL 14 release *must be committed by April 7, 2021 AoE* ("anywhere on earth", se

Re: Why logical replication lancher exits 1?

On Mon, Mar 22, 2021 at 1:11 PM Tatsuo Ishii wrote: > It seems only logical replication launcher exited with exit code 1 > when it received shutdown request. Why? FWIW here's an earlier discussion of that topic: https://www.postgresql.org/message-id/flat/CAEepm%3D1c3hG1g3iKYwfa_PDsT49RBaBJsaot_q

Re: row filtering for logical replication

On Tue, Mar 9, 2021, at 12:05 PM, Rahila Syed wrote: > Please find some comments below: Thanks for your review. > 1. If the where clause contains non-replica identity columns, the delete > performed on a replicated row > using DELETE from pub_tab where repl_ident_col = n; > is not being replicat

Re: row filtering for logical replication

On Thu, Mar 18, 2021, at 7:51 AM, Rahila Syed wrote: > 1. > I think the docs are being incorrectly updated to add a column to > pg_partitioned_table > instead of pg_publication_rel. Good catch. > 2. +typedef struct PublicationRelationQual > +{ > + Oid relid; > +

Re: Wrong statistics for size of XLOG_SWITCH during pg_waldump.

On 2021/03/19 18:27, Fujii Masao wrote: On 2021/03/19 15:06, shinya11.k...@nttdata.com wrote: But 0 value maybe looks strange, so in current version I show it like >below: Type N (%) Record size (%) FPI size (%) Combined size (%) - --- --- --- --- - --- ...

Re: replication cleanup code incorrect way to use of HTAB HASH_REMOVE ?

On Mon, Mar 22, 2021 at 3:20 AM Peter Smith wrote: > > On Sun, Mar 21, 2021 at 8:54 PM Amit Kapila wrote: > > > > On Sat, Mar 20, 2021 at 12:54 PM Peter Smith wrote: > > > > > > PSA my patch to correct this by firstly doing a HASH_FIND, then only > > > HASH_REMOVE after we've finished using the

Re: Add client connection check during the execution of the query

On Sat, Mar 6, 2021 at 5:50 PM Zhihong Yu wrote: > + if (client_connection_check_interval > 0) > + enable_timeout_after(CLIENT_CONNECTION_CHECK_TIMEOUT, > > + /* Start timeout for checking if the client has gone away if necessary. */ > + if (client_connection_check_interval) T

  1   2   >