>
>
> > WARNING: invalid input syntax for type integer: "four"
> > row_written | stats_applied |
> > stats_rejected| params_rejected
> > -+--+
> > --+-
> > t
On Thu, Jun 20, 2024 at 10:03 PM Michael Paquier wrote:
>
> On Thu, Jun 20, 2024 at 08:01:19PM -0400, Bruce Momjian wrote:
> > FYI, looking at the release notes, I see 15 GUC variables added in this
> > release, and two removed. That 15 number seemed unusually high so I
> > thought I would report
> Tatsuo Ishii writes:
>> In our documentations, "subquery", "sub-query", "sub-select" and
>> "sub-SELECT" are used. In English, are they interchangeable?
>
> Pretty nearly. I think "sub-query" can include DML such as
> INSERT RETURNING, whereas "sub-select" should only be a SELECT.
> (I'm not c
Tatsuo Ishii writes:
> In our documentations, "subquery", "sub-query", "sub-select" and
> "sub-SELECT" are used. In English, are they interchangeable?
Pretty nearly. I think "sub-query" can include DML such as
INSERT RETURNING, whereas "sub-select" should only be a SELECT.
(I'm not claiming that
On Sat, Aug 3, 2024 at 7:30 PM Andrew Dunstan wrote:
>
>
> On 2024-08-02 Fr 2:45 PM, Peter Eisentraut wrote:
> > On 01.08.24 23:38, Andrew Dunstan wrote:
> >> Not totally opposed, and I will probably give it a try very soon, but
> >> I'm wondering if this really needs to go in the core repo. We've
On Sat, Aug 3, 2024 at 2:45 AM Peter Eisentraut wrote:
>
> On 01.08.24 23:38, Andrew Dunstan wrote:
> > Not totally opposed, and I will probably give it a try very soon, but
> > I'm wondering if this really needs to go in the core repo. We've
> > generally shied away from doing much in the way of
On Fri, Aug 2, 2024 at 5:38 AM Andrew Dunstan wrote:
>
>
> On 2024-08-01 Th 10:56 AM, Junwang Zhao wrote:
> > Stack Overflow 2024 developer survey[1] said VSCode
> > is the most used development environment.
> >
> > In a PostgreSQL Hacker Mentoring discussion, we talked
> > about how to use vscode
On Fri, Aug 2, 2024 at 12:29 AM Jelte Fennema-Nio wrote:
>
> On Thu, 1 Aug 2024 at 16:56, Junwang Zhao wrote:
> > I post my daily used devcontainer config[2] , Jelte(ccd)
> > suggested that it might be a good idea we integrate the
> > config into postgres repo so that the barrier to entry for
> >
In our documentations, "subquery", "sub-query", "sub-select" and
"sub-SELECT" are used. In English, are they interchangeable? I am
asking because we are looking for Japanese translations for the
words. If they have the identical meaning in English, we can choose
single Japanese word for them. If n
On Sat, Aug 3, 2024 at 6:14 PM Peter Geoghegan wrote:
> Displaying the number of primitive scans would already be useful for
> index scans with SAOPs, even without this patch. The same general
> concepts (estimated vs. actual primitive index scans) already exist,
> as of Postgres 17. That's really
On Sat, Aug 3, 2024 at 3:34 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> I see that the patch is not supposed to deal with aggregates in any special
> way.
Right.
> But from what I understand after a quick review, skip scan is not getting
> applied to them if there are no quals in the query
Peter Eisentraut writes:
> This has all been committed now.
Various buildfarm animals are complaining about
g++ -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
-Werror=vla -Werror=unguarded-availability-new -Wendif-labels
-Wmissing-format-attribute -Wcast-function-type
"David G. Johnston" writes:
> On Thursday, August 1, 2024, Tom Lane wrote:
>> I think what is happening there is you're getting the fallback
>> "cast via I/O" behavior. There's no jsonb->text cast function
>> in the catalogs.
>> Perhaps it's worth adding one, so that it can be made to behave
>>
> On Wed, Jun 26, 2024 at 03:16:07PM GMT, Peter Geoghegan wrote:
>
> Loose index scan is a far more specialized technique than skip scan.
> It only applies within special scans that feed into a DISTINCT group
> aggregate. Whereas my skip scan patch isn't like that at all -- it's
> much more general
On Fri, Aug 2, 2024 at 4:00 PM Nathan Bossart
wrote:
> On Fri, Aug 02, 2024 at 01:33:45AM -0400, Tom Lane wrote:
> > 2. On the other end of the scale, if you've got a *boatload* of
> > functions, what does it do to pg_dump's memory requirements?
>
> Hm. I think this is sufficient reason to withd
Heikki Linnakangas writes:
> I'm actually not even sure if it's intentional to throw the error even
> with "char[1]". It makes sense to give an error on "char", but who says
> that "char[1]" isn't a valid string?
I agree that that behavior looks more like an implementation artifact
than anythin
On Fri, Aug 02, 2024 at 07:03:58PM +0300, Andrey M. Borodin wrote:
> The test works fine with SQL interface “select
> injection_points_load('get-new-multixact-id');”.
Yes, just use a load() here to make sure that the DSM required by the
waits are properly initialized before entering in the critica
Melanie Plageman writes:
> For the "Prevent infinite loop in VACUUM" item, I noticed two things
Thanks for looking!
> 1) In REL_17_STABLE, the behavior is an ERROR -- not an infinite loop.
> Perhaps it is not worth mentioning the differing behavior because 17
> hasn't GA'd yet, but I just wanted
On 03/08/2024 18:20, Tom Lane wrote:
Heikki Linnakangas writes:
On 03/08/2024 14:04, Peter Eisentraut wrote:
I noticed (during [0]) to some uses of the function atol() seem
inappropriate.
+1 except for this one:
/* If we have just one character this is not a string */
-
Heikki Linnakangas writes:
> On 03/08/2024 14:04, Peter Eisentraut wrote:
>> I noticed (during [0]) to some uses of the function atol() seem
>> inappropriate.
> +1 except for this one:
>> /* If we have just one character this is not a string */
>> -if (atol(p->type->size) ==
On Fri, Aug 2, 2024 at 4:26 PM Tom Lane wrote:
>
> See
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=ee219ee8c40d88e7a0ef52c3c1b76c90bbd0d164
>
> As usual, please send corrections/comments by Sunday.
For the "Prevent infinite loop in VACUUM" item, I noticed two things
1)
On 03/08/2024 14:04, Peter Eisentraut wrote:
I noticed (during [0]) to some uses of the function atol() seem
inappropriate. Either they assume that sizeof(long)==8 and so might
truncate data if not, or they are gratuitous because the surrounding
code does not use the long type. This patch fix
On 26.07.24 11:07, Peter Eisentraut wrote:
I have committed all of the fixes that I had previously posted, but
before actually activating the warning option, I found another small
hiccup with the Bison files.
This has all been committed now.
On 2024-08-02 Fr 2:45 PM, Peter Eisentraut wrote:
On 01.08.24 23:38, Andrew Dunstan wrote:
Not totally opposed, and I will probably give it a try very soon, but
I'm wondering if this really needs to go in the core repo. We've
generally shied away from doing much in the way of editor / devenv
I noticed (during [0]) to some uses of the function atol() seem
inappropriate. Either they assume that sizeof(long)==8 and so might
truncate data if not, or they are gratuitous because the surrounding
code does not use the long type. This patch fixes these, by using
atoll() or atoi() instead.
On 7/30/24 1:31 PM, Andrey M. Borodin wrote:>> On 30 Jul 2024, at 14:57,
Tomas Vondra wrote:
How do we synchronize Shared Fake LSN with global XLogCtl->unloggedLSN? Just bump
XLogCtl->unloggedLSN if necessary?
Perhaps, consider using GetFakeLSNForUnloggedRel() instead of shared counter? As
26 matches
Mail list logo
