On Wed, Apr 3, 2024 at 8:38 AM shveta malik wrote:
>
> > > Or a simple solution is that the slotsync worker updates
> > > inactive_since as it does for non-synced slots, and disables
> > > timeout-based slot invalidation for synced slots.
>
> I like this idea better, it takes care of such a case
On Wed, Apr 3, 2024 at 9:36 AM Bharath Rupireddy
wrote:
>
> On Wed, Apr 3, 2024 at 9:04 AM Amit Kapila wrote:
> >
> > > I'd just rename LogicalSlotAdvanceAndCheckSnapState(XLogRecPtr
> > > moveto, bool *found_consistent_snapshot) to
> > > pg_logical_replication_slot_advance(XLogRecPtr moveto,
On 3/24/24 00:38, Peter Eisentraut wrote:> I have committed the patches
v33-0001-Add-temporal-FOREIGN-KEYs.patch and v33-0002-Support-multiranges-in-temporal-FKs.patch
(together).
Hi Hackers,
I found some problems with temporal primary keys and the idea of uniqueness, especially around the
Thanks to all for review, testing and commit!!!
On 2 April 2024 22:04:54 GMT+03:00, Tom Lane wrote:
>Akshat Jaimini writes:
>> The code seems to implement the feature and has good and explanatory
>> comments associated with it.
>> I believe we can go ahead with committing patch although I
On Wed, Apr 3, 2024 at 9:04 AM Amit Kapila wrote:
>
> > I'd just rename LogicalSlotAdvanceAndCheckSnapState(XLogRecPtr
> > moveto, bool *found_consistent_snapshot) to
> > pg_logical_replication_slot_advance(XLogRecPtr moveto, bool
> > *found_consistent_snapshot) and use it. If others don't like
On Tue, Mar 26, 2024 at 02:14:14PM -0500, Nathan Bossart wrote:
> On Mon, Jan 15, 2024 at 08:50:25AM -0600, Nathan Bossart wrote:
>> Thanks for reviewing. I've marked this as ready-for-committer, and I'm
>> hoping to commit it in the near future.
>
> This one probably ought to go into v17, but I
On Tue, Apr 2, 2024 at 7:42 PM Bharath Rupireddy
wrote:
>
> On Tue, Apr 2, 2024 at 7:25 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > > 1. Can we just remove pg_logical_replication_slot_advance and use
> > > LogicalSlotAdvanceAndCheckSnapState instead? If worried about the
> > > function naming,
On Tue, Apr 2, 2024 at 9:57 PM Amit Langote wrote:
>
> Please let me know if you have further comments on 0001. I'd like to
> get that in before spending more energy on 0002.
>
hi. some issues with the doc.
i think, some of the "path expression" can be replaced by
"path_expression".
maybe not
On Tue, Apr 2, 2024 at 11:58 AM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Tue, Apr 02, 2024 at 12:07:54PM +0900, Masahiko Sawada wrote:
> > On Mon, Apr 1, 2024 at 12:18 PM Bharath Rupireddy
> >
> > FWIW, coming to this thread late, I think that the inactive_since
> > should not be synchronized from
On Tue, Apr 02, 2024 at 05:20:20PM -0500, Nathan Bossart wrote:
> Sorry for the noise. I noticed a couple of silly mistakes immediately
> after sending v21.
Sigh... I missed a line while rebasing these patches, which seems to have
grossly offended cfbot. Apologies again for the noise.
--
Tomas Vondra writes:
> On 4/2/24 10:23, Andy Fan wrote:
>>
>>> On Wed, Mar 02, 2022 at 11:38:21AM -0600, Justin Pryzby wrote:
Rebased over 269b532ae and muted compiler warnings.
>>
>> Thank you Justin for the rebase!
>>
>> Hello Tomas,
>>
>> Thanks for the patch! Before I review the
Hi,
In
"Re: Commitfest Manager for March" on Mon, 1 Apr 2024 11:57:27 +0300,
Heikki Linnakangas wrote:
> On 01/04/2024 09:05, Andrey M. Borodin wrote:
>> I think it makes sense to close this commitfest only after Feature
>> Freeze on April 8, 2024 at 0:00 AoE.
>> What do you think?
>
>
On Tue, Apr 2, 2024 at 9:39 PM Thomas Munro wrote:
> So this is the version I'm going to commit shortly, barring objections.
And done, after fixing a small snafu with smgr-only reads coming from
CreateAndCopyRelationData() (BM_PERMANENT would be
incorrectly/unnecessarily set for unlogged
On Wed, Mar 27, 2024 at 11:27 AM Wolfgang Walther
wrote:
> The animal runs in a docker container via GitHub Actions in [2].
Great idea :-)
>
> Yeah, but that problem exists no matter what. I haven't read enough
> of the patch to find where it's determining that, but I assume there's
> code in there to intuit the statistics storage type depending on the
> table column's data type and the statistics kind.
>
Correct. It borrows a lot
On Tue, Apr 02, 2024 at 05:01:32PM -0500, Nathan Bossart wrote:
> In v21, 0001 is just the above inlining idea, which seems worth doing
> independent of $SUBJECT. 0002 and 0003 are the AVX-512 patches, which I've
> modified similarly to 0001, i.e., I've inlined the "fast" version in the
>
Jeff Davis writes:
> We need to get the original element type on the import side somehow,
> right? Otherwise it will be hard to tell whether '{1, 2, 3, 4}' has
> element type "int4" or "text", which affects the binary representation
> of the anyarray value in pg_statistic.
Yeah, but that problem
On Tue, Apr 02, 2024 at 01:40:21PM -0500, Nathan Bossart wrote:
> On Tue, Apr 02, 2024 at 01:43:48PM -0400, Tom Lane wrote:
>> I don't like the double evaluation of the macro argument. Seems like
>> you could get the same results more safely with
>>
>> static inline uint64
>>
On Tue, 2024-04-02 at 17:31 -0400, Tom Lane wrote:
> And that means that we don't need the sending
> side to know the element type anyway.
We need to get the original element type on the import side somehow,
right? Otherwise it will be hard to tell whether '{1, 2, 3, 4}' has
element type "int4"
>
> side to know the element type anyway. So, I apologize for sending
> us down a useless side path. We may as well stick to the function
> signature as shown in the v15 patch --- although maybe variadic
> any is still worthwhile so that an unrecognized field name doesn't
> need to be a hard
Jeff Davis writes:
> On the export side, the problem is that the element type (and
> dimensionality and maybe hasnull) is an important part of the anyarray
> value, but it's not part of the output of anyarray_out(). For new
> versions, we can add a scalar function that simply outputs the
>
On 2024-04-02 Tu 11:43, ShadowGhost wrote:
At the moment, this cast supports only these structures, as it was
enough for my tasks:
{str:numeric}
{str:str}
{str:bool}
{str:null}
But it's a great idea and I'll think about implementing it.
Please don't top-post on the PostgreSQL lists. See
> On 2 Apr 2024, at 20:55, Daniel Gustafsson wrote:
> The attached removes 1.0.2 support (meson build parts untested yet)
And a rebased version which applies over the hmac_openssl.c changes earlier
today that I hadn't pulled in.
--
Daniel Gustafsson
On Tue, 2024-04-02 at 12:59 -0400, Corey Huinker wrote:
> However, some of the ANYARRAYs have element types that are
> themselves arrays, and near as I can tell, such a construct is not
> expressible in SQL. So, rather than getting an anyarray of an array
> type, you instead get an array of one
Ranier Vilela writes:
> While I working in [1], Coverity reported some errors:
> src/bin/pg_basebackup/pg_createsubscriber.c
> CID 1542690: (#1 of 2): Out-of-bounds access (OVERRUN)
> alloc_strlen: Allocating insufficient memory for the terminating null of
> the string. [Note: The source code
On 2024-04-02 Tu 15:38, Jacob Champion wrote:
On Mon, Apr 1, 2024 at 4:53 PM Andrew Dunstan wrote:
Anyway, here are new patches. I've rolled the new semantic test into the
first patch.
Looks good! I've marked RfC.
Thanks! I appreciate all the work you've done on this. I will give it
one
Tom Lane wrote:
> > I should say that I've noticed significant latency improvements with
> > FETCH_COUNT retrieving large resultsets, such that it would benefit
> > non-interactive use cases.
>
> Do you have a theory for why that is? It's pretty counterintuitive
> that it would help at
On Tue, Apr 02, 2024 at 01:24:27PM -0400, Melanie Plageman wrote:
> On Tue, Apr 2, 2024 at 9:11 AM Heikki Linnakangas wrote:
> >
> > On 01/04/2024 20:22, Melanie Plageman wrote:
> > > Review for 0003-0006 (I didn't have any new thoughts on 0002). I know
> > > you didn't modify them much/at all,
> On 2 Apr 2024, at 22:46, Bruce Momjian wrote:
> On Tue, Apr 2, 2024 at 11:34:46AM +0200, Magnus Hagander wrote:
>> I do like the term "current" better. It conveys (at least a bit) that we
>> really consider all the older ones to be, well, obsolete. The difference
>> "current vs obsolete" is
On Tue, Apr 2, 2024 at 11:34:46AM +0200, Magnus Hagander wrote:
> On Tue, Apr 2, 2024 at 9:24 AM Daniel Gustafsson wrote:
> A few small comments:
>
> +considers performing minor upgrades to be less risky than continuing to
> +run superseded minor versions.
>
> I think
jian he writes:
> On Thu, Jan 18, 2024 at 4:17 PM Peter Eisentraut wrote:
>> Reading back through the discussion, I wasn't quite able to interpret
>> the resolution regarding Oracle compatibility. From the patch, it looks
>> like you chose not to adopt the parameter names from Oracle. Was that
On Tue, 2 Apr 2024 at 00:31, Nathan Bossart wrote:
> On Tue, Apr 02, 2024 at 12:11:59AM +0300, Ants Aasma wrote:
> > What about using the masking capabilities of AVX-512 to handle the
> > tail in the same code path? Masked out portions of a load instruction
> > will not generate an exception. To
"Daniel Verite" writes:
> Tom Lane wrote:
>> I do not buy that psql's FETCH_COUNT mode is a sufficient reason
>> to add it. FETCH_COUNT mode is not something you'd use
>> non-interactively
> I should say that I've noticed significant latency improvements with
> FETCH_COUNT retrieving
Tom Lane wrote:
> I do not buy that psql's FETCH_COUNT mode is a sufficient reason
> to add it. FETCH_COUNT mode is not something you'd use
> non-interactively
I should say that I've noticed significant latency improvements with
FETCH_COUNT retrieving large resultsets, such that it
> On Thu, 28 Mar 2024 at 04:34, Regina Obe wrote:
> > CREATE TABLE edge_data AS
> > SELECT i AS edge_id, i + 1 AS start_node, i + 2 As end_node FROM
> > generate_series(1,10) AS i;
> >
> > WITH edge AS (
> > SELECT start_node, end_node
> > FROM edge_data
> > WHERE edge_id = 1
> >
"Daniel Verite" writes:
> Robert Haas wrote:
>> Those links unfortunately seem not to be entirely specific to this
>> issue. Other, related things seem to be discussed there, and it's not
>> obvious that everyone agrees on what to do, or really that anyone
>> agrees on what to do.
> The
On Sun, 2024-03-31 at 21:18 +0530, Bharath Rupireddy wrote:
> if (table_modify_buffer_insert() is defined)
> table_modify_buffer_insert(...);
> else
> {
> myState->bistate = GetBulkInsertState();
> table_tuple_insert(...);
> }
We can't alloc/free the bulk insert state for every insert
On Mon, Apr 1, 2024 at 4:53 PM Andrew Dunstan wrote:
> Anyway, here are new patches. I've rolled the new semantic test into the
> first patch.
Looks good! I've marked RfC.
> json_lex() is not really a very hot piece of code.
Sure, but I figure if someone is trying to get the performance of the
Michael Paquier writes:
> On Fri, Mar 08, 2024 at 07:46:26PM +0900, Michael Paquier wrote:
>> Sounds good to me.
> I've applied the patch of this thread as b36fbd9f8da1, though I did
> not see a huge point in backpatching as at the end this is just a
> consistency improvement.
I've closed the
Akshat Jaimini writes:
> The code seems to implement the feature and has good and explanatory comments
> associated with it.
> I believe we can go ahead with committing patch although I would request some
> senior contributors to also take a look at this patch since I am relatively
> new to
> On 30 Mar 2024, at 22:27, Thomas Munro wrote:
> On Sun, Mar 31, 2024 at 9:59 AM Tom Lane wrote:
Thanks a lot for bringing this up again Thomas, 1.0.2 has bitten me so many
times and I'd be thrilled to get rid of it.
>> I think it's probably true that <=1.0.2 is not in any distro that
>> we
On Tue, Apr 02, 2024 at 01:43:48PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
>> On 2024-Apr-02, Nathan Bossart wrote:
>>> Another idea I had is to turn pg_popcount() into a macro that just uses the
>>> pg_number_of_ones array when called for few bytes:
>>>
>>> static inline uint64
>>>
Hackers,
In the Security lessons from liblzma thread[1], walther broached the subject of
an extension directory path[1]:
> Also a configurable directoy to look up extensions, possibly even to be
> changed at run-time like [2]. The patch says this:
>
>> This directory is prepended to paths
> On 2 Apr 2024, at 20:13, Ranier Vilela wrote:
> Fix by freeing the pointer, like pclose_check (src/common/exec.c) similar
> case.
Off the cuff, seems reasonable when loglevel is LOG.
--
Daniel Gustafsson
On 4/2/24 10:23, Andy Fan wrote:
>
>> On Wed, Mar 02, 2022 at 11:38:21AM -0600, Justin Pryzby wrote:
>>> Rebased over 269b532ae and muted compiler warnings.
>
> Thank you Justin for the rebase!
>
> Hello Tomas,
>
> Thanks for the patch! Before I review the path at the code level, I want
> to
Hi,
Per Coverity.
Coverity reported a resource leak at the function
run_ssl_passphrase_command.
7. alloc_fn: Storage is returned from allocation function
wait_result_to_str.["show details"]
8. noescape: Assuming resource wait_result_to_str(pclose_rc) is not freed
or pointed-to as ellipsis
Alvaro Herrera writes:
> On 2024-Apr-02, Nathan Bossart wrote:
>> Another idea I had is to turn pg_popcount() into a macro that just uses the
>> pg_number_of_ones array when called for few bytes:
>>
>> static inline uint64
>> pg_popcount_inline(const char *buf, int bytes)
>> {
>>
On 2024-Apr-02, Nathan Bossart wrote:
> Another idea I had is to turn pg_popcount() into a macro that just uses the
> pg_number_of_ones array when called for few bytes:
>
> static inline uint64
> pg_popcount_inline(const char *buf, int bytes)
> {
> uint64
On Tue, Apr 2, 2024 at 9:11 AM Heikki Linnakangas wrote:
>
> On 01/04/2024 20:22, Melanie Plageman wrote:
> > Review for 0003-0006 (I didn't have any new thoughts on 0002). I know
> > you didn't modify them much/at all, but I noticed some things in my code
> > that could be better.
>
> Ok, here's
On 01/04/2024 22:58, Melanie Plageman wrote:
Attached v7 has version 14 of the streaming read API as well as a few
small tweaks to comments and code.
I saw benchmarks in this thread to show that there's no regression when
the data is in cache, but I didn't see any benchmarks demonstrating the
I have refactored pg_set_relation_stats to be variadic, and I'm working on
pg_set_attribute_sttats, but I'm encountering an issue with the anyarray
values.
Jeff suggested looking at anyarray_send as a way of extracting the type,
and with some extra twiddling we can get and cast the type. However,
Robert Haas writes:
> On Tue, Apr 2, 2024 at 11:54 AM Tom Lane wrote:
>> I suspect that it'd behave poorly when there are both disabled and
>> promoted sub-paths in a tree, for pretty much the same reasons you
>> explained just upthread.
> Hmm, can you explain further? I think essentially you'd
"Daniel Verite" writes:
> Updated patches are attached.
I started to look through this, and almost immediately noted
-
- Retrieving Query Results Row-by-Row
+
+ Retrieving Query Results in chunks
This is a bit problematic, because changing the sect1 ID will
change the page's URL, eg
On Tue, Apr 2, 2024 at 11:54 AM Tom Lane wrote:
> > I'm pretty sure negative costs are going to create a variety of
> > unpleasant planning artifacts.
>
> Indeed. It might be okay to have negative values for disabled-ness
> if we treat disabled-ness as a "separate order of infinity", but
> I
Robert Haas writes:
> On Tue, Apr 2, 2024 at 10:04 AM Greg Sabino Mullane
> wrote:
>> if (!enable_seqscan)
>> startup_cost += disable_cost;
>> else if (promote_seqscan)
>> startup_cost -= promotion_cost; // or replace "promote" with "encourage"?
> I'm pretty sure negative costs are
On Mon, Apr 01, 2024 at 05:11:17PM -0500, Nathan Bossart wrote:
> Here is a v19 of the patch set. I moved out the refactoring of the
> function pointer selection code to 0001. I think this is a good change
> independent of $SUBJECT, and I plan to commit this soon. In 0002, I
> changed the
Matthias van de Meent writes:
> Attached is v9, which is rebased on master to handle 24eebc65's
> changed signature of pq_sendcountedtext.
> It now also includes autocompletion, and a second patch which adds
> documentation to give users insights into this new addition to
> EXPLAIN.
I took a
At the moment, this cast supports only these structures, as it was enough
for my tasks:
{str:numeric}
{str:str}
{str:bool}
{str:null}
But it's a great idea and I'll think about implementing it.
вт, 2 апр. 2024 г. в 19:48, Andrew Dunstan :
>
> On 2024-04-02 Tu 07:07, ShadowGhost wrote:
> > Hello
On 2024-04-02 13:15, Bharath Rupireddy wrote:
On Tue, Apr 2, 2024 at 3:41 PM Kartyshov Ivan
wrote:
8 years, we tried to add this feature, and now we suggest the best way
for this feature is to commit the minimal version first.
Just curious, do you or anyone else have an immediate use for
On Tue, 2024-04-02 at 11:49 +0300, Alexander Korotkov wrote:
> I don't like the idea that every custom table AM reltoptions should
> begin with StdRdOptions. I would rather introduce the new data
> structure with table options, which need to be accessed outside of
> table AM. Then reloptions
On Tue, 2024-04-02 at 05:38 -0400, Corey Huinker wrote:
> Here's a one-liner patch for disabling update of pg_class
> relpages/reltuples/relallviible during a binary upgrade.
This change makes sense to me regardless of the rest of the work.
Updating the relpages/reltuples/relallvisible during
On Tue, Apr 2, 2024 at 10:04 AM Greg Sabino Mullane wrote:
> So rather than listing all the things we don't want to happen, we need a way
> to force (nay, highly encourage) a particular solution. As our costing is a
> based on positive numbers, what if we did something like this in costsize.c?
On Tue Apr 2, 2024 at 9:32 AM CDT, Robert Haas wrote:
On Mon, Apr 1, 2024 at 12:04 PM Tristan Partin wrote:
> > This sentence seems a bit contorted to me, like maybe Yoda wrote it.
>
> Incorporated feedback, I have :).
Committed it, I did. My thanks for working on this issue, I extend.
On Mon, Apr 1, 2024 at 12:04 PM Tristan Partin wrote:
> > This sentence seems a bit contorted to me, like maybe Yoda wrote it.
>
> Incorporated feedback, I have :).
Committed it, I did. My thanks for working on this issue, I extend.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Tue, Apr 2, 2024 at 7:25 PM Zhijie Hou (Fujitsu)
wrote:
>
> > 1. Can we just remove pg_logical_replication_slot_advance and use
> > LogicalSlotAdvanceAndCheckSnapState instead? If worried about the
> > function naming, LogicalSlotAdvanceAndCheckSnapState can be renamed to
> >
On Mon, Apr 1, 2024 at 7:54 PM Robert Haas wrote:
> What I think we're mostly doing in the regression tests is shutting
> off every relevant type of plan except one. I theorize that what we
> actually want to do is tell the planner what we do want to happen,
> rather than what we don't want to
> On 2 Apr 2024, at 15:50, Tom Lane wrote:
> I'll go ahead with what I have.
+1
--
Daniel Gustafsson
On Tuesday, April 2, 2024 8:49 PM Bharath Rupireddy
wrote:
>
> On Tue, Apr 2, 2024 at 2:11 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > CFbot[1] complained about one query result's order in the tap-test, so I am
> > attaching a V7 patch set which fixed this. There are no changes in 0001.
> >
> >
Daniel Gustafsson writes:
> On 2 Apr 2024, at 02:01, Tom Lane wrote:
>> I don't think
>> it is helpful to put the resource owner manipulations inside #ifdef
>> HAVE_HMAC_CTX_NEW and HAVE_HMAC_CTX_FREE --- ...
>> What do you think of rearranging it as attached?
> +1 on this patch, it makes the
meson.build has this code
ldopts = run_command(perl, '-MExtUtils::Embed', '-e', 'ldopts',
check: true).stdout().strip() undesired =
run_command(perl_conf_cmd, 'ccdlflags', check:
true).stdout().split() undesired += run_command(perl_conf_cmd,
'ldflags', check:
On Fri, Mar 22, 2024 at 12:08 AM Amit Langote wrote:
>
> On Wed, Mar 20, 2024 at 9:53 PM Amit Langote wrote:
> > I'll push 0001 tomorrow.
>
> Pushed that one. Here's the remaining JSON_TABLE() patch.
>
I know v45 is very different from v47.
but v45 contains all the remaining features to be
On 01/04/2024 20:22, Melanie Plageman wrote:
Review for 0003-0006 (I didn't have any new thoughts on 0002). I know
you didn't modify them much/at all, but I noticed some things in my code
that could be better.
Ok, here's what I have now. I made a lot of small comment changes here
and there,
On Tue, Apr 2, 2024 at 2:11 PM Zhijie Hou (Fujitsu)
wrote:
>
> CFbot[1] complained about one query result's order in the tap-test, so I am
> attaching a V7 patch set which fixed this. There are no changes in 0001.
>
> [1] https://cirrus-ci.com/task/6375962162495488
Thanks. Here are some
On 2024-04-02 Tu 07:07, ShadowGhost wrote:
Hello all.
Recently, when working with the hstore and json formats, I came across
the fact that PostgreSQL has a cast of hstore to json, but there is no
reverse cast. I thought it might make it more difficult to work with
these formats. And I
On Tue, Apr 2, 2024 at 2:47 PM Andy Fan wrote:
> Bharath Rupireddy writes:
>
> > On Tue, Apr 2, 2024 at 3:41 PM Kartyshov Ivan
> > wrote:
> >>
> >> 8 years, we tried to add this feature, and now we suggest the best way
> >> for this feature is to commit the minimal version first.
> >
> > Just
Hi, Andrey!
On 31.03.2024 12:22, Andrey M. Borodin wrote:
On 15 Jan 2024, at 13:11, Anton A. Melnikov wrote:
If there are any ideas pro and contra would be glad to discuss them.
Hi, Anton!
This is kind of ancient thread. I've marked CF entry [0] as "Needs review" and
you as an author
On Tue, Apr 2, 2024 at 1:11 PM Kartyshov Ivan
wrote:
> On 2024-04-02 11:14, Andy Fan wrote:
> > If so, when users call pg_wal_replay_wait, they can get informed when
> > the wal is replaied to the target_lsn, but they can't know how long
> > time
> > it waits unless they check it in application
> On 2 Apr 2024, at 02:01, Tom Lane wrote:
> hmac_openssl.c:90:1: warning: unused function 'ResourceOwnerRememberHMAC'
> [-Wunused-function]
> hmac_openssl.c:95:1: warning: unused function 'ResourceOwnerForgetHMAC'
> [-Wunused-function]
>
> Looking at the code, this is all from commit
Bharath Rupireddy writes:
> On Tue, Apr 2, 2024 at 3:41 PM Kartyshov Ivan
> wrote:
>>
>> 8 years, we tried to add this feature, and now we suggest the best way
>> for this feature is to commit the minimal version first.
>
> Just curious, do you or anyone else have an immediate use for this
>
> On 2 Apr 2024, at 01:21, Nathan Bossart wrote:
>
> I haven't looked too closely, but I'm pretty skeptical that the test suite
> in your patch would be stable. Unfortunately, I don't have any better
> ideas at the moment besides not adding a test for this new role.
We can add tests just
Hello all.
Recently, when working with the hstore and json formats, I came across the
fact that PostgreSQL has a cast of hstore to json, but there is no reverse
cast. I thought it might make it more difficult to work with these formats.
And I decided to make a cast json in the hstore. I used the
On 2024-04-01 11:31, Masahiko Sawada wrote:
On Fri, Mar 29, 2024 at 11:54 AM torikoshia
wrote:
On 2024-03-28 21:54, Masahiko Sawada wrote:
> On Thu, Mar 28, 2024 at 9:38 PM torikoshia
> wrote:
>>
>> On 2024-03-28 10:20, Masahiko Sawada wrote:
>> > Hi,
>> >
>> > On Thu, Jan 18, 2024 at 5:33
On Tue, Apr 2, 2024 at 3:41 PM Kartyshov Ivan
wrote:
>
> 8 years, we tried to add this feature, and now we suggest the best way
> for this feature is to commit the minimal version first.
Just curious, do you or anyone else have an immediate use for this
function? If yes, how are they achieving
On 2024-04-02 11:14, Andy Fan wrote:
If so, when users call pg_wal_replay_wait, they can get informed when
the wal is replaied to the target_lsn, but they can't know how long
time
it waits unless they check it in application side, I think such
information will be useful for monitor purpose
Here's a one-liner patch for disabling update of pg_class
relpages/reltuples/relallviible during a binary upgrade.
This was causting pg_upgrade tests to fail in the existing stats import
work.
From 322db8c9e8796ce673f7d7b63bd64e4c9403a144 Mon Sep 17 00:00:00 2001
From: Corey Huinker
Date: Mon, 1
On Tue, Apr 2, 2024 at 9:24 AM Daniel Gustafsson wrote:
> > On 2 Apr 2024, at 00:56, Bruce Momjian wrote:
>
> > I ended up writing the attached doc patch. I found that some or our
> > text was overly-wordy, causing the impact of what we were trying to say
> > to be lessened. We might want to
On Wed, Mar 13, 2024 at 7:47 PM Jeremy Schneider
wrote:
>
> > On Mar 13, 2024, at 11:39 AM, Tom Lane wrote:
> >
> > Jeremy Schneider writes:
> >>> On 3/13/24 11:21 AM, Tom Lane wrote:
> >>> Agreed, we would probably add confusion not reduce it if we were to
> >>> change our longstanding
On 4/1/24 23:45, Thomas Munro wrote:
> ...
>>
>> I was very puzzled by the awful performance on ZFS. When every other fs
>> (EXT4/XFS/BTRFS) took 150-200 seconds to run pg_combinebackup, it took
>> 900-1000 seconds on ZFS, no matter what I did. I tried all the tuning
>> advice I could think of,
Hi,
On Tue, Apr 02, 2024 at 02:19:30PM +0530, Amit Kapila wrote:
> On Tue, Apr 2, 2024 at 1:54 PM Bertrand Drouvot
> wrote:
> > What about adding a "wait" injection point in LogStandbySnapshot() to
> > prevent
> > checkpointer/bgwriter to log a standby snapshot? Something among those
> >
Hi, Jeff!
On Tue, Apr 2, 2024 at 8:19 AM Jeff Davis wrote:
> On Sat, 2024-03-30 at 23:33 +0200, Alexander Korotkov wrote:
> > I've pushed 0001, 0002 and 0006.
>
> Sorry to jump in to this discussion so late. I had worked on something
> like the custom reloptions (0002) in the past, and there
On Tue, Apr 2, 2024 at 1:54 PM Bertrand Drouvot
wrote:
>
> On Tue, Apr 02, 2024 at 07:20:46AM +, Zhijie Hou (Fujitsu) wrote:
> > I added one test in 040_standby_failover_slots_sync.pl in 0002 patch, which
> > can
> > reproduce the data loss issue consistently on my machine.
>
> Thanks!
>
> >
On Tuesday, April 2, 2024 3:21 PM Zhijie Hou (Fujitsu)
wrote:
> On Tuesday, April 2, 2024 8:35 AM Zhijie Hou (Fujitsu)
> wrote:
> >
> > On Monday, April 1, 2024 7:30 PM Amit Kapila
> > wrote:
> > >
> > > On Mon, Apr 1, 2024 at 6:26 AM Zhijie Hou (Fujitsu)
> > >
> > > wrote:
> > > >
> > > > On
I had been planning to commit v14 this morning but got cold feet with
the BMR-based interface. Heikki didn't like it much, and in the end,
neither did I. I have now removed it, and it seems much better. No
other significant changes, just parameter types and inlining details.
For example:
*
Hi,
On Tue, Apr 02, 2024 at 12:41:35PM +0530, Bharath Rupireddy wrote:
> On Tue, Apr 2, 2024 at 11:58 AM Bertrand Drouvot
> wrote:
> >
> > > Or a simple solution is that the slotsync worker updates
> > > inactive_since as it does for non-synced slots, and disables
> > > timeout-based slot
> On Wed, Mar 02, 2022 at 11:38:21AM -0600, Justin Pryzby wrote:
>> Rebased over 269b532ae and muted compiler warnings.
Thank you Justin for the rebase!
Hello Tomas,
Thanks for the patch! Before I review the path at the code level, I want
to explain my understanding about this patch first.
Hi,
On Tue, Apr 02, 2024 at 07:20:46AM +, Zhijie Hou (Fujitsu) wrote:
> I added one test in 040_standby_failover_slots_sync.pl in 0002 patch, which
> can
> reproduce the data loss issue consistently on my machine.
Thanks!
> It may not reproduce
> in some rare cases if concurrent
Hi Alexander!
>> +
>> +pg_wal_replay_wait (
>> + target_lsn pg_lsn,
>> + timeout bigint
>> DEFAULT 0)
>> +void
>> +
>>
>> Should we return the millseconds of waiting time? I think this
>> information may be useful for customer if they want to
Hi, Andy!
On Tue, Apr 2, 2024 at 6:29 AM Andy Fan wrote:
> > Did you forget to attach the new patch?
> >
> > Yes, here it is.
> >
> > [4. text/x-diff;
> > v17-0001-Implement-pg_wal_replay_wait-stored-procedure.patch]...
>
> +
> +pg_wal_replay_wait (
> + target_lsn
On Mon, Apr 1, 2024 at 10:41 PM vignesh C wrote:
>
> On Thu, 28 Mar 2024 at 13:05, Masahiko Sawada wrote:
> >
> > Hi,
> >
> > Thank you for the patch!
> >
> > On Mon, Jul 3, 2023 at 12:12 AM vignesh C wrote:
> > >
> > > Hi,
> > >
> > > Improved tab completion for "ALTER DEFAULT PRIVILEGE" and
Hi,
Thanks for the review!
On Wed, 27 Mar 2024 at 23:15, Melanie Plageman
wrote:
>
> On Tue, Mar 26, 2024 at 02:51:27PM +0300, Nazir Bilal Yavuz wrote:
> > Hi,
> >
> > On Wed, 28 Feb 2024 at 14:42, Nazir Bilal Yavuz wrote:
> > >
> > >
> > > The new version of the streaming read API [1] is
1 - 100 of 105 matches
Mail list logo
