RE: Added schema level support for publication.

On Thurs, Oct 21, 2021 12:25 AM vignesh C wrote: > This version of patch retains the changes related to PublicationRelInfo, I > will > handle the merging of the patches in the next version so that this version of > patch change related to PublicationRelInfo can be reviewed easily. Thanks for the

Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?

On Fri, Oct 15, 2021 at 11:53 PM Jeff Davis wrote: > > On Fri, 2021-10-15 at 13:52 -0400, Stephen Frost wrote: > > While I appreciate that > > it > > isn't really addressing the complaint you have that it'd be nice if > > we > > made things simpler for administrators by making it so they don't > >

Re: pg_receivewal starting position

Le jeudi 21 octobre 2021, 07:35:08 CEST Michael Paquier a écrit : > On Wed, Oct 20, 2021 at 02:58:26PM +0200, Ronan Dunklau wrote: > > After sending the previous patch suite, I figured it would be worthwhile > > to > > also have tests covering timeline switches, which was not covered before. > > T

Re: [Bug] Logical Replication failing if the DateStyle is different in Publisher & Subscriber

On Thu, Oct 21, 2021 at 11:16 AM Masahiko Sawada wrote: > > On Wed, Oct 20, 2021 at 8:12 PM Japin Li wrote: > > > > > > On Mon, 18 Oct 2021 at 17:27, Dilip Kumar wrote: > > > On Mon, Oct 18, 2021 at 1:41 PM Japin Li wrote: > > > > > >> I attached v3 patch that set IntervalStyle to 'postgres' wh

Re: Reserve prefixes for loaded libraries proposal

On Thu, Sep 30, 2021 at 11:54:04PM +0200, Florin Irion wrote: > We could also help users get a warning if they set a parameter with the > `SET` > command. I've seen many cases where users make typos and break things badly, > check the following example: > > ``` > postgres=# BEGIN; > BEGIN > postgr

Re: Data is copied twice when specifying both child and parent table in publication

On Thu, Oct 21, 2021 at 2:56 PM Peter Smith wrote: > > I just wanted to bring to your attention an earlier thread [1] in > which I had already encountered/reported behaviour that is either > exactly the same or is closely related to what is being discussed in > this current thread. If it is differ

Re: pgsql: Document XLOG_INCLUDE_XID a little better

On Thu, Oct 21, 2021 at 9:11 AM Amit Kapila wrote: > > On Wed, Oct 20, 2021 at 8:49 PM Dilip Kumar wrote: > > > > On Wed, Oct 20, 2021 at 7:09 PM Alvaro Herrera > > wrote: > > > > > > Does MarkTopTransactionIdLogged() have to be inside XLogInsertRecord's > > > critical section? > > > > I think

Re: [Bug] Logical Replication failing if the DateStyle is different in Publisher & Subscriber

On Wed, Oct 20, 2021 at 8:12 PM Japin Li wrote: > > > On Mon, 18 Oct 2021 at 17:27, Dilip Kumar wrote: > > On Mon, Oct 18, 2021 at 1:41 PM Japin Li wrote: > > > >> I attached v3 patch that set IntervalStyle to 'postgres' when the > >> server backend is walsender, and this problem has gone. > > >

Re: ThisTimeLineID can be used uninitialized

On Wed, Oct 20, 2021 at 09:08:57AM -0400, Robert Haas wrote: > On Tue, Oct 19, 2021 at 7:30 PM Alvaro Herrera > wrote: >>> Istm we should introduce an InvalidTimeLineID, and explicitly initialize >>> sendTimeLine to that, and assert that it's valid / invalid in a bunch of >>> places? >> >> That's

Re: pg_receivewal starting position

On Wed, Oct 20, 2021 at 02:58:26PM +0200, Ronan Dunklau wrote: > After sending the previous patch suite, I figured it would be worthwhile to > also have tests covering timeline switches, which was not covered before. That seems independent to me. I'll take a look. > So please find attached a ne

Re: can we add subscription TAP test option "vcregress subscriptioncheck" for MSVC builds?

On Tue, Oct 19, 2021 at 11:49 AM Bharath Rupireddy wrote: > > On Tue, Oct 19, 2021 at 6:16 AM Michael Paquier wrote: > > > > On Mon, Oct 18, 2021 at 09:56:41AM -0400, Andrew Dunstan wrote: > > > Well, see > > > > >

Re: Skipping logical replication transactions on subscriber side

On Wed, Oct 20, 2021 at 12:33 PM Greg Nancarrow wrote: > > On Mon, Oct 18, 2021 at 12:34 PM Masahiko Sawada > wrote: > > > > I've attached updated patches that incorporate all comments I got so far. > > > > Minor comment on patch 17-0003 Thank you for the comment! > > src/backend/replication/l

Re: XTS cipher mode for cluster file encryption

On 2021/10/20 20:24, Stephen Frost wrote: > PG does have a block-based IO API, it's just not exposed as hooks. In > particular, take a look at md.c, though perhaps you'd be more interested > in the higher level bufmgr.c routines. For the specific places where > encryption may hook in, looking at

Re: lastOverflowedXid does not handle transaction ID wraparound

At Wed, 20 Oct 2021 08:55:12 -0700, Stan Hu wrote in > On Wed, Oct 20, 2021 at 4:00 AM Andrey Borodin wrote: > > > > > > > > 17 окт. 2021 г., в 21:55, Dmitry Dolgov <9erthali...@gmail.com> > > написал(а): > > > I wonder what would be side > > > effects of clearing it when the snapshot is not su

Re: lastOverflowedXid does not handle transaction ID wraparound

At Wed, 20 Oct 2021 13:48:33 +0200, Dmitry Dolgov <9erthali...@gmail.com> wrote in > > On Wed, Oct 20, 2021 at 04:00:35PM +0500, Andrey Borodin wrote: > > > 17 окт. 2021 г., в 21:55, Dmitry Dolgov <9erthali...@gmail.com> > > > написал(а): > > > I wonder what would be side > > > effects of cleari

Re: Data is copied twice when specifying both child and parent table in publication

Hi, I just wanted to bring to your attention an earlier thread [1] in which I had already encountered/reported behaviour that is either exactly the same or is closely related to what is being discussed in this current thread. If it is different please take that into account also. -- [1] http

Re: pgsql: Document XLOG_INCLUDE_XID a little better

On Wed, Oct 20, 2021 at 8:49 PM Dilip Kumar wrote: > > On Wed, Oct 20, 2021 at 7:09 PM Alvaro Herrera > wrote: > > > > Does MarkTopTransactionIdLogged() have to be inside XLogInsertRecord's > > critical section? > > I think this function is doing somewhat similar things to what we are > doing in

Re: [PATCH] Fix memory corruption in pg_shdepend.c

On Wed, Oct 20, 2021 at 8:27 PM Michael Paquier wrote: > Perhaps. This means the creation of a new database with shared deps > in contrib/amcheck/t/. But is amcheck really a correct target here? > The fields involved here are an int, some OIDs and a char with a given > subset of values making th

Re: [PATCH] Fix memory corruption in pg_shdepend.c

On Wed, Oct 20, 2021 at 07:59:50PM -0700, Peter Geoghegan wrote: > I think that EDB's pg_catcheck tool can detect problems like this one. Yes, pg_catcheck is able to catch that. > Perhaps it can be converted into an amcheck/pg_amcheck patch, and > submitted. That would give us very broad coverage

Re: pgsql: Document XLOG_INCLUDE_XID a little better

On Wed, Oct 20, 2021 at 9:46 PM Alvaro Herrera wrote: > > On 2021-Oct-20, Dilip Kumar wrote: > > > On Wed, Oct 20, 2021 at 7:09 PM Alvaro Herrera > > wrote: > > > > In IsTopTransactionIdLogPending(), I suggest to reorder the tests so > > > that the faster ones are first -- or at least, the last

Re: Skipping logical replication transactions on subscriber side

On Wed, Oct 20, 2021 at 12:03 PM houzj.f...@fujitsu.com wrote: > > On Mon, Oct 18, 2021 9:34 AM Masahiko Sawada wrote: > > I've attached updated patches that incorporate all comments I got so far. > > Hi, > > Here are some minor comments for the patches. Thank you for the comments! > > v17-0001

Re: [PATCH] Fix memory corruption in pg_shdepend.c

On Wed, Oct 20, 2021 at 5:20 AM Alvaro Herrera wrote: > Ouch ... this means that pg_shdepends contents are broken for databases > created with 14.0? hmm ... yes. I think that EDB's pg_catcheck tool can detect problems like this one. Perhaps it can be converted into an amcheck/pg_amcheck patch, a

Re: [PATCH] Fix memory corruption in pg_shdepend.c

On Wed, Oct 20, 2021 at 09:19:51AM -0300, Alvaro Herrera wrote: > Ouch ... this means that pg_shdepends contents are broken for databases > created with 14.0? hmm ... yes. Yes, it means so :( I have fixed the issue for now, and monitored the rest of the tree. Another issue is that we have zero

Re: Failed transaction statistics to measure the logical replication progress

On Mon, Oct 18, 2021 at 7:03 PM Amit Kapila wrote: > > On Thu, Oct 14, 2021 at 9:23 AM houzj.f...@fujitsu.com > wrote: > > > > On Thursday, September 30, 2021 12:15 PM Amit Kapila > > > > > > > > These all views are related to untransmitted to the collector but what > > > we really need is a vi

Re: Added schema level support for publication.

On Thu, Oct 21, 2021 at 3:25 AM vignesh C wrote: > > Attached v44 patch as the fixes for the same. > Regarding the documentation, I think some minor updates are needed in: doc/src/sgml/logical-replication.sgml. For example, currently it says: Publications may currently only contain tables. Ob

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

On Wed, 2021-10-20 at 16:36 -0400, Stephen Frost wrote: > > I think that's basically giving up the important part of this idea, > > which is to allow meaningful administration without superuser > > privileges. "highly-privileged roles only" sounds like in practice > > it > > would amount to the sup

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

Greetings, On Wed, Oct 20, 2021 at 16:23 Robert Haas wrote: > On Wed, Oct 20, 2021 at 1:20 PM Jeff Davis wrote: > > A downside is that with my suggestion, event triggers would still be > > for the highly-privileged roles only. Allowing unprivileged users to > > create event triggers that have l

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

On Wed, Oct 20, 2021 at 1:20 PM Jeff Davis wrote: > A downside is that with my suggestion, event triggers would still be > for the highly-privileged roles only. Allowing unprivileged users to > create event triggers that have limited scope might allow some really > interesting use cases. There mig

Re: Non-superuser event trigger owners

Over in [1], you wrote: > On Oct 20, 2021, at 11:27 AM, Jeff Davis wrote: > > On Wed, 2021-10-20 at 10:32 -0700, Mark Dilger wrote: >> I'd like to have a much clearer understanding of Noah's complaint >> first. There are multiple things to consider: (1) the role which >> owns the trigger, (2) t

Re: Interrupts vs signals

Hi, On 2021-10-21 07:55:54 +1300, Thomas Munro wrote: > I wonder if we really need signals to implement interrupts. Given > that they are non-preemptive/cooperative (work happens at the next > CFI()), why not just use shared memory flags and latches? That skips > a bunch of code, global variable

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

On Thu, 2021-05-27 at 23:06 -0700, Noah Misch wrote: > pg_logical_replication would not be safe to delegate that way: > https://postgr.es/m/flat/CACqFVBbx6PDq%2B%3DvHM0n78kHzn8tvOM-kGO_2q_q0zNAMT%2BTzdA%40mail.gmail.com What do you mean "that way"? Do you mean it's not safe to delegate subscripti

Re: Split xlog.c

On Thu, Sep 16, 2021 at 4:24 AM Heikki Linnakangas wrote: > Here is another rebase. Like probably everyone else who has an opinion on the topic, I like the idea of splitting xlog.c. I don't have a fully formed opinion on the changes yet, but it seems to be a surprisingly equal split, which seems

Re: Extending amcheck to check toast size and compression

> On Oct 20, 2021, at 11:42 AM, Greg Stark wrote: > > > > On Wed., Oct. 20, 2021, 12:41 Mark Dilger, > wrote: > > I used a switch statement to trigger a compiler warning in such an event. > > Catching better compiler diagnostics is an excellent reason to choose this > structure. I guess

Re: [RFC] speed up count(*)

On Wed, Oct 20, 2021 at 2:41 PM Tomas Vondra wrote: > BTW you mentioned using BRIN indexes for min/max - I've been thinking > about using BRIN indexes for ordering/sorting, which seems related. And > I think it's actually doable, so I wonder why you concluded using BRIN > indexes for min/max is n

Interrupts vs signals

Hi, I wonder if we really need signals to implement interrupts. Given that they are non-preemptive/cooperative (work happens at the next CFI()), why not just use shared memory flags and latches? That skips a bunch of code, global variables and scary warnings about programming in signal handlers.

Re: Extending amcheck to check toast size and compression

On Wed., Oct. 20, 2021, 12:41 Mark Dilger, wrote: > > I used a switch statement to trigger a compiler warning in such an event. > Catching better compiler diagnostics is an excellent reason to choose this structure. I guess all I could ask is that the comment saying no default branch say this is

Re: [RFC] speed up count(*)

On 10/20/21 20:33, John Naylor wrote: On Wed, Oct 20, 2021 at 2:23 PM Tomas Vondra mailto:tomas.von...@enterprisedb.com>> wrote: > > Couldn't we simply inspect the visibility map, use the index data only > for fully visible/summarized ranges, and inspect the heap for the > remaining pa

Non-superuser subscription owners

These patches have been split off the now deprecated monolithic "Delegating superuser tasks to new security roles" thread at [1]. The purpose of these patches is to allow non-superuser subscription owners without risk of them overwriting tables they lack privilege to write directly. This both a

CREATEROLE and role ownership hierarchies

These patches have been split off the now deprecated monolithic "Delegating superuser tasks to new security roles" thread at [1]. The purpose of these patches is to fix the CREATEROLE escalation attack vector misfeature. (Not everyone will see CREATEROLE that way, but the perceived value of th

Non-superuser event trigger owners

These patches have been split off the now deprecated monolithic "Delegating superuser tasks to new security roles" thread at [1]. The purpose of these patches is to allow ordinary users to create and own event triggers without introducing escalation attack vectors: v1-0001-Allow-event-trigger

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

I have now received multiple requests to split this patchset into multiple parts, including some off-list. I'll be posting four new patch sets on four new topics: New privileged roles which can SET and ALTER SYSTEM SET (v8-0002 through v8-0013) Non-superuser event trigger owners (v8-0014 and

Re: [RFC] speed up count(*)

On Wed, Oct 20, 2021 at 2:23 PM Tomas Vondra wrote: > > Couldn't we simply inspect the visibility map, use the index data only > for fully visible/summarized ranges, and inspect the heap for the > remaining pages? That'd still be a huge improvement for tables with most > only a few pages modified

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

On Wed, 2021-10-20 at 10:32 -0700, Mark Dilger wrote: > I'd like to have a much clearer understanding of Noah's complaint > first. There are multiple things to consider: (1) the role which > owns the trigger, (2) the role which is performing an action which > would cause the trigger to fire, (3) t

Re: [RFC] speed up count(*)

On 10/20/21 19:57, Tom Lane wrote: John Naylor writes: Perennially our users have complaints about slow count(*) when coming from some other systems. Index-only scans help, but I think we can do better. I recently wondered if a BRIN index could be used to answer min/max aggregate queries over t

Re: [RFC] speed up count(*)

Hi, On October 20, 2021 10:57:50 AM PDT, Tom Lane wrote: >John Naylor writes: >> Perennially our users have complaints about slow count(*) when coming from >> some other systems. Index-only scans help, but I think we can do better. I >> recently wondered if a BRIN index could be used to answer

Re: [RFC] speed up count(*)

John Naylor writes: > Perennially our users have complaints about slow count(*) when coming from > some other systems. Index-only scans help, but I think we can do better. I > recently wondered if a BRIN index could be used to answer min/max aggregate > queries over the whole table, and it turns o

[RFC] speed up count(*)

Hi, Perennially our users have complaints about slow count(*) when coming from some other systems. Index-only scans help, but I think we can do better. I recently wondered if a BRIN index could be used to answer min/max aggregate queries over the whole table, and it turns out it doesn't. However,

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

> On Oct 20, 2021, at 10:20 AM, Jeff Davis wrote: > > I'm trying to suggest an approach that is flexible enough (not limited > to superusers), but also addresses Noah's complaint that ordinary role > membership should not implicitly control event trigger firing. > > The most direct way to add

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

On Tue, 2021-10-19 at 18:52 -0400, Stephen Frost wrote: > > The implementation in the patch set does this, but with finer > > grained precision, because the universe of roles is divided into > > more than just superuser vs. non-superuser. > > This last point is particularly important. Non-super us

Re: [PATCH] Prefer getenv("HOME") to find the UNIX home directory

On 10/20/21 04:55, Daniel Gustafsson wrote: Is the proposed change portable across all linux/unix systems we support? Reading aobut indicates that it's likely to be, but neither NetBSD nor FreeBSD have the upthread referenced wording in their manpages. Since the proposed change falls back to th

Re: Extending amcheck to check toast size and compression

> On Oct 19, 2021, at 1:58 PM, Greg Stark wrote: > > Right so here's a review. > > I think the patch is committable as is. It's an improvement and it > does the job as promised. I do have some comments but I don't think > they're serious issues and would actually be pretty happy committing >

Re: Some questions about schema privileges

On Wed, Oct 20, 2021 at 8:59 AM Anna Akenteva wrote: > Hi all, > > I have been wondering about some things related to schema privileges: > > 1) Why do visibility rules apply to the \d command, but not to system > tables? What is the purpose of hiding stuff from \d output while users > can get the

Re: pgsql: Document XLOG_INCLUDE_XID a little better

On 2021-Oct-20, Dilip Kumar wrote: > On Wed, Oct 20, 2021 at 7:09 PM Alvaro Herrera > wrote: > > In IsTopTransactionIdLogPending(), I suggest to reorder the tests so > > that the faster ones are first -- or at least, the last one should be at > > the top, so in some cases we can return without

add retry mechanism for achieving recovery target before emitting FATA error "recovery ended before configured recovery target was reached"

Hi, The FATAL error "recovery ended before configured recovery target was reached" introduced by commit at [1] in PG 14 is causing the standby to go down after having spent a good amount of time in recovery. There can be cases where the arrival of required WAL (for reaching recovery target) from

Re: [RFC] building postgres with meson

Hi, On 2021-10-19 19:41:56 -0700, Andres Freund wrote: > On 2021-10-19 18:49:43 -0700, Andres Freund wrote: > > I wonder when it'll be faster to run 32bit ppc via qemu than natively :) > > Freebsd didn't seem to want to boot, but surprisingly a debian buster image > started at least the installer

Some questions about schema privileges

Hi all, I have been wondering about some things related to schema privileges: 1) Why do visibility rules apply to the \d command, but not to system tables? What is the purpose of hiding stuff from \d output while users can get the same info another way? 2) What is the reasoning behind separating

Re: lastOverflowedXid does not handle transaction ID wraparound

On Wed, Oct 20, 2021 at 4:00 AM Andrey Borodin wrote: > > > > 17 окт. 2021 г., в 21:55, Dmitry Dolgov <9erthali...@gmail.com> > написал(а): > > I wonder what would be side > > effects of clearing it when the snapshot is not suboverfloved anymore? > > I think we should just invalidate lastOverflow

Re: pgsql: Document XLOG_INCLUDE_XID a little better

On Wed, Oct 20, 2021 at 7:09 PM Alvaro Herrera wrote: > > API-wise, this seems a good improvement and it brings a lot of clarity > to what is really going on. Thanks for working on it. > > Some minor comments: Thanks for the review, most of the comments look fine, and will work on those, but I t

Re: pg14 psql broke \d datname.nspname.relname

> On Oct 13, 2021, at 1:43 PM, Mark Dilger wrote: > > The issue of name parsing impacts pg_dump and pg_dumpall, also. Consider > what happens with: > > pg_dump -t production.critical.secrets > secrets.dump > dropdb production > > In v13, if your default database is "testing", and database "t

Re: cursor use vs pg_stat_statements

On 10/20/21 9:02 AM, Laurenz Albe wrote: > On Tue, 2021-10-19 at 15:24 -0400, Andrew Dunstan wrote: >> The problem I'm writing about (h/t Simon Riggs for finding it) is >> illustrated by the following snippet of java: >> >>   public static void runtest(Connection conn) throws Exception { >>   

Re: Data is copied twice when specifying both child and parent table in publication

On Wed, Oct 20, 2021 at 9:19 PM Amit Kapila wrote: > > I don't see why data need to be replicated again even in that case. > Can you see any such duplicate data replicated for non-partitioned > tables? > If my example is slightly modified to use the same-named tables on the subscriber side, but w

Re: ThisTimeLineID can be used uninitialized

On 2021-Oct-20, Robert Haas wrote: > On Tue, Oct 19, 2021 at 7:30 PM Alvaro Herrera > wrote: > > Hah. Yeah, when you can do things like that and the tests don't break, > > that indicates a problem in the tests. > > I *think* the problem is actually in the code, not the tests. In other > words,

Re: pgsql: Document XLOG_INCLUDE_XID a little better

API-wise, this seems a good improvement and it brings a lot of clarity to what is really going on. Thanks for working on it. Some minor comments: Please do not revert the comment change in xlogrecord.h. It is not wrong. The exceptions mentioned are values 252-255, so "a few" is better than "a

Re: ThisTimeLineID can be used uninitialized

On Tue, Oct 19, 2021 at 7:30 PM Alvaro Herrera wrote: > Hah. Yeah, when you can do things like that and the tests don't break, > that indicates a problem in the tests. I *think* the problem is actually in the code, not the tests. In other words, from what I can tell, we copy the bogus timeline v

Re: cursor use vs pg_stat_statements

On Tue, 2021-10-19 at 15:24 -0400, Andrew Dunstan wrote: > > The problem I'm writing about (h/t Simon Riggs for finding it) is > illustrated by the following snippet of java: > >   public static void runtest(Connection conn) throws Exception { >     Statement stmt = conn.createStatement()

Re: pg_receivewal starting position

Le mercredi 20 octobre 2021 11:40:18 CEST, vous avez écrit : > > +# Setup the slot, and connect to it a first time > > +$primary->run_log( > > + [ 'pg_receivewal', '--slot', $slot_name, '--create-slot' ], > > + 'creating a replication slot'); > > +$primary->psql('postgres', > > + 'INSERT INTO

Re: refactoring basebackup.c

Hi Robert, I mean #define CHUNK_SIZE is still in the patch. > Oops, removed now. > > > With just that change, you can set > > > next_buf_len = LZ4F_HEADER_SIZE_MAX + mysink->output_buffer_bound -- > > > but that's also more than you need. You can instead do next_buf_len = > > > Min(LZ4F_HEADER_

Re: Postgres perl module namespace

On 10/19/21 11:22 PM, Michael Paquier wrote: > On Tue, Oct 19, 2021 at 10:16:06PM +0200, Erik Rijkers wrote: >>> [0001-move-perl-test-modules-to-PostgreSQL-Test-namespace.patch ] >>> [0002-move-PostgreSQL-Test-PostgresVersion-up-in-the-names.patch] > It seems to me that the hardest part is sorted

Re: XTS cipher mode for cluster file encryption

Greetings, * Sasasu (i...@sasa.su) wrote: > But If PG has a clear block-based IO API, TDE is much easier to understand. PG does have a block-based IO API, it's just not exposed as hooks. In particular, take a look at md.c, though perhaps you'd be more interested in the higher level bufmgr.c rout

Re: [PATCH] Fix memory corruption in pg_shdepend.c

On 2021-Oct-20, Michael Paquier wrote: > On Wed, Oct 20, 2021 at 01:01:31PM +0300, Aleksander Alekseev wrote: > > I checked the rest of the PostgreSQL code and apparently, it should > > have been tts_values[Anum_pg_shdepend_FOO - 1]. > > > > The patch is attached. The problem was first reported o

Re: [PATCH] Prefer getenv("HOME") to find the UNIX home directory

> On 20 Oct 2021, at 07:40, Kyotaro Horiguchi wrote: > > At Tue, 19 Oct 2021 02:44:03 -0700, Anders Kaseorg wrote in >> On 10/19/21 01:34, Kyotaro Horiguchi wrote: >>> I tend to agree to this, but seeing ssh ignoring $HOME, I'm not sure >>> it's safe that we follow the variable at least when ac

Re: lastOverflowedXid does not handle transaction ID wraparound

> On Wed, Oct 20, 2021 at 04:00:35PM +0500, Andrey Borodin wrote: > > 17 окт. 2021 г., в 21:55, Dmitry Dolgov <9erthali...@gmail.com> написал(а): > > I wonder what would be side > > effects of clearing it when the snapshot is not suboverfloved anymore? > > I think we should just invalidate lastOver

Re: [PATCH] Fix memory corruption in pg_shdepend.c

> On 20 Oct 2021, at 12:55, Michael Paquier wrote: > > On Wed, Oct 20, 2021 at 01:01:31PM +0300, Aleksander Alekseev wrote: >> I checked the rest of the PostgreSQL code and apparently, it should >> have been tts_values[Anum_pg_shdepend_FOO - 1]. >> >> The patch is attached. The problem was first

Re: pgsql: Document XLOG_INCLUDE_XID a little better

On Wed, Oct 20, 2021 at 4:17 PM Amit Kapila wrote: > > On Wed, Oct 20, 2021 at 10:25 AM Dilip Kumar wrote: > > > > I have one comment here, basically, you have changed the function name > > to "IsTopTransactionIdLogged", but it still behaves like > > IsTopTransactionIdLogPending. Now with the ne

Re: Question about building an exportable snapshop

On Wed, Oct 20, 2021 at 5:06 PM Amit Kapila wrote: > > On Tue, Oct 12, 2021 at 6:21 PM Dilip Kumar wrote: > > > > While working on the issue [1], I realize that if a subtransaction > > hasn't done any catalog change then we don't add this in the commit > > xid list even if we are building a full

Re: Question about building an exportable snapshop

On Tue, Oct 12, 2021 at 6:21 PM Dilip Kumar wrote: > > While working on the issue [1], I realize that if a subtransaction > hasn't done any catalog change then we don't add this in the commit > xid list even if we are building a full snapshot [2]. > I think this is true only if we have reached SN

Re: [Bug] Logical Replication failing if the DateStyle is different in Publisher & Subscriber

On Mon, 18 Oct 2021 at 17:27, Dilip Kumar wrote: > On Mon, Oct 18, 2021 at 1:41 PM Japin Li wrote: > >> I attached v3 patch that set IntervalStyle to 'postgres' when the >> server backend is walsender, and this problem has gone. > >> I test that set IntervalStyle to 'sql_standard' on publisher a

Re: lastOverflowedXid does not handle transaction ID wraparound

> 17 окт. 2021 г., в 21:55, Dmitry Dolgov <9erthali...@gmail.com> написал(а): > I wonder what would be side > effects of clearing it when the snapshot is not suboverfloved anymore? I think we should just invalidate lastOverflowedXid on every XLOG_RUNNING_XACTS if subxid_overflow == false. I ca

Re: [PATCH] Fix memory corruption in pg_shdepend.c

On Wed, Oct 20, 2021 at 01:01:31PM +0300, Aleksander Alekseev wrote: > I checked the rest of the PostgreSQL code and apparently, it should > have been tts_values[Anum_pg_shdepend_FOO - 1]. > > The patch is attached. The problem was first reported offlist by Sven > Klemm. Investigated and fixed by

Re: pgsql: Document XLOG_INCLUDE_XID a little better

On Wed, Oct 20, 2021 at 10:25 AM Dilip Kumar wrote: > > On Mon, Oct 18, 2021 at 10:48 AM Amit Kapila wrote: > > > > > Today, I have looked at this patch again and slightly changed a > > comment, one of the function name and variable name. Do, let me know > > if you or others have any suggestions

Re: Data is copied twice when specifying both child and parent table in publication

On Wed, Oct 20, 2021 at 3:03 PM Greg Nancarrow wrote: > > On Wed, Oct 20, 2021 at 7:59 PM Amit Kapila wrote: > > > > > > Actually, at least with the scenario I gave steps for, after looking > > > > at it again and debugging, I think that the behavior is understandable > > > > and not a bug. > > >

Re: LogicalChanges* and LogicalSubxact* wait events are never reported

On 2021/10/20 18:17, Amit Kapila wrote: > On Wed, Oct 20, 2021 at 10:50 AM Michael Paquier wrote: >> >> On Wed, Oct 20, 2021 at 02:12:20PM +0900, Masahiro Ikeda wrote: >>> If my understanding is right, it's better to remove them since they make >>> users confused. Please see the attached patch.

[PATCH] Fix memory corruption in pg_shdepend.c

Hi hackers, One of our test runs under the memory sanitizer cathed [1] the following stacktrace: ``` heaptuple.c:1044:13: runtime error: load of value 111, which is not a valid value for type '_Bool' #0 0x55fbb5e0857b in heap_form_tuple /home/runner/pgbuild/src/backend/access/common/heaptuple

Re: pg_receivewal starting position

Le mercredi 20 octobre 2021, 07:13:15 CEST Michael Paquier a écrit : > On Tue, Oct 19, 2021 at 05:32:55PM +0200, Ronan Dunklau wrote: > > Following recommendations, I stripped most of the features from the patch. > > For now we support only physical replication slots, and only provide the > > two f

Re: Data is copied twice when specifying both child and parent table in publication

On Wed, Oct 20, 2021 at 7:59 PM Amit Kapila wrote: > > > > Actually, at least with the scenario I gave steps for, after looking > > > at it again and debugging, I think that the behavior is understandable > > > and not a bug. > > > The reason is that the INSERTed data is first published though the

Re: LogicalChanges* and LogicalSubxact* wait events are never reported

On Wed, Oct 20, 2021 at 10:50 AM Michael Paquier wrote: > > On Wed, Oct 20, 2021 at 02:12:20PM +0900, Masahiro Ikeda wrote: > > If my understanding is right, it's better to remove them since they make > > users confused. Please see the attached patch. I confirmed that to make > > check-world passe

Re: Data is copied twice when specifying both child and parent table in publication

On Wed, Oct 20, 2021 at 7:02 PM Dilip Kumar wrote: > > > Actually, at least with the scenario I gave steps for, after looking > > at it again and debugging, I think that the behavior is understandable > > and not a bug. > > The reason is that the INSERTed data is first published though the > > par

Re: Data is copied twice when specifying both child and parent table in publication

On Wed, Oct 20, 2021 at 1:32 PM Dilip Kumar wrote: > > On Wed, Oct 20, 2021 at 12:44 PM Greg Nancarrow wrote: > > > > On Mon, Oct 18, 2021 at 5:00 PM Amit Kapila wrote: > > > > > > > I have not debugged it yet to find out why, but with the patch > > > > applied, the original double-publish probl

Re: Data is copied twice when specifying both child and parent table in publication

On Wed, Oct 20, 2021 at 12:44 PM Greg Nancarrow wrote: > > On Mon, Oct 18, 2021 at 5:00 PM Amit Kapila wrote: > > > > > I have not debugged it yet to find out why, but with the patch > > > applied, the original double-publish problem that I reported > > > (converted to just use TABLE rather than

Re: Data is copied twice when specifying both child and parent table in publication

On Mon, Oct 18, 2021 at 5:00 PM Amit Kapila wrote: > > > I have not debugged it yet to find out why, but with the patch > > applied, the original double-publish problem that I reported > > (converted to just use TABLE rather than ALL TABLES IN SCHEMA) still > > occurs. > > > > Yeah, I think this i

Re: XTS cipher mode for cluster file encryption

On 2021/10/20 02:54, Stephen Frost wrote: > I agree with Robert- using hooks for this really isn't realistic. OK, I agree use hooks is too invasive. Just a whim, never mind. But If PG has a clear block-based IO API, TDE is much easier to understand. security people may lack database knowledge b

Re: Added schema level support for publication.

On Tue, Oct 19, 2021 at 9:42 PM vignesh C wrote: > Thanks for the modified patch. I have a few more comments and suggestions: As the thread [1] is still not concluded, I suggest we fix the duplicate data case only when schemas are involved by slightly tweaking the code as per attached. This is j