On Wed, Oct 27, 2021 at 3:18 AM Bossart, Nathan wrote:
>
> On 10/26/21, 2:04 PM, "Jeff Davis" wrote:
> > Should we just add a builtin function pg_checkpoint(), and deprecate
> > the syntax?
>
> That seems reasonable to me.
IMHO, moving away from SQL command "CHECKPOINT" to function
"pg_checkpoin
Hi all,
While reviewing the code for opclass parameters with indexes, I have
noticed that opclass parameters are lost after a concurrent reindex.
As we use a IndexInfo to hold the information of the new index when
creating a copy of the old one, it is just a matter of making sure
that ii_OpclassOp
On Sat, Oct 23, 2021 at 11:10 PM Bharath Rupireddy
wrote:
>
> On Fri, Oct 22, 2021 at 9:26 PM Justin Pryzby wrote:
> > I concluded that it's better to add a function to list metadata of an
> > arbitrary
> > dir, rather than adding more functions to handle specific, hardcoded dirs:
> > https://ww
On Sat, Oct 30, 2021 at 1:28 AM Michael Paquier wrote:
> Hi all,
>
> While reviewing the code for opclass parameters with indexes, I have
> noticed that opclass parameters are lost after a concurrent reindex.
> As we use a IndexInfo to hold the information of the new index when
> creating a copy
On Sat, Oct 30, 2021 at 3:59 AM Zhihong Yu wrote:
>
>
> On Sat, Oct 30, 2021 at 1:28 AM Michael Paquier
> wrote:
>
>> Hi all,
>>
>> While reviewing the code for opclass parameters with indexes, I have
>> noticed that opclass parameters are lost after a concurrent reindex.
>> As we use a IndexInf
On Sat, Oct 30, 2021 at 04:11:06AM -0700, Zhihong Yu wrote:
> Should datumCopy() be used inside the loop ? I saw the following
> in get_attoptions(Oid relid, int16 attnum):
Yeah, you are right that it would be better here to use
get_attoptions() to grab a copy of each attribute's option directly
f
Kevin Burke writes:
> I've been trying to run the SSL tests against my branch and that was
> tougher than expected because I didn't realize that additional output was
> being saved that I couldn't see - it wasn't even getting to the part where
> it could run the tests. This patch adds a note to th
I probably would not have looked there honestly; I was working in the
terminal and had the source code right there. Could we put a link to that
page in the README?
"For more information on Postgres's TAP tests, see the docs:
https://www.postgresql.org/docs/devel/regress-tap.html";
Kevin
On Sat,
Kevin Burke writes:
> I probably would not have looked there honestly; I was working in the
> terminal and had the source code right there.
Yeah, that was kind of what I thought.
> "For more information on Postgres's TAP tests, see the docs:
> https://www.postgresql.org/docs/devel/regress-tap.ht
On Sat, 2021-10-30 at 13:24 +0530, Bharath Rupireddy wrote:
> IMHO, moving away from SQL command "CHECKPOINT" to function
> "pg_checkpoint()" isn't nice as the SQL command has been there for a
> long time and all the applications or services that were/are being
> built around the postgres ecosystem
> On 30 Oct 2021, at 20:12, Tom Lane wrote:
> I'd be inclined to add just one sentence to the boilerplate text these use,
> along the lines of
> "If the tests fail, examining the logs left behind in tmp_check/log/
> may be helpful."
Wouldn't it make more sense to start collecting troubleshoo
On Fri, Oct 29, 2021 at 10:40:06AM +, Joel Mariadasan (jomariad) wrote:
> Hi,
>
> The scanning tool used by our organization has detected the presence of
> vulnerable libxml version in the latest Postgres 13.4 release for windows
> (Zip version).
>
> Detected by Automated Scanning tool:
> l
Daniel Gustafsson writes:
> Wouldn't it make more sense to start collecting troubleshooting advice in
> src/test/perl/README and instead refer to that in the boilerplate? I notice
> that we don't document for example PG_TEST_NOCLEAN anywhere (which admittedly
> is my fault), a trubleshooting sect
Hi,
Due to bug #17245: [1] I spent a considerably amount of time looking at vacuum
related code. And I found a few things that I think could stand improvement:
- There's pretty much no tests. This is way way too complicated feature for
that. If there had been tests for the obvious edge case of
On 2021-Oct-30, Jeff Davis wrote:
> I tend to agree with all of this. The CHECKPOINT command is already
> there and people already use it. If we are already chipping away at the
> need for superuser elsewhere, we should offer a way to use CHECKPOINT
> without being superuser.
+1
> If the purpose
On 10/30/21, 11:14 AM, "Jeff Davis" wrote:
> On Sat, 2021-10-30 at 13:24 +0530, Bharath Rupireddy wrote:
>> IMHO, moving away from SQL command "CHECKPOINT" to function
>> "pg_checkpoint()" isn't nice as the SQL command has been there for a
>> long time and all the applications or services that wer
16 matches
Mail list logo
