On Mon, 2023-09-25 at 17:49 -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 2023-09-25 Mo 11:06, Andrew Dunstan wrote:
> > > On 2023-09-25 Mo 04:59, Laurenz Albe wrote:
> > > > CREATE TABLE boom (t character varying(5) DEFAULT 'a long string');
>
> > Thinking about this a little more, woul
On Thu, Aug 10, 2023 at 02:59:07PM +0900, Michael Paquier wrote:
> My apologies if I sounded unclear here. It seems to me that we should
> wrap the patch on [1] first, and get it backpatched. At least that
> makes for less conflicts when 0001 gets merged for HEAD when we are
> able to set a prope
> On 26 Sep 2023, at 00:20, Nathan Bossart wrote:
>
> On Thu, Sep 21, 2023 at 11:18:00AM +0900, bt23nguyent wrote:
>> -basic_archive_configured(ArchiveModuleState *state)
>> +basic_archive_configured(ArchiveModuleState *state, char **logdetail)
>
> Could we do something more like GUC_check_errde
Hello Hayato and Jian,
On Tue, 4 Jul 2023 01:30:56 +
"Hayato Kuroda (Fujitsu)" wrote:
> Dear Jian,
> > looks fine. Do you need to add to commitfest?
>
> Thank you for your confirmation. ! I registered to following:
>
> https://commitfest.postgresql.org/44/4437/
The way the Postgres com
On 20/7/2023 18:46, Tomas Vondra wrote:
2) estimating quicksort comparisons - This relies on ndistinct
estimates, and I'm not sure how much more reliable we can make those.
Probably not much :-( Not sure what to do about this, the only thing I
can think of is to track "reliability" of the estimat
Dear Michael,
> > 1. Your approach must be back-patched to older versions which support
> > logical
> >replication feature, but the oldest one (PG10) has already been
> unsupported.
> >We should not modify such a branch.
>
> This suggestion would be only for HEAD as it changes the behavi
On Mon, Sep 25, 2023 at 7:14 PM Ranier Vilela wrote:
>
> Em seg., 25 de set. de 2023 às 08:23, Ashutosh Bapat
> escreveu:
>>
>> On Sat, Sep 23, 2023 at 7:29 PM Ranier Vilela wrote:
>> >
>> > Hi,
>> >
>> > Per Coverity.
>> > CID 1518088 (#2 of 2): Improper use of negative value (NEGATIVE_RETURNS
On Wed, 20 Sept 2023 at 16:54, Amit Kapila wrote:
>
> On Fri, Sep 15, 2023 at 3:08 PM vignesh C wrote:
> >
> > The attached v8 version patch has the changes for the same.
> >
>
> Is the check to ensure remote_lsn is valid correct in function
> check_for_subscription_state()? How about the case wh
On Fri, 22 Sep 2023 10:12:29 +0900
Michael Paquier wrote:
> As of today, I can see that the only buildfarm members relying on
> these scripts are bowerbird and hamerkop, so these two would fail if
> the patch attached were to be applied today. I am adding Andrew
> D. and the maintainers of hamer
Dear Bharath,
Again, thank you for reviewing! PSA a new version.
>
> Here are some more comments/thoughts on the v44 patch:
>
> 1.
> +# pg_upgrade will fail because the slot still has unconsumed WAL records
> +command_fails(
> +[
>
> Add a test case to hit fprintf(script, "The slot \"%s\"
On Tue, 26 Sep 2023 08:18:01 +0900
Michael Paquier wrote:
> On Mon, Sep 25, 2023 at 11:07:57AM -0400, Andrew Dunstan wrote:
> > +1
>
> Thanks, applied and backpatched then.
Thank you!
Regards,
Yugo Nagata
> --
> Michael
--
Yugo NAGATA
On Wed, Aug 23, 2023 at 12:46:45PM +0200, Peter Eisentraut wrote:
> Apparently, the headerscheck and cpluspluscheck targets still didn't work
> right in the Cirrus jobs. Here is an updated patch to address that. This
> is also rebased over some recent changes that affected this patch (generated
>
On Monday, September 25, 2023 7:01 PM Kuroda, Hayato/黒田 隼人
wrote:
> To: 'Bharath Rupireddy'
> Cc: Amit Kapila ; Dilip Kumar
> >
> > 5. In continuation to the above comment:
> >
> > Why can't this logic be something like - if there's any WAL record
> > seen after a slot's confirmed flush LSN is o
Forgot to attach. Sorry.
On Mon, 25 Sep 2023 23:30:38 -0500
"Karl O. Pinc" wrote:
> Version 3.
>
> Re-do title, which is all of patch v3-003.
>
> On Mon, 25 Sep 2023 17:55:59 -0500
> "Karl O. Pinc" wrote:
>
> > On Mon, 25 Sep 2023 14:14:37 +0200
> > Daniel Gustafsson wrote:
>
> > > Once
Version 3.
Re-do title, which is all of patch v3-003.
On Mon, 25 Sep 2023 17:55:59 -0500
"Karl O. Pinc" wrote:
> On Mon, 25 Sep 2023 14:14:37 +0200
> Daniel Gustafsson wrote:
> > Once done you can do "git format-patch origin/master -v 1" which
> > will generate a set of n patches named v1-000
Hi,
In the regression test I see tests the one below [1], but generally,
jsonb_path_query is a SRF,
and the definition in pg_proc.dat has it as such [0], looking at the
implementation it doesn’t look like it calls jsonb_query_first behind the
scenes (say if it detects it’s being called in SELE
On Sun, Sep 24, 2023 at 10:42:49AM +0900, Michael Paquier wrote:
> Indeed, or Windows decides that making long 8-byte is wiser, but I
> doubt that's ever going to happen on backward-compatibility ground.
While looking more at that, I've noticed that I missed BufFileAppend()
and BufFileSeekBlock(),
On Mon, Sep 25, 2023 at 11:43 AM Michael Paquier wrote:
>
> On Mon, Sep 25, 2023 at 10:05:41AM +0530, Amit Kapila wrote:
> > I also don't think that this patch has to solve the problem of
> > publishers in any way but as per my understanding, if due to some
> > reason we are not able to do the upg
Hi, hackers
When I try to update unicode mapping tables using make update-unicode [1],
I encountered an error about following:
generate_unaccent_rules.py --unicode-data-file
../../src/common/unicode/UnicodeData.txt --latin-ascii-file Latin-ASCII.xml
>unaccent.rules
/bin/sh: 1: generate_unacce
On Tue, Sep 26, 2023 at 5:45 AM Tom Lane wrote:
> Hmm. This kind of makes me itch, because in principle a ressortgroupref
> identifier should uniquely identify a sorting/grouping column. If it
> fails to do so here, maybe there are outright bugs lurking elsewhere?
>
> I poked into it a little a
On Tue, 26 Sep 2023 at 06:20, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 25.09.23 08:02, Japin Li wrote:
>>> When I try to update the unicode mapping table through *.xml in
>>> src/backend/utils/mb/Unicode/, it doesn't update the *.map files.
>>> I find the make cannot go to this director
On Tue, 26 Sep 2023 at 05:58, Peter Eisentraut wrote:
> On 25.09.23 08:02, Japin Li wrote:
>> When I try to update the unicode mapping table through *.xml in
>> src/backend/utils/mb/Unicode/, it doesn't update the *.map files.
>> I find the make cannot go to this directory, what can I do to upda
>
> I've applied this down to v16 now, thanks for the submission!
>
Thanks for pushing!
Masaki Kuwamura
On Tue, Sep 26, 2023 at 7:16 AM Nathan Bossart wrote:
>
> On Thu, Sep 21, 2023 at 04:01:20PM +0530, Amit Kapila wrote:
> > The changes looks good to me, though I haven't tested it. But feel
> > free to commit if you are fine with this patch.
>
> Committed.
>
Thanks for pushing.
--
Kind Regar
On Mon, Sep 25, 2023 at 02:49:50PM +0900, Ryoga Yoshida wrote:
> On 2023-09-25 14:38, Michael Paquier wrote:
>> Another idea would be to do like in pgstat.c by adding the following
>> line, then use "nowait" to call each sub-function:
>> nowait = !force;
>> pgstat_flush_wal(nowait);
>> pgstat_flush
On Mon, Sep 25, 2023 at 11:07:57AM -0400, Andrew Dunstan wrote:
> +1
Thanks, applied and backpatched then.
--
Michael
signature.asc
Description: PGP signature
On Mon, 25 Sep 2023 14:14:37 +0200
Daniel Gustafsson wrote:
> > On 25 Sep 2023, at 14:00, Karl O. Pinc wrote:
>
> > Is there a preferred data format or should I send
> > each patch in a separate attachment with description?
> Once done you can do "git format-patch origin/master -v 1" which
On Mon, Sep 25, 2023 at 03:18:13AM +,
fujii.y...@df.mitsubishielectric.co.jp wrote:
> Hi Mr.Bruce, Mr.Pyhalov, Mr.Finnerty, hackers.
>
> Thank you for your valuable comments. I sincerely apologize for the very late
> reply.
> Here is a response to your comments or a fix to the patch.
>
> Tu
On Fri, Sep 15, 2023 at 02:25:38PM -0700, Yurii Rashkovskii wrote:
> Thank you for the feedback. I've updated the glossary and updated the
> terminology to be consistent. Please see the new patch attached.
Thanks for the new version of the patch.
This user owns all system catalog tables in
On Thu, Sep 21, 2023 at 11:18:00AM +0900, bt23nguyent wrote:
> -basic_archive_configured(ArchiveModuleState *state)
> +basic_archive_configured(ArchiveModuleState *state, char **logdetail)
Could we do something more like GUC_check_errdetail() instead to maintain
backward compatibility with v16?
-
Peter Eisentraut writes:
> On 25.09.23 08:02, Japin Li wrote:
>> When I try to update the unicode mapping table through *.xml in
>> src/backend/utils/mb/Unicode/, it doesn't update the *.map files.
>> I find the make cannot go to this directory, what can I do to update
>> the mapping tables?
> Th
On Fri, Sep 15, 2023 at 02:36:16PM -0700, Yurii Rashkovskii wrote:
> On Fri, Sep 15, 2023 at 1:47 PM Nathan Bossart
> wrote:
>> I think another issue is that the aforementioned note doesn't mention the
>> new SET option added in 3d14e17.
>
> How do you think we should word it in that note to make
On 25.09.23 08:02, Japin Li wrote:
When I try to update the unicode mapping table through *.xml in
src/backend/utils/mb/Unicode/, it doesn't update the *.map files.
I find the make cannot go to this directory, what can I do to update
the mapping tables?
This is done by "make update-unicode".
Andrew Dunstan writes:
> On 2023-09-25 Mo 11:06, Andrew Dunstan wrote:
>> On 2023-09-25 Mo 04:59, Laurenz Albe wrote:
>>> CREATE TABLE boom (t character varying(5) DEFAULT 'a long string');
> Thinking about this a little more, wouldn't it be better if we checked
> at the time we set the default
Richard Guo writes:
> I noticed a wrong comment in search_indexed_tlist_for_sortgroupref().
> /* The equal() check should be redundant, but let's be paranoid */
> It turns out that the equal() check is necessary, because the given
> sort/group expression might be type of FuncExpr which c
Hi,
On 2023-09-25 12:48:30 -0700, Andres Freund wrote:
> On 2023-09-25 15:42:26 -0400, Tom Lane wrote:
> > I just did a git bisect run to discover when the failure documented
> > in bug #18130 [1] started. And the answer is commit 82a4edabd.
> > Now, it's pretty obvious that that commit didn't in
On Mon, Sep 25, 2023 at 11:45 AM Robert Haas wrote:
> > The reason I was thinking of using the "lsn at the end of the last vacuum",
> > is
> > that it seems to be more adapative to the frequency of vacuuming.
>
> Yes, but I think it's *too* adaptive. The frequency of vacuuming can
> plausibly be
On Thu, Sep 21, 2023 at 04:01:20PM +0530, Amit Kapila wrote:
> The changes looks good to me, though I haven't tested it. But feel
> free to commit if you are fine with this patch.
Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On 25.09.23 21:20, Paul Jungwirth wrote:
On 9/24/23 21:52, jian he wrote:
On Wed, Sep 20, 2023 at 10:50 AM Paul Jungwirth
wrote:
On 9/17/23 20:11, jian he wrote:
small issues so far I found, v14.
Thank you again for the review! v15 is attached.
hi. some tiny issues.
Rebased v16 patche
On 2023-09-25 Mo 11:06, Andrew Dunstan wrote:
On 2023-09-25 Mo 04:59, Laurenz Albe wrote:
On Mon, 2023-09-25 at 09:54 +0200, Laurenz Albe wrote:
In v16 and later, the following fails:
CREATE TABLE boom (t character varying(5) DEFAULT 'a long string');
COPY boom FROM STDIN;
ERROR: value to
On Sat, Sep 23, 2023 at 3:53 PM Melanie Plageman
wrote:
> Freeze tuples on a page opportunistically if the page would be totally
> frozen and:
>
> 4. Buffer is already dirty and no FPI is required OR page LSN is older
> than 33% of the LSNs since the last vacuum of the table.
>
> 5. Buffer is a
On 9/25/23 14:03, Jeff Davis wrote:
On Mon, 2023-09-25 at 12:00 -0400, Joe Conway wrote:
Should there be a way to have a separate "execution" search_path?
I hadn't considered that and I like that idea for a few reasons:
* a lot of the problem cases are for functions that don't need to
acce
Hi,
On 2023-09-25 15:42:26 -0400, Tom Lane wrote:
> I just did a git bisect run to discover when the failure documented
> in bug #18130 [1] started. And the answer is commit 82a4edabd.
> Now, it's pretty obvious that that commit didn't in itself cause
> problems like this:
>
> postgres=# \copy t
Andres Freund writes:
> On 2023-09-06 18:01:53 -0400, Tom Lane wrote:
>> It turns out that this patch is what's making buildfarm member
>> chipmunk fail in contrib/pg_visibility [1]. That's easily reproduced
>> by running the test with shared_buffers = 10MB. I didn't dig further
>> than the "git
Hi,
On 2023-09-25 01:48:31 +0100, Peter Eisentraut wrote:
> I noticed that this patch set introduced this pg_dump test:
>
> On 12.07.23 03:59, Andres Freund wrote:
> > + 'CREATE DATABASE invalid...' => {
> > + create_order => 1,
> > + create_sql => q(CREATE DATABASE invalid;
On Fri, Sep 8, 2023 at 12:07 AM Andres Freund wrote:
> > Downthread, I proposed using the RedoRecPtr of the latest checkpoint
> > rather than the LSN of the previou vacuum. I still like that idea.
>
> Assuming that "downthread" references
> https://postgr.es/m/CA%2BTgmoYb670VcDFbekjn2YQOKF9a7e-kBF
On Mon, 2023-09-25 at 12:00 -0400, Joe Conway wrote:
> Should there be a way to have a separate "execution" search_path?
I hadn't considered that and I like that idea for a few reasons:
* a lot of the problem cases are for functions that don't need to
access tables at all, e.g., in an index exp
On Mon, 2023-09-25 at 11:30 -0400, Robert Haas wrote:
> On Fri, Sep 22, 2023 at 4:05 PM Jeff Davis wrote:
> > You expect
> > Bob to do something like:
> >
> > CREATE FUNCTION ... SET search_path = pg_catalog, pg_temp ...
> >
> > for all functions, not just SECURITY DEFINER functions, is that
>
On Wed, 20 Sept 2023 at 07:06, Michael Paquier wrote:
>
> On Tue, Sep 19, 2023 at 12:07:07PM +0200, Matthias van de Meent wrote:
> > V5 is a rebased version of v4, and includes the latest patch from
> > "smaller XLRec block header" [0] as 0001.
>
> 0001 and 0007 are the meat of the changes.
Corre
On Mon, Sep 25, 2023 at 12:00 PM Joe Conway wrote:
> Should there be a way to have a separate "execution" search_path?
I have heard that idea proposed before, and I don't think it's a
terrible idea, but I also don't think it fixes anything terribly
fundamental. I think it's pretty normal for peop
On Sat, Sep 23, 2023 at 4:22 PM Peter Geoghegan wrote:
> Attached draft patch shows how this could work.
>
> _bt_restore_array_keys() has comments that seem to suppose that
> calling _bt_preprocess_keys is fairly expensive, and something that's
> well worth avoiding. But...is it, really? I wonder
On Tue, 19 Sept 2023 at 01:03, Andres Freund wrote:
>
> Hi,
>
> On 2023-05-18 19:22:26 +0300, Heikki Linnakangas wrote:
> > On 18/05/2023 17:59, Matthias van de Meent wrote:
> > > It changes the block IDs used to fit in 6 bits, using the upper 2 bits
> > > of the block_id field to store how much d
On Sun, 2 Jul 2023 at 20:42, vignesh C wrote:
>
> Hi,
>
> Improved tab completion for "ALTER DEFAULT PRIVILEGE" and "ALTER TABLE":
> 1) GRANT, REVOKE and FOR USER keyword was not displayed in tab
> completion of alter default privileges like the below statement:
> ALTER DEFAULT PRIVILEGES GRANT IN
On Tue, 19 Sept 2023 at 22:49, Peter Geoghegan wrote:
>
> On Tue, Sep 19, 2023 at 6:28 AM Matthias van de Meent
> wrote:
> > > To be clear, page deletion does what I described here (it does an
> > > in-place update of the downlink to the deleted page, so the same pivot
> > > tuple now points to i
On 9/25/23 11:30, Robert Haas wrote:
I don't believe that people want to run their functions under a
sanitized search_path that only includes system schemas. That might
work for some people, but I think most people will define functions
that call other functions that they themselves defined, or a
jacktby jacktby writes:
> I find this in source code
> #define ShareLock 5 /* CREATE INDEX
> (WITHOUT CONCURRENTLY) */
> I think if there is no CONCURRENTLY, so why we need a lock, I think that’s
> unnecessary. What’s the point?
We need a lock precisely to prev
On Fri, Sep 22, 2023 at 4:05 PM Jeff Davis wrote:
> On Thu, 2023-09-21 at 14:06 -0400, Robert Haas wrote:
> > Also, in a case like this, I don't think it's unreasonable to ask
> > whether, perhaps, Bob just needs to be a little more careful about
> > setting search_path.
>
> That's what this whole
Daniel Gustafsson writes:
> On 25 Sep 2023, at 05:34, Japin Li wrote:
>> How about "See gram.h target's comment in src/backend/parser/Makefile"
>> or just "See src/backend/parser/Makefile"?
> The latter seems more stable, if the Makefile is ever restructured it's almost
> guaranteed that this co
On 2023-09-21 Th 21:12, Michael Paquier wrote:
As of today, I can see that the only buildfarm members relying on
these scripts are bowerbird and hamerkop, so these two would fail if
the patch attached were to be applied today. I am adding Andrew
D. and the maintainers of hamerkop (SRA-OSS) in
On 2023-09-25 Mo 03:14, Daniel Gustafsson wrote:
On 25 Sep 2023, at 08:58, Michael Paquier wrote:
I would say yes, but with a backpatch.
Agreed.
+1
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On 2023-09-25 Mo 04:59, Laurenz Albe wrote:
On Mon, 2023-09-25 at 09:54 +0200, Laurenz Albe wrote:
In v16 and later, the following fails:
CREATE TABLE boom (t character varying(5) DEFAULT 'a long string');
COPY boom FROM STDIN;
ERROR: value too long for type character varying(5)
In PostgreS
I find this in source code
#define ShareLock 5 /* CREATE INDEX
(WITHOUT CONCURRENTLY) */
I think if there is no CONCURRENTLY, so why we need a lock, I think that’s
unnecessary. What’s the point?
in doc/src/sgml/ref/alter_operator.sgml
HASHES
Indicates this operator can support a hash join. Can only be set
when the operator does not support a hash join.
MERGES
Indicates this operator can support a merge join. Can only be set
w
Hi,
On 9/25/23 10:44 AM, Drouvot, Bertrand wrote:
Hi,
On 9/23/23 3:38 AM, Amit Kapila wrote:
On Fri, Sep 22, 2023 at 6:01 PM Drouvot, Bertrand
wrote:
There is a difference here that we also need to prevent removal of
rows required by sync_slots. That could be achieved by physical slot
(and
> On 24 Sep 2023, at 10:22, Kuwamura Masaki
> wrote:
>
> LGTM too!
I've applied this down to v16 now, thanks for the submission!
--
Daniel Gustafsson
Dear Ajin, Shveta,
Thank you for rebasing the patch set! Here are new comments for v19_2-0001.
01. WalSndWaitForStandbyNeeded()
```
if (SlotIsPhysical(MyReplicationSlot))
return false;
```
Is there a possibility that physical walsenders call this function?
IIUC followin
On Mon, Sep 25, 2023 at 12:58 PM Pavel Borisov wrote:
> One more doubt about naming. Calling function
> _bt_checkkeys(IndexScanDesc scan, IndexTuple tuple, int tupnatts,
> ScanDirection dir, bool *continuescan, bool requiredMatchedByPrecheck)
> as
> (void) _bt_checkkeys(scan, itup, indnatts, dir,
Em seg., 25 de set. de 2023 às 08:23, Ashutosh Bapat <
ashutosh.bapat@gmail.com> escreveu:
> On Sat, Sep 23, 2023 at 7:29 PM Ranier Vilela wrote:
> >
> > Hi,
> >
> > Per Coverity.
> > CID 1518088 (#2 of 2): Improper use of negative value (NEGATIVE_RETURNS)
> >
> > The function bms_singleton_m
On Wed, Sep 6, 2023 at 11:20 PM Robert Haas wrote:
> On Wed, Sep 6, 2023 at 5:12 AM Amit Langote wrote:
> > Attached updated patches. Thanks for the review.
>
> I think 0001 looks ready to commit. I'm not sure that the commit
> message needs to mention future patches here, since this code cleanu
> On 25 Sep 2023, at 11:13, Alexander Korotkov wrote:
> I'd like to do a short summary of
> design issues on this thread.
Thanks for summarizing this long thread!
> the patch for the GUC option to disable
> all event triggers resides in a separate thread [4]. Apparently that
> patch should be c
> On 25 Sep 2023, at 09:52, Daniel Gustafsson wrote:
>
>> On 25 Sep 2023, at 09:50, Michael Paquier wrote:
>>
>> On Mon, Sep 25, 2023 at 09:19:35AM +0200, Daniel Gustafsson wrote:
>>> Fair enough, although I used "fire" instead of "run" which is consistent
>>> with
>>> the event trigger docume
> On 25 Sep 2023, at 14:00, Karl O. Pinc wrote:
> Is there a preferred data format or should I send
> each patch in a separate attachment with description?
The easiest way would be to create a patchset off of master I think. In a
branch, commit each change with an explanatory commit message. O
On Mon, 25 Sep 2023 09:26:38 +0200
Daniel Gustafsson wrote:
> > On 25 Sep 2023, at 00:57, Karl O. Pinc wrote:
>
> > I have made various, mostly unrelated to each other,
> > small improvements to the documentation.
> While I agree it's subjective, I don't think adding a new section or
> par
Hi,
I attached the second version of the patch.
On Mon, 11 Sept 2023 at 15:11, Daniel Gustafsson wrote:
>
> > On 11 Sep 2023, at 13:03, Nazir Bilal Yavuz wrote:
>
> >> Almost, but not entirely. There are a set of scripts which generate
> >> content
> >> for the docs based on files in src/, li
On Mon, Sep 25, 2023 at 1:23 PM Bharath Rupireddy
wrote:
>
> On Mon, Sep 25, 2023 at 12:32 PM Dilip Kumar wrote:
> >
> > > > Is there anything else that stops this patch from supporting migration
> > > > of logical replication slots from PG versions < 17?
> > >
> > > IMHO one of the main change w
On Sat, Sep 23, 2023 at 7:29 PM Ranier Vilela wrote:
>
> Hi,
>
> Per Coverity.
> CID 1518088 (#2 of 2): Improper use of negative value (NEGATIVE_RETURNS)
>
> The function bms_singleton_member can returns a negative number.
>
> /*
> * Get a child rel for rel2 with the relids. See above comments.
>
Dear Bharath,
Thank you for giving comments! Before addressing your comments,
I wanted to reply some of them.
> 4.
> +/*
> + * There is a possibility that following records may be generated
> + * during the upgrade.
> + */
> +is_valid = is_xlog_record_type(
/*
* AlterOperator
* routine implementing ALTER OPERATOR SET (option = ...).
*
* Currently, only RESTRICT and JOIN estimator functions can be changed.
*/
ObjectAddress
AlterOperator(AlterOperatorStmt *stmt)
The above comment needs to change, other than that, it passed the
test, works as expe
On 2023-09-25 15:27, torikoshia wrote:
On Tue, Sep 19, 2023 at 3:23 AM Greg Sabino Mullane
wrote:
Thanks for your investigation!
On Fri, Sep 15, 2023 at 11:11 AM torikoshia
wrote:
I do not intend to adhere to this rule(my terminals are usually
bigger
than 80 chars per line), but wouldn't it
Sorry, I've mistaken with attached version previously. Correct v5 attached.
On Mon, 25 Sept 2023 at 13:58, Pavel Borisov wrote:
>
> Hi, Alexander!
>
> I found and fixed a couple of naming issues that came to v4 from
> earlier patches.
> Also, I added initialization of requiredMatchedByPrecheck in
I noticed a wrong comment in search_indexed_tlist_for_sortgroupref().
foreach(lc, itlist->tlist)
{
TargetEntry *tle = (TargetEntry *) lfirst(lc);
/* The equal() check should be redundant, but let's be paranoid */
if (tle->ressortgroupref == sortgroupref &&
On 22/09/2023 23:52, Jeff Davis wrote:
src/backend/transam/README says:
...
4. Mark the shared buffer(s) as dirty with MarkBufferDirty(). (This
must happen before the WAL record is inserted; see notes in
SyncOneBuffer().)
...
But GenericXLogFinish() does this:
...
/* Ins
Hi, Alexander!
I found and fixed a couple of naming issues that came to v4 from
earlier patches.
Also, I added initialization of requiredMatchedByPrecheck in case of first page.
Please see patch v5.
One more doubt about naming. Calling function
_bt_checkkeys(IndexScanDesc scan, IndexTuple tuple,
On 25/9/2023 14:21, torikoshia wrote:
On 2023-09-20 14:39, Lepikhov Andrei wrote:
Hmm, as a test, I made sure to call ProcessLogQueryPlanInterrupt() on
all CFI using
v28-0002-Testing-attempt-logging-plan-on-ever-CFI-call.patch, and then
ran the following query but did not cause any problems.
Hi,
The current approach could be better because we want to use it on
Windows/MacOS and other systems. So, I've tried to develop another
strategy - detaching shmem and DSM blocks before executing the abort()
routine.
As I can see, it helps and reduces the size of the core file.
--
regards,
A
Hi!
On Wed, Jun 14, 2023 at 10:49 PM Mikhail Gribkov wrote:
> The attached v40 patch is a fresh rebase on master branch to actualize the
> state before the upcoming commitfest.
> Nothing has changed beyond rebasing.
>
> And just for convenience, here is a link to the exact message of the thread
On Mon, 2023-09-25 at 09:54 +0200, Laurenz Albe wrote:
> In v16 and later, the following fails:
>
> CREATE TABLE boom (t character varying(5) DEFAULT 'a long string');
>
> COPY boom FROM STDIN;
> ERROR: value too long for type character varying(5)
>
> In PostgreSQL v15 and earlier, the COPY sta
Hi Thomas,
I will check it today.
Regards
Nikola
On Sat, 23 Sept 2023 at 04:54, Thomas Munro wrote:
> I am not sure why REL_16_STABLE fails consistently as of ~4 days ago.
> It seems like bad storage or something? Just now it happened also on
> HEAD. I wonder why it would be sensitive to the
Hi,
On 9/23/23 3:38 AM, Amit Kapila wrote:
On Fri, Sep 22, 2023 at 6:01 PM Drouvot, Bertrand
wrote:
Thanks for all the work that has been done on this feature, and sorry
to have been quiet on it for so long.
On 9/18/23 12:22 PM, shveta malik wrote:
On Wed, Sep 13, 2023 at 4:48 PM Hayato Kur
On Mon, Sep 25, 2023 at 1:23 PM Bharath Rupireddy
wrote:
>
> On Mon, Sep 25, 2023 at 12:32 PM Dilip Kumar wrote:
> >
> > > > Is there anything else that stops this patch from supporting migration
> > > > of logical replication slots from PG versions < 17?
> > >
> > > IMHO one of the main change w
> On 4 Jul 2023, at 14:50, Daniel Gustafsson wrote:
>
>> On 4 Jul 2023, at 13:59, Heikki Linnakangas wrote:
>> On 08/03/2023 00:05, Daniel Gustafsson wrote:
>
>>> If we are going to continue using this for reading $stuff from pipes, maybe
>>> we
>>> should think about presenting a nicer API wh
In v16 and later, the following fails:
CREATE TABLE boom (t character varying(5) DEFAULT 'a long string');
COPY boom FROM STDIN;
ERROR: value too long for type character varying(5)
In PostgreSQL v15 and earlier, the COPY statement succeeds.
The error is thrown in BeginCopyFrom in line 1578 (HE
On Mon, Sep 25, 2023 at 12:32 PM Dilip Kumar wrote:
>
> > > Is there anything else that stops this patch from supporting migration
> > > of logical replication slots from PG versions < 17?
> >
> > IMHO one of the main change we are doing in PG 17 is that on shutdown
> > checkpoint we are ensuring
> On 25 Sep 2023, at 09:50, Michael Paquier wrote:
>
> On Mon, Sep 25, 2023 at 09:19:35AM +0200, Daniel Gustafsson wrote:
>> Fair enough, although I used "fire" instead of "run" which is consistent with
>> the event trigger documentation.
>
> Okay by me.
Great, I'll go ahead and apply this vers
On Mon, Sep 25, 2023 at 09:19:35AM +0200, Daniel Gustafsson wrote:
> Fair enough, although I used "fire" instead of "run" which is consistent with
> the event trigger documentation.
Okay by me.
--
Michael
signature.asc
Description: PGP signature
On Sat, Sep 23, 2023 at 10:18 AM Hayato Kuroda (Fujitsu)
wrote:
>
> Again, thank you for reviewing! Here is a new version patch.
Here are some more comments/thoughts on the v44 patch:
1.
+# pg_upgrade will fail because the slot still has unconsumed WAL records
+command_fails(
+[
Add a test
On Mon, 25 Sept 2023 at 00:32, vignesh C wrote:
>
> On Sat, 23 Sept 2023 at 11:28, Amit Kapila wrote:
> >
> > On Sat, Sep 23, 2023 at 1:27 AM vignesh C wrote:
> > >
> > >
> > > Fixed this issue by checking if the subscription owner has changed
> > > from superuser to non-superuser in case the pg
> On 25 Sep 2023, at 05:34, Japin Li wrote:
> Maybe be reference src/backend/parser/Makefile is better than current.
>
> How about "See gram.h target's comment in src/backend/parser/Makefile"
> or just "See src/backend/parser/Makefile"?
The latter seems more stable, if the Makefile is ever rest
> On 25 Sep 2023, at 00:57, Karl O. Pinc wrote:
> I have made various, mostly unrelated to each other,
> small improvements to the documentation. These
> are usually in the areas of plpgsql, schemas, and permissions.
> Most change 1 lines, but some supply short overviews.
>
> "Short" is subject
On 2023-09-20 14:39, Lepikhov Andrei wrote:
Thanks for your reply.
On Tue, Sep 19, 2023, at 8:39 PM, torikoshia wrote:
On 2023-09-15 15:21, Lepikhov Andrei wrote:
On Thu, Sep 7, 2023, at 1:09 PM, torikoshia wrote:
I have explored this patch and, by and large, agree with the code.
But
some qu
1 - 100 of 106 matches
Mail list logo
