> 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
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
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 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
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
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-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
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
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, 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 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 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
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
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,
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
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
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
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
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
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
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
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.
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
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
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
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: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
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
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
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 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
"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
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
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? | ?
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
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
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'
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
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 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 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: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
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 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
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, 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
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,
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, 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.
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
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 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
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 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 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, 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 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, 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 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 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 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 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 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 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 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 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-
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 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
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 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, 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 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 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 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 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
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 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
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 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
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 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 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 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
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 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
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
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
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
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
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 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
91 matches
Mail list logo
