Dear Kato-san,
Thank you for giving comments! And sorry for late reply.
I rebased my patches.
> Even for local-only transaction, I thought it useless to execute
> CallCheckingRemoteServersCallbacks() and enable_timeout_after(). Can I
> make it so that it determines outside whether it contains
On Wed, Dec 15, 2021 at 10:20 AM Greg Nancarrow wrote:
>
> On Mon, Dec 13, 2021 at 8:49 PM Peter Smith wrote:
> >
> > PSA the v46* patch set.
> >
>
> 0001
>
> (1)
>
> "If a subscriber is a pre-15 version, the initial table
> synchronization won't use row filters even if they are defined in the
>
On Wed, Dec 15, 2021 at 6:33 AM Peter Geoghegan wrote:
>
> How did you test this? I ask because it would be nice if there was a
> convenient way to try this out, as somebody with a general interest.
> Even just a minimal test module, that you used for development work.
>
I have tested this
On Tue, Dec 14, 2021 at 11:28 AM Amit Kapila wrote:
>
> On Mon, Dec 13, 2021 at 5:48 PM osumi.takami...@fujitsu.com
> wrote:
> >
> > On Monday, December 13, 2021 6:19 PM Amit Kapila
> > wrote:
> > > On Tue, Dec 7, 2021 at 3:12 PM osumi.takami...@fujitsu.com
> > > wrote:
> > >
> > > Few
On Wed, Dec 15, 2021 at 1:49 PM Masahiko Sawada wrote:
>
> We don't expect such usage but yes, it could happen and seems not
> good. I thought we can acquire Share lock on pg_subscription during
> the skip but not sure it's a good idea. It would be better if we can
> find a way to allow users to
On Mon, Dec 13, 2021 at 8:49 PM Peter Smith wrote:
>
> PSA the v46* patch set.
>
0001
(1)
"If a subscriber is a pre-15 version, the initial table
synchronization won't use row filters even if they are defined in the
publisher."
Won't this lead to data inconsistencies or errors that otherwise
On Wed, Dec 15, 2021 at 9:46 AM Amit Kapila wrote:
>
> On Tue, Dec 14, 2021 at 11:40 AM Dilip Kumar wrote:
>
> That's right and I agree there could be some use case for it and even
> specifying the operation but I think we can always extend the existing
> feature for it if the need arises. Note
On Tue, Dec 14, 2021 at 11:40 AM Dilip Kumar wrote:
>
> On Fri, Dec 3, 2021 at 12:12 PM Masahiko Sawada wrote:
> >
> > Skipping a whole transaction by specifying xid would be a good start.
> > Ideally, we'd like to automatically skip only operations within the
> > transaction that fail but it
At Tue, 14 Dec 2021 19:31:21 +0530, Ashutosh Bapat
wrote in
> On Tue, Dec 14, 2021 at 9:35 AM Kyotaro Horiguchi
> wrote:
> > > [17605] LOG: terminating process 17614 to release replication slot "s1"
> > + [17605] DETAIL: The slot's restart_lsn 0/2CA0 exceeds
> > max_slot_wal_keep_size.
On Wed, Dec 15, 2021 at 8:19 AM Masahiko Sawada wrote:
>
> On Tue, Dec 14, 2021 at 2:35 PM Greg Nancarrow wrote:
> >
> > On Tue, Dec 14, 2021 at 3:23 PM vignesh C wrote:
> > >
> > > While the worker is skipping one of the skip transactions specified by
> > > the user and immediately if the user
On Wed, Dec 15, 2021 at 3:52 PM Michael Paquier wrote:
> On Wed, Dec 15, 2021 at 10:45:28AM +1300, Thomas Munro wrote:
> > Ah, right. I hope we can make the leap to 0x0A00 (Win10) soon and
> > just stop thinking about these old ghosts, as mentioned by various
> > people in various threads.
>
>
On Tue, Dec 14, 2021 at 4:54 PM Amit Kapila wrote:
>
> > Actually, I was trying to understand the use case for skipping while
> > streaming. Actually, during streaming we are not doing any database
> > operation that means this will not generate any error.
> >
>
> Say, there is an error the
On Wed, Dec 15, 2021 at 6:47 AM Peter Smith wrote:
>
> On Tue, Dec 14, 2021 at 10:12 PM Amit Kapila wrote:
> >
> > On Tue, Dec 14, 2021 at 10:50 AM Amit Kapila
> > wrote:
> > >
> > > On Tue, Dec 14, 2021 at 4:44 AM Peter Smith wrote:
> > >
> > > Few other comments:
> > > ===
>
On Tue, Dec 14, 2021 at 07:10:49PM +0530, Ashutosh Bapat wrote:
> This code in RelationGetIndexList() is not according to that comment.
>
>if (replident == REPLICA_IDENTITY_DEFAULT && OidIsValid(pkeyIndex))
> relation->rd_replidindex = pkeyIndex;
> else if (replident ==
At Tue, 14 Dec 2021 19:04:09 +0530, Bharath Rupireddy
wrote in
> On Fri, Dec 3, 2021 at 7:39 PM Bharath Rupireddy
> wrote:
> >
> > On Wed, Dec 1, 2021 at 9:50 PM Alvaro Herrera
> > wrote:
> > > I think the PIDs are log-worthy for sure, but it's not clear to me that
> > > it is desirable to
On Wed, Dec 15, 2021 at 8:23 AM Peter Geoghegan wrote:
>
> On Mon, Dec 13, 2021 at 7:03 PM Amit Kapila wrote:
> > Thanks, I can take care of this before committing. The v9-0001* looks
> > good to me as well, so, I am planning to commit that tomorrow unless I
> > see more comments or any
On Mon, Dec 13, 2021 at 7:03 PM Amit Kapila wrote:
> Thanks, I can take care of this before committing. The v9-0001* looks
> good to me as well, so, I am planning to commit that tomorrow unless I
> see more comments or any objection to that.
I would like to thank both Masahiko and yourself for
On Wed, Dec 15, 2021 at 10:45:28AM +1300, Thomas Munro wrote:
> Ah, right. I hope we can make the leap to 0x0A00 (Win10) soon and
> just stop thinking about these old ghosts, as mentioned by various
> people in various threads.
Seeing your message here.. My apologies for the short digression.
On Tue, Dec 14, 2021 at 2:35 PM Greg Nancarrow wrote:
>
> On Tue, Dec 14, 2021 at 3:23 PM vignesh C wrote:
> >
> > While the worker is skipping one of the skip transactions specified by
> > the user and immediately if the user specifies another skip
> > transaction while the skipping of the
Chapman Flack writes:
> On 12/14/21 20:02, Tom Lane wrote:
>> The API contract for lookup_rowtype_tupdesc specifies that you must "call
>> ReleaseTupleDesc or DecrTupleDescRefCount when done using the tupdesc".
>> It's safe to assume that the tupdesc will stick around as long as you
>> haven't
On 12/14/21 20:02, Tom Lane wrote:
> The API contract for lookup_rowtype_tupdesc specifies that you must "call
> ReleaseTupleDesc or DecrTupleDescRefCount when done using the tupdesc".
> It's safe to assume that the tupdesc will stick around as long as you
> haven't done that.
I think what threw
On Mon, Dec 13, 2021 at 10:14:49PM -0800, Andres Freund wrote:
> Tom's point was that the buildfarm scripts do
> if ($self->{bfconf}->{using_msvc})
> @checklog = run_log("perl vcregress.pl upgradecheck");
> else
> "cd
On Tue, Dec 14, 2021 at 10:12 PM Amit Kapila wrote:
>
> On Tue, Dec 14, 2021 at 10:50 AM Amit Kapila wrote:
> >
> > On Tue, Dec 14, 2021 at 4:44 AM Peter Smith wrote:
> >
> > Few other comments:
> > ===
>
> Few more comments:
> ==
> v46-0001/0002
>
Chapman Flack writes:
> But if I have gone straight to the typcache to ask for a RECORD tupdesc,
> and the one it gives me has -1 refcount, is it reasonable to assume
> I can retain a reference to that without the defensive copy?
The API contract for lookup_rowtype_tupdesc specifies that you
On Tue, Dec 14, 2021 at 3:00 PM Robert Haas wrote:
> I got interested in this problem again because of the
> idea discussed in
> https://www.postgresql.org/message-id/CA%2BTgmoZgapzekbTqdBrcH8O8Yifi10_nB7uWLB8ajAhGL21M6A%40mail.gmail.com
> of having a "dead TID" relation fork in which to
On Tue, Dec 14, 2021 at 8:24 PM Amit Kapila wrote:
>
> On Tue, Dec 14, 2021 at 3:41 PM Dilip Kumar wrote:
> >
> > On Tue, Dec 14, 2021 at 2:36 PM Amit Kapila wrote:
> > >
> > > > >
> > > > > I agree with this theory. Can we reflect this in comments so that in
> > > > > the future we know why we
Thanks a lot Michael for the explanation.
On 2021-12-13 4:05 a.m., Michael Paquier wrote:
On Fri, Dec 10, 2021 at 01:44:40PM -0800, David Zhang wrote:
Inside the test script `src/test/recovery/t/001_stream_rep.pl`, a comment at
line 30 says `my_backup` is "not mandatory",
30 # Take backup
On 12/14/21 18:03, Tom Lane wrote:
> Tupdescs for RECORD types are a different story: ... Refcounting
> isn't terribly necessary in that case; and at least for the shared
> tupdesc case, we don't do it, to avoid questions of modifying a
> piece of shared state.
Ok, that's kind of what I was
Chapman Flack writes:
> There are some things about the life cycle of the common TupleDesc
> that I'm not 100% sure about.
> 1. In general, if you get one from relcache or typcache, it is
>reference-counted, right?
Tupdescs for named composite types should be, since those are
potentially
Tomas Vondra writes:
[...]
>
> Thanks, looks interesting. A couple generic comments, based on a quick
> code review.
Thank you for the constructive review!
>
> 1) Can the extension be marked as trusted, just like fuzzystrmatch?
I have now moved the daitch_mokotoff function into the
Peter Eisentraut writes:
> OK, makes sense. Here is an alternative patch. It introduces two
> light-weight macros strtoi64() and strtou64() (compare e.g., strtoimax()
> in POSIX) in c.h and removes pg_strtouint64(). This moves the
> portability layer from numutils.c to c.h, so it's closer
On Mon, Dec 13, 2021 at 5:34 PM Mark Dilger
wrote:
>
>
>
> > On Dec 13, 2021, at 1:33 PM, Mark Dilger
> > wrote:
> >
> > but will repost in a few hours
>
> ... and here it is:
currently there is a failure in check-world (not sure if it's known):
diff -U3
On 28.11.21 07:52, Bharath Rupireddy wrote:
1) Instead of a new LIST_SLOT command, can't we use
READ_REPLICATION_SLOT (slight modifications needs to be done to make
it support logical replication slots and to get more information from
the subscriber).
I looked at that but didn't see an obvious
On 24.11.21 17:25, Dimitri Fontaine wrote:
Is there a case to be made about doing the same thing for physical
replication slots too?
It has been considered. At the moment, I'm not doing it, because it
would add more code and complexity and it's not that important. But it
could be added in
I wrote:
> Anyway, it seems like there's some consensus that 9.2 is a good
> stopping place for today. I'll push forward with
> (1) back-patching as necessary to make 9.2 and up build cleanly
> on the platforms I have handy;
> (2) ripping out pg_dump's support for pre-9.2 servers;
> (3) ripping
On 24.11.21 07:11, Masahiko Sawada wrote:
I haven’t looked at the patch deeply but regarding 007_sync_rep.pl,
the tests seem to fail since the tests rely on the order of the wal
sender array on the shared memory. Since a background worker for
synchronizing replication slots periodically connects
On 31.10.21 11:08, Peter Eisentraut wrote:
I want to reactivate $subject. I took Petr Jelinek's patch from [0],
rebased it, added a bit of testing. It basically works, but as
mentioned in [0], there are various issues to work out.
The idea is that the standby runs a background worker to
On Wed, Dec 15, 2021 at 9:14 AM Juan José Santamaría Flecha
wrote:
> What I meant to say is that to run the test, you need a database that has
> successfully run pg_import_system_collations. This would be also possible in
> Mingw for _WIN32_WINNT> = 0x0600, but the current value in
>
Hi,
I went through the v9 patch, and I have a couple comments / questions.
Apologies if some of this was already discussed earlier, it's hard to
cross-check in such a long thread. Most of the comments are in 0002 to
make it easier to locate, and it also makes proposed code changes
clearer I
On 12/14/21 20:35, Alvaro Herrera wrote:
On 2021-Dec-14, Tomas Vondra wrote:
Yeah. I think it's not clear if this should behave more like an index or a
view. When an indexed column gets dropped we simply drop the index. But if
you drop a column referenced by a view, we fail with an error. I
On 13.12.21 15:44, Tom Lane wrote:
Our current hard-coded uses of long long are all written on the
assumption that it's*at least* 64 bits, so we'd survive OK on
such a platform so long as we don't start confusing it with
*exactly* 64 bits.
OK, makes sense. Here is an alternative patch. It
Hi,
There are some things about the life cycle of the common TupleDesc
that I'm not 100% sure about.
1. In general, if you get one from relcache or typcache, it is
reference-counted, right?
2. The only exception I know of is if you ask the typcache for
a blessed one (RECORD+typmod), and
On Tue, Dec 14, 2021 at 10:47 AM Robert Haas wrote:
> Well I just don't understand why you insist on using the word
> "skipping." I think what we're talking about - or at least what we
> should be talking about - is whether relation_needs_vacanalyze() sets
> *wraparound = true right after the
On Mon, Dec 13, 2021 at 9:54 PM Thomas Munro wrote:
>
> I haven't tested yet but +1 for the feature. I guess the API didn't
> exist at the time collation support was added.
>
> Good to hear.
> This conversion makes sense, to keep the user experience the same
> across platforms. Nitpick on
On 12/14/21, 12:09 PM, "Bossart, Nathan" wrote:
> On 12/14/21, 9:00 AM, "Bruce Momjian" wrote:
>> Have we changed temporary file handling in any recent major releases,
>> meaning is this a current problem or one already improved in PG 14.
>
> I haven't noticed any recent improvements while
On 12/14/21, 9:00 AM, "Bruce Momjian" wrote:
> Have we changed temporary file handling in any recent major releases,
> meaning is this a current problem or one already improved in PG 14.
I haven't noticed any recent improvements while working in this area.
Nathan
On 2021-Dec-05, Brar Piening wrote:
> When working with the Frontend/Backend Protocol implementation in Npgsql
> and discussing things with the team, I often struggle with the fact that
> you can't set deep links to individual message formats in the somewhat
> lengthy html docs pages.
>
> The
On 2021-Dec-14, Tomas Vondra wrote:
> Yeah. I think it's not clear if this should behave more like an index or a
> view. When an indexed column gets dropped we simply drop the index. But if
> you drop a column referenced by a view, we fail with an error. I think we
> should handle this more like
On 12/14/21 17:43, Alvaro Herrera wrote:
On 2021-Dec-13, Alvaro Herrera wrote:
I think this means we need a new OBJECT_PUBLICATION_REL_COLUMN value in
the ObjectType (paralelling OBJECT_COLUMN), and no new ObjectClass
value. Looking now to confirm.
After working on this a little bit more, I
On Sun, Dec 5, 2021 at 11:15 AM Daniel Gustafsson wrote:
> > On 5 Dec 2021, at 16:51, Brar Piening wrote:
>
> > The attached patch adds id's to various elements in protocol.sgml to
> > make them more accesssible via the public html documentation interface.
>
> Off the cuff without having
On Tue, 2021-12-14 at 07:41 -0800, Mark Dilger wrote:
> I went a different direction with this. The need is to prevent non-
> superuser subscription owners from *circumventing* RLS. For this
> patch set, I'm just checking whether RLS should be enforced against
> the subscription owner, and if
On Tue, Dec 14, 2021 at 1:16 PM Peter Geoghegan wrote:
> I think that you'd agree that the arguments in favor of skipping are
> strongest ...
Well I just don't understand why you insist on using the word
"skipping." I think what we're talking about - or at least what we
should be talking about -
tushar writes:
> Please refer to this scenario where pg_upgrade operation is failing if
> the table is create in single-user mode.
Fixed in v14:
https://git.postgresql.org/gitweb/?p=postgresql.git=commitdiff=f7f70d5e2
regards, tom lane
On 12/14/21 2:35 AM, Robert Haas wrote:
I spent much of today reviewing 0001. Here's an updated version, so
far only lightly tested. Please check whether I've broken anything.
Thanks Robert, I tested from v96/12/13/v14 -> v15( with patch)
things are working fine i.e table /index relfilenode is
On Tue, Dec 14, 2021 at 2:35 AM Robert Haas wrote:
>
> On Mon, Dec 13, 2021 at 9:40 AM Shruthi Gowda wrote:
> > > I am reviewing another patch
> > > "v5-0001-Preserve-relfilenode-and-tablespace-OID-in-pg_upg" as well
> > > and will provide the comments soon if any...
>
> I spent much of today
On Tue, Dec 14, 2021 at 6:05 AM Robert Haas wrote:
> I think this is a reasonable line of thinking, but I think it's a
> little imprecise. In general, we could be vacuuming a relation to
> advance relfrozenxid, but we could also be vacuuming a relation to
> advance relminmxid, or we could be
Hi,
Please refer to this scenario where pg_upgrade operation is failing if
the table is create in single-user mode.
PG v13
--connect to PG v13 using single user mode ( ./postgres --single -D
/tmp/data13 postgres )
--create table ( backend> create table r(n int); )
--exit ( ctrl + D)
--
On Mon, Dec 13, 2021 at 11:05:46PM +, Bossart, Nathan wrote:
> On 12/13/21, 12:37 PM, "Robert Haas" wrote:
> > On Mon, Dec 13, 2021 at 1:21 PM Bossart, Nathan wrote:
> >> > But against all that, if these tasks are slowing down checkpoints and
> >> > that's avoidable, that seems pretty
On 2021-Dec-13, Alvaro Herrera wrote:
> I think this means we need a new OBJECT_PUBLICATION_REL_COLUMN value in
> the ObjectType (paralelling OBJECT_COLUMN), and no new ObjectClass
> value. Looking now to confirm.
After working on this a little bit more, I realized that this is a bad
idea
> On Dec 13, 2021, at 10:18 PM, Jeff Davis wrote:
>
>>This is implemented but I still need to update the documentation
>> before
>>posting.
>
> We also discussed how much of the insert path we want to include in the
> apply worker. The immediate need is for the patch to support RLS,
On Wed, Dec 8, 2021 at 1:40 PM John Naylor wrote:
>
> It's been a while, but here are a few more suggested
> removals/edits/additions to the TODO list. Any objections or new
> information, let me know:
>
> - Auto-fill the free space map by scanning the buffer cache or by
> checking pages written
On Tue, Dec 14, 2021 at 9:35 AM Kyotaro Horiguchi
wrote:
>
> Hello.
>
> As complained in pgsql-bugs [1], when a process is terminated due to
> max_slot_wal_keep_size, the related messages don't mention the root
> cause for *the termination*. Note that the third message does not
> show for
On Sun, Dec 12, 2021 at 8:47 PM Peter Geoghegan wrote:
> I am currently working on decoupling advancing relfrozenxid from tuple
> freezing [1]. That is, I'm teaching VACUUM to keep track of
> information that it uses to generate an "optimal value" for the
> table's final relfrozenxid: the most
On 2021-12-13 20:53, Andrew Dunstan wrote:
Any thoughts?
It's also failing on REL_14_STABLE, so I think it must be an
environmental change.
I did an pkg update && pkg upgrade and it messed up the SSL-libraries.
It had both libressl and openssl and when I upgraded it some how removed
On Tue, Dec 14, 2021 at 9:35 AM Kyotaro Horiguchi
wrote:
>
> Hello.
>
> As complained in pgsql-bugs [1], when a process is terminated due to
> max_slot_wal_keep_size, the related messages don't mention the root
> cause for *the termination*. Note that the third message does not
> show for
On Tue, Dec 14, 2021 at 6:08 PM wangw.f...@fujitsu.com
wrote:
>
> Hi hackers,
>
> When I doing development based by PG, I found the following comment have a
> little problem in file src/include/catalog/pg_class.h.
>
> /*
> * an explicitly chosen candidate key's columns are used as replica
On Fri, Dec 3, 2021 at 7:39 PM Bharath Rupireddy
wrote:
>
> On Wed, Dec 1, 2021 at 9:50 PM Alvaro Herrera wrote:
> >
> > On 2021-Dec-01, Bharath Rupireddy wrote:
> >
> > > The active_pid of ReplicationSlot structure, which tells whether a
> > > replication slot is active or inactive, isn't
On Tues, Dec 14, 2021 10:28 AM Amit Kapila wrote:
> On Mon, Dec 13, 2021 at 5:48 PM osumi.takami...@fujitsu.com
> wrote:
> >
> > On Monday, December 13, 2021 6:19 PM Amit Kapila
> wrote:
> > > On Tue, Dec 7, 2021 at 3:12 PM osumi.takami...@fujitsu.com
> > > wrote:
> > >
> > > Few questions and
Hi,
I have looked into the v2 patch and here are my comments:
+ PG_RETURN_INT32(local_beentry->subxact_overflowed);
+}
Should this be PG_RETURN_BOOL instead of PG_RETURN_INT32??
--
+{ oid => '6107', descr => 'statistics: cached subtransaction count of
backend',
+ proname =>
Hi hackers,
When I doing development based by PG, I found the following comment have a
little problem in file src/include/catalog/pg_class.h.
/*
* an explicitly chosen candidate key's columns are used as replica identity.
* Note this will still be set if the index has been dropped; in that
On Tue, Dec 14, 2021 at 3:41 PM Dilip Kumar wrote:
>
> On Tue, Dec 14, 2021 at 2:36 PM Amit Kapila wrote:
> >
> > > >
> > > > I agree with this theory. Can we reflect this in comments so that in
> > > > the future we know why we didn't pursue this direction?
> > >
> > > I might be missing
On Tue, Dec 14, 2021 at 10:50 AM Amit Kapila wrote:
>
> On Tue, Dec 14, 2021 at 4:44 AM Peter Smith wrote:
>
> Few other comments:
> ===
Few more comments:
==
v46-0001/0002
===
1. After rowfilter_walker() why do we need
EXPR_KIND_PUBLICATION_WHERE? I
On Tue, Dec 14, 2021 at 11:18 AM Thomas Munro wrote:
> On Tue, Dec 14, 2021 at 7:53 AM Andres Freund wrote:
> > On 2021-12-13 17:51:00 +1300, Thomas Munro wrote:
> > > I tried that. It seems OK, and gets rid of the PG_FINALLY(), which is
> > > nice. Latches still have higher priority, and
On Tue, Dec 14, 2021 at 2:36 PM Amit Kapila wrote:
>
> > >
> > > I agree with this theory. Can we reflect this in comments so that in
> > > the future we know why we didn't pursue this direction?
> >
> > I might be missing something here, but for streaming, transaction
> > users can decide
On Fri, Dec 10, 2021 at 11:14 AM Masahiko Sawada wrote:
>
> On Thu, Dec 9, 2021 at 6:16 PM Amit Kapila wrote:
> >
> > On Thu, Dec 9, 2021 at 2:24 PM Masahiko Sawada
> > wrote:
> > >
> > > On Thu, Dec 9, 2021 at 11:47 AM Amit Kapila
> > > wrote:
> > > >
> > > > I am thinking that we can start
> On 14 Dec 2021, at 05:11, Andres Freund wrote:
> On 2021-12-14 16:51:58 +1300, Thomas Munro wrote:
>> I'd better go and figure out how to fix cfbot when this lands...
>
> I assume it'd be:
> - stop adding the CI stuff
> - adjust links to CI tasks, appveyor wouldn't be used anymore
> - perhaps
On Tue, Dec 14, 2021 at 1:07 PM Dilip Kumar wrote:
>
> On Tue, Dec 14, 2021 at 8:20 AM Amit Kapila wrote:
> >
> > On Mon, Dec 13, 2021 at 6:55 PM Masahiko Sawada
> > wrote:
>
> > > In streaming cases, we don’t know when stream-commit or stream-abort
> > > comes and another conflict could occur
Hi
I did the following steps on PG.
1. Building a synchronous streaming replication environment.
2. Executing the following SQL statements on primary
(1) postgres=# CREATE EXTENSION pageinspect;
(2) postgres=# begin;
(3) postgres=# select txid_current();
(4) postgres=# create table
78 matches
Mail list logo
