On Mon, May 3, 2021 at 11:59 AM Dilip Kumar wrote:
>
> On Mon, May 3, 2021 at 10:42 AM Bharath Rupireddy
> wrote:
> >
> > Hi,
> >
> > In apply_handle_truncate, the following comment before ExecuteTruncateGuts
> > says that it defaults to RESTRICT even if the CASCADE option has been
> > specifie
sh,On Mon, May 3, 2021 at 12:37 PM Bharath Rupireddy
wrote:
>
> On Mon, May 3, 2021 at 11:59 AM Dilip Kumar wrote:
> >
> > On Mon, May 3, 2021 at 10:42 AM Bharath Rupireddy
> > wrote:
> > >
> > > Hi,
> > >
> > > In apply_handle_truncate, the following comment before
> > > ExecuteTruncateGuts s
On Mon, May 3, 2021 at 12:08 PM Bharath Rupireddy
wrote:
>
> On Sun, May 2, 2021 at 8:44 PM vignesh C wrote:
> >
> > On Sat, May 1, 2021 at 9:02 PM Bharath Rupireddy
> > wrote:
> > >
> > > On Sat, May 1, 2021 at 7:25 PM vignesh C wrote:
> > > > > > I'm not attaching above one line change as a p
On Mon, May 3, 2021 at 10:48 AM Dilip Kumar wrote:
>
> On Sun, May 2, 2021 at 10:04 PM vignesh C wrote:
> >
> > Thanks for the comments.
> > The Attached patch has the fixes for the same.
>
> I was reviewing the documentation part, I think in the below paragraph
> we should include validate_publi
Hi
I am testing a new subscripting interface for jsonb, and I found one issue.
DO $$
DECLARE v jsonb;
BEGIN
v['a'] = '"Ahoj"';
RAISE NOTICE '%', v['a'];
END;
$$;
NOTICE: "Ahoj"
DO
When I use this interface for reading, the jsonb type is returned. What is
the correct way for casting from jso
Hi
po 3. 5. 2021 v 11:15 odesílatel Pavel Stehule
napsal:
> Hi
>
> I am testing a new subscripting interface for jsonb, and I found one issue.
>
> DO $$
> DECLARE v jsonb;
> BEGIN
> v['a'] = '"Ahoj"';
> RAISE NOTICE '%', v['a'];
> END;
> $$;
> NOTICE: "Ahoj"
> DO
>
> When I use this interfa
On Mon, May 3, 2021 at 12:24 PM Pavel Stehule
wrote:
> Is it possible to do this with built functionality?
>
> I miss the cast function for json scalar string value to string.
>
#>>'{}'
.m
po 3. 5. 2021 v 11:26 odesílatel Marko Tiikkaja napsal:
> On Mon, May 3, 2021 at 12:24 PM Pavel Stehule
> wrote:
>
>> Is it possible to do this with built functionality?
>>
>> I miss the cast function for json scalar string value to string.
>>
>
> #>>'{}'
>
It is working. Thank you. But this sy
On 21.01.21 02:33, Tom Lane wrote:
I'd be inclined to spell it "connection to server at ... failed",
but that sort of wording is surely also possible.
"connection to server" rather than "connection to database" works for
me; in fact, I think I like it slightly better.
If I don't hear any oth
On Mon, May 3, 2021 at 2:27 PM Amit Kapila wrote:
>
> On Thu, Apr 29, 2021 at 10:37 AM Amit Kapila wrote:
> >
> > On Wed, Apr 28, 2021 at 7:43 PM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, Apr 28, 2021 at 3:25 PM Amit Kapila
> > > wrote:
> > > >
> > >
> > > > I am not sure if any of these
On Mon, May 3, 2021 at 2:29 PM Amit Kapila wrote:
>
> On Fri, Apr 30, 2021 at 1:47 PM Amit Kapila wrote:
> >
> > LGTM. I have slightly edited the comments in the attached. I'll push
> > this early next week unless there are more comments.
> >
>
> Pushed.
Thank you!
Regards,
--
Masahiko Sawada
On Sun, May 2, 2021 at 1:23 AM Zhihong Yu wrote:
>
>
>
> On Fri, Apr 30, 2021 at 9:09 PM Masahiko Sawada wrote:
>>
>> On Wed, Mar 17, 2021 at 6:03 PM Zhihong Yu wrote:
>> >
>> > Hi,
>> > For v35-0007-Prepare-foreign-transactions-at-commit-time.patch :
>>
>> Thank you for reviewing the patch!
>>
On Mon, May 3, 2021 at 1:02 PM Dilip Kumar wrote:
>
> I think you are comparing the user-exposed behavior with the internal
> code comments. The meaning of the comments is that it should not
> truncate any table on subscriber using cascade, because there might be
> some subscriber-specific relati
We have already pushed the configurable lz4 toast compression code[1].
In the custom compression thread, we were already having the patch to
support the compression method options[2]. But the design for the
base patches was heavily modified before commit but I never rebased
this patch based on the
On Mon, May 3, 2021 at 12:08 PM Bharath Rupireddy
wrote:
>
> On Sun, May 2, 2021 at 8:44 PM vignesh C wrote:
> >
> > On Sat, May 1, 2021 at 9:02 PM Bharath Rupireddy
> > wrote:
> > >
> > > On Sat, May 1, 2021 at 7:25 PM vignesh C wrote:
> > > > > > I'm not attaching above one line change as a p
Hi Sven,
> The attached patch allows CustomScan nodes to signal whether they
> support projection.
I noticed that you didn't change custom-scan.sgml accordingly. The
updated patch is attached. Otherwise, it seems to be fine in terms of
compiling, passing tests etc.
> I named the flag CUSTOMPATH_
On Mon, May 3, 2021 at 5:48 PM Masahiko Sawada wrote:
>
> On Mon, May 3, 2021 at 2:27 PM Amit Kapila wrote:
> >
> > On Thu, Apr 29, 2021 at 10:37 AM Amit Kapila
> > wrote:
> > >
> > > On Wed, Apr 28, 2021 at 7:43 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Wed, Apr 28, 2021 at 3:25 PM
On Mon, May 3, 2021 at 5:25 AM Masahiko Sawada
wrote:
> On Sun, May 2, 2021 at 1:23 AM Zhihong Yu wrote:
> >
> >
> >
> > On Fri, Apr 30, 2021 at 9:09 PM Masahiko Sawada
> wrote:
> >>
> >> On Wed, Mar 17, 2021 at 6:03 PM Zhihong Yu wrote:
> >> >
> >> > Hi,
> >> > For v35-0007-Prepare-foreign-tr
On Mon, May 3, 2021 at 6:08 AM Peter Eisentraut
wrote:
> I find these new error messages to be more distracting than before in
> some cases. For example:
>
> PG13:
>
> clusterdb: error: could not connect to database typo: FATAL: database
> "typo" does not exist
>
> PG14:
>
> clusterdb: error: co
On Sat, Apr 3, 2021 at 10:07 PM Peter Geoghegan wrote:
> I would like to deal with this work within the scope of the project
> we're discussing over on the "New IndexAM API controlling index vacuum
> strategies" thread. The latest revision of that patch series includes
> a modified version of your
On Mon, May 3, 2021 at 1:46 PM Dilip Kumar wrote:
>
> On Mon, May 3, 2021 at 10:48 AM Dilip Kumar wrote:
> >
> > On Sun, May 2, 2021 at 10:04 PM vignesh C wrote:
> > >
> > > Thanks for the comments.
> > > The Attached patch has the fixes for the same.
> >
> > I was reviewing the documentation pa
On Mon, May 3, 2021 at 11:11 AM Bharath Rupireddy
wrote:
>
> On Sun, May 2, 2021 at 10:04 PM vignesh C wrote:
> > > 5) Instead of adding a new file 021_validate_publications.pl for
> > > tests, spawning a new test database which would make the overall
> > > regression slower, can't we add with th
On Mon, 3 May 2021 at 16:26, John Naylor wrote:
>
> On Sat, Apr 3, 2021 at 10:07 PM Peter Geoghegan wrote:
> > I would like to deal with this work within the scope of the project
> > we're discussing over on the "New IndexAM API controlling index vacuum
> > strategies" thread. The latest revision
On Fri, Apr 30, 2021 at 5:22 PM Peter Geoghegan wrote:
> I strongly suspect that index-organized tables (or indirect indexes,
> or anything else that assumes that TID-like identifiers map directly
> to logical rows as opposed to physical versions) are going to break
> too many assumptions to ever
Robert Haas writes:
> On Mon, May 3, 2021 at 6:08 AM Peter Eisentraut
> wrote:
>> Throwing the socket address in there seems a bit distracting and
>> misleading, and it also pushes off the actual information very far to
>> the end. (Also, in some cases the socket path is very long, making the
>>
On Fri, Apr 30, 2021 at 6:19 PM Peter Geoghegan wrote:
> A remaining problem is that we must generate a new round of index
> tuples for each and every index when only one indexed column is
> logically modified by an UPDATE statement. I think that this is much
> less of a problem now due to bottom-
On Sat, May 1, 2021 at 12:37 PM Chapman Flack wrote:
> Maybe version 0 is where the provider just builds a shared object
> to go in shared_preload_libraries. The provider has probably already
> done a bunch of other stuff more challenging than that.
>
> The GUC system would have to expose a way fo
On Mon, May 3, 2021 at 7:41 AM Robert Haas wrote:
> So here. The complexity of getting a table AM that does anything
> non-trivial working is formidable, and I don't expect it to happen
> right away. Picking one that is essentially block-based and can use
> 48-bit TIDs is very likely the right ini
On 05/03/21 11:22, Robert Haas wrote:
>> The GUC system would have to expose a way for the shared object to
>> chain extra_check_hooks off existing GUCs. An extra_check_hook can check
>> both the value and the role of the caller.
>
> I think there are two parts to this problem. First, the SP needs
On Mon, May 3, 2021 at 8:03 AM Robert Haas wrote:
> It's reasonable to wonder. I think it depends on whether the problem
> is bloat or just general slowness. To the extent that the problem is
> bloat, bottom-index deletion will help a lot, but it's not going to
> help with slowness because, as you
> On May 3, 2021, at 8:22 AM, Robert Haas wrote:
>
> One problem with having a separate predefined role for every PGC_SUSET
> GUC is that it's no help for extensions. Both auto_explain and
> pg_stat_statements have such GUCs, and there may be out-of-core
> extensions that do as well. We should
On Fri, Apr 30, 2021 at 5:07 PM Robert Haas wrote:
> On Fri, Apr 30, 2021 at 4:26 PM Mark Dilger
> wrote:
> > After further reflection, no other verbiage seems any better. I'd say go
> > ahead and commit it this way.
>
> OK. I'll plan to do that on Monday, barring objections.
Done now.
--
Ro
On Mon, May 3, 2021 at 11:26 AM Peter Geoghegan wrote:
> It just has to be able to accept the restriction that
> indexes must have a unique TID-like identifier for each version (not
> quite a version actually -- whatever the equivalent of a HOT chain
> is). This is a restriction that Jeff had pret
On Mon, May 3, 2021 at 9:45 AM Robert Haas wrote:
> But if you're saying those identifiers have to be fixed-width and 48
> (or even 64) bits, I disagree that we wish to have such a requirement
> in perpetuity.
Once you require that TID-like identifiers must point to particular
versions (as oppose
On Mon, May 3, 2021 at 1:00 PM Peter Geoghegan wrote:
> You don't accept any of that, though. Fair enough. I predict that
> avoiding making a hard choice will make Jeff's work here a lot harder,
> though.
I don't really think so, or at least I don't see a reason why it
should. As things stand tod
On Mon, 3 May 2021 at 19:00, Peter Geoghegan wrote:
>
> On Mon, May 3, 2021 at 9:45 AM Robert Haas wrote:
> > But if you're saying those identifiers have to be fixed-width and 48
> > (or even 64) bits, I disagree that we wish to have such a requirement
> > in perpetuity.
>
> Once you require that
On Mon, May 3, 2021 at 11:45 AM Chapman Flack wrote:
> I guess I was thinking, but forgot to convey to the keyboard, that the
> existence of a non-empty extra_check_hooks chain on a SUSET GUC (which
> could only have been attached from a shared preload library) would
> implicitly change SUSET to m
On Mon, May 3, 2021 at 12:25 PM Mark Dilger
wrote:
> As things stand, all custom variables defined via the
> DefineCustom{Bool,Int,Real,String,Enum}Variable are placed in the
> CUSTOM_OPTIONS config_group. We could add a role for controlling any SUSET
> CUSTOM_OPTIONS GUCs, or we could extend
On Mon, May 3, 2021 at 10:22 AM Robert Haas wrote:
> I don't really think so, or at least I don't see a reason why it
> should. As things stand today, I don't think it's possible for a table
> AM author to make any other choice than to assume that their TIDs have
> to look and work like heap TIDs;
On 05/03/21 13:23, Robert Haas wrote:
> On Mon, May 3, 2021 at 11:45 AM Chapman Flack wrote:
>> I guess I was thinking, but forgot to convey to the keyboard, that the
>> existence of a non-empty extra_check_hooks chain on a SUSET GUC (which
>> could only have been attached from a shared preload li
Joe,
Thanks,
This works and I don't have to install anything!
Dave Cramer
On Thu, 29 Apr 2021 at 16:16, Joe Conway wrote:
> On 4/29/21 6:56 AM, Dave Cramer wrote:
> > For testing unusual situations I'd like to be able to cause a backend to
> > terminate due to something like a segfault. Do w
On Mon, 2021-05-03 at 09:59 -0700, Peter Geoghegan wrote:
> You don't accept any of that, though. Fair enough. I predict that
> avoiding making a hard choice will make Jeff's work here a lot
> harder,
> though.
For the purposes of this discussion, what's making my life difficult is
that we don't h
On Mon, May 3, 2021 at 10:22 AM Matthias van de Meent
wrote:
> For IoT, as far as I know, one of the constraints is that there exists
> some unique constraint on the table, which also defines the ordering.
> Assuming that that is the case, we can use + transaction id> to identify tuple versions.
Hi,
On 2021-05-01 17:35:09 +0500, Andrey Borodin wrote:
> I'm investigating somewhat resemblant case.
> We have an OLTP sharded installation where shards are almost always under
> rebalancing. Data movement is implemented with 2pc.
> Switchover happens quite often due to datacenter drills. The in
On Mon, 2021-05-03 at 13:22 -0400, Robert Haas wrote:
> to look and work like heap TIDs; that is, there had better be a block
> number portion and an item number portion,
Right (at least for now).
> and the item number had
> better be smaller than MaxOffsetNumber,
That's not clear to me at all,
On Mon, 2021-05-03 at 10:38 -0700, Peter Geoghegan wrote:
> I don't think it's much good to just do that. You probably need a
> full
> 64-bits for something like a column store. But that's all you need.
I would definitely like that for citus columnar, and it would
definitely make it easier to mana
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, May 3, 2021 at 12:25 PM Mark Dilger
> wrote:
> > As things stand, all custom variables defined via the
> > DefineCustom{Bool,Int,Real,String,Enum}Variable are placed in the
> > CUSTOM_OPTIONS config_group. We could add a role fo
On Mon, May 3, 2021 at 10:57 AM Jeff Davis wrote:
> For the purposes of this discussion, what's making my life difficult is
> that we don't have a good definition for TID, leaving me with two
> options:
>
> 1. be overly conservative, accept MaxOffsetNumber=2048, wasting a
> bunch of address spac
Stephen Frost writes:
> One thing that seems missing from this discussion and is part of what
> paused my effort on the 'admin' role proposed towards the end of the
> last cycle is that we really need to consider how this all plays with
> ALTER SYSTEM and not just SUSET GUCs but also other (eg: PO
On Mon, May 3, 2021 at 2:41 PM Stephen Frost wrote:
> In general, I agree that we should be looking at predefined roles as
> being similar to the Linux capabilities system- defining certain kinds
> of operations which the user who has that role is allowed to do, and
> then both in-core and extensi
On Sun, May 2, 2021 at 12:27:37PM +0800, Julien Rouhaud wrote:
> Hi Aleksander,
>
> On Wed, Apr 28, 2021 at 03:22:39PM +0300, Aleksander Alekseev wrote:
> > Hi Julien,
> >
> > > You should see failures doing a check-world or simply a make -C
> > > contrib/pg_stat_statements check
> >
> > Sorry,
On Mon, May 3, 2021 at 2:48 PM Tom Lane wrote:
> I'm still of the opinion that slicing and dicing this at the per-GUC
> level is a huge waste of effort. Just invent one role that lets
> grantees set any GUC, document it as being superuser-equivalent,
> and be done.
If you want to grant someone f
On Mon, 3 May 2021 at 20:43, Peter Geoghegan wrote:
>
> On Mon, May 3, 2021 at 10:57 AM Jeff Davis wrote:
> > For the purposes of this discussion, what's making my life difficult is
> > that we don't have a good definition for TID, leaving me with two
> > options:
> >
> > 1. be overly conservat
On 30.04.21 05:22, Craig Ringer wrote:
On Thu, 29 Apr 2021 at 15:31, Peter Eisentraut
wrote:
So if you could produce a separate patch that adds the
_ENABLED guards targeting PG14 (and PG13), that would be helpful.
Here is a proposed patch for this.
LGTM.
Applies and builds fine on master a
Hi,
A colleague debugged an issue where their postgres was occasionally
crash-restarting under load.
The cause turned out to be that a relatively complex archive_command was
used, which could in some rare circumstances have a bash subshell
pipeline not succeed. It wasn't at all obvious why that'
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, May 3, 2021 at 2:48 PM Tom Lane wrote:
> > I'm still of the opinion that slicing and dicing this at the per-GUC
> > level is a huge waste of effort. Just invent one role that lets
> > grantees set any GUC, document it as being sup
On 2021-May-03, Andres Freund wrote:
> The issue turns out to be that postgres was in a container, with pid
> namespaces enabled. Because postgres was run directly in the container,
> without a parent process inside, it thus becomes pid 1. Which mostly
> works without a problem. Until, as the case
On Sun, May 2, 2021, at 18:53, Tom Lane wrote:
> fix-exponential-cost-of-checkmatchall-2.patch
Successfully tested.
SELECT
is_match <> (subject ~ pattern),
captured IS DISTINCT FROM regexp_match(subject, pattern, flags),
COUNT(*)
FROM performance_test
GROUP BY 1,2
ORDER BY 1,2;
?column? | ?
Alvaro Herrera writes:
> On 2021-May-03, Andres Freund wrote:
>> The issue turns out to be that postgres was in a container, with pid
>> namespaces enabled. Because postgres was run directly in the container,
>> without a parent process inside, it thus becomes pid 1. Which mostly
>> works without
"Joel Jacobson" writes:
> On Sun, May 2, 2021, at 18:53, Tom Lane wrote:
>> fix-exponential-cost-of-checkmatchall-2.patch
> Successfully tested.
Again, thanks for checking!
regards, tom lane
On Mon, May 3, 2021, at 21:38, Tom Lane wrote:
> "Joel Jacobson" mailto:joel%40compiler.org>> writes:
> > On Sun, May 2, 2021, at 18:53, Tom Lane wrote:
> >> fix-exponential-cost-of-checkmatchall-2.patch
>
> > Successfully tested.
>
> Again, thanks for checking!
You're welcome, thanks for coding
Alvaro Herrera writes:
> I also heard a story where things ran into trouble (I didn't get the
> whole story of *what* was the problem with that) because the datadir is /.
BTW, as far as that goes, I think the general recommendation is that
the datadir shouldn't be a mount point, because bad thing
On Mon, May 3, 2021 at 12:06 PM Matthias van de Meent
wrote:
> One could relatively easily disable bitmap scans on the table AM by
> not installing the relevant bitmap support functions on the registered
> TableAM structure, and thus not touch that problem.
I have no idea how much it'll hurt thin
On 2021-May-03, Tom Lane wrote:
> Alvaro Herrera writes:
> > I also heard a story where things ran into trouble (I didn't get the
> > whole story of *what* was the problem with that) because the datadir is /.
>
> BTW, as far as that goes, I think the general recommendation is that
> the datadir
Hi,
On 2021-05-03 15:37:24 -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2021-May-03, Andres Freund wrote:
> >> The issue turns out to be that postgres was in a container, with pid
> >> namespaces enabled. Because postgres was run directly in the container,
> >> without a parent process
Andres Freund writes:
> On 2021-05-03 15:37:24 -0400, Tom Lane wrote:
>> And who's to say that ignoring unexpected child deaths is okay,
>> anyway? We could hardly be sure that the dead process hadn't been
>> connected to shared memory.
> I don't think checking the exit status of unexpected chil
Hi,
On 2021-05-03 15:25:53 -0400, Alvaro Herrera wrote:
> I also heard a story where things ran into trouble (I didn't get the
> whole story of *what* was the problem with that) because the datadir is /.
> I know -- nobody in their right mind would put the datadir in / -- but
> apparently in the c
On 2021-May-03, Andres Freund wrote:
> Using / for a single statically linked binary that e.g. just serves a
> bunch of hardcoded files is one thing. Putting actual data in / for
> something like postgres another.
Yeah, I just had a word with them and I had misunderstood what they were
doing. Th
On 5/3/21 3:07 PM, Andres Freund wrote:
> Hi,
>
> A colleague debugged an issue where their postgres was occasionally
> crash-restarting under load.
>
> The cause turned out to be that a relatively complex archive_command was
> used, which could in some rare circumstances have a bash subshell
> p
Hi,
On 2021-05-03 16:20:43 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2021-05-03 15:37:24 -0400, Tom Lane wrote:
> >> And who's to say that ignoring unexpected child deaths is okay,
> >> anyway? We could hardly be sure that the dead process hadn't been
> >> connected to shared memory.
I and various colleagues of mine have from time to time encountered
systems that got a bit behind on WAL archiving, because the
archive_command started failing and nobody noticed right away.
Ideally, people should have monitoring for this and put it to rights
immediately, but some people don't. If
On Fri, 2021-04-30 at 10:55 -0700, Jeff Davis wrote:
> On Fri, 2021-04-30 at 12:35 -0400, Tom Lane wrote:
> > ISTM that would be up to the index AM. We'd need some interlocks
> > on
> > which index AMs could be used with which table AMs in any case, I
> > think.
>
> I'm not sure why? It seems lik
Tom Lane writes:
> Alvaro Herrera writes:
>> On 2021-May-03, Andres Freund wrote:
>>> The issue turns out to be that postgres was in a container, with pid
>>> namespaces enabled. Because postgres was run directly in the container,
>>> without a parent process inside, it thus becomes pid 1. Which
Andres Freund writes:
> On 2021-05-03 16:20:43 -0400, Tom Lane wrote:
>> Hmm, by that argument, any unexpected child PID in reaper() ought to be
>> grounds for a restart, regardless of its exit code. Which'd be fine by
>> me. I'm on board with being more restrictive about this, not less so.
> A
So, I've written a patch which avoids doing the immediate fsync for
index builds either by using shared buffers or by queueing sync requests
for the checkpointer. If a checkpoint starts during the index build and
the backend is not using shared buffers for the index build, it will
need to do the fs
On Mon, May 3, 2021 at 2:03 PM Jeff Davis wrote:
> Another point: the idea of supporting only some kinds of indexes
> doesn't mix well with partitioning. If you declare an index on the
> parent, we should do something reasonable if one partition's table AM
> doesn't support that index AM.
Sure, b
Michael Paquier writes:
> On Tue, Apr 13, 2021 at 04:39:58PM +0900, Michael Paquier wrote:
>> Looks fine to me. Let's wait a bit first to see if Fujii-san has any
>> objections to this cleanup as that's his code originally, from
>> 32a9c0bd.
> And hearing nothing, done. The tests of postgres_fd
Thanks for doing further analysis on this.
On Mon, 26 Apr 2021 at 20:31, Yuya Watari wrote:
> Thank you for running experiments on your machine and I really
> appreciate your deep analysis.
>
> Your results are very interesting. In 5 queries, the result cache is
> cheaper but slower. Especially,
While reviewing some logical replication code I stumbled across a
variable usage that looks suspicious to me.
Note that the AlterSubscription_refresh function (unlike other
functions in the subscriptioncmds.c) is using the global variable
"wrconn" instead of a local stack variable of the same name
On Mon, 2021-05-03 at 15:07 -0700, Peter Geoghegan wrote:
> Sure, but it either makes sense for the columnar table AM to support
> bitmap scans (or some analogous type of scan that works only slightly
> differently) or it doesn't. It's not at all clear which it is right
> now.
It makes sense for m
On Mon, May 3, 2021 at 5:15 PM Jeff Davis wrote:
> I don't see why in-core changes are a strict requirement. It doesn't
> make too much difference if a lossy TID doesn't correspond exactly to
> the columnar layout -- it should be fine as long as there's locality,
> right?
But look at the details:
On Mon, 2021-05-03 at 18:12 -0700, Peter Geoghegan wrote:
> But look at the details: tidbitmap.c uses MaxHeapTuplesPerPage as its
> MAX_TUPLES_PER_PAGE, which seems like a problem -- that's 291 with
> default BLCKSZ. I doubt that that restriction is something that you
> can afford to live with, eve
On Tue, May 4, 2021 at 5:00 AM Peter Smith wrote:
>
> While reviewing some logical replication code I stumbled across a
> variable usage that looks suspicious to me.
>
> Note that the AlterSubscription_refresh function (unlike other
> functions in the subscriptioncmds.c) is using the global variab
On Mon, May 3, 2021 at 10:21 PM Amit Kapila wrote:
>
> On Mon, May 3, 2021 at 5:48 PM Masahiko Sawada wrote:
> >
> > On Mon, May 3, 2021 at 2:27 PM Amit Kapila wrote:
> > >
> > > On Thu, Apr 29, 2021 at 10:37 AM Amit Kapila
> > > wrote:
> > > >
> > > > On Wed, Apr 28, 2021 at 7:43 PM Masahiko
Hi,
On 2021-05-03 16:49:16 -0400, Robert Haas wrote:
> I have two possible ideas for addressing this; perhaps other people
> will have further suggestions. A relatively non-invasive fix would be
> to teach pgarch.c how to increment a WAL file name. After archiving
> segment N, check using stat() w
Hi,
On 2021-05-04 09:29:42 +1000, Peter Smith wrote:
> While reviewing some logical replication code I stumbled across a
> variable usage that looks suspicious to me.
> Note that the AlterSubscription_refresh function (unlike other
> functions in the subscriptioncmds.c) is using the global variab
Hi,
On 2021-04-30 11:51:07 -0700, Peter Geoghegan wrote:
> I think that it's reasonable to impose some cost on index AMs here,
> but that needs to be bounded sensibly and unambiguously. For example,
> it would probably be okay if you had either 6 byte or 8 byte TIDs, but
> no other variations. You
On Tue, May 4, 2021 at 1:56 PM Bharath Rupireddy
wrote:
>
> On Tue, May 4, 2021 at 5:00 AM Peter Smith wrote:
> >
> > While reviewing some logical replication code I stumbled across a
> > variable usage that looks suspicious to me.
> >
> > Note that the AlterSubscription_refresh function (unlike
On Tue, May 4, 2021 at 2:31 PM Andres Freund wrote:
>
> Hi,
>
> On 2021-05-04 09:29:42 +1000, Peter Smith wrote:
> > While reviewing some logical replication code I stumbled across a
> > variable usage that looks suspicious to me.
>
> > Note that the AlterSubscription_refresh function (unlike othe
On Tue, May 4, 2021 at 9:48 AM Masahiko Sawada wrote:
>
> On Mon, May 3, 2021 at 10:21 PM Amit Kapila wrote:
> >
> > On Mon, May 3, 2021 at 5:48 PM Masahiko Sawada
> > wrote:
> > >
> > > On Mon, May 3, 2021 at 2:27 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Thu, Apr 29, 2021 at 10:37 AM A
> 3 мая 2021 г., в 23:10, Andres Freund написал(а):
>
> Hi,
>
> On 2021-05-01 17:35:09 +0500, Andrey Borodin wrote:
>> I'm investigating somewhat resemblant case.
>> We have an OLTP sharded installation where shards are almost always under
>> rebalancing. Data movement is implemented with 2p
91 matches
Mail list logo
