On Tue, May 23, 2023 at 8:21 PM Amit Kapila wrote:
>
> On Mon, May 22, 2023 at 6:06 PM Masahiko Sawada wrote:
> >
> > Thank you for updating the patch! Here are review comments:
> >
> > + /*
> > +* Make sure that the copy command runs as the table owner, unless
> > +* the us
> On 25 May 2023, at 00:18, Michael Paquier wrote:
>
> On Wed, May 24, 2023 at 01:03:04PM +0200, Daniel Gustafsson wrote:
>> When we moved the goalposts to 1.0.1 (commit 7b283d0e1d1) we referred to
>> RHEL6
>> using 1.0.1, and RHEL6 goes out of ELS in late June 2024 seems possible to
>> drop
>>
> On 24 May 2023, at 16:15, Tom Lane wrote:
> We had definitely better have some animals still using 1.0.2, but
> I don't see much reason to think that the last public release
> wouldn't be good enough.
There are still RHEL7 animals like chub who use 1.0.2 so I'm not worried. We
might want to c
Why does pgindent require that pg_bsd_indent be installed in the path?
Couldn't pgindent call the pg_bsd_indent built inside the tree? That
would make the whole process much smoother.
On Thu, May 25, 2023 at 12:33 PM Masahiko Sawada wrote:
>
> On Tue, May 23, 2023 at 8:21 PM Amit Kapila wrote:
> >
> > On Mon, May 22, 2023 at 6:06 PM Masahiko Sawada
> > wrote:
> > >
> > > Thank you for updating the patch! Here are review comments:
> > >
> > > + /*
> > > +* Make
Tom Lane writes:
>Hans Buschmann writes:
>> This inspired me to propose dropping 32bit support for PostgreSQL starting
>> with PG17.
>I don't think this is a great idea. Even if Intel isn't interested,
>there'll be plenty of 32-bit left in the lower end of the market
>(think ARM, IoT, and so
Hi,
Peter Smith , 24 May 2023 Çar, 05:59 tarihinde şunu
yazdı:
> Hi, and thanks for the patch! It is an interesting idea.
>
> I have not yet fully read this thread, so below are only my first
> impressions after looking at patch 0001. Sorry if some of these were
> already discussed earlier.
>
>
Working with PostgreSQL Logical Replication is just great! It helps a lot
doing real time replication for analytical purposes without using any other
3d party service. Although all these years working as a product architect
of reporting I have noted a few requirements which are always a challenge
a
Until PG15, calling pgindent without arguments would process the whole
tree. Now you get
No files to process at ./src/tools/pgindent/pgindent line 372.
Is that intentional?
Also, pgperltidy accepts no arguments and always processes the whole
tree. It would be nice if there were a way to pr
hi.
https://www.postgresql.org/docs/current/pgwalinspect.html
last query should be:
SELECT * FROM pg_get_wal_stats('0/1E847D00', '0/1E84F500')
WHERE count > 0 AND
"resource_manager/record_type" = 'Transaction'
LIMIT 1;
> On 25 May 2023, at 11:13, jian he wrote:
>
> hi.
> https://www.postgresql.org/docs/current/pgwalinspect.html
>
> last query should be:
> SELECT * FROM pg_get_wal_stats('0/1E847D00', '0/1E84F500')
> WHERE count > 0 AND
> "resource_manager/record_type" = 'Transaction'
> LIMIT 1;
Nice
> On 25 May 2023, at 11:10, Peter Eisentraut wrote:
> Also, pgperltidy accepts no arguments and always processes the whole tree.
> It would be nice if there were a way to process individual files or
> directories, like pgindent can.
+1, thanks! I've wanted that several times but never gotten
On 3/6/23 10:30, Michał Kłeczek wrote:
> Hi All,
>
> I just wanted to ask about the status and plans for this patch.
> I can see it being stuck at “Waiting for Author” status in several
> commit tests.
>
> I think this patch would be really beneficial for us as we heavily use
> views to structure
On 2023-May-22, Alvaro Herrera wrote:
> Hah, yeah, that's because an empty pipeline never calls the code to
> allocate the flag array. Here's the trivial fix.
Pushed to both branches, thanks for the report.
--
Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
Peter Eisentraut writes:
> Why does pgindent require that pg_bsd_indent be installed in the path?
> Couldn't pgindent call the pg_bsd_indent built inside the tree? That
> would make the whole process much smoother.
Well, the current expectation is that you run it in a distclean'd
tree, in whic
Peter Eisentraut writes:
> Until PG15, calling pgindent without arguments would process the whole
> tree. Now you get
> No files to process at ./src/tools/pgindent/pgindent line 372.
> Is that intentional?
It was intentional, cf b16259b3c and the linked discussion.
> Also, pgperltidy accepts n
On Mon, 22 May 2023 at 13:52, Andrew Dunstan wrote:
> A performant server side set of functions would be written in C and follow
> the patterns in ruleutils.c.
We have lots of DDL ruleutils in our Citus codebase:
https://github.com/citusdata/citus/blob/main/src/backend/distributed/deparser/citus
Hi,
The recovery tap test has 4 implementations of find_in_log sub routine
for various uses, I felt we can generalize these and have a single
function for the same. The attached patch is an attempt to have a
generalized sub routine find_in_log which can be used by all of them.
Thoughts?
Regards,
On 5/24/23 22:22, Andres Freund wrote:
> Hi,
>
> On 2023-05-24 21:56:22 +0200, Tomas Vondra wrote:
The really hard thing was determining what causes the memory leak - the
simple instrumentation doesn't help with that at all. It tells you there
might be a leak, but you don't know
Richard Guo writes:
> The "incompatible_relids" idea is a stroke of genius. I reviewed the
> patch and did not find any problem. So big +1 to the patch.
Pushed, thanks for the report and the review.
regards, tom lane
On 5/25/23 12:16 AM, Andres Freund wrote:
Hi,
On 2023-05-24 23:30:58 -0400, Jonathan S. Katz wrote:
Ah, OK, that's why I didn't grok it. I read through the first message
in[1] and definitely agree it should be in the announcement. How about:
"PostgreSQL 16 also shows up to a 300% improvement w
On 5/24/23 21:49, Tomas Vondra wrote:
>
>
> On 5/24/23 20:55, Andres Freund wrote:
>> Hi,
>>
>> On 2023-05-24 15:38:41 +0200, Tomas Vondra wrote:
>>> I looked at this again, and I think GetPerTupleMemoryContext(estate)
>>> might do the trick, see the 0002 part.
>>
>> Yea, that seems like the ri
On 5/24/23 22:19, Andres Freund wrote:
>
> ...
>
> Hm - stepping back a bit, why are we doing the work in ExecGetAllUpdatedCols()
> over and over? Unless I am missing something, the result doesn't change
> across rows. And it doesn't look that cheap to compute, leaving aside the
> allocation that
Re: Andres Freund
> That's due to MAKELEVEL:
>
> submake-generated-headers:
> ifndef NO_GENERATED_HEADERS
> ifeq ($(MAKELEVEL),0)
> $(MAKE) -C $(top_builddir)/src/backend generated-headers
> endif
> endif
>
> So the distcheck target needs to reset MAKELEVEL=0 - unless somebody has a
> bette
On 2023-05-24 10:26, Michael Paquier wrote:
On Mon, May 22, 2023 at 06:24:49PM +0900, torikoshia wrote:
Thanks for your advice, attached patches.
0001 looks OK, thanks!
+Remove files including backup history file.
This could be reworded as "Remove backup history files.", I assume.
+
On 5/24/23 05:04, Daniel Gustafsson wrote:
>> On 23 May 2023, at 23:02, Stephen Frost wrote:
>> * Jacob Champion (jchamp...@timescale.com) wrote:
>
>>> - low iteration counts accepted by the client make it easier than it
>>> probably should be for a MITM to brute-force passwords (note that
>>> PG
Hi,
On 2023-05-25 09:09:45 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > Why does pgindent require that pg_bsd_indent be installed in the path?
> > Couldn't pgindent call the pg_bsd_indent built inside the tree? That
> > would make the whole process much smoother.
>
> Well, the curren
On 5/23/23 21:37, Michael Paquier wrote:
> On Tue, May 23, 2023 at 10:01:03PM -0400, Stephen Frost wrote:
>> To the extent that there was an issue when it was implemented ... it's
>> now been implemented and so that was presumably overcome (though I don't
>> really specifically recall what the issu
Andres Freund writes:
> On 2023-05-25 09:09:45 -0400, Tom Lane wrote:
>> Peter Eisentraut writes:
>>> Why does pgindent require that pg_bsd_indent be installed in the path?
> Isn't the situation actually *easier* in VPATH builds? There's no build
> artifacts in the source tree, so you can just
Greetings,
* Peter Eisentraut (peter.eisentr...@enterprisedb.com) wrote:
> On 24.05.23 02:34, Thomas Munro wrote:
> > Thanks all for the feedback. It was a nice idea and it *almost*
> > works, but it seems like we just can't drop segmented mode. And the
> > automatic transition schemes I showed
Greetings,
* Jacob Champion (jchamp...@timescale.com) wrote:
> On 5/24/23 05:04, Daniel Gustafsson wrote:
> >> On 23 May 2023, at 23:02, Stephen Frost wrote:
> >> Perhaps more succinctly- maybe we should be making adjustments to the
> >> current language instead of just adding a new paragraph.
>
vignesh C writes:
> Hi,
>
> The recovery tap test has 4 implementations of find_in_log sub routine
> for various uses, I felt we can generalize these and have a single
> function for the same. The attached patch is an attempt to have a
> generalized sub routine find_in_log which can be used by al
On Thu, May 25, 2023 at 10:29 AM Stephen Frost wrote:
> I was referring specifically to that ordering as not being ideal or in
> line with the rest of the flow of that section. We should integrate the
> concerns higher in the section where we outline the reason these things
> matter and then foll
On 5/25/23 1:29 PM, Stephen Frost wrote:
Greetings,
* Jacob Champion (jchamp...@timescale.com) wrote:
On 5/24/23 05:04, Daniel Gustafsson wrote:
On 23 May 2023, at 23:02, Stephen Frost wrote:
Perhaps more succinctly- maybe we should be making adjustments to the
current language instead of jus
Hi Nathan,
A nice side effect of using the float8[] to represent vectors is that it allows
for vectors of different sizes to coexist in the same column.
We most frequently see (pgvector) vector columns being used for storing ML
embeddings. Given that different models produce embeddings with a d
On Wed, 2023-04-19 at 14:07 +1200, Thomas Munro wrote:
> That strengthens my opinion that C.UTF-8 (the real C.UTF-8 supplied
> by
> the glibc project) isn't supposed to be versioned, but it's extremely
> unfortunate that a bunch of OSes (Debian and maybe more) have been
> sorting text in some other
Jeff Davis writes:
> What should we do with locales like C.UTF-8 in both libc and ICU?
I vote for passing those to the existing C-specific code paths,
whereever we have any (not sure that we do for functionality).
The semantics are quite well-defined and I can see no good coming of
allowing eit
On Thu, May 25, 2023 at 10:48 AM Jonathan S. Katz wrote:
> Overall, +1 to tightening the language around the docs in this area.
>
> However, to paraphrase Stephen, I think the language, as currently
> written, makes the problem sound scarier than it actually is, and I
> agree that we should just i
Bruce Momjian writes:
> I have completed the first draft of the PG 16 release notes. You can
> see the output here:
>
> https://momjian.us/pgsql_docs/release-16.html
>
> I will adjust it to the feedback I receive; that URL will quickly show
> all updates.
The bit about auto_explain and q
On Thu, 2023-05-18 at 16:49 -0400, Bruce Momjian wrote:
> I have completed the first draft of the PG 16 release notes.
I found two typos.
Yours,
Laurenz Albe
diff --git a/doc/src/sgml/release-16.sgml b/doc/src/sgml/release-16.sgml
index faecae7c42..7dad0b8550 100644
--- a/doc/src/sgml/release-16.
Richard Guo writes:
> On Wed, May 24, 2023 at 2:48 AM Tom Lane wrote:
>> I wonder if we could do something involving recording the
>> rinfo_serial numbers of all the clauses extracted from a particular
>> syntactic join level (we could keep this in a bitmapset attached
>> to each SpecialJoinInfo,
On Thu, May 25, 2023 at 06:34:20PM +0100, Dagfinn Ilmari Mannsåker wrote:
> However, none of the other functions in ::Utils know anything about node
> objects, which makes me think it should be a method on the node itself
> (i.e. in PostgreSQL::Test::Cluster) instead. Also, I think log_contains
>
On Mon, May 22, 2023 at 10:59 AM Peter Geoghegan wrote:
> Attached is v2, which does it that way. It also adjusts the approach
> taken to release locks and pins when the left sibling validation check
> fails.
I pushed this just now, backpatching all the way.
> Not including a revised amcheck pat
On Thu, May 25, 2023 at 10:27:02AM +0200, Daniel Gustafsson wrote:
> There are still RHEL7 animals like chub who use 1.0.2 so I'm not worried. We
> might want to consider displaying the OpenSSL version number during configure
> (meson already does it) in all branches to make it easier to figure ou
On Mon, 2023-05-22 at 14:34 +0200, Peter Eisentraut wrote:
> Please put blank lines between
>
>
>
>
> etc., matching existing style.
>
> We usually don't capitalize the collation parameters like
>
> CREATE COLLATION mycollation1 (PROVIDER = icu, LOCALE = 'ja-JP);
>
> elsewhere in the documen
At Thu, 25 May 2023 23:51:18 +0900, torikoshia
wrote in
> Updated patches according to your comment.
+ printf(_(" -x --strip-extension=EXTclean up files if they have
this extension\n"));
Perhaps a comma is needed after "-x". The apparent inconsistency
between the long name and the
On 5/25/23 3:27 PM, Jacob Champion wrote:
On Thu, May 25, 2023 at 10:48 AM Jonathan S. Katz wrote:
Overall, +1 to tightening the language around the docs in this area.
However, to paraphrase Stephen, I think the language, as currently
written, makes the problem sound scarier than it actually i
Commit 61b313e4, which prepared index access method code for the
logical decoding on standbys work, made quite a few mechanical
changes. Many routines were revised in order to make sure that heaprel
was available in _bt_getbuf()'s P_NEW (new page allocation) path. But
this went further than it real
On Thu, May 25, 2023 at 10:16:27AM +0200, Daniel Gustafsson wrote:
> -#ifdef HAVE_BE_TLS_GET_CERTIFICATE_HASH
> +#ifdef USE_OPENSSL
> Since this is only calling the pgtls abstraction API and not directly into the
> SSL implementation we should use USE_SSL here instead. Same for the
> corresponding
On Fri, May 26, 2023 at 10:07:48AM +0900, Kyotaro Horiguchi wrote:
> + if (!IsXLogFileName(walfile) &&
> !IsPartialXLogFileName(walfile) &&
> + (!cleanBackupHistory ||
> !IsBackupHistoryFileName(walfile)))
> + continue;
>
On Thu, May 25, 2023 at 11:51:18PM +0900, torikoshia wrote:
> Updated patches according to your comment.
- ok(!-f "$tempdir/$walfiles[1]",
- "$test_name: second older WAL file was cleaned up");
- ok(-f "$tempdir/$walfiles[2]",
+ ok(!-f "$tempdir/@$walfiles[1]",
+ "$test_name: sec
51 matches
Mail list logo
