On Sat, Jan 20, 2024 at 08:10:03AM +0530, vignesh C wrote:
> The patch does not apply anymore, please post a rebased version of the patch :
There is more to it. Some of the columns of pg_stat_bgwriter have
been moved to a different view, aka pg_stat_checkpointer. I have
marked the patch as
On Tue, Jan 30, 2024 at 6:24 AM Masahiko Sawada wrote:
>
> Hi,
>
> While working on radix tree patch[1], John Naylor found that dsa.c
> doesn't already use shared locks even in dsa_dump(). dsa_dump() seems
> a pure read-only function so I thought we could use a shared lock mode
> there. Is there
Andrey,
I think this phrase is outdated: "This function can optionally accept a
timestamp used instead of current time.This allows implementation of k-way
sotable identifiers."
This phrase is wrong: "Both functions return a version 4 (random) UUID."
For this phrase the reason is unclear and the
On Tue, Jan 30, 2024 at 02:45:31PM +0900, Sutou Kouhei wrote:
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Tue, 30 Jan 2024 11:11:59 +0900,
> Masahiko Sawada wrote:
>
>> ---
>> +if (!format_specified)
>> +/* Set the default
On Mon, Jan 29, 2024 at 6:11 PM Alexander Kuzmenkov
wrote:
>
> Hello hackers,
>
> While investigating some query plans, I noticed some code that seems
> to be wrong: when create_merge_append_path() estimates the cost of
> sorting an input, it calls cost_sort() passing subpath->parent->tuples
> as
On Mon, Jan 29, 2024 at 2:17 PM wrote:
>
> Greetings, everyone!
>
> While analyzing output of Svace static analyzer [1] I've found a bug.
>
> In function intoasc(interval * i, char *str) from file
> src/interfaces/ecpg/compatlib/informix.c
> we return a non-terminated string since we use memcpy
> On 30 Jan 2024, at 01:38, Jelte Fennema-Nio wrote:
>
> Yeah, I liked the feature to generate UUIDv7 based on timestamp too.
> But following the spec seems more important than a nice feature to me.
PFA v15. Changes: removed timestamp argument, incorporated Jelte’s
documentation addons.
Hi! Thank you for your work on this subject.
I have reviewed your patch and I think it is better to add an Assert for
JOIN_RIGHT_SEMI to the ExecMergeJoin and ExecNestLoop functions to
prevent the use of RIGHT_SEMI for these types of connections (NestedLoop
and MergeJoin).
Mostly I'm
On Mon, Jan 29, 2024 at 10:43 PM Alvaro Herrera wrote:
>
> Okay, so I gave this another look and concluded that I definitely didn't
> like the whole business of having one level open the explain group and
> return outwards whether it had been done so that the other level would
> close it. So I
> On 26 Jan 2024, at 19:58, Japin Li wrote:
>
> Thanks for updating the patch. Here are some comments for v24.
>
> +
> +Terminate any session that spans longer than the specified amount of
> +time in transaction. The limit applies both to explicit transactions
> +
Hi Alexander,
On Sun, Jan 28, 2024 at 1:30 PM Alexander Lakhin wrote:
>
> Hello Peter,
>
> 26.01.2024 16:42, Peter Eisentraut wrote:
> >
> > I have committed all this. These are great improvements.
> >
>
> Please look at the segmentation fault triggered by the following query since
> 4d969b2f8:
On Sat, Jan 27, 2024 at 8:26 AM vignesh C wrote:
>
> On Tue, 31 Oct 2023 at 10:48, Ashutosh Bapat
> wrote:
> >
> > On Thu, Sep 14, 2023 at 4:39 PM Ashutosh Bapat
> > wrote:
> > >
> > > The patch set is thus
> > > 0001 - patch used to measure memory used during planning
> > >
> > > 0002 - Patch
On Mon, Jan 29, 2024 at 6:47 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Monday, January 29, 2024 7:30 PM Amit Kapila
> wrote:
> >
>
> > ===
> > 1.
> > parse_subscription_options()
> > {
> > ...
> > /*
> > * We've been explicitly asked to not connect, that requires some
> > *
On Tue, 30 Jan 2024 13:47:45 +0800
jian he wrote:
> On Tue, Jan 30, 2024 at 12:35 PM Yugo NAGATA wrote:
> >
> >
> > Sorry, I also attached a wrong file.
> > Attached is the correct one.
> I think you attached the wrong file again. also please name it as v4.
Opps..sorry, again.
I attached the
On Tue, Jan 30, 2024 at 12:35 PM Yugo NAGATA wrote:
>
>
> Sorry, I also attached a wrong file.
> Attached is the correct one.
I think you attached the wrong file again. also please name it as v4.
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Tue, 30 Jan 2024 11:11:59 +0900,
Masahiko Sawada wrote:
> ---
> +if (!format_specified)
> +/* Set the default format. */
> +ProcessCopyOptionFormatTo(pstate,
On Fri, Jan 26, 2024 at 8:42 PM vignesh C wrote:
>
> On Wed, 4 Oct 2023 at 04:02, Ashutosh Bapat
> wrote:
> >
> > On Fri, Sep 29, 2023 at 8:36 AM Amit Langote
> > wrote:
> > > IOW, something
> > > like the following would have sufficed:
.. snip...
> >
> > Works for me. PFA patchset with these
po 29. 1. 2024 v 10:26 odesílatel Pavel Stehule
napsal:
>
>
> ne 28. 1. 2024 v 22:52 odesílatel Jelte Fennema-Nio
> napsal:
>
>> On Sun, 28 Jan 2024 at 20:01, Pavel Stehule
>> wrote:
>> > There is another reason - compatibility with other drivers. We
>> maintain just libpq, but there are
On Tue, 30 Jan 2024 12:12:31 +0800
jian he wrote:
> On Fri, Jan 26, 2024 at 8:42 AM Yugo NAGATA wrote:
> >
> > On Tue, 2 Jan 2024 08:00:00 +0800
> > jian he wrote:
> >
> > > On Mon, Nov 6, 2023 at 8:00 AM jian he
> > > wrote:
> > > >
> > > > minor doc issues.
> > > > Returns the chunk id of
On Fri, Jan 26, 2024 at 8:42 AM Yugo NAGATA wrote:
>
> On Tue, 2 Jan 2024 08:00:00 +0800
> jian he wrote:
>
> > On Mon, Nov 6, 2023 at 8:00 AM jian he wrote:
> > >
> > > minor doc issues.
> > > Returns the chunk id of the TOASTed value, or NULL if the value is not
> > > TOASTed.
> > > Should
On Tue, Jan 30, 2024 at 7:29 AM Peter Smith wrote:
>
> Here are some review comments for v72-0001
>
> ==
> doc/src/sgml/ref/alter_subscription.sgml
>
> 1.
> + parameter value of the subscription. Otherwise, the slot on the
> + publisher may behave differently from what
Thomas Munro writes:
> On Sat, Jan 13, 2024 at 1:51 PM Tom Lane wrote:
>> Time for a bug report to IO::Tty's authors, I guess.
> Ahh, there is one: https://github.com/cpan-authors/IO-Tty/issues/38
Just for the archives' sake: I hit this today on a fresh install
of FreeBSD 14.0, which has
On Tue, 30 Jan 2024 at 07:24, Zhijie Hou (Fujitsu)
wrote:
>
> On Monday, January 29, 2024 9:22 PM vignesh C wrote:
> >
> > On Fri, 26 Jan 2024 at 11:30, Alexander Lakhin wrote:
> > >
> > > Hello hackers,
> > >
> > > After determining a possible cause for intermittent failures of the
> > > test
On Fri, Jan 19, 2024 at 7:21 PM Masahiko Sawada wrote:
>
> On Thu, Jan 18, 2024 at 6:54 PM Amit Kapila wrote:
> >
> > On Thu, Jan 18, 2024 at 11:15 AM Peter Smith wrote:
> > >
> > > On Thu, Jan 18, 2024 at 12:55 PM Masahiko Sawada
> > > wrote:
> > > >
> > > ...
> > > >
> > > > Although we can
On Fri, Jan 26, 2024 at 8:33 PM James Coleman wrote:
>
> On Tue, Jan 23, 2024 at 2:46 AM Dilip Kumar wrote:
> >
> > On Tue, Jan 23, 2024 at 7:18 AM James Coleman wrote:
> > >
> > > On Mon, Jan 22, 2024 at 8:21 PM James Coleman wrote:
> > > >
> > > > See rebased patch attached.
> > >
> > > I
On Sat, Jan 27, 2024 at 11:29 AM vignesh C wrote:
> CFBot shows that the patch does not apply anymore as in [1]:
>
> Please post an updated version for the same.
Attached is an updated patch. Nothing else has changed.
Thanks
Richard
On Mon, Jan 29, 2024 at 6:45 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Mon, 29 Jan 2024 11:37:07 +0800,
> Junwang Zhao wrote:
>
> >> > > Does it make sense to pass only non-builtin options to the custom
> >> > >
On Sun, Jan 28, 2024, at 10:10 PM, Euler Taveira wrote:
> On Fri, Jan 26, 2024, at 4:55 AM, Hayato Kuroda (Fujitsu) wrote:
>> Again, thanks for updating the patch! There are my random comments for v9.
>
> Thanks for checking v9. I already incorporated some of the points below into
> the next
Here are some review comments for v72-0001
==
doc/src/sgml/ref/alter_subscription.sgml
1.
+ parameter value of the subscription. Otherwise, the slot on the
+ publisher may behave differently from what subscription's
+ failover
+ option says. The slot on the publisher
On Monday, January 29, 2024 9:22 PM vignesh C wrote:
>
> On Fri, 26 Jan 2024 at 11:30, Alexander Lakhin wrote:
> >
> > Hello hackers,
> >
> > After determining a possible cause for intermittent failures of the
> > test subscription/031_column_list [1], I was wondering what makes
> > another
On Fri, Jan 26, 2024 at 8:28 AM vignesh C wrote:
>
> CFBot shows that the patch does not apply anymore as in [1]:
> === applying patch
> ./v3-0002-Add-lazy_scan_skip-unskippable-state-to-LVRelStat.patch
> patching file src/backend/access/heap/vacuumlazy.c
> ...
> Hunk #10 FAILED at 1042.
> Hunk
Hello Dave,
> Tatsuo Ishii writes:
>> Below is outputs from "pgproto" command coming with Pgpool-II.
>> (Lines starting "FE" represents a message from frontend to backend.
>> Lines starting "BE" represents a message from backend to frontend.)
>
>> FE=> Parse(stmt="", query="SET
On Mon, Jan 29, 2024 at 8:48 PM John Naylor wrote:
>
> On Mon, Jan 29, 2024 at 2:29 PM Masahiko Sawada wrote:
>
> > > > +/*
> > > > + * Calculate the slab blocksize so that we can allocate at least 32
> > > > chunks
> > > > + * from the block.
> > > > + */
> > > > +#define
Hi,
While working on radix tree patch[1], John Naylor found that dsa.c
doesn't already use shared locks even in dsa_dump(). dsa_dump() seems
a pure read-only function so I thought we could use a shared lock mode
there. Is there any reason to use exclusive mode even in dsa_dump()?
Ultimately,
On Mon, Jan 29, 2024 at 10:03:19AM -0400, David Steele wrote:
> I took a pass at this on PG14 and things definitely look a lot different
> back there. Not only is the timeline missing, but there are two sections of
> code for ending a backup, one for standby backup and one for primary.
Andrey,
I understand and agree with your goals. But instead of dangerous universal
functions, it is better to develop safe highly specialized functions that
implement only these goals.
There should not be a function uuidv7(T) from an arbitrary timestamp, but there
should be a special function
On 29/01/2024 17:54, reid.thomp...@crunchydata.com wrote:
On Thu, 2024-01-25 at 01:51 +0200, Heikki Linnakangas wrote:
And here we go. BackendID is now a 1-based index directly into the
PGPROC array.
Would it be worthwhile to also note in this comment FIRST_AUX_PROC's
and IsAuxProcess()'s
Tatsuo Ishii writes:
> Below is outputs from "pgproto" command coming with Pgpool-II.
> (Lines starting "FE" represents a message from frontend to backend.
> Lines starting "BE" represents a message from backend to frontend.)
> FE=> Parse(stmt="", query="SET extra_float_digits = 3")
> FE=>
On Tue, 30 Jan 2024 at 12:25, David Rowley wrote:
> I'll push this change to master only as there don't seem to have been
> any complaints. We can reconsider that if someone complains.
Pushed.
David
Peter Smith writes:
>> IIUC these releases notes [1] say autolink.index.see existed since
>> v1.79.1, but unfortunately, that is more recent than my ancient
>> installed v1.78.1
> Is anything going to be changed for this?
I assume Peter E. is going to address it, but FOSDEM is this week and
so
On Fri, 26 Jan 2024 at 19:54, David Rowley wrote:
> Currently, nodeMemoize.c builds the hashtable for the cache during
> executor startup. This is not what is done in hash joins. I think we
> should make the two behave the same way.
I ran a few benchmarks on this, mostly for archive purposes.
While taking care of a Pgpool-II trouble report from user [1], I found
an interesting usage pattern of the extended query protocol. In my
understanding a series of queries in the extended query protocol is
ended by a sync message. Then one ReadyForQuery response comes for one
sync message. However
On Thu, Jan 25, 2024 at 9:12 AM Peter Smith wrote:
>
> On Tue, Jan 23, 2024 at 12:32 PM Peter Smith wrote:
> >
> > On Tue, Jan 23, 2024 at 12:13 PM Tom Lane wrote:
> > >
> > > Peter Smith writes:
> > > > I usually the HTML documentation locally using command:
> > > > make STYLE=website html
>
On Tue, Jan 30, 2024 at 11:23:57AM +1300, David Rowley wrote:
> On Tue, 30 Jan 2024 at 08:32, Nathan Bossart wrote:
>> I'm currently +0.1 for this change. I don't see any huge problem with
>> trimming a few instructions, but I'm dubious there's any measurable impact.
>> However, a cycle saved is
On Mon, Jan 29, 2024 at 4:24 PM David Rowley wrote:
>
> On Tue, 30 Jan 2024 at 10:17, Melanie Plageman
> wrote:
> > Though logically the performance with 0001 and 0002 should be the same
> > as master (no new non-inline function calls, no additional looping),
> > I've done a bit of profiling
Hi,
On January 29, 2024 2:09:23 PM PST, Tom Lane wrote:
>Andres Freund writes:
>> On 2024-01-29 15:01:06 -0500, Robert Haas wrote:
>>> And it still baffles me why we allow everyone to pick their own system for
>>> capitalizing identifiers out of a hat, without even insisting on consistency
>>>
On Tue, 30 Jan 2024 at 08:32, Nathan Bossart wrote:
> I'm currently +0.1 for this change. I don't see any huge problem with
> trimming a few instructions, but I'm dubious there's any measurable impact.
> However, a cycle saved is a cycle earned...
FWIW, In [1] and subsequent replies, there are
Andres Freund writes:
> On 2024-01-29 15:01:06 -0500, Robert Haas wrote:
>> And it still baffles me why we allow everyone to pick their own system for
>> capitalizing identifiers out of a hat, without even insisting on consistency
>> from one end of the same identifier to the other.
> Yes.
On Tue, 30 Jan 2024 at 10:17, Melanie Plageman
wrote:
> Though logically the performance with 0001 and 0002 should be the same
> as master (no new non-inline function calls, no additional looping),
> I've done a bit of profiling anyway. I created a large multi-GB table,
> read it all into shared
Hi,
Last year, David and I worked on a round of refactoring for
heapgettup() and heapgettup_pagemode() [1]. Now that the streaming
read API has been proposed [2], there is a bit more refactoring that
can be done on master to prepare sequential scan to support streaming
reads.
Patches 0001 and
On Mon, Jan 29, 2024 at 03:18:50PM -0500, Robert Haas wrote:
> I'm wondering if what we need to do is run pg_walsummary on both
> summary files in that case. If we just pick one or the other, how do
> we know which one to pick?
Even if we do that, isn't it possible that none of the summaries will
On Sun, 21 Jan 2024 at 03:06, Jeff Davis wrote:
> Yes, thank you. I don't think we need to change the algorithm.
Jumping in here at a random point just to share my findings from
poking around this on and off. I am concentrating here on cstring
hashing as that is the most complicated one.
One
On Mon, 29 Jan 2024 at 19:37, Tristan Partin wrote:
>
> On Mon Jan 29, 2024 at 11:37 AM CST, Alvaro Herrera wrote:
> > I just realized while looking at Jelte's patch for the new nonblocking
> > query cancel stuff that the Meson build doesn't run the libpq_pipeline
> > tests :-(
> >
> > Is there
Hi,
On 2024-01-29 15:01:06 -0500, Robert Haas wrote:
> And it still baffles me why we allow everyone to pick their own system for
> capitalizing identifiers out of a hat, without even insisting on consistency
> from one end of the same identifier to the other.
Yes. Please. I hate some
On Mon, 29 Jan 2024 at 19:32, Andrey M. Borodin wrote:
> Even if the developer pass constant time to uuidv7(T) they will get what they
> asked for - unique identifier. Moreover - it still will be keeping locality.
> There will be no negative consequences at all.
It will be significantly "less
On Mon, Jan 29, 2024 at 1:21 PM Nathan Bossart wrote:
> > Ah, I think this query:
> >
> > SELECT tli, start_lsn, end_lsn from pg_available_wal_summaries()
> > WHERE tli = $summarized_tli AND end_lsn > '$summarized_lsn'
> >
> > is returning more than one row in some cases. I
On 2024-01-29 Mo 14:58, Andres Freund wrote:
Hi,
On 2023-12-27 12:48:40 +0100, Jelte Fennema-Nio wrote:
Postgres currently requires all variables to be declared at the top of
the function, because it specifies -Wdeclaration-after-statement. One
of the reasons that we had this warning was
On 28.01.2024 22:51, Pavel Luzanov wrote:
On 23.01.2024 04:18, Tom Lane wrote:
I think expecting the pg_roles view to change for this is problematic.
You can't have that in the back branches, so with this patch psql
will show something different against a pre-17 server than later
versions. At
On Mon, Jan 29, 2024 at 1:38 PM Heikki Linnakangas wrote:
> -0.5 from me, for exactly those reasons Robert said. I wouldn't mind
> removing the compiler flag as long as we mostly keep the current style
> of declarations at top, with exceptions when it really makes sense. But
> in practice it
Hi,
On 2023-12-27 12:48:40 +0100, Jelte Fennema-Nio wrote:
> Postgres currently requires all variables to be declared at the top of
> the function, because it specifies -Wdeclaration-after-statement. One
> of the reasons that we had this warning was because C89 required this
> style of
On Mon, Jan 29, 2024 at 04:43:32PM -0300, Ranier Vilela wrote:
> Em seg., 29 de jan. de 2024 às 16:32, Nathan Bossart <
> nathandboss...@gmail.com> escreveu:
>> -#define WORDNUM(x) ((x) / BITS_PER_BITMAPWORD)
>> -#define BITNUM(x) ((x) % BITS_PER_BITMAPWORD)
>> +#define WORDNUM(x)
Em seg., 29 de jan. de 2024 às 16:32, Nathan Bossart <
nathandboss...@gmail.com> escreveu:
> On Mon, Jan 29, 2024 at 01:30:47PM -0300, Ranier Vilela wrote:
> > IMO I believe that bitmapset can obtain an optimization in the
> calculation
> > of the WORDNUM and BITNUM macros.
> >
> > As you know,
On Mon, Jan 29, 2024, at 12:03 PM, Jelte Fennema-Nio wrote:
> I feel like this is the type of change where there's not much
> discussion to be had. And the only way to resolve it is to use some
> voting to gauge community opinion.
>
> So my suggestion is for people to respond with -1, -0.5, +-0,
On Mon, Jan 29, 2024 at 01:30:47PM -0300, Ranier Vilela wrote:
> IMO I believe that bitmapset can obtain an optimization in the calculation
> of the WORDNUM and BITNUM macros.
>
> As you know, in bitmapset, negative members are not allowed.
>
> if (x < 0)
> elog(ERROR, "negative bitmapset member
po 29. 1. 2024 v 19:36 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Mon, Jan 29, 2024 at 08:57:42AM +0100, Pavel Stehule wrote:
> > Hi
> >
> > ne 28. 1. 2024 v 19:00 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> > napsal:
> >
> > > Thanks for the update, smaller patches
On 29/01/2024 19:07, Robert Haas wrote:
On Mon, Jan 29, 2024 at 10:03 AM Jelte Fennema-Nio wrote:
I feel like this is the type of change where there's not much
discussion to be had. And the only way to resolve it is to use some
voting to gauge community opinion.
So my suggestion is for people
On Mon Jan 29, 2024 at 11:37 AM CST, Alvaro Herrera wrote:
I just realized while looking at Jelte's patch for the new nonblocking
query cancel stuff that the Meson build doesn't run the libpq_pipeline
tests :-(
Is there any way to wire the tests to make it work?
I can try to take a look for
> On Mon, Jan 29, 2024 at 08:57:42AM +0100, Pavel Stehule wrote:
> Hi
>
> ne 28. 1. 2024 v 19:00 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> napsal:
>
> > Thanks for the update, smaller patches looks promising.
> >
> > Off the list Pavel has mentioned that the first two patches contain a
>
> On 25 Jan 2024, at 22:04, Sergey Prokhorenko
> wrote:
>
> Aleksander,
>
> In this case the documentation must state that the functions
> uuid_extract_time() and uuidv7(T) are against the RFC requirements, and that
> developers may use these functions with caution at their own risk, and
On Sat, Jan 27, 2024 at 10:31:09AM -0600, Nathan Bossart wrote:
> On Sat, Jan 27, 2024 at 11:00:01AM +0300, Alexander Lakhin wrote:
>> I'm discouraged by "\n1" in the file name and in the
>> "examining summary..." message.
>> regress_log_002_blocks from the following successful test run on the
On Fri, Jan 26, 2024 at 01:24:19PM -0500, Tom Lane wrote:
> Nathan Bossart writes:
>> I see that I was planning on back-patching this to v16, but since
>> is_valid_ascii() was introduced in v15, I'm wondering if it'd be better to
>> back-patch it there so that is_valid_ascii() lives in the same
On Mon, Jan 29, 2024 at 11:12 AM Heikki Linnakangas wrote:
> Agreed, that's silly.
+1.
> If there's already some data in PqSendBuffer, I wonder if it would be
> better to fill it up with data, flush it, and then send the rest of the
> data directly. Instead of flushing the partial data first.
On Mon, Jan 29, 2024 at 11:11 PM Bharath Rupireddy
wrote:
>
> On Wed, Jan 24, 2024 at 7:15 AM Jeff Davis wrote:
> >
> > On Tue, 2024-01-23 at 15:21 +0530, Ashutosh Bapat wrote:
> > > I am with the prefix. The changes it causes make review difficult. If
> > > you can separate those changes into a
On Wed, Jan 24, 2024 at 7:15 AM Jeff Davis wrote:
>
> On Tue, 2024-01-23 at 15:21 +0530, Ashutosh Bapat wrote:
> > I am with the prefix. The changes it causes make review difficult. If
> > you can separate those changes into a patch that will help.
>
> I ended up just removing the dummy FDW. Real
I just realized while looking at Jelte's patch for the new nonblocking
query cancel stuff that the Meson build doesn't run the libpq_pipeline
tests :-(
Is there any way to wire the tests to make it work?
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"I can't
po 29. 1. 2024 v 18:11 odesílatel Tom Lane napsal:
> Steve Chavez writes:
> > However, :{?variable_name} is already taken by psql to test whether a
> > variable is defined or not. It might be confusing to use the same syntax.
>
> Hmm. Maybe we could go with :{+...} or the like?
>
> > How about
Okay, so I gave this another look and concluded that I definitely didn't
like the whole business of having one level open the explain group and
return outwards whether it had been done so that the other level would
close it. So I made the code do what I said I thought it should do
(adding a new
On Mon, 29 Jan 2024 at 10:42, Mark Dilger
wrote:
> I don't think anybody is proposing re-working the existing codebase. I
> understand this to be only about allowing new code to use the newer style.
> Personally, I like, as much as possible, to use initializations to const
> variables and avoid
Steve Chavez writes:
> However, :{?variable_name} is already taken by psql to test whether a
> variable is defined or not. It might be confusing to use the same syntax.
Hmm. Maybe we could go with :{+...} or the like?
> How about using the convention of interpreting an identifier as a file
On Mon, Jan 29, 2024 at 10:03 AM Jelte Fennema-Nio wrote:
> I feel like this is the type of change where there's not much
> discussion to be had. And the only way to resolve it is to use some
> voting to gauge community opinion.
>
> So my suggestion is for people to respond with -1, -0.5, +-0,
po 29. 1. 2024 v 17:54 odesílatel Steve Chavez napsal:
> > I like your ideas upthread about \file_read and :{filename}
>
> Great ideas! :{filename} looks more convenient to use than \file_read just
> because it's one less command to execute.
>
> However, :{?variable_name} is already taken by
> I like your ideas upthread about \file_read and :{filename}
Great ideas! :{filename} looks more convenient to use than \file_read just
because it's one less command to execute.
However, :{?variable_name} is already taken by psql to test whether a
variable is defined or not. It might be
Em seg., 29 de jan. de 2024 às 12:03, Jelte Fennema-Nio
escreveu:
> I feel like this is the type of change where there's not much
> discussion to be had. And the only way to resolve it is to use some
> voting to gauge community opinion.
>
> So my suggestion is for people to respond with -1,
Hi,
IMO I believe that bitmapset can obtain an optimization in the calculation
of the WORDNUM and BITNUM macros.
As you know, in bitmapset, negative members are not allowed.
if (x < 0)
elog(ERROR, "negative bitmapset member not allowed");
Then, allow the compiler to optimize and do the
Dave Cramer
www.postgres.rocks
On Mon, 29 Jan 2024 at 11:16, Andrew Dunstan wrote:
>
> On 2024-01-26 Fr 09:18, Dave Cramer wrote:
>
>
>
> On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan wrote:
>
>>
>> On 2024-01-25 Th 20:32, Michael Paquier wrote:
>> > On Thu, Jan 25, 2024 at 04:52:30PM -0500,
On 2024-01-26 Fr 09:18, Dave Cramer wrote:
On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan wrote:
On 2024-01-25 Th 20:32, Michael Paquier wrote:
> On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote:
>> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan
wrote:
>>> On
On 20/11/2023 14:21, Melih Mutlu wrote:
Hi hackers
I've been looking into ways to reduce the overhead we're having in
pqcomm and I'd like to propose a small patch to modify how
socket_putmessage works.
Currently socket_putmessage copies any input data into the pqcomm send
buffer
I wrote:
> Peter Eisentraut writes:
>> In PL/Tcl, we used to have these CONST84 and CONST86 things, for similar
>> reasons. Maybe that would be another approach.
> Yeah, if the simple cast approach turns out to create warnings,
> we'll have to fall back on using actually different
On Thu, 2024-01-25 at 01:51 +0200, Heikki Linnakangas wrote:
>
> And here we go. BackendID is now a 1-based index directly into the
> PGPROC array.
>
Would it be worthwhile to also note in this comment FIRST_AUX_PROC's
and IsAuxProcess()'s dependency on B_ARCHIVER and it's location in the
enum
Hey there, coming back to this. I poked at the logs in the master branch and
saw no mention of to_regtype; did I miss it?
On Sep 17, 2023, at 10:58 PM, David G. Johnston
wrote:
> Parses a string of text, extracts a potential type name from it, and
> translates that name into an OID. Failure
Le lundi 29 janvier 2024, 15:59:04 CET Tomas Vondra a écrit :
> I'm not sure work_mem is a good parameter to drive this. It doesn't say
> how much memory we expect the backend to use - it's a per-operation
> limit, so it doesn't work particularly well with partitioning (e.g. with
> 100 partitions,
> On Jan 29, 2024, at 7:35 AM, Isaac Morland wrote:
>
> On Mon, 29 Jan 2024 at 10:31, Mark Dilger
> wrote:
>
> -Infinity for refactoring the entire codebase and backpatching.
>
> I don't think anybody is proposing re-working the existing codebase. I
> understand this to be only about
On Mon, Jan 29, 2024 at 10:23:38AM -0500, Tom Lane wrote:
> Jelte Fennema-Nio writes:
>> I feel like this is the type of change where there's not much
>> discussion to be had. And the only way to resolve it is to use some
>> voting to gauge community opinion.
>
>> So my suggestion is for people
On 2024-01-26 Fr 09:18, Dave Cramer wrote:
On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan wrote:
On 2024-01-25 Th 20:32, Michael Paquier wrote:
> On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote:
>> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan
wrote:
>>> On
On Mon, 29 Jan 2024 at 10:31, Mark Dilger
wrote:
>
>
> > On Jan 29, 2024, at 7:03 AM, Jelte Fennema-Nio
> wrote:
> >
> > So my suggestion is for people to respond with -1, -0.5, +-0, +0.5, or
> > +1 to indicate support against/for the change.
>
> -1 for me.
>
> -Infinity for refactoring the
> On Jan 29, 2024, at 7:03 AM, Jelte Fennema-Nio wrote:
>
> So my suggestion is for people to respond with -1, -0.5, +-0, +0.5, or
> +1 to indicate support against/for the change.
-1 for me.
-Infinity for refactoring the entire codebase and backpatching.
—
Mark Dilger
EnterpriseDB:
Jelte Fennema-Nio writes:
> I feel like this is the type of change where there's not much
> discussion to be had. And the only way to resolve it is to use some
> voting to gauge community opinion.
> So my suggestion is for people to respond with -1, -0.5, +-0, +0.5, or
> +1 to indicate support
Peter Eisentraut writes:
> On 27.01.24 20:04, Tom Lane wrote:
>> I don't mind adopting the "const" --- it's a good idea in isolation.
>> The trouble is in fixing our code to work with both old and new
>> libxml2 versions. We could thrash around with a configure test or
>> something, but I think
On 2024-Jan-29, Alvaro Herrera wrote:
> In Dilip's patch to improve SLRU concurrency, there's a requirement to
> prevent predicate.c's SLRU control lock from being used to control
> access to another shared memory structure, SerialControlData. This
> struct is used to keep track of the areas of
I feel like this is the type of change where there's not much
discussion to be had. And the only way to resolve it is to use some
voting to gauge community opinion.
So my suggestion is for people to respond with -1, -0.5, +-0, +0.5, or
+1 to indicate support against/for the change.
I'll start:
1 - 100 of 139 matches
Mail list logo
