On Fri, Jul 5, 2024 at 05:11:22PM -0400, Bruce Momjian wrote:
> Wow, I see that now:
>
> test=> SELECT 'now('::timestamptz;
> timestamptz
> ---
>2024-07-05 17:04:33.457915-04
>
> If I remove the 'now()' mention in the docs, patch at
On Fri, 01 Nov 2024 at 21:47, David Rowley wrote:
> On Fri, 1 Nov 2024 at 20:49, Michael Paquier wrote:
>>
>> On Fri, Nov 01, 2024 at 07:44:22AM +, Bertrand Drouvot wrote:
>> > Worth to add a comment as to why pg_memory_is_all_zeros() should not
>> > be used here?
>>
>> I would not add one in
Hi!
On Fri, 25 Oct 2024 at 17:01, Andrey M. Borodin wrote:
>
>
>
> > On 25 Oct 2024, at 00:55, Rahila Syed wrote:
> >
> > While writing this email, I realized I evicted buffers for the table
> > and not the index. I will perform the test again. However,
> > I would like to know your opinion on w
On Fri, 01 Nov 2024 at 09:33, Dean Rasheed wrote:
> On Wed, 16 Oct 2024 at 08:43, Andy Fan wrote:
>>
>> Thanks for the detailed feedback! Here is the rebased version.
>>
>
> I took another look at this and I think it's in reasonable shape.
>
> I'm attaching an update, rebasing it on top of 9be4e
Hi,
On 2024-10-29 15:00:02 -0700, Jeff Davis wrote:
> On Wed, 2024-04-03 at 16:12 +0300, Melih Mutlu wrote:
> > Rebased. PSA.
>
> Thank you. I missed your patch and came up with a similar patch over
> here:
>
> https://www.postgresql.org/message-id/flat/78599c442380ddb5990117e281a4fa65a74231af.ca.
On Fri, 2024-11-01 at 15:19 -0400, Andres Freund wrote:
> I'm a bit worried about the increase in "wasted" memory we might end
> up when
> creating one aset for *everything*. Just splitting out Relcache and
> CatCache
> isn't a big deal from that angle, they're always used reasonably
> much. But
>
Hi all,
Here's a v4, with a separate wait event for each location. (I could
use some eyes on the specific phrasing I've chosen for each one.)
On Sun, Sep 1, 2024 at 5:10 PM Michael Paquier wrote:
> Could it be more transparent to use a "startup" or
> "starting"" state instead that gets also used
On Fri, Nov 1, 2024 at 3:20 PM Tom Lane wrote:
> Michel Pelletier writes:
>
> Well, you shouldn't be using PERFORM. Not only does it not do the
> right thing, but it's not optimized for expanded objects at all:
> they'll get flattened both on the way into the statement and on
> the way out. Tr
On Fri, Nov 1, 2024 at 3:27 PM Tom Lane wrote:
> Michel Pelletier writes:
>
> Here is a v1 patch series that does the first part of what we've been
> talking about, which is to implement the new optimization rule for
> the case of a single RHS reference to the target variable. I'm
> curious to
HI, all hackers:
In the GitHub repository for PostgreSQL’s pg_hint_plan extension, there is an
issue where the generated join order does not match the assigned join order.
After reviewing the source code, I found that this inconsistency with input
hints is due to PostgreSQL’s implementation and
On Fri, Nov 1, 2024 at 11:13:09AM +0800, 李奇隆 wrote:
> HI, all hackers:
>
>
> In the GitHub repository for PostgreSQL’s pg_hint_plan extension, there is an
> issue where the generated join order does not match the assigned join order.
> After reviewing the source code, I found that this inconsist
> On 1 Nov 2024, at 12:51, Nazir Bilal Yavuz wrote:
>
> am not
> sure whether 'BufferStrategyControl.lastFreeBuffer -
> BufferStrategyControl.firstFreeBuffer' is safe to use.
Ugh... it will work. But it seems to me too dirty hack. There's no scalable way
to know size of a free list.
Let's j
Hi,
On 2024-10-30 09:58:30 -0400, Andres Freund wrote:
> On 2024-10-30 14:16:51 +0200, Heikki Linnakangas wrote:
> > Could we put the overhead on the FlushBuffer()
> > instead?
> >
> > How about something like this:
> >
> > To set hint bits:
> >
> > 1. Lock page in SHARED mode.
> > 2. Read BM_IO_I
On Thu, 31 Oct 2024 at 18:51, Melanie Plageman
wrote:
>
> Would it also be useful to have the number set all-visible? It seems
> like if we added a new line prefixed with visibility map, it ought to
> include all-visible and all-frozen then.
> Something like this:
> visibility map: %u pages set
On Fri, Nov 1, 2024 at 2:21 AM Richard Guo wrote:
> ... an aggregated row from the partial
> aggregation matches the other side of the join if and only if each row
> in the partial group does, thereby ensuring that all rows in the same
> partial group have the same 'destiny'.
Ah, I really like th
> On Fri, Oct 18, 2024 at 09:21:19PM GMT, Dmitry Dolgov wrote:
>
> TL;DR A PoC for changing shared_buffers without PostgreSQL restart, via
> changing shared memory mapping layout. Any feedback is appreciated.
It was pointed out to me, that earlier this year there was a useful
discussion about simi
On Fri, 1 Nov 2024 at 15:43, Kirill Reshke wrote:
>
> Hi hackers!
>
> I have been working on cloudberry/greenplum tab completion features,
> and I spotted that the postgres version of psql does not tab-complete
> ALTER TABLE ADD COLUMN IF NOT EXISTS pattern.
> So, I propose to support this.
>
> --
On Fri, 2024-11-01 at 14:08 +0100, Andreas Karlsson wrote:
> > Agreed -- a lot of work has gone into optimizing the regex code,
> > and we
> > don't want a perf regression there. But I'm also not sure exactly
> > which
> > kinds of tests I should be running for that.
>
> I think we should at least
Hi!
I've checked set_subquery_pathlist(), and would rather say that it has
a different purpose and I'd better not compare these functions directly.
generate_orderedappend_paths() was introduced 6 years ago, and
commit that considers tuple_fraction authored by Tomas Vondra
was suggested by Tom Lan
On Mon, Oct 28, 2024 at 01:07:16PM +0100, Daniel Gustafsson wrote:
> > On 17 Oct 2024, at 00:35, Bruce Momjian wrote:
> > On Tue, Jul 16, 2024 at 08:23:11AM -0400, Andrew Dunstan wrote:
>
> >> See https://postgr.es/m/4acddcd4-1c08-44e7-ba60-cab102259...@dunslane.net
> >>
> >> I agree we should
Hi everyone,
> I upgraded to Meson 1.6.0 and Lcov 2.0-1. Unfortunately it doesn't work:
> [...]
> I didn't investigate further.
Lcov 2.1 and 2.2beta don't work either.
--
Best regards,
Aleksander Alekseev
On 10/26/24 12:42 AM, Jeff Davis wrote:
On Thu, 2024-10-24 at 10:05 +0200, Andreas Karlsson wrote:
Why is there no pg_locale_builtin.c?
Just that it would be a fairly small file, but I'm fine with doing
that.
I think adding such a small file would make life easier for people new
to the coll
On Fri, Nov 1, 2024 at 5:12 AM Alastair Turner wrote:
>
> On Thu, 31 Oct 2024 at 18:51, Melanie Plageman
> wrote:
>>
>>
>> Would it also be useful to have the number set all-visible? It seems
>> like if we added a new line prefixed with visibility map, it ought to
>> include all-visible and all-
On Fri, Nov 1, 2024 at 12:23 PM Masahiko Sawada wrote:
> Having "marked by this operation" twice seems to be redundant. How
> about something like the output below?
>
> visibility map: %u pages set all-visible (%u pages total), %u pages
> set all-frozen (%u pages total)
For me, the meaning of tha
On 01/11/2024 14:56, 송영욱 wrote:
Hi hackers,
I’m currently studying the internals of PostgreSQL, specifically the
vacuum process.
I've learned that PostgreSQL’s MVCC model has had issues in the past,
such as XID wraparound and table bloating problems. It seems that these
issues may have been
On Thu, Oct 31, 2024 at 1:43 PM Bruce Momjian wrote:
> > I am not a fan of this patch. I don't see why _removing_ the
> magnetic
> > part helps because you then have no logic for any 1.2 was chosen.
> >
> > Okay, but we have no documented logic on why 4.0 was chosen either. :)
>
> Uh, we
> On 31 Oct 2024, at 23:04, Stepan Neretin wrote:
>
>
> Firstly, I'd like to discuss the increased_clock_precision variable, which
> currently divides the timestamp into milliseconds and nanoseconds. However,
> this approach only approximates the extra bits for sub-millisecond
> precision, le
Hi,
On Fri, Nov 01, 2024 at 09:47:05PM +1300, David Rowley wrote:
> On Fri, 1 Nov 2024 at 20:49, Michael Paquier wrote:
> >
> > On Fri, Nov 01, 2024 at 07:44:22AM +, Bertrand Drouvot wrote:
> > > Worth to add a comment as to why pg_memory_is_all_zeros() should not
> > > be used here?
> >
> >
Bruce Momjian writes:
> On Fri, Nov 1, 2024 at 11:13:09AM +0800, 李奇隆 wrote:
>> In the GitHub repository for PostgreSQL’s pg_hint_plan extension, there is an
>> issue where the generated join order does not match the assigned join order.
>> After reviewing the source code, I found that this incons
On Wed, Oct 16, 2024 at 09:54:57AM -0400, Bruce Momjian wrote:
> On Wed, Oct 16, 2024 at 10:00:15AM +0200, Peter Eisentraut wrote:
> > On 15.10.24 23:51, Bruce Momjian wrote:
> > > On Tue, Oct 15, 2024 at 05:27:49PM -0400, Tom Lane wrote:
> > > > Bruce Momjian writes:
> > > > > Well, we can only u
>
> $ psql "postgres://localhost:5432/postgres?application_name=a b"
> psql: error: trailing data found: "a b"
>
This works fine for me, and sets a space in the application_name string as
expected. Do you have a different example?
Cheers,
Greg
Hi,
> Thanks for the hint. I'm using Meson 1.3.2. Although it's not ancient
> (Feb 2024) there is 1.6.0 available. I'll try upgrading and let you
> know the results.
I upgraded to Meson 1.6.0 and Lcov 2.0-1. Unfortunately it doesn't work:
```
genhtml: ERROR: no data for line:864, TLA:UNC,
file:/
Hi hackers,
I’m currently studying the internals of PostgreSQL, specifically the vacuum
process.
I've learned that PostgreSQL’s MVCC model has had issues in the past, such
as XID wraparound and table bloating problems. It seems that these issues
may have been mitigated by implementing features li
On Wed, Oct 30, 2024 at 9:01 AM Peter Eisentraut
wrote:
> On 27.10.24 13:37, Torsten Förtsch wrote:
> > The attached patch enables pg_recvlogical to create a temporary slot.
>
> I think you should explain a bit why you want to do that, what use case
> or scenario this is meant to address.
>
In m
On 01.11.24 12:53, Alvaro Herrera wrote:
On 2024-Oct-31, Daniel Gustafsson wrote:
When looking at our Git tree for a recent conference presentation I happened to
notice that we have recently gained duplicate names in the shortlog. Not sure
if we care enough to fix that with a .mailmap, but if
On Tue, 2024-10-29 at 08:16 +0100, Pavel Stehule wrote:
> again, necessary rebase
I have started looking at patch 5, and I have some questions and comments.
- The commit message is headed "memory cleaning after DROP VARIABLE", but
the rest of the commit message speaks of sinval messages. These
I have pushed Release 18 of the PostgreSQL Buildfarm client
In addition to numerous minor tweaks and bug fixes, the following changes
are made:
- many improvements in the collection of log files
- accommodate change in data checksum default in cross version upgrade
testing
- increase
Hi,
Thanks for the patch!
On 2024-11-01 12:17:00 +0300, Nazir Bilal Yavuz wrote:
> I made these tasks triggered manually like MinGW task to save CI credits
> but a related line is commented out for now to trigger CFBot.
Oh, I need to pick my patch which allows repo-level config of which tasks r
On Thu, Oct 31, 2024 at 09:20:52PM -0700, Noah Misch wrote:
> Here, one of the autovacuum workers had the guilty stack trace, appearing at
> the end of this message. heap_inplace_update_and_unlock() calls
> CacheInvalidateHeapTupleInplace() while holding BUFFER_LOCK_EXCLUSIVE on a
> buffer of pg_c
> Yes, we _allow_ LATIN1 characters in the SGML docs, but I replaced the
> LATIN1 characters we had with HTML entities, so there are none
> currently.
>
> I think it is too easy for non-Latin1 UTF8 to creep into our SGML docs
> so I added a cron job on my server to alert me when non-ASCII characte
On Thu, Oct 31, 2024 at 03:32:39PM +0900, Michael Paquier wrote:
> @Tom added in CC: Is there a specific reason why CheckTransactionBlock()
> did not include a check based on XACT_FLAGS_PIPELINING when it got
> introduced in 20432f873140, while IsInTransactionBlock() considers it?
This also makes
Michel Pelletier writes:
> Here's two backtraces from gdb from this function:
> CREATE OR REPLACE FUNCTION test2(graph matrix)
> RETURNS bigint LANGUAGE plpgsql AS
> $$
> BEGIN
> perform set_element(graph, 1, 1, 1);
> RETURN nvals(graph);
> end;
> $$;
Well, you shouldn
Hi Bruce,
> On Wed, Oct 16, 2024 at 09:54:57AM -0400, Bruce Momjian wrote:
>> On Wed, Oct 16, 2024 at 10:00:15AM +0200, Peter Eisentraut wrote:
>> > On 15.10.24 23:51, Bruce Momjian wrote:
>> > > On Tue, Oct 15, 2024 at 05:27:49PM -0400, Tom Lane wrote:
>> > > > Bruce Momjian writes:
>> > > > > W
Hi,
On 2024-11-01 14:47:37 -0700, Jeff Davis wrote:
> On Fri, 2024-11-01 at 15:19 -0400, Andres Freund wrote:
> > I'm a bit worried about the increase in "wasted" memory we might end
> > up when
> > creating one aset for *everything*. Just splitting out Relcache and
> > CatCache
> > isn't a big de
Michel Pelletier writes:
> That all sounds great, and it sounds like my prosupport function just needs
> to return true, or set some kind of flag saying aliasing is ok. I'd like
> to help as much as possible, but some of that reparenting stuff was pretty
> deep for me, other than being a quick sa
On Sat, Nov 2, 2024 at 07:27:00AM +0900, Tatsuo Ishii wrote:
> > On Wed, Oct 16, 2024 at 09:54:57AM -0400, Bruce Momjian wrote:
> >> On Wed, Oct 16, 2024 at 10:00:15AM +0200, Peter Eisentraut wrote:
> >> > On 15.10.24 23:51, Bruce Momjian wrote:
> >> > > On Tue, Oct 15, 2024 at 05:27:49PM -0400, T
On Fri, Nov 1, 2024 at 10:33 AM Andrey M. Borodin wrote:
>
>
>
> > On 31 Oct 2024, at 23:04, Stepan Neretin wrote:
> >
> >
> > Firstly, I'd like to discuss the increased_clock_precision variable, which
> > currently divides the timestamp into milliseconds and nanoseconds. However,
> > this approa
On Wed, Oct 30, 2024 at 4:54 AM Joel Jacobson wrote:
>
> On Wed, Oct 30, 2024, at 09:14, Joel Jacobson wrote:
> > $ psql -f bench_result.sql
>
> Ops, I realized I benchmarked a debug build,
> reran the benchmark with `meson setup build --buildtype=release`,
> and also added benchmarking of HEAD:
>
On Fri, Nov 1, 2024 at 9:41 AM Robert Haas wrote:
>
> On Fri, Nov 1, 2024 at 12:23 PM Masahiko Sawada wrote:
> > Having "marked by this operation" twice seems to be redundant. How
> > about something like the output below?
> >
> > visibility map: %u pages set all-visible (%u pages total), %u page
This is another version of the patch. It now includes tests.
On Fri, Nov 1, 2024 at 1:42 PM Torsten Förtsch
wrote:
> On Wed, Oct 30, 2024 at 9:01 AM Peter Eisentraut
> wrote:
>
>> On 27.10.24 13:37, Torsten Förtsch wrote:
>> > The attached patch enables pg_recvlogical to create a temporary slo
On Fri, 1 Nov 2024 at 19:27, Michael Paquier wrote:
> Under gcc -O2 or -O3, the single-byte check or the 8-byte check don't
> make a difference. Please see the attached (allzeros.txt) for a quick
> check if you want to check by yourself. With 1M iterations, both
> average around 3ms for 1M itera
Hi,
On Wed, Oct 23, 2024 at 10:48 PM Tender Wang wrote:
> I think the root cause of this thread and [1] are same. We don't use the
> Partition Key collation but column's
> collation to fill the RelOptInfo partexprs field in
> set_baserel_partition_key_exprs().
> If the Partition Key definition
On Fri, Nov 01, 2024 at 08:21:50PM +1300, David Rowley wrote:
> My vote is to just revert this usage of the function. Anything more
> elaborate would need to check pointer alignment before using any types
> larger than char. The previous code does not need to do that because
> the page is going to
Hi,
On Fri, Nov 01, 2024 at 04:36:45PM +0900, Michael Paquier wrote:
> On Fri, Nov 01, 2024 at 08:21:50PM +1300, David Rowley wrote:
> > My vote is to just revert this usage of the function. Anything more
> > elaborate would need to check pointer alignment before using any types
> > larger than ch
On Fri, Nov 01, 2024 at 07:44:22AM +, Bertrand Drouvot wrote:
> Thanks!
Cool, will fix that in a bit.
> Worth to add a comment as to why pg_memory_is_all_zeros() should not
> be used here?
I would not add one in bufpage.c, documenting that where
pg_memory_is_all_zeros() is defined may be mor
On Fri, Nov 01, 2024 at 06:33:51AM +, Bertrand Drouvot wrote:
> We could try to write a more elaborate version of pg_memory_is_all_zeros(),
> but
> as it looks like there is only one use case, then it's probably better to not
> implement (revert) this change here and "just" add a comment as to
On Fri, 1 Nov 2024 at 19:33, Bertrand Drouvot
wrote:
> Agree, I did a quick test (see [0]) and it looks like it's significantly
> slower
> using the new inline function.
>
> We could try to write a more elaborate version of pg_memory_is_all_zeros(),
> but
> as it looks like there is only one use
On Fri, 1 Nov 2024 at 20:14, Michael Paquier wrote:
> 2) On HEAD at 49d6c7d8daba:
> .LVL299:
>.loc 1 131 16 is_stmt 0 discriminator 1 view .LVU524
>cmpq$8192, %rbx
>je .L419
>
> 3) With the patch sent at [1]:
> .LVL306:
>.loc 3 201 23 is_stmt 1 discriminator 1 view .LVU545
Amit Langote 于2024年11月1日周五 15:27写道：
> Hi,
>
> On Wed, Oct 23, 2024 at 10:48 PM Tender Wang wrote:
> > I think the root cause of this thread and [1] are same. We don't use
> the Partition Key collation but column's
> > collation to fill the RelOptInfo partexprs field in
> set_baserel_partition_k
Dear Vignesh,
Thanks for rebasing the patch! Before reviewing deeply, I want to confirm the
specification.
I understood like below based on the documentation.
- If publish_generated_columns is false, the publication won't replicate
generated columns
- If publish_generated_columns is true, the b
Hi,
On Thu, Oct 31, 2024 at 12:06:25PM -0400, Robert Haas wrote:
> On Thu, Oct 31, 2024 at 11:41 AM Bertrand Drouvot
> wrote:
> > I'm not sure about 0001 but I think 0002 deserves a back patch as I think
> > it fits
> > into the "low-risk fixes" category [0].
>
> I'm inclined to back-patch both
just a quick reply while testing v4-0001.
tests copy from src/test/regress/sql/partition_aggregate.sql first 40 lines.
drop table if exists pagg_tab;
CREATE TABLE pagg_tab (a int, b int, c text, d int) PARTITION BY
LIST(c collate "C");
CREATE TABLE pagg_tab_p1 PARTITION OF pagg_tab FOR VALUES IN (
Hi,
Thanks for looking into this!
On Thu, 31 Oct 2024 at 21:18, Andrey M. Borodin wrote:
>
> > On 8 Aug 2024, at 11:32, Nazir Bilal Yavuz wrote:
> >
> > Any feedback would be appreciated.
>
> I've took a look into the patch. It seems to me that you add new block
> numbers to the read stream un
On Fri, 1 Nov 2024 at 20:49, Michael Paquier wrote:
>
> On Fri, Nov 01, 2024 at 07:44:22AM +, Bertrand Drouvot wrote:
> > Worth to add a comment as to why pg_memory_is_all_zeros() should not
> > be used here?
>
> I would not add one in bufpage.c, documenting that where
> pg_memory_is_all_zeros
> On Nov 1, 2024, at 16:24, Heikki Linnakangas wrote:
>
> On 01/11/2024 09:19, feichanghong wrote:
>> Hi hackers,
>> In the _bt_killitems function, the following logic is present: we search to
>> the right for an index item that matches the heap TID and attempt to mark it
>> as dead. If that
Hi,
Thanks for looking into this!
On Thu, 31 Oct 2024 at 22:02, Stepan Neretin wrote:
>
> At first A quick look it looks good. I will take a closer look at it
> tomorrow. Could you please let me know about the performance tests and
> graphics?
Sorry but I didn't understand what you mean by pe
Hello hackers,
Please take a look at the October report on buildfarm failures:
# SELECT br, count(*) FROM failures WHERE dt >= '2024-10-01' AND
dt < '2024-11-01' GROUP BY br;
REL_12_STABLE: 9
REL_13_STABLE: 9
REL_14_STABLE: 19
REL_15_STABLE: 25
REL_16_STABLE: 12
REL_17_STABLE: 14
master: 109
--
On Fri, Nov 1, 2024 at 5:08 PM jian he wrote:
> just a quick reply while testing v4-0001.
> tests copy from src/test/regress/sql/partition_aggregate.sql first 40 lines.
>
> drop table if exists pagg_tab;
> CREATE TABLE pagg_tab (a int, b int, c text, d int) PARTITION BY
> LIST(c collate "C");
> CR
Hi,
NetBSD and OpenBSD Postgres CI images are generated [1] but their tasks are
not added to the upstream Postgres yet. The attached patch adds NetBSD and
OpenBSD tasks to the Postgres CI.
I made these tasks triggered manually like MinGW task to save CI credits
but a related line is commented out
On Wed, 16 Oct 2024 at 08:43, Andy Fan wrote:
>
> Thanks for the detailed feedback! Here is the rebased version.
>
I took another look at this and I think it's in reasonable shape.
I'm attaching an update, rebasing it on top of 9be4e5d293.
Also it was missing a required update to the meson.bui
On 01/11/2024 09:19, feichanghong wrote:
Hi hackers,
In the _bt_killitems function, the following logic is present: we
search to the right for an index item that matches the heap TID and
attempt to mark it as dead. If that index item has already been
marked as dead by other concurrent process
Hi hackers!
I have been working on cloudberry/greenplum tab completion features,
and I spotted that the postgres version of psql does not tab-complete
ALTER TABLE ADD COLUMN IF NOT EXISTS pattern.
So, I propose to support this.
--
Best regards,
Kirill Reshke
v1-0001-Add-missing-psql-tab-comple
Hi,
On Fri, Nov 1, 2024 at 11:39 AM Tender Wang wrote:
> Amit Langote 于2024年10月31日周四 21:09写道：
>> On Wed, Oct 30, 2024 at 9:36 PM Junwang Zhao wrote:
>> > On Wed, Oct 30, 2024 at 11:58 AM jian he
>> > wrote:
> In have_partkey_equi_join()
> ...
> if (exprs_known_equal(root, expr1, expr2, btree_
Hi hackers,
In the _bt_killitems function, the following logic is present: we search to the
right for an index item that matches the heap TID and attempt to mark it as
dead. If that index item has already been marked as dead by other concurrent
processes, we will continue searching. However, there
Hi,
On Fri, Nov 1, 2024 at 2:39 PM jian he wrote:
> On Thu, Oct 31, 2024 at 9:09 PM Amit Langote wrote:
> >
> >
> > I think we should insist that the join key collation and the partition
> > collation are exactly the same and refuse to match them if they are
> > not.
> >
> > + {
> > +
On 01/11/2024 10:41, feichanghong wrote:
On Nov 1, 2024, at 16:24, Heikki Linnakangas wrote:
On 01/11/2024 09:19, feichanghong wrote:
Hi hackers,
In the _bt_killitems function, the following logic is present: we
search to the right for an index item that matches the heap TID and
attempt t
On 01.11.24 10:17, Nazir Bilal Yavuz wrote:
NetBSD and OpenBSD Postgres CI images are generated [1] but their tasks
are not added to the upstream Postgres yet. The attached patch adds
NetBSD and OpenBSD tasks to the Postgres CI.
I made these tasks triggered manually like MinGW task to save CI
Currently we document the message size length as a constant like
Int32(5) for some message types in the frontend backend protocol
doument[1].
ReadyForQuery (B)
Byte1('Z')
Identifies the message type. ReadyForQuery is sent whenever the backend
is ready for a new query cycle.
Int3
On 2024-Oct-31, Daniel Gustafsson wrote:
> When looking at our Git tree for a recent conference presentation I happened
> to
> notice that we have recently gained duplicate names in the shortlog. Not sure
> if we care enough to fix that with a .mailmap, but if we do the attached diff
> makes sur
79 matches
Mail list logo
