On 25.03.22 14:08, Peter Eisentraut wrote:
2. Some of these comment lines have become pretty long after having
added the attribute macro.
e.g.
PlannerInfo *subroot pg_node_attr(readwrite_ignore); /* modified
"root" for planning the subquery;
not printed, too large, not interesting enough
On Sunday, May 22, 2022, Saladin wrote:
>
> The output i expected:
> pg_largeobject_metadata and pg_largeobject in both database A and database
> B should have rows.Shouldn't only in database A.So, i can use large object
> functions
> to operate large_objectin remote table or foreign table.
>
On Mon, May 23, 2022 at 10:03 AM Kyotaro Horiguchi
wrote:
>
> At Sat, 21 May 2022 15:35:58 +0530, Amit Kapila
> wrote in
> > I think if we don't have any better ideas then we should go with
> > either this or one of the other proposals in this thread. The other
> > idea that occurred to me is
On 16.05.22 15:23, Amul Sul wrote:
+static inline OffsetNumber
+PageGetMaxOffsetNumber(Page page)
+{
+ if (((PageHeader) page)->pd_lower <= SizeOfPageHeaderData)
+ return 0;
+ else
+ return PageHeader) page)->pd_lower - SizeOfPageHeaderData)
/ sizeof(ItemIdData));
+}
The
On Mon, May 23, 2022 at 10:54 AM Tom Lane wrote:
>
> Dilip Kumar writes:
> > I don't think that the local pg_largeobject should maintain the
> > foreign server's data, instead that the export should fetch the data
> > from the remote's pg_largeobject table. Then I just checked inserting
> >
Dilip Kumar writes:
> I don't think that the local pg_largeobject should maintain the
> foreign server's data, instead that the export should fetch the data
> from the remote's pg_largeobject table. Then I just checked inserting
> into the foriegn from your test as shown below[1] and I noticed
On Mon, May 23, 2022 at 7:16 AM Saladin wrote:
>
> PostgreSQL version:PostgreSQL 14.0 on x86_64-pc-linux-gnu, compiled by gcc
> (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39), 64-bit
> Platform information:Linux version 3.10.0-1127.el7.x86_64
> (mockbu...@kbuilder.bsys.centos.org) (gcc version 4.8.5
At Sat, 21 May 2022 19:08:06 +0530, Bharath Rupireddy
wrote in
> How about we add GUC check hooks for both max_wal_size and
> min_wal_size where we can either emit ERROR or WARNING if values are
> not "at least twice as wal_segment_size"?
It should be ERROR.
As you say, it should have been
On Sat, May 21, 2022 at 11:06 AM vignesh C wrote:
>
> On Fri, May 20, 2022 at 11:23 AM Peter Smith wrote:
> >
> > Below are my review comments for v6-0002.
> >
> > ==
> >
> > 1. Commit message.
> > The psql \d family of commands to display excluded tables.
> >
> > SUGGESTION
> > The psql \d
On Sat, May 21, 2022 at 11:26 PM rajesh singarapu
wrote:
>
> On Sat, May 21, 2022 at 7:08 PM Bharath Rupireddy
> wrote:
> >
> > Hi,
> >
> > Currently postgres allows setting any value for max_wal_size or
> > min_wal_size, not enforcing "at least twice as wal_segment_size" limit
> > [1]. This
At Sat, 21 May 2022 15:35:58 +0530, Amit Kapila wrote
in
> I think if we don't have any better ideas then we should go with
> either this or one of the other proposals in this thread. The other
> idea that occurred to me is whether we can somehow update the snapshot
> we have serialized on disk
On Thu, May 19, 2022 at 04:12:01PM -0400, Robert Haas wrote:
> On Thu, May 19, 2022 at 4:20 AM Michael Paquier wrote:
>> Btw, shouldn't we have something a bit more, err, extensible for the
>> design of an extensible varlena header? If we keep it down to some
>> bitwise information, we'd be fine
On Fri, May 20, 2022 at 3:08 PM vignesh C wrote:
>
> On Wed, May 18, 2022 at 10:29 AM Amit Kapila wrote:
> >
> >
> > Few comments on v13-0001
> > ==
> > 1.
> > + *
> > + * FIXME: LOGICALREP_PROTO_LOCALONLY_VERSION_NUM needs to be bumped to 4 in
> > + * PG16.
> > ...
> > @@
On Mon, May 23, 2022 at 02:00:18AM +, Shinoda, Noriyoshi (PN Japan FSIP)
wrote:
> Thanks to all the developers. The attached patch updates the manual
> for the pg_database catalog.
> The current pg_database view definition is missing the
> datlocprovider column. The attached patch adds this
Hi hackers,
Thanks to all the developers. The attached patch updates the manual for the
pg_database catalog.
The current pg_database view definition is missing the datlocprovider column.
The attached patch adds this column info.
https://www.postgresql.org/docs/15/catalog-pg-database.html
PostgreSQL version:PostgreSQL 14.0 on x86_64-pc-linux-gnu, compiled by gcc
(GCC) 4.8.5 20150623 (Red Hat 4.8.5-39), 64-bit
Platform information:Linux version 3.10.0-1127.el7.x86_64
(mockbu...@kbuilder.bsys.centos.org) (gcc version 4.8.5 20150623 (Red Hat
4.8.5-39) (GCC) ) #1 SMP Tue Mar 31
At Sun, 22 May 2022 09:55:37 +0200, Przemysław Sztoch
wrote in
> David G. Johnston wrote on 5/19/2022 3:46 AM:
> > As an aside, I'd rather overcome this particular objection by having
> > the CREATE object command all accept an optional "COMMENT IS" clause.
> >
> I believe that it is not worth
Hi,
It'd be cool to commit and backpatch this - I'd like to re-enable the conflict
tests in the backbranches, and I don't think we want to do so with this issue
in place.
On 2022-05-10 16:39:11 +1200, Thomas Munro wrote:
> On Tue, Apr 12, 2022 at 10:50 AM Andres Freund wrote:
> > On 2022-04-12
On Sun, May 22, 2022 at 01:26:08PM -0700, Nathan Bossart wrote:
> Yeah, this crossed my mind. I thought that "superusers, roles with
> privileges of the pg_read_all_stats_role, roles with privileges of the user
> owning the session being reported on, and the user owning the session being
>
forking: <20220307191054.n5enrlf6kdn7z...@alap3.anarazel.de>
An update.
ccache 4.6.1 was released which allows compiling postgres
I submitted a request to update the package in chocolatey.
But with the existing build system, it's no faster anyway, I guess due to poor
use of parallelism.
Hi,
On 2022-05-20 01:25:10 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-05-20 00:22:14 -0400, Tom Lane wrote:
> >> There's some fallout in the expected-file, of course, but this
> >> does seem to fix it (20 consecutive successful runs now at
> >> 100/2). Don't see why though ...
>
On Sun, May 22, 2022 at 09:59:47AM +0900, Michael Paquier wrote:
> +visible to superusers, roles with privileges of the
> +pg_read_all_stats role, and roles with privileges of
> +the user owning the session being reported on, so it should not
> +represent a security risk. Only
Hi David,
>Over the past few days I've been gathering some benchmark results
>together to show the sort performance improvements in PG15 [1].
>One of the test cases I did was to demonstrate Heikki's change to use
>a k-way merge (65014000b).
>The test I did to try this out was along the lines
Greetings (everyone except Israa),
* Israa Odeh (israa.k.o...@gmail.com) wrote:
>Please I need to cancel my subscription to this mailing list, could you
>delete me from it, or tell me how to unsubscribe.
To hopefully forstall general replies and such to this- they've already
been
David G. Johnston wrote on 5/19/2022 3:46 AM:
I think that this feature is at least worth considering - but absent
an existing command that does this I would agree that doing so
constitutes a separate feature.
As an aside, I'd rather overcome this particular objection by having
the CREATE
> On 22 May 2022, at 08:41, Gurjeet Singh wrote:
> The initialization in PostmasterMain() blindly turns on LoadedSSL,
> irrespective of the outcome of secure_initialize().
This call is invoked with isServerStart set to true so any error in
secure_initialize should error out with ereport FATAL
The initialization in PostmasterMain() blindly turns on LoadedSSL,
irrespective of the outcome of secure_initialize(). I don't think
that's how it should behave, primarily because of the pattern followed
by the other places that call secure_initialize().
This patch makes PostmasterMain() behave
27 matches
Mail list logo
