On Wed, Sep 11, 2024 at 06:21:37PM +0900, Michael Paquier wrote:
>> If gxact1's local xid is not frozen, the startup process will remove
>> the orphaned 2pc file. However, if the xid's corresponding clog file is
>> truncated by `vacuum`, the startup process will raise error 'could not
>> access s
Hi,
On Mon, Jul 8, 2024 at 7:08 PM Junwang Zhao wrote:
> On Mon, Jul 8, 2024 at 3:22 PM Nitin Jadhav
> wrote:
> >
> > In [1], Andres reported a -Wuse-after-free bug in the
> > ATExecAttachPartition() function. I've created a patch to address it
> > with pointers from Amit offlist.
> >
> > The i
On Tue, 01 Oct 2024 10:33:50 +0900 (JST)
Tatsuo Ishii wrote:
> >> That's because non-breaking space (nbsp) is not encoded as 0xa0 in
> >> UTF-8. nbsp in UTF-8 is "0xc2 0xa0" (2 bytes) (A 0xa0 is a nbsp's code
> >> point in Unicode. i.e. U+00A0).
> >> So grep -P "[\xC2\xA0]" should work to detect
On 01.10.24 06:27, Hunaid Sohail wrote:
> There are two users in the conninfo+: 'session' and 'authenticated'.
> Both are documented.
Right. I meant "Session User"
> Authenticated User: The name of the user returned by PQuser()
> Session User: The session user's name.
Thanks
--
Jim
Hi Jian,
On Mon, Sep 30, 2024 at 11:13 PM jian he wrote:
>
> On Mon, Sep 30, 2024 at 1:01 PM Junwang Zhao wrote:
> >
> > > I would suggest accepting:
> > > asc
> > > desc
> > > asc nulls first
> > > asc nulls last *
> > > desc nulls first *
> > > desc nulls last
> > >
> > > As valid inputs for "
Hi,
On Mon, Sep 30, 2024 at 11:16 PM Jim Jones
wrote:
> On 26.09.24 09:15, Hunaid Sohail wrote:
> > This patch renames "Current User" to "Authenticated User" as suggested
> > by me in my last email. I have also updated the documentation
> accordingly.
>
> Could you perhaps in the documentation e
On Tue, Oct 1, 2024 at 9:48 AM shveta malik wrote:
>
I have started reviewing patch002, it is WIP, but please find initial
set of comments:
1.
ExecSimpleRelationInsert():
+ /* Check for conflict and return to caller for resolution if found */
+ if (resolver != CR_ERROR &&
+ has_conflicting_tuple
On Mon, Sep 30, 2024 at 2:55 PM Peter Smith wrote:
>
> On Mon, Sep 30, 2024 at 4:29 PM shveta malik wrote:
> >
> > On Mon, Sep 30, 2024 at 11:04 AM Peter Smith wrote:
> > >
> > > On Mon, Sep 30, 2024 at 2:27 PM shveta malik
> > > wrote:
> > > >
> > > > On Fri, Sep 27, 2024 at 1:00 PM Peter Smi
> On Mon, 30 Sep 2024 17:23:24 +0900 (JST)
> Tatsuo Ishii wrote:
>
>> >> I think there's an unnecessary underscore in config.sgml.
>> >> Attached patch fixes it.
>> >
>> > I could not apply the patch with an error.
>> >
>> > error: patch failed: doc/src/sgml/config.sgml:9380
>> > error: doc/s
On Mon, Sep 30, 2024 at 10:07:55AM +0900, Michael Paquier wrote:
> The first point is just some prevention for the future. The second
> case is something we should fix and test. I am attaching a patch that
> addresses both. Note that the test case cannot use a transaction
> block as query IDs ar
>> That's because non-breaking space (nbsp) is not encoded as 0xa0 in
>> UTF-8. nbsp in UTF-8 is "0xc2 0xa0" (2 bytes) (A 0xa0 is a nbsp's code
>> point in Unicode. i.e. U+00A0).
>> So grep -P "[\xC2\xA0]" should work to detect nbsp.
>
> `LC_ALL=C grep -P "\xC2\xA0"` works for my environment.
> (
On 30/09/2024 17.29, Daniel Gustafsson wrote:
On 30 Sep 2024, at 16:55, Tom Lane wrote:
TBH I'm not finding anything very much wrong with the current
behavior... this has to be a rare situation, do we need to add
debatable behavior to make it easier?
One argument would be to make the checks
On Mon, Sep 30, 2024 at 6:38 AM Antonin Houska wrote:
>
> Jacob Champion wrote:
>
> > On Fri, Sep 27, 2024 at 10:58 AM Antonin Houska wrote:
> > That's why people are so pedantic about saying that OAuth is an
> > authorization framework and not an authentication framework.
>
> This statement alo
"Daniel Verite" writes:
> [ v6-0001-Support-backslash-dot-on-a-line-by-itself-as-vali.patch ]
I did some more work on the docs and comments, and pushed that.
Returning to my upthread thought that
>>> I think we should fix it so that \. that's not alone on a line
>>> throws an error, but I would
Hi,
On Mon, Sep 30, 2024 at 11:21:30PM +0200, Daniel Gustafsson wrote:
> > Yeah, I think a view like pg_stat_progress_checksums would work.
>
> Added in the attached version. It probably needs some polish (the docs for
> sure do) but it's at least a start.
Just a nitpick, but we call it data_ch
Daniel Gustafsson writes:
>> On 30 Sep 2024, at 16:55, Tom Lane wrote:
>> TBH I'm not finding anything very much wrong with the current
>> behavior... this has to be a rare situation, do we need to add
>> debatable behavior to make it easier?
> One argument would be to make the checks consistent
Robert Haas writes:
> On Mon, Sep 30, 2024 at 11:31 AM Tom Lane wrote:
>> WFM, modulo the suggestion about changing data types.
> I would prefer not to make the data type change here because it has
> quite a few tentacles.
I see your point for the function's "len" argument, but perhaps it's
wor
> On 30 Sep 2024, at 17:43, Tom Lane wrote:
>
> Nathan Bossart writes:
>> On Mon, Sep 30, 2024 at 04:13:55PM +0200, Daniel Gustafsson wrote:
>>> I'm not a native speaker so I'm not sure which is right, but grepping for
>>> other
>>> lists of items shows that the last "and" item is often precede
Robert Haas writes:
> On Mon, Sep 30, 2024 at 11:24 AM Tom Lane wrote:
>> Um, wait ... we do have strtou64(), so you should use that.
> The thing we should be worried about is not how large a JSON blob
> might be, but rather how large any file that appears in the data
> directory might be. So ui
On 24/7/2024 15:22, Ashutosh Bapat wrote:
On Wed, Jul 24, 2024 at 9:42 AM Richard Guo wrote:
Is there a specific query that demonstrates benefits from this change?
I'm curious about scenarios where a partitionwise join runs slower
than a non-partitionwise join.
[1] provides a testcase where a
David Rowley писал(а) 2024-09-24 01:07:
On Tue, 24 Sept 2024 at 02:47, Vladlen Popolitov
wrote:
I agree, it is better to fix all them together. I also do not like
this
hack, it will be removed from the patch, if I check and change
all at once.
I think, it will take about 1 week to fix and tes
> On 30 Sep 2024, at 16:55, Tom Lane wrote:
> TBH I'm not finding anything very much wrong with the current
> behavior... this has to be a rare situation, do we need to add
> debatable behavior to make it easier?
One argument would be to make the checks consistent, pg_upgrade generally tries
to
On Mon, Sep 30, 2024 at 11:31 AM Tom Lane wrote:
> WFM, modulo the suggestion about changing data types.
I would prefer not to make the data type change here because it has
quite a few tentacles. If I change member_copy_control_data() then I
have to change astreamer_verify_content() which means c
On Mon, Sep 30, 2024 at 11:24 AM Tom Lane wrote:
> > This is just a string in a
> > JSON file that represents an integer which will hopefully turn out to
> > be the size of the file on disk. I guess I don't know what type I
> > should be using here. Most things in PostgreSQL use a type like uint32
Kirill Reshke writes:
> I happened to notice that `set_rel_pathlist` params, RelOptInfo *rel
> and RangeTblEntry *rte are
> unnecessary, because upon all usages,
> `rte=root->simple_rte_array[rti]` and
> `rel=root->simple_rel_array[rti]` holds. What's the point of providing
> the same information
I happened to notice that `set_rel_pathlist` params, RelOptInfo *rel
and RangeTblEntry *rte are
unnecessary, because upon all usages,
`rte=root->simple_rte_array[rti]` and
`rel=root->simple_rel_array[rti]` holds. What's the point of providing
the same information 3 times? Is it kept like that for e
Rebased.
Author: Noah Misch
Commit: Noah Misch
For inplace update, send nontransactional invalidations.
The inplace update survives ROLLBACK. The inval didn't, so another
backend's DDL could then update the row without incorporating the
inplace update. In the test
On Mon, Sep 30, 2024 at 10:49:17AM -0400, Andres Freund wrote:
> We also discussed the topic at
> https://postgr.es/m/20240925020022.c5.nmisch%40google.com
> > ... neither BM_SETTING_HINTS nor keeping bounce buffers looks like a bad
> > decision. From what I've heard so far of the performance eff
=?utf-8?Q?Micha=C5=82_K=C5=82eczek?= writes:
>> On 30 Sep 2024, at 14:14, Ashutosh Bapat
>> wrote:
>> It is difficult to understand the exact problem from your description.
>> Can you please provide EXPLAIN outputs showing the expected plan and
>> the unexpected plan; plans on the node where the
Artur Zakirov wrote:
> I've tested the patch and it seems it works as expected.
Thanks for looking at this!
> It seems it isn't necessary to handle "\." within
> "CopyAttributeOutCSV()" (file "src/backend/commands/copyto.c")
> anymore.
It's still useful to produce CSV data that can be s
"Daniel Westermann (DWE)" writes:
>> Taking a closer look, many of the other switches-requiring-an-argument
>> also just absorb "optarg" without checking its value till much later,
>> so I'm not sure how far we could move the needle by special-casing
>> --compress.
> My point was not so much abou
On Wed, Sep 25, 2024 at 03:46:27PM -0700, Masahiko Sawada wrote:
> On Wed, Sep 18, 2024 at 6:46 PM Noah Misch wrote:
> > On Tue, Sep 17, 2024 at 09:43:41PM -0700, Masahiko Sawada wrote:
> > > On Mon, Sep 16, 2024 at 9:24 AM Noah Misch wrote:
> > > > On Thu, Sep 12, 2024 at 03:42:48PM -0700, Masah
Hi,
Thanks for taking a look.
> On 30 Sep 2024, at 14:14, Ashutosh Bapat wrote:
>
> Hi Michal,
> It is difficult to understand the exact problem from your description.
> Can you please provide EXPLAIN outputs showing the expected plan and
> the unexpected plan; plans on the node where the query
On 2024/09/22 20:44, Nitin Jadhav wrote:
+
CheckpointStats.ckpt_slru_written,
+ (double)
CheckpointStats.ckpt_slru_written * 100 / NBuffers,
I don't think NBuffers represents the maximum number of SL
Hi
On 26.09.24 09:15, Hunaid Sohail wrote:
> This patch renames "Current User" to "Authenticated User" as suggested
> by me in my last email. I have also updated the documentation accordingly.
Could you perhaps in the documentation elaborate a bit more on the
difference between "Current User" and
>I wrote:
>> As this example shows, we really ought to validate the compression
>> argument on sight in order to get sensible error messages. The
>> trouble is that for server-side compression the code wants to just
>> pass the string through to the server and not form its own opinion
>> as to whe
On Sat, 2024-09-28 at 00:04 +1200, David Rowley wrote:
> On Fri, 27 Sept 2024 at 20:42, Laurenz Albe wrote:
> > 2. The "disabled nodes" are not only shown at the nodes where nodes
> >were actually disabled, but also at every nodes above these nodes.
>
> I'm also not a fan either and I'd like
I wrote:
> As this example shows, we really ought to validate the compression
> argument on sight in order to get sensible error messages. The
> trouble is that for server-side compression the code wants to just
> pass the string through to the server and not form its own opinion
> as to whether i
On 2024/09/30 16:00, Anton A. Melnikov wrote:
On 30.09.2024 06:26, Fujii Masao wrote:
Thanks for the review! I've pushed the 0001 patch.
Thanks a lot!
As for switching in the pg_proc.dat entries the idea was to put them in order
so that the pg_stat_get_checkpointer* functions were groupe
I am just contacting you to talk about a current issue with our database.
We have run out of a positive sequence in one of our tables and are now
operating with negative sequences. To address this, we plan to migrate from
the int4 ID column to an int8 ID column.
The plan involves renaming the int8
Antonin Houska wrote:
> Jacob Champion wrote:
> > Now, the token introspection endpoint I mentioned upthread
>
> Can you please point me to the particular message?
Please ignore this dumb question. You probably referred to the email I was
responding to.
--
Antonin Houska
Web: https://www.cyb
"Daniel Westermann (DWE)" writes:
> shouldn't this give the same error message?
> $ pg_basebackup --checkpoint=fast --format=t --compress
> --pgdata=/var/tmp/dummy
> pg_basebackup: error: must specify output directory or backup target
> pg_basebackup: hint: Try "pg_basebackup --help" for more in
On 2024/09/30 20:10, Daniel Westermann (DWE) wrote:
Hi,
shouldn't this give the same error message?
$ pg_basebackup --checkpoint=fast --format=t --compress --pgdata=/var/tmp/dummy
pg_basebackup: error: must specify output directory or backup target
pg_basebackup: hint: Try "pg_basebackup --h
btsugieyuusuke writes:
>> Therefore, shouldn't “f:” and “w:” be removed?
Looks like that to me too. Pushed.
regards, tom lane
On Mon, 30 Sept 2024 at 16:49, Andres Freund wrote:
> On 2024-09-17 11:08:19 -0700, Noah Misch wrote:
> > > - I am worried about the need for bounce buffers for writes of checksummed
> > > buffers. That quickly ends up being a significant chunk of memory,
> > > particularly when using a small
On 2024-09-30 Mo 11:11 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 2024-09-30 Mo 10:08 AM, Tom Lane wrote:
Not entirely ... if fairywren had been generating that warning all
along, I would have noticed it long ago, because I periodically
scrape the BF database for compiler warnings. There
Nathan Bossart writes:
> On Mon, Sep 30, 2024 at 04:13:55PM +0200, Daniel Gustafsson wrote:
>> I'm not a native speaker so I'm not sure which is right, but grepping for
>> other
>> lists of items shows that the last "and" item is often preceded by a comma so
>> I'll do that.
> I'm not aware of a
On 2024/09/26 21:57, torikoshia wrote:
Updated the patches.
Thanks for updating the patches! I’ve made some changes based on your work,
which are attached.
Barring any objections, I'm thinking to push these patches.
For patches 0001 and 0003, I ran pgindent and updated the commit message.
Robert Haas writes:
> On Sun, Sep 29, 2024 at 1:03 PM Tom Lane wrote:
>>> CID 1620458: Resource leaks (RESOURCE_LEAK)
>>> Variable "buffer" going out of scope leaks the storage it points to.
> This looks like a real leak. It can only happen once per tarfile when
> verifying a tar backup so it
Robert Haas writes:
> On Sat, Sep 28, 2024 at 6:59 PM Tom Lane wrote:
>> Now, manifest_file.size is in fact a size_t, so %zu is the correct
>> format spec for it. But astreamer_verify.checksum_bytes is declared
>> uint64. This leads me to question whether size_t was the correct
>> choice for ma
PREPARE test_prepare_pgss1(int, int) AS select generate_series($1, $2);
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
EXECUTE test_prepare_pgss1 (1,2);
EXECUTE test_prepare_pgss1 (1,3);
SELECT toplevel, calls, query, queryid, rows FROM pg_stat_statements
ORDER BY query COLLATE "C", toplevel;
On Sun, Sep 29, 2024 at 1:03 PM Tom Lane wrote:
> *** CID 1620458: Resource leaks (RESOURCE_LEAK)
> /srv/coverity/git/pgsql-git/postgresql/src/bin/pg_verifybackup/pg_verifybackup.c:
> 1025 in verify_tar_file()
> 1019relpath);
> 1020
>
On Mon, Sep 30, 2024 at 1:01 PM Junwang Zhao wrote:
>
> > I would suggest accepting:
> > asc
> > desc
> > asc nulls first
> > asc nulls last *
> > desc nulls first *
> > desc nulls last
> >
> > As valid inputs for "dir" - and that the starred options are the defaults
> > when null position is omi
Maxim Orlov writes:
> But for the second one: do we really need any lock for temp relations?
Yes. Our implementation restrictions preclude access to the contents
of another session's temp tables, but it is not forbidden to do DDL
on them so long as no content access is required. (Without this,
Andrew Dunstan writes:
> On 2024-09-30 Mo 10:08 AM, Tom Lane wrote:
>> Not entirely ... if fairywren had been generating that warning all
>> along, I would have noticed it long ago, because I periodically
>> scrape the BF database for compiler warnings. There has to have
>> been some recent chang
On Sat, Sep 28, 2024 at 6:59 PM Tom Lane wrote:
> Now, manifest_file.size is in fact a size_t, so %zu is the correct
> format spec for it. But astreamer_verify.checksum_bytes is declared
> uint64. This leads me to question whether size_t was the correct
> choice for manifest_file.size. If it is
On 2024-09-30 Mo 10:08 AM, Tom Lane wrote:
Andrew Dunstan writes:
Ah, so this is because gcc 14.1.0 treats this as an error but gcc 12.2.0
treats it as a warning. Now it makes sense.
Not entirely ... if fairywren had been generating that warning all
along, I would have noticed it long ago, b
Nathan Bossart writes:
> Should we have pg_upgrade skip invalid databases? If the only valid action
> is to drop them, IMHO it seems unnecessary to require users to manually
> drop them before retrying pg_upgrade.
I was thinking the same. But I wonder if there is any chance of
losing data that
Hi!
Working with temp relations is some kind of bottleneck in Postgres, in my
view.
There are no problems if you want to handle it from time to time, not
arguing
that. But if you have to make a massive temp tables creation/deletion,
you'll
soon step into a performance degradation.
To the best of
Hi,
On 2024-09-17 11:08:19 -0700, Noah Misch wrote:
> > - I am worried about the need for bounce buffers for writes of checksummed
> > buffers. That quickly ends up being a significant chunk of memory,
> > particularly when using a small shared_buffers with a higher than default
> > number o
On Mon, 30 Sep 2024 20:07:31 +0900 (JST)
Tatsuo Ishii wrote:
> >> I wonder if it would be worth to add a check for this like we have to tabs?
>
> +1.
>
> >> The attached adds a rule to "make -C doc/src/sgml check" for trapping nbsp
> >> (doing so made me realize we don't have an equivalent meso
On Mon, Sep 30, 2024 at 04:13:55PM +0200, Daniel Gustafsson wrote:
>> On 30 Sep 2024, at 12:38, Yugo Nagata wrote:
>>
>> Should we put a comma between REINDEX and "and" as following?
>>
>> "... MATERIALIZED VIEW, REINDEX, and LOCK TABLE on all relations."
>
> I'm not a native speaker so I'm not
> On 30 Sep 2024, at 12:38, Yugo Nagata wrote:
>
> On Mon, 30 Sep 2024 11:40:29 +0200
> Daniel Gustafsson wrote:
>
>> - * MATERIALIZED VIEW, and REINDEX on all relations.
>> + * MATERIALIZED VIEW, REINDEX and LOCK TABLE on all relations.
>
> Should we put a comma between REINDEX and "and" as f
On Sun, Sep 29, 2024 at 08:45:50PM -0400, Thomas Krennwallner wrote:
> if a cluster contains invalid databases that we cannot connect to anymore,
> pg_upgrade would currently fail when trying to connect to the first
> encountered invalid database with
>
> [...]
>
> If there is more than one inval
Andrew Dunstan writes:
> Ah, so this is because gcc 14.1.0 treats this as an error but gcc 12.2.0
> treats it as a warning. Now it makes sense.
Not entirely ... if fairywren had been generating that warning all
along, I would have noticed it long ago, because I periodically
scrape the BF databas
On Fri, Sep 27, 2024 at 12:03 PM Dagfinn Ilmari Mannsåker
wrote:
> It might also be worth mentioning cloudy block storage (e.g. AWS' EBS),
> which is typically backed by SSDs, but has extra network latency.
>
That seems a little too in the weeds for me, but wording suggestions are
welcome. To ge
Jacob Champion wrote:
> On Fri, Sep 27, 2024 at 10:58 AM Antonin Houska wrote:
> > Have you considered sending the token for validation to the server, like
> > this
> >
> > curl -X GET "https://www.googleapis.com/oauth2/v3/userinfo"; -H
> > "Authorization: Bearer $TOKEN"
>
> In short, no, but
On 2024-09-29 Su 6:28 PM, Thomas Munro wrote:
Just an idea...
--- a/src/include/port/win32.h
+++ b/src/include/port/win32.h
@@ -16,7 +16,7 @@
* get support for GetLocaleInfoEx() with locales. For everything else
* the minimum version is Windows XP (0x0501).
*/
-#if defined(_MSC_VER) &
Hi Michal,
It is difficult to understand the exact problem from your description.
Can you please provide EXPLAIN outputs showing the expected plan and
the unexpected plan; plans on the node where the query is run and
where the partitions are located.
On Mon, Sep 30, 2024 at 12:19 AM Michał Kłeczek
On 2024-09-28 10:48, Jian he wrote:
Thanks for your comments!
+/*
+ * Extract REJECT_LIMIT value from a DefElem.
+ */
+static int64
+defGetCopyRejectLimitOptions(DefElem *def)
+{
+ int64 reject_limit;
+
+ if (def->arg == NULL)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("REJECT_
> 2.
> Similarly with above, the relcache won't be invalidated when ALTER
> PUBLICATION
> OWNER TO is executed. This means that privilage checks may be ignored if the
> entry
> is still valid. Not sure, but is there a possibility this causes an
> inconsistency?
Hmm, IIUC, the attribute pubowner i
On 2024-09-30 Mo 7:00 AM, Alexander Lakhin wrote:
Hello Andrew and Thomas,
29.09.2024 18:47, Andrew Dunstan пишет:
I'm inclined to think we might need to reverse the order of the last
two. TBH I don't really understand how this has worked up to now.
I've looked at the last successful ru
Hi,
shouldn't this give the same error message?
$ pg_basebackup --checkpoint=fast --format=t --compress --pgdata=/var/tmp/dummy
pg_basebackup: error: must specify output directory or backup target
pg_basebackup: hint: Try "pg_basebackup --help" for more information.
$ pg_basebackup --pgdata=/var
>> I wonder if it would be worth to add a check for this like we have to tabs?
+1.
>> The attached adds a rule to "make -C doc/src/sgml check" for trapping nbsp
>> (doing so made me realize we don't have an equivalent meson target).
>
> Your patch couldn't detect 0xA0 in config.sgml in my machin
Hello Andrew and Thomas,
29.09.2024 18:47, Andrew Dunstan пишет:
I'm inclined to think we might need to reverse the order of the last two. TBH I don't really understand how this has
worked up to now.
I've looked at the last successful run [1] and discovered that
fe-secure-common.c didn't c
I forgot to attach the patch file, so I'm attaching it in reply．
2024-09-30 15:02 に btsugieyuusuke さんは書きました:
Hi hackers,
I found probably something to fix in pg_walsummary.
pg_walsummary specifies “f:iqw:” as the third argument of
getopt_long().
/* process command-line options */
while ((c
On Mon, 30 Sep 2024 11:40:29 +0200
Daniel Gustafsson wrote:
> - * MATERIALIZED VIEW, and REINDEX on all relations.
> + * MATERIALIZED VIEW, REINDEX and LOCK TABLE on all relations.
Should we put a comma between REINDEX and "and" as following?
"... MATERIALIZED VIEW, REINDEX, and LOCK
On Mon, 30 Sep 2024 11:59:48 +0200
Daniel Gustafsson wrote:
> > On 30 Sep 2024, at 11:03, Tatsuo Ishii wrote:
> >
> I think there's an unnecessary underscore in config.sgml.
> >
> > I was wrong. The particular byte sequences just looked an underscore
> > on my editor but the byte sequence
Dear Shlok,
> I have addressed the comment for 0002 patch and attached the patches.
> Also, I have moved the tests in the 0002 to 0001 patch.
Thanks for updating the patch. 0002 patch seems to remove cache invalidations
from publication_invalidation_cb(). Related with it, I found an issue and had
Hello,
On 2024-Sep-27, Amit Langote wrote:
> On Fri, Sep 27, 2024 at 2:52 AM Alvaro Herrera
> wrote:
> > While studying a review note from Jian He on not-null constraints, I
> > came across some behavior introduced by commit 9139aa19423b[1] that I
> > think is mistaken.
> Yeah, I don’t quite r
> On 30 Sep 2024, at 11:03, Tatsuo Ishii wrote:
>
I think there's an unnecessary underscore in config.sgml.
>
> I was wrong. The particular byte sequences just looked an underscore
> on my editor but the byte sequence is actually 0xc2a0, which must be a
> "non breaking space" encoded in UTF
On 18/9/2024 17:48, Robert Haas wrote:
Comments?
Let me share my personal experience on path management in the planner.
The main thing important for extensions is flexibility - I would discuss
a decision that is not limited by join ordering but could be applied to
implement an index picking st
> On 30 Sep 2024, at 10:29, btsugieyuusuke
> wrote:
>
> Hi hackers,
> I found a flaw in the ACL_MAINTAIN comment.
>
> Commands such as VACUUM are listed as commands that are allowed to be
> executed by the MAINTAIN privilege.
> However, LOCK TABLE is missing from the comment.
>
>> /*
>> * Che
On Mon, 30 Sep 2024 18:03:44 +0900 (JST)
Tatsuo Ishii wrote:
> >>> I think there's an unnecessary underscore in config.sgml.
>
> I was wrong. The particular byte sequences just looked an underscore
> on my editor but the byte sequence is actually 0xc2a0, which must be a
> "non breaking space" en
On Mon, Sep 30, 2024 at 4:29 PM shveta malik wrote:
>
> On Mon, Sep 30, 2024 at 11:04 AM Peter Smith wrote:
> >
> > On Mon, Sep 30, 2024 at 2:27 PM shveta malik wrote:
> > >
> > > On Fri, Sep 27, 2024 at 1:00 PM Peter Smith wrote:
> > >
> > > > ~~~
> > > >
> > > > 14.
> > > > 99. General - orde
On Mon, Sep 30, 2024 at 9:01 AM Vinícius Abrahão
wrote:
> Greetings
>
> I understand the complexity of implementing a pseudo data type when
> passing it over parameters, or using it when creating an object.
> vide: git grep pseudo | egrep -v -e "po|out|sgml|sql" | more
>
> My initial problem was
On Mon, 30 Sep 2024 17:23:24 +0900 (JST)
Tatsuo Ishii wrote:
> >> I think there's an unnecessary underscore in config.sgml.
> >> Attached patch fixes it.
> >
> > I could not apply the patch with an error.
> >
> > error: patch failed: doc/src/sgml/config.sgml:9380
> > error: doc/src/sgml/confi
>>> I think there's an unnecessary underscore in config.sgml.
I was wrong. The particular byte sequences just looked an underscore
on my editor but the byte sequence is actually 0xc2a0, which must be a
"non breaking space" encoded in UTF-8. I guess someone mistakenly
insert a non breaking space wh
Hi Vignesh,
On Mon, Sep 23, 2024 at 10:49 PM vignesh C wrote:
>
> 3) In create publication column list/publish_generated_columns
> documentation we should mention that if generated column is mentioned
> in column list, generated columns mentioned in column list will be
> replication irrespective
Hi hackers,
I found a flaw in the ACL_MAINTAIN comment.
Commands such as VACUUM are listed as commands that are allowed to be
executed by the MAINTAIN privilege.
However, LOCK TABLE is missing from the comment.
/*
* Check if ACL_MAINTAIN is being checked and, if so, and not already
In, 0001-func.sgml-Consistently-use-optional-to-indicate-opti.patch
-format(formatstr
text [, formatarg
"any" [, ...] ])
+format(formatstr
text , formatarg
"any" [, ...] )
i change it further to
+format(formatstr
text , formatarg
"any" , ... )
i did these kind of change to format,
concat_ws, con
>> I think there's an unnecessary underscore in config.sgml.
>> Attached patch fixes it.
>
> I could not apply the patch with an error.
>
> error: patch failed: doc/src/sgml/config.sgml:9380
> error: doc/src/sgml/config.sgml: patch does not apply
Strange. I have no problem applying the patch h
Hi Tom
On 25.09.24 18:02, Tom Lane wrote:
> AFAICS, all we do with an embedded XML version string is pass it to
> libxml2's xmlNewDoc(), which is the authority on whether it means
> anything. I'd be inclined to do the same here.
Thanks. I used xml_is_document(), which calls xmlNewDoc(), to check
Greetings
I understand the complexity of implementing a pseudo data type when
passing it over parameters, or using it when creating an object.
vide: git grep pseudo | egrep -v -e "po|out|sgml|sql" | more
My initial problem was saving history (for backup to be used during
troubleshoot analysis) of
On Mon, 30 Sep 2024 15:34:04 +0900 (JST)
Tatsuo Ishii wrote:
> I think there's an unnecessary underscore in config.sgml.
> Attached patch fixes it.
I could not apply the patch with an error.
error: patch failed: doc/src/sgml/config.sgml:9380
error: doc/src/sgml/config.sgml: patch does not app
turns out I hardcoded some line number information,
which makes the script v7_split_func_sgml.py cannot apply anymore.
this time, it should be bullet-proof.
same as before:
step1. python3 v8_split_func_sgml.py
step2. git apply v8-0001-all-filelist-for-directory-doc-src-sgml-func.patch
(step2, can
Hi Shubham. Here are my review comment for patch v34-0002.
==
doc/src/sgml/ref/create_publication.sgml
1.
+
+ This parameter can only be set true if
copy_data is
+ set to false.
+
Huh? AFAIK the patch implements COPY for generated columns, so why are
you say
Thanks for responding.
> It is odd that the standby server crashes when
replication fails because the standby would keep retrying to get the
next record even in such case.
As I mentioned earlier, when replication fails, it retries to establish
streaming replication. At this point, the value
On Fri, Sep 27, 2024 at 2:33 PM shveta malik wrote:
>
> On Fri, Sep 27, 2024 at 10:44 AM shveta malik wrote:
> >
> > > >
> > > > Thanks for the review.
> > > > Here is the v14 patch-set fixing review comments in [1] and [2].
> > > >
> > >
> > > Thanks for the patches. I am reviewing patch001, it
On 30.09.2024 06:26, Fujii Masao wrote:
Thanks for the review! I've pushed the 0001 patch.
Thanks a lot!
As for switching in the pg_proc.dat entries the idea was to put them in order
so that the pg_stat_get_checkpointer* functions were grouped together.
I don't know if this is the common an
100 matches
Mail list logo
