On Tue, Jan 9, 2024 at 5:44 PM Zhijie Hou (Fujitsu)
wrote:
>
comments on 0002
1.
+/* Worker's nap time in case of regular activity on the primary server */
+#define WORKER_DEFAULT_NAPTIME_MS 10L /* 10 ms */
+
+/* Worker's nap time in case of no-activity on the primary server */
On Wed, Jan 10, 2024 at 01:29:30PM +0700, Andrei Lepikhov wrote:
> What do you think about this really useful feature? Do you wish to develop
> it further?
I am biased here. This seems like a lot of code for something we've
been delegating to the explain hook for ages. Even if I can see the
On Wed, Jan 10, 2024 at 01:25:36AM -0500, Tom Lane wrote:
> John Naylor writes:
>> Off the top of my head, I like to use '//' comments as quick notes to
>> myself that stand out from normal code comments, and I'm in the habit
>> of putting debug print statements flush against the left margin so
On 1/9/24 2:31 PM, Jeff Davis wrote:
> On Tue, 2024-01-09 at 14:17 -0800, Jeremy Schneider wrote:
>> I think we missed something in psql, pretty sure I applied all the
>> patches but I see this error:
>>
>> =# \l
>> ERROR: 42703: column d.datlocale does not exist
>> LINE 8: d.datlocale as
On Tue, Jan 9, 2024 at 11:36 PM torikoshia wrote:
>
> On Tue, Dec 19, 2023 at 10:14 AM Masahiko Sawada
> wrote:
> > If we want only such a feature we need to implement it together (the
> > patch could be split, though). But if some parts of the feature are
> > useful for users as well, I'd
On Wed, Jan 10, 2024 at 10:00 AM Tom Lane wrote:
>
> Michael Paquier writes:
> > This suggestion has showed up more than once in the past, and WAL
> > insertion is a path that can become so hot under some workloads that
> > changing it to a GUC would not be wise from the point of view of
> >
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 22 Dec 2023 10:58:05 +0800,
Junwang Zhao wrote:
>> 1. Add an opaque space for custom COPY TO handler
>>* Add CopyToState{Get,Set}Opaque()
>>
>>
Bharath Rupireddy writes:
> On Wed, Jan 10, 2024 at 12:54 PM Tom Lane wrote:
>> Yeah. I'm not quite sure what's a good way to make this work, but
>> it seems like having "make check-world" always invoke it would not
>> be desirable. Making that conditional on an environment variable
>> setting
On Tue, Apr 11, 2023 at 11:43 AM Andy Fan wrote:
> On Tue, Apr 11, 2023 at 11:03 AM Richard Guo
> wrote:
>
>> As the comment above add_path() says, 'The pathlist is kept sorted by
>> total_cost, with cheaper paths at the front.' And it seems that
>> get_cheapest_parallel_safe_total_inner()
On Wed, Jan 10, 2024 at 9:05 AM Masahiko Sawada wrote:
>
> I've done in 0010 patch in v51 patch set. Whereas RT_NODE_4 and
> RT_NODE_16 structs declaration needs RT_FANOUT_4_HI and
> RT_FANOUT_16_HI respectively, RT_FANOUT_16_LO and RT_FANOUT_48 need
> RT_NODE_16 and RT_NODE_48 structs
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Wed, 10 Jan 2024 15:33:22 +0900,
Masahiko Sawada wrote:
>> We can use the satic const struct approach by choosing one
>> of the followings:
>>
>> ...
>>
>> 4. ... other idea?
>
> It's a just idea but the
On Sun, Dec 31, 2023 at 09:37:31AM +0900, Michael Paquier wrote:
> On Fri, Dec 29, 2023 at 12:52:30PM +0100, Jelte Fennema-Nio wrote:
>> Those are some nice improvements. And I think once this patch is in,
>> it would make sense to add the pgbench feature you're suggesting.
>> Because indeed that
On 2024-01-03 20:40, Melih Mutlu wrote:
Hi,
Thanks for reviewing. Please find the updated patch attached.
torikoshia , 4 Ara 2023 Pzt, 07:43
tarihinde şunu yazdı:
I reviewed v3 patch and here are some minor comments:
+
+
+ path int4
Should 'int4' be 'int4[]'?
Other
On Wed, Jan 10, 2024 at 12:54 PM Tom Lane wrote:
>
> Michael Paquier writes:
> > On Wed, Jan 10, 2024 at 01:25:36AM -0500, Tom Lane wrote:
> >> So that leads to the conclusion that I wouldn't want an automatic
> >> pgindent check to happen during "make all" or "make check", because
> >> I want
On Wed, Jan 03, 2024 at 04:10:58PM +0300, Nazir Bilal Yavuz wrote:
> On Sun, 31 Dec 2023 at 03:58, Michael Paquier wrote:
>> Apologies if my previous wording sounded confusing. The idea I had in
>> mind was to keep op_bytes in pg_stat_io, and extend it so as a value
>> of NULL (or 0, or -1) is a
On Wed, Jan 10, 2024 at 12:00 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Fri, 22 Dec 2023 10:00:24 +0900,
> Michael Paquier wrote:
>
> >> 3. Export CopySend*()
> >>
> >>* If we like minimum API, we just need to
Bharath Rupireddy writes:
> On Wed, Jan 10, 2024 at 10:00 AM Tom Lane wrote:
>> Maybe. I bet just bumping up the constant by 2X or 4X or so would get
>> most of the win for far less work; it's not like adding a few more
>> LWLocks is expensive. But we need some evidence about what to set it
On Wed, Jan 10, 2024 at 2:20 AM Tristan Partin wrote:
>
> On Tue Jan 9, 2024 at 3:00 AM CST, John Naylor wrote:
> > I don't indent during most of development, and don't intend to start.
>
> Could you expand on why you don't? I could understand as you're writing,
> but I would think formatting on
John Naylor writes:
> Off the top of my head, I like to use '//' comments as quick notes to
> myself that stand out from normal code comments, and I'm in the habit
> of putting debug print statements flush against the left margin so
> they're really obvious. Both of these would be wiped out by
On Wed, Jan 10, 2024 at 3:40 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Wed, 10 Jan 2024 15:33:22 +0900,
> Masahiko Sawada wrote:
>
> >> We can use the satic const struct approach by choosing one
> >> of the
On 30/11/2023 22:40, Konstantin Knizhnik wrote:
In all this cases we are using array of `Instrumentation` and if it
contains varying part, then it is not clear where to place it.
Yes, there is also code which serialize and sends instrumentations
between worker processes and I have updated this
Michael Paquier writes:
> On Wed, Jan 10, 2024 at 01:25:36AM -0500, Tom Lane wrote:
>> So that leads to the conclusion that I wouldn't want an automatic
>> pgindent check to happen during "make all" or "make check", because
>> I want those things to succeed before I consider pgindent'ing.
>>
On Mon, 2024-01-08 at 18:43 +, Dean Rasheed wrote:
> I can see the appeal in this feature. However, as it stands, this
> isn't compatible with copy format json, and I think it would need to
> duplicate quite a lot of the JSON output code in client-side code to
> make it compatible.
>
>
On Tue, Jan 9, 2024 at 8:08 AM Alexander Korotkov wrote:
> On Tue, Jan 9, 2024 at 6:00 AM Alexander Lakhin wrote:
> > 09.01.2024 01:09, Alexander Korotkov wrote:
> > > Fixed in 30b4955a46.
> >
> > Thank you for fixing that!
> >
> > I've found another anomaly coined with d3d55ce57. This query:
>
Hi Laurenz, thanks for taking a look!
On Sat, Jan 6, 2024 at 4:00 AM Laurenz Albe wrote:
> While your original use case is valid, I cannot think of
> any other use case. So it is a special-purpose statement that is only
> useful for certain processing of append-only tables.
It is definitely
Peter Eisentraut writes:
> In 30e7c175b81, support for pre-9.2 servers was removed from pg_dump.
> But I found that a lot of dead code was left for supporting dumping
> triggers from those old versions, presumably because that code was not
> behind straightforward versioned "if" branches.
On Tue, Jan 09, 2024 at 09:20:09AM +0700, John Naylor wrote:
> On Tue, Jan 9, 2024 at 12:37 AM Nathan Bossart
> wrote:
>>
>> > I suspect that there could be a regression lurking for some inputs
>> > that the benchmark doesn't look at: pg_lfind32() currently needs to be
>> > able to read 4 vector
On Mon Jan 8, 2024 at 6:08 PM CST, Tom Lane wrote:
"Tristan Partin" writes:
> On Mon Jan 8, 2024 at 2:48 PM CST, Tom Lane wrote:
>> +(isascii((unsigned char)
mybuf.data[mybuf.len - 1]) &&
>> +
Hello, Melanie!
Sorry to interrupt you, just a quick question.
> Correct, but there are changes being discussed where we would freeze
> tuples during pruning as well [0], which would invalidate that
> implementation detail. And, if I had to choose between improved
> opportunistic freezing and
Hello Michael and Bertrand,
I'd also like to note that even with FREEZE added [1], I happened to see
the test failure:
5 # Failed test 'inactiveslot slot invalidation is logged with vacuum
on pg_class'
5 # at t/035_standby_logical_decoding.pl line 222.
5
5 # Failed test
I wrote:
> However, the patch looks a little incomplete: you did not remove
> fetching of all of the now-unneeded values from the SQL queries.
Oh, scratch that, I now see that we already did that query
optimization.
regards, tom lane
On 08.01.24 22:08, Nathan Bossart wrote:
I think these are reasonable concerns, but with this patch, we now have the
following functions:
pg_get_identity_sequence(table regclass, column name) -> regclass
pg_get_serial_sequence(table text, column text) -> text
If we only look at
On Mon, Jan 8, 2024 at 5:39 PM Tom Lane wrote:
> I think we're talking at cross-purposes. What I was wondering about
> (at least further down in the thread) was whether we shouldn't be
> checking *both* the "real" and the "parent" relids to make sure they
> don't overlap the parameterization
Robert Haas writes:
> On Mon, Jan 8, 2024 at 5:39 PM Tom Lane wrote:
>> I think we're talking at cross-purposes. What I was wondering about
>> (at least further down in the thread) was whether we shouldn't be
>> checking *both* the "real" and the "parent" relids to make sure they
>> don't
Peter Eisentraut writes:
> Would it work to change the signature of pg_get_serial_sequence to
> pg_get_serial_sequence(table anyelement, column text) -> anyelement
> and then check inside the function code whether text or regclass was passed?
Probably not very well, because then we'd get no
On Tue, 9 Jan 2024 at 16:03, Peter Eisentraut wrote:
> On 29.11.23 18:15, Nathan Bossart wrote:
> > Using the same benchmark as we did for the SSE2 linear searches in
> > XidInMVCCSnapshot() (commit 37a6e5d) [1] [2], I see the following:
> >
> >writerssse2avx2 %
> >256
On Mon, Jan 8, 2024 at 3:51 PM Robert Haas wrote:
>
> On Fri, Jan 5, 2024 at 3:34 PM Melanie Plageman
> wrote:
>
> This part of 0002 makes me very, very uncomfortable:
>
> + /*
> +* Update all line pointers per the record, and repair
> fragmentation.
> +
On 06.01.24 18:25, vignesh C wrote:
One of the test has failed in cfbot at [1] with:
abi-compliance-checker
[12:04:10.537] The output from the failed tests:
[12:04:10.537]
[12:04:10.537] 129/282 postgresql:abidiff / plpgsql.abidiff FAIL 1.25s
(exit status 4)
[12:04:10.537]
[12:04:10.537] ---
[cc'ing Joe]
On Tue, 9 Jan 2024 at 14:35, Christoph Berg wrote:
>
> Getting it print numeric/boolean without quotes was actually easy, as
> well as json(b). Implemented as the attached v2 patch.
>
> But: not quoting json means that NULL and 'null'::json will both be
> rendered as 'null'. That
On Mon, Oct 30, 2023 at 2:21 PM Bharath Rupireddy
wrote:
>
> Hi,
>
> How about adding code indent checks (like what BF member koel has) to
> the SanityCheck CI task? This helps catch indentation problems way
> before things are committed so that developers can find them out in
> their respective
On Thu, Dec 28, 2023 at 7:58 PM Ranier Vilela wrote:
> I think it would be more productive to initialize the entire array with -1,
> and avoid flagging, one by one, the items that should be -1.
This just moves an operation from one place to the other, while
obliterating the explanatory comment,
Hello Amit,
09.01.2024 13:08, Amit Kapila wrote:
As to checkpoint_timeout, personally I would not increase it, because it
seems unbelievable to me that pg_restore (with the cluster containing only
two empty databases) can run for longer than 5 minutes. I'd rather
investigate such situation
On 9/1/2024 16:45, vignesh C wrote:
On Tue, 9 Jan 2024 at 14:31, Andrei Lepikhov wrote:
Here is a new version of GROUP-BY optimization without sort model.
On 21/12/2023 17:53, Alexander Korotkov wrote:
I'd like to make some notes.
1) As already mentioned, there is clearly a repetitive
On Mon, Jan 8, 2024 at 9:40 PM Andy Fan wrote:
> The singler handler I was refering to is 'CHECK_FOR_INTERRUPTS', Based
> on this, spin_lock and lwlock are acted pretty differently.
CHECK_FOR_INTERRUPTS() is not a signal handler, and it's OK to acquire
and release spin locks or lwlocks there. We
On Tue, Jan 9, 2024 at 12:56 AM Michael Paquier wrote:
>
> On Mon, Jan 08, 2024 at 03:50:47PM -0500, Robert Haas wrote:
> > Hmm, interesting. I haven't had time to study this fully today, but I
> > think 0001 looks fine and could just be committed. Hooray for killing
> > useless variables with
On 09.01.24 16:27, Tom Lane wrote:
Peter Eisentraut writes:
In 30e7c175b81, support for pre-9.2 servers was removed from pg_dump.
But I found that a lot of dead code was left for supporting dumping
triggers from those old versions, presumably because that code was not
behind straightforward
On Tue, Jan 09, 2024 at 02:26:20PM +0900, Michael Paquier wrote:
> On Tue, Jan 09, 2024 at 04:55:07AM +, Bertrand Drouvot wrote:
>> Thanks! v6 looks good to me.
>
> WFM. Thanks for putting in place this sanity check when compiling.
Committed. Thanks for reviewing!
--
Nathan Bossart
On 29.11.23 18:15, Nathan Bossart wrote:
Using the same benchmark as we did for the SSE2 linear searches in
XidInMVCCSnapshot() (commit 37a6e5d) [1] [2], I see the following:
writerssse2avx2 %
25611951188-1
512 9281054 +14
1024 633
On Thu, Dec 21, 2023 at 4:32 PM Peter Eisentraut wrote:
>
> On 19.12.23 11:47, Ashutosh Bapat wrote:
> > At this point I am looking for opinions on the above rules and whether
> > the implementation is on the right track.
>
> This looks on the right track to me.
Thanks.
>
> > 0001 - change to
On Tue, Dec 19, 2023 at 10:14 AM Masahiko Sawada
wrote:
If we want only such a feature we need to implement it together (the
patch could be split, though). But if some parts of the feature are
useful for users as well, I'd recommend implementing it incrementally.
That way, the patches can get
Re: Dean Rasheed
> > I'll note that the current code uses PG's string representation of
> > strings which is meant to be round-trip safe when fed back into the
> > server. So quoted numeric values aren't a problem at all. (And that
> > part is fixable.)
>
> I'm not sure that being round-trip safe
On Tuesday, January 9, 2024 9:17 AM Peter Smith wrote:
>
> Here are some review comments for patch v57-0001.
Thanks for the comments!
>
> ==
> doc/src/sgml/protocol.sgml
>
> 1. CREATE_REPLICATION_SLOT ... FAILOVER
>
> +
> +FAILOVER [ class="parameter">boolean ]
> +
Hi,
Thank you for working on this! I agree that the current message is not friendly.
On Thu, 9 Nov 2023 at 10:19, Junwang Zhao wrote:
>
> On Thu, Nov 9, 2023 at 3:08 PM Junwang Zhao wrote:
> >
> > After a PITR shutdown, the db state should be *shut down in recovery*, try
> > the
> > patch
On Tue, Jan 9, 2024 at 5:44 PM Zhijie Hou (Fujitsu)
wrote:
>
> V58-0002
>
+static bool
+synchronize_one_slot(WalReceiverConn *wrconn, RemoteSlot *remote_slot)
{
...
+ /* Slot ready for sync, so sync it. */
+ else
+ {
+ /*
+ * Sanity check: With hot_standby_feedback enabled and
+ * invalidations
On Sat, 21 Oct 2023 at 18:34, Konstantin Knizhnik wrote:
>
> Hi hackers,
>
> EXPLAIN statement has a list of options (i.e. ANALYZE, BUFFERS, COST,...)
> which help to provide useful details of query execution.
> In Neon we have added PREFETCH option which shows information about page
>
Hi!
On Tue, Dec 5, 2023 at 9:03 PM Dmitry Koval wrote:
> I agree with Alexander Lakhin about PROC_IN_VACUUM and
> VISHORIZON_DATA_STRICT:
> 1) probably manipulations with the PROC_IN_VACUUM flag in
> pg_visibility.c were needed for condition [1] and can be removed now;
Right, PROC_IN_VACUUM is
On Tue, Jan 9, 2024 at 2:30 PM Alexander Lakhin wrote:
>
> 09.01.2024 08:49, Hayato Kuroda (Fujitsu) wrote:
> > Based on the suggestion by Amit, I have created a patch with the alternative
> > approach. This just does GUC settings. The reported failure is only for
> > 003_logical_slots, but the
On Tue, Jan 9, 2024 at 9:40 AM Masahiko Sawada wrote:
> In addition, I've made some changes and cleanups:
These look good to me, although I have not tried dumping a node in a while.
> 0011 - simplify the radix tree iteration code. I hope it makes the
> code clear and readable. Also I removed
On 2024-Jan-08, Alvaro Herrera wrote:
> So I think we should do 0001 and perhaps some further tweaks to the
> original brininsert optimization commit: [...]
So I propose the attached patch, which should fix the reported bug and
the things I mentioned above, and also the typos Alexander mentioned
On 04.01.24 00:23, Matthias van de Meent wrote:
Something like the attached? It splits out into the following
0001: basic 'omit default values'
/* Write an integer field (anything written as ":fldname %d") */
-#define WRITE_INT_FIELD(fldname) \
+#define WRITE_INT_FIELD_DIRECT(fldname) \
On Thu, 16 Nov 2023 at 05:30, jian he wrote:
>
> On Fri, Nov 3, 2023 at 12:34 AM Marko Tiikkaja wrote:
> >
> > I am now. Thanks! :-) Will try to keep an eye on the builds in the future.
> >
> > Attached v4 of the patch which should fix the issue.
> >
>
> doc seems to still have an issue.
>
On Sun, Jan 7, 2024 at 3:03 PM vignesh C wrote:
> One of the tests in CFBot has failed at [1] with:
> - Relations: (public.ft1 t1) SEMI JOIN (public.ft2 t2)
> - Remote SQL: SELECT r1."C 1", r1.c2, r1.c3, r1.c4, r1.c5, r1.c6,
> r1.c7, r1.c8 FROM "S 1"."T 1" r1 WHERE ((r1."C 1" < 20)) AND
On Fri, 8 Dec 2023 at 15:17, Kartyshov Ivan wrote:
>
> Should rise disscusion on separate utility statement or find
> case where procedure version is failed.
>
> 1) Classic (wait_classic_v3.patch)
> https://www.postgresql.org/message-id/3cc883048264c2e9af022033925ff8db%40postgrespro.ru
>
Here is a new version of GROUP-BY optimization without sort model.
On 21/12/2023 17:53, Alexander Korotkov wrote:
I'd like to make some notes.
1) As already mentioned, there is clearly a repetitive pattern for the
code following after get_useful_group_keys_orderings() calls. I think
it would
On Tue, 9 Jan 2024 at 14:31, Andrei Lepikhov wrote:
>
> Here is a new version of GROUP-BY optimization without sort model.
>
> On 21/12/2023 17:53, Alexander Korotkov wrote:
> > I'd like to make some notes.
> >
> > 1) As already mentioned, there is clearly a repetitive pattern for the
> > code
Hi, Andrei!
> Hmm, I don't see this old code in these patches. Resend 0002-* because
> of trailing spaces.
>
AFAIK, cfbot does not seek old versions of patchset parts in previous
messages. So for it to run correctly, a new version of the whole patchset
should be sent even if most patches are
Hello Kuroda-san,
09.01.2024 08:49, Hayato Kuroda (Fujitsu) wrote:
Based on the suggestion by Amit, I have created a patch with the alternative
approach. This just does GUC settings. The reported failure is only for
003_logical_slots, but the patch also includes changes for the recently added
On Tue, Jan 9, 2024 at 12:31 PM Hayato Kuroda (Fujitsu)
wrote:
>
> > > > I don't see any harm in users giving those information but we should
> > > > have some checks to ensure that the server is in standby mode and is
> > > > running locally. The other related point is do we need to take input
>
On Mon, 4 Sept 2023 at 16:59, Kyotaro Horiguchi wrote:
>
> At Thu, 24 Aug 2023 11:22:32 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > I could turn this into something like undo longs in a simple form, but
> > I'd rather not craft a general-purpose undo log system for this unelss
> > it's
Re: Dean Rasheed
> I can see the appeal in this feature. However, as it stands, this
> isn't compatible with copy format json, and I think it would need to
> duplicate quite a lot of the JSON output code in client-side code to
> make it compatible.
I can see we probably wouldn't want two
>> On 9 Jan 2024, at 00:54, Tatsuo Ishii wrote:
>>
On 4 Jan 2024, at 13:39, Tatsuo Ishii wrote:
>>>
> Attached is the patch that does this.
>>>
>>> I don't think the patch was attached?
>>>
Any objection?
>>>
>>> I didn't study the RFC in depth but as expected it seems to back
On Tue, 9 Jan 2024 at 09:43, Christoph Berg wrote:
>
> I can see we probably wouldn't want two different output formats named
> json, but the general idea of "allow psql to format results as json of
> strings" makes a lot of sense, so we should try to make it work. Does
> it even have to be
>From the previous thread on this issue. I think the following proposal
seemed like it had the most buy-in from committers. But so far nobody
implemented it:
On Wed, 18 Oct 2023 at 16:07, Robert Haas wrote:
>
> On Wed, Oct 18, 2023 at 3:21 AM Peter Eisentraut wrote:
> > On 18.10.23 06:40, David
Hello again,
I have now committed 0001.
I got some off-list review of 0004; specifically, Michael Paquier said
it looked OK, and Tom Lane found another bug. So I've added a fix for
that in what's now 0003.
Here's v2. I plan to commit the rest of this fairly soon if there are
no comments.
On Tue, Dec 26, 2023 at 8:49 AM Andrew Dunstan wrote:
> Quite a long time ago Robert asked me about the possibility of an
> incremental JSON parser. I wrote one, and I've tweaked it a bit, but the
> performance is significantly worse that that of the current Recursive
> Descent parser.
The
Hi,
On January 9, 2024 11:33:29 AM PST, Robert Haas wrote:
>On Tue, Jan 9, 2024 at 2:23 PM Melanie Plageman
> wrote:
>> Yes, I agree. I thought about it more, and I prefer updating the FSM
>> and setting nonempty_pages into lazy_scan_[no]prune(). Originally, I
>> had ordered the patch set with
I had already written the patch for immediate reaping addressing the
below feedback before I saw the emails that said everyone is happy
with using hastup in lazy_scan_[no]prune() in a preliminary patch. Let
me know if you have a strong preference for reordering. Otherwise, I
will write the three
On Tue, Dec 5, 2023 at 1:44 AM Daniel Gustafsson wrote:
>
> > On 8 Nov 2023, at 20:00, Jacob Champion wrote:
>
> > Unfortunately the configure/Makefile build of libpq now seems to be
> > pulling in an `exit()` dependency in a way that Meson does not.
>
> I believe this comes from the libcurl and
On Tue, Jan 9, 2024 at 11:35 AM Melanie Plageman
wrote:
> The easiest solution would be to change the name of the parameter to
> heap_page_prune_execute()'s from "no_indexes" to something like
> "validate_unused", since it is only used in assert builds for
> validation.
Right.
> However,
Tom Lane writes:
> Peter Eisentraut writes:
>> Would it work to change the signature of pg_get_serial_sequence to
>> pg_get_serial_sequence(table anyelement, column text) -> anyelement
>> and then check inside the function code whether text or regclass was passed?
>
> Probably not very
On Tue, Jan 9, 2024 at 10:56 AM Melanie Plageman
wrote:
> Andres had actually said that he didn't like pushing the update of
> nonempty_pages into lazy_scan_[no]prune(). So, my v4 patch set
> eliminates this.
Mmph - but I was so looking forward to killing hastup!
> On the other hand, the
On Tue, Jan 9, 2024 at 1:31 PM Robert Haas wrote:
>
> On Tue, Jan 9, 2024 at 10:56 AM Melanie Plageman
> wrote:
> > Andres had actually said that he didn't like pushing the update of
> > nonempty_pages into lazy_scan_[no]prune(). So, my v4 patch set
> > eliminates this.
>
> Mmph - but I was so
On Tue, Jan 9, 2024 at 2:23 PM Melanie Plageman
wrote:
> Yes, I agree. I thought about it more, and I prefer updating the FSM
> and setting nonempty_pages into lazy_scan_[no]prune(). Originally, I
> had ordered the patch set with that first (before the patch to do
> immediate reaping), but there
On Tue Jan 9, 2024 at 3:00 AM CST, John Naylor wrote:
On Mon, Oct 30, 2023 at 2:21 PM Bharath Rupireddy
wrote:
>
> Hi,
>
> How about adding code indent checks (like what BF member koel has) to
> the SanityCheck CI task? This helps catch indentation problems way
> before things are committed so
On Thu, Jan 4, 2024 at 9:55 AM Tomas Vondra
wrote:
> Here's a somewhat reworked version of the patch. My initial goal was to
> see if it could adopt the StreamingRead API proposed in [1], but that
> turned out to be less straight-forward than I hoped, for two reasons:
I guess we need Thomas or
On 03.01.2024 02:37, Jim Nasby wrote:
Some attributes are arguably important enough to warrant their own
column. The most obvious is NOLOGIN, since those roles are generally
used for a very different purpose than LOGIN roles. SUPERUSER might be
another candidate (though, I much prefer a
On Tue Jan 9, 2024 at 2:49 PM CST, Robert Haas wrote:
On Tue, Jan 9, 2024 at 2:20 PM Tristan Partin wrote:
> > I don't indent during most of development, and don't intend to start.
>
> Could you expand on why you don't? I could understand as you're writing,
> but I would think formatting on
> On 9 Jan 2024, at 22:20, Tom Lane wrote:
> In short, I don't think that putting this into CI is the answer.
> Putting it into committers' standard workflow is a better idea,
> if we can get all the committers on board with that.
+many
--
Daniel Gustafsson
On Tue, Jan 9, 2024 at 4:42 PM Daniel Gustafsson wrote:
> > On 9 Jan 2024, at 22:20, Tom Lane wrote:
> > In short, I don't think that putting this into CI is the answer.
> > Putting it into committers' standard workflow is a better idea,
> > if we can get all the committers on board with that.
>
On 12/28/23 6:57 PM, Jeff Davis wrote:
> On Wed, 2023-12-27 at 17:26 -0800, Jeff Davis wrote:
> Attached a more complete version that fixes a few bugs, stabilizes the
> tests, and improves the documentation. I optimized the performance, too
> -- now it's beating both libc's "C.utf8" and ICU
On Tue, 2024-01-09 at 14:17 -0800, Jeremy Schneider wrote:
> I think we missed something in psql, pretty sure I applied all the
> patches but I see this error:
>
> =# \l
> ERROR: 42703: column d.datlocale does not exist
> LINE 8: d.datlocale as "Locale",
>
Thank you. I'll fix this in the
Robert Haas writes:
> On Tue, Jan 9, 2024 at 2:20 PM Tristan Partin wrote:
>>> I don't indent during most of development, and don't intend to start.
>> Could you expand on why you don't? I could understand as you're writing,
>> but I would think formatting on save, might be useful.
> John
On Tue, Jan 9, 2024 at 3:40 PM Robert Haas wrote:
>
> On Tue, Jan 9, 2024 at 3:13 PM Melanie Plageman
> wrote:
> > I had already written the patch for immediate reaping addressing the
> > below feedback before I saw the emails that said everyone is happy
> > with using hastup in
On Tue, Jan 9, 2024 at 3:13 PM Melanie Plageman
wrote:
> I had already written the patch for immediate reaping addressing the
> below feedback before I saw the emails that said everyone is happy
> with using hastup in lazy_scan_[no]prune() in a preliminary patch. Let
> me know if you have a
On Tue, Jan 9, 2024 at 2:20 PM Tristan Partin wrote:
> > I don't indent during most of development, and don't intend to start.
>
> Could you expand on why you don't? I could understand as you're writing,
> but I would think formatting on save, might be useful.
John might have his own answer to
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
> Tom Lane writes:
>> Maybe it would work to have both
>> pg_get_serial_sequence(table text, column text) -> text
>> pg_get_serial_sequence(table regclass, column text) -> regclass
> I think it would be more correct to use name for the column
On Tue, 9 Jan 2024 at 18:20, Nathan Bossart wrote:
>
> On Tue, Jan 09, 2024 at 09:20:09AM +0700, John Naylor wrote:
> > On Tue, Jan 9, 2024 at 12:37 AM Nathan Bossart
> > wrote:
> >>
> >> > I suspect that there could be a regression lurking for some inputs
> >> > that the benchmark doesn't look
On 1/8/24 2:10 PM, Robert Haas wrote:
On Fri, Jan 5, 2024 at 3:57 PM Andres Freund wrote:
I will be astonished if you can make this work well enough to avoid
huge regressions in plausible cases. There are plenty of cases where
we do a very thorough job opportunistically removing index tuples.
On 1/9/24 3:20 PM, Tom Lane wrote:
In short, I don't think that putting this into CI is the answer.
Putting it into committers' standard workflow is a better idea,
if we can get all the committers on board with that.
FWIW, that's the approach that go takes - not only for committing to go
Hi,
I think we need to be more aggressive about marking things returned
with feedback when they don't get updated. If a patch is waiting for
reviews for a long time, well, that's one thing. Maybe we eventually
close it due to lack of interest in reviewing it, but that should be
done cautiously,
1 - 100 of 123 matches
Mail list logo
