On Wed, May 31, 2023 at 10:47 AM Richard Guo wrote:
> On Tue, May 30, 2023 at 10:48 PM Markus Winand
> wrote:
>
>> I found an error similar to others before ([1]) that is still persists as
>> of head right now (0bcb3ca3b9).
>>
>> CREATE TABLE t (
>> n INTEGER
>> );
>>
>> SELECT *
>> FR
On Wed, 31 May 2023 at 15:57, Shinoda, Noriyoshi (PN Japan FSIP)
wrote:
> According to the documentation [2], the data type of the columns added to
> these views is 'timestamptz'.
> However, columns of the same data type in pg_stat_all_tables.last_vacuum,
> last_analyze and other tables are unif
On Wed, 31 May 2023 at 11:32, Bruce Momjian wrote:
>
> On Thu, May 25, 2023 at 05:57:25PM +1200, David Rowley wrote:
> > On 64-bit builds, it was 16 bytes for AllocSet contexts, 24 bytes for
> > generation contexts and 16 bytes for slab contexts.
>
> Okay, item added to Source Code:
I don't think
Hi,
On 5/30/23 5:24 PM, Andres Freund wrote:
Hi,
On 2023-05-29 14:31:24 +0200, Drouvot, Bertrand wrote:
On 5/29/23 1:03 PM, Tom Lane wrote:
but I wouldn't be surprised if something in the logical replication
mechanism itself could be running a transaction at the wrong instant.
Some of the ot
Hi, hackers.
PostgreSQL 16 Beta1, added last access time to pg_stat_all_tables and
pg_stat_all_indexes views by this patch [1].
According to the documentation [2], the data type of the columns added to these
views is 'timestamptz'.
However, columns of the same data type in pg_stat_all_tables.la
On Tue, May 30, 2023 at 10:48 PM Markus Winand
wrote:
> I found an error similar to others before ([1]) that is still persists as
> of head right now (0bcb3ca3b9).
>
> CREATE TABLE t (
> n INTEGER
> );
>
> SELECT *
> FROM (VALUES (1)) t(c)
> LEFT JOIN t ljl1 ON true
> LEFT JOIN LATE
On 2023-05-26 10:07, Kyotaro Horiguchi wrote:
Thanks for your review!
+ printf(_(" -x --strip-extension=EXTclean up files if they have
this extension\n"));
Perhaps a comma is needed after "-x".
That's an oversight. Modified it.
The apparent inconsistency
between the long name and
On Wed, 12 Apr 2023 at 21:03, David Rowley wrote:
> I'm not sure if we should consider backpatching a fix for this bug.
> We tend not to commit stuff that would destabilise plans in the back
> branches. On the other hand, it's fairly hard to imagine how we
> could make this much worse even given
On Thu, May 25, 2023 at 05:57:25PM +1200, David Rowley wrote:
> On Thu, 25 May 2023 at 05:45, Bruce Momjian wrote:
> >
> > On Wed, May 24, 2023 at 01:43:50PM -0400, Bruce Momjian wrote:
> > > > * Reduce palloc() memory overhead for all memory allocations down to 8
> > > > bytes on all platforms. (
On Tue, May 30, 2023 at 06:33:09AM -0400, Masahiko Sawada wrote:
> Hi,
>
> On Thu, May 18, 2023 at 4:49 PM Bruce Momjian wrote:
> >
> > I have completed the first draft of the PG 16 release notes. You can
> > see the output here:
> >
>
> I have one suggestion on this item:
>
>
>
>
>
> Allo
Good morning,
My name is Nick Mayer, and I had a question concerning PostgreSQL's EAL. Has
PostgreSQL been put through any audit/security testing, and does it have an
EAL? If so, would I be able to get this information? I would appreciate any
assistance you are able to provide for this.
Thanks
On Wed Apr 12, 2023 at 4:19 PM CDT, Peter Eisentraut wrote:
> On 11.04.23 19:18, Andres Freund wrote:
> >> Subject: [PATCH v9 2/5] Add data layout options sub-section in installation
> >> docs
> >>
> >> This commit separates out blocksize, segsize and wal_blocksize
> >> options into a separate Da
Hey!
Nice work organizing the docs. Looks pretty good. I had a single comment
regarding the Meson docs in general.
It seems like Postgres cares a bit about Windows/Mac development. Is
ninja the blessed way to build Postgres on Windows and Mac? Otherwise, I
would suggest just being more generic an
On Fri, May 12, 2023 at 7:48 PM Stephen Frost wrote:
>
> Greetings,
>
> * David Christensen (david.christen...@crunchydata.com) wrote:
> > Refreshing this with HEAD as of today, v4.
>
> Thanks for updating this!
Thanks for the patience in my response here.
> > Subject: [PATCH v4 1/3] Add reserve
On Fri, May 12, 2023 at 2:35 AM Richard Guo wrote:
>
> I happened to notice that the query below can be inefficient.
>
> # explain (costs off)
> select * from
> int8_tbl a left join
> (int8_tbl b inner join
>lateral (select *, b.q2 as x from int8_tbl c) ss on b.q2 = ss.q1)
> on a.q1 = b.
Do you want me to try PG 16 without ICU or PG 15 with ICU?
I can do that, but it will take a few days before the server is available.
On Mon, May 29, 2023 at 9:55 AM Peter Geoghegan wrote:
> On Sun, May 28, 2023 at 2:42 PM David Rowley wrote:
> > c6e0fe1f2 might have helped improve some of that
Hi,
On 2023-05-29 14:31:24 +0200, Drouvot, Bertrand wrote:
> On 5/29/23 1:03 PM, Tom Lane wrote:
> > but I wouldn't be surprised if something in the logical replication
> > mechanism itself could be running a transaction at the wrong instant.
> >
> > Some of the other recovery tests set
> > autov
On Mon, 22 May 2023 at 15:50, Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Wang,
>
> Thank you for reviewing! PSA new version.
Thanks for the updated patch, Few comments:
Few comments
1) check_for_parameter_settings, check_for_confirmed_flush_lsn and
check_are_logical_slots_active functions all have t
I found an error similar to others before ([1]) that is still persists as of
head right now (0bcb3ca3b9).
CREATE TABLE t (
n INTEGER
);
SELECT *
FROM (VALUES (1)) t(c)
LEFT JOIN t ljl1 ON true
LEFT JOIN LATERAL (WITH cte AS (SELECT * FROM t WHERE t.n = ljl1.n) SELECT *
FROM cte) l
Did not even remember sending an original reply. Disregard.
--
Tristan Partin
Neon (https://neon.tech)
On Tue May 23, 2023 at 7:51 PM CDT, Michael Paquier wrote:
> On Mon, May 22, 2023 at 12:26:34PM -0500, Tristan Partin wrote:
> > This is a way that would solve bug #17698[1]. It just reuses the same
> > handler as SIGINT (with a function rename).
> >
> > This patch works best if it is combined wit
On Tue May 23, 2023 at 7:31 PM CDT, Michael Paquier wrote:
> On Mon, May 22, 2023 at 10:02:02AM -0500, Tristan Partin wrote:
> > The way that pgbench handled SIGINT changed in
> > 1d468b9ad81b9139b4a0b16b416c3597925af4b0. Unfortunately this had a
> > couple of unintended consequences, at least from
On 28.05.23 02:48, Thomas Munro wrote:
Another potential option name would be --segsize, if we think we're
going to use this for temp files too eventually.
Maybe it's not so beautiful to have that global variable
rel_segment_size (which replaces REL_SEGSIZE everywhere). Another
idea would be to
Hi hackers,
Please find attached a patch proposal to $SUBJECT.
Indeed, we have seen occurrences in [1] that some slots were
not invalidated (while we expected vacuum to remove dead rows
leading to slots invalidation on the standby).
Though we don't have strong evidences that this
was due to tra
Hi,
On Thu, May 18, 2023 at 4:49 PM Bruce Momjian wrote:
>
> I have completed the first draft of the PG 16 release notes. You can
> see the output here:
>
I have one suggestion on this item:
Allow logical replication subscribers to process only changes that
have no origin (Vignesh C, Amit
Bruce Momjian writes:
> On Sat, May 27, 2023 at 09:34:37PM -0400, Bruce Momjian wrote:
>> > > This is controlled by auto_explain.log_parameter_max_length, and by
>> > > default query parameters will be logged with no length
>> > > restriction. SHOULD THIS BE MORE CLEARLY IDENTIFIED AS CONTROLLING
On Sat, May 27, 2023 at 09:34:37PM -0400, Bruce Momjian wrote:
> > > This is controlled by auto_explain.log_parameter_max_length, and by
> > > default query parameters will be logged with no length
> > > restriction. SHOULD THIS BE MORE CLEARLY IDENTIFIED AS CONTROLLING THE
> > > EXECUTION OF PREPA
On Tue, May 30, 2023 at 10:28 AM Richard Guo wrote:
> I haven't thought through how to fix it, but I suspect that we may need
> to do more checking before we decide to remove PHVs in
> remove_rel_from_query.
>
Hmm, maybe we can additionally check if the PHV needs to be evaluated
above the join.
> On 29 May 2023, at 02:39, Shinoda, Noriyoshi (PN Japan FSIP)
> wrote:
> In PostgreSQL 16 Beta 1, standalone backend was added to the backend type by
> this patch [1]. I think this patch will change the value of backend_type
> column in the pg_stat_activity view, but it's not explained in the
29 matches
Mail list logo
