On 07.10.22 18:43, Robert Haas wrote:
On Fri, Oct 7, 2022 at 8:10 AM Peter Eisentraut
wrote:
The only drawback in terms of code robustness is that someone adding a
new shared object type would have to remember to add it to
EventTriggerSupportsObjectType().
This doesn't seem like a good idea t
On Wed, Oct 12, 2022 at 12:50 PM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
>
> On 05.10.22 22:07, Andres Freund wrote:
> > 0001: autoconf: Unify CFLAGS_SSE42 and CFLAGS_ARMV8_CRC32C
>
> I wonder, there has been some work lately to use SIMD and such in other
> places. Would that
On Wed, Sep 07, 2022 at 10:48:39AM +0200, Drouvot, Bertrand wrote:
> + if (bistate)
> + {
> + table_finish_bulk_insert(toastrel, options); // XXX
>
> I think it's too early, as it looks to me that at this stage we may have not
> finished the whole bulk insert yet.
Yeah,
On Mon, Oct 03, 2022 at 12:55:40PM +0100, Dave Page wrote:
> Thanks. It's just the changes in xact.c, so it doesn't seem like it would
> cause you any more work either way, in which case, I'll leave it to you :-)
Okay, I have just moved the patch to the next CF then, still marked as
ready for comm
Dear Sawada-san,
> FYI, as I just replied to the related thread[1], the assertion failure
> in REL14 and REL15 can be fixed by the patch proposed there. So I'd
> like to see how the discussion goes. Regardless of this proposed fix,
> the patch proposed by Kuroda-san is required for HEAD, REL14, an
>
> The feedback was pretty positive, so I dug through all the tests to at
> least get to the point where I could see the end of it. The attached
> patch 0001 is the actual code and documentation changes. The 0002 patch
> is just tests randomly updated or disabled to make the whole suite pass.
>
Hi,
On 10/11/22 8:29 AM, Michael Paquier wrote:
On Mon, Oct 10, 2022 at 09:00:06AM +0200, Drouvot, Bertrand wrote:
foreach(cell, tokens)
{
[...]
+ tokreg = lfirst(cell);
+ if (!token_is_regexp(tokreg))
{
- if (str
On Wed, Oct 12, 2022 at 10:09 AM Ankit Oza wrote:
>
> Thanks Ashutosh,
>
> Actually we use the Postgres service offered by Azure (Flexible server). So,
> I was looking at the following documentation which talks about Logical
> Replication and Logical Decoding as two different methods of replicat
On Wed, Sep 7, 2022 at 11:06 AM kuroda.hay...@fujitsu.com
wrote:
>
> Dear Amit,
>
> Thanks for giving comments!
>
> > Did you get this new assertion failure after you applied the patch for
> > the first failure? Because otherwise, how can you reach it with the
> > same test case?
>
> The first fai
On Tue, Oct 11, 2022 at 7:00 PM Ajin Cherian wrote:
>
I was going through 0001 patch and I have a few comments/suggestions.
1.
@@ -6001,7 +6001,7 @@ getObjectIdentityParts(const ObjectAddress *object,
transformType = format_type_be_qualified(transform->trftype);
On Tue, Oct 11, 2022 at 5:52 AM Masahiko Sawada wrote:
>
> On Fri, Oct 7, 2022 at 2:00 PM Amit Kapila wrote:
> >
> > About your point that having different partition structures for
> > publisher and subscriber, I don't know how common it will be once we
> > have DDL replication. Also, the default
On Tue, Aug 16, 2022 at 02:58:43PM +0800, Julien Rouhaud wrote:
> I don't think that's an improvement. With this patch if you see the
> "paral_planned_not_exec" counter going up, you still don't know if this is
> because of the !es_use_parallel_mode or if you simply have too many parallel
> querie
On Sat, Sep 17, 2022 at 12:29 PM Nathan Bossart
wrote:
>
> On Fri, Sep 16, 2022 at 02:54:14PM +0700, John Naylor wrote:
> > v6 demonstrates why this should have been put off towards the end.
(more below)
>
> Since the SIMD code is fresh in my mind, I wanted to offer my review for
> 0001 in the "Im
Dear Sawada-san,
Thank you for reviewing HEAD patch! PSA v3 patch.
> +# Test that we can force the top transaction to do timetravel when one of sub
> +# transactions needs that. This is necessary when we restart decoding
> from RUNNING_XACT
> +# without the wal to associate subtransaction to its
On Tue, Sep 27, 2022 at 04:22:39PM +, John Morris wrote:
> I’m also wondering about code simplification vs a more general
> encryption/compression framework. I started with the current
> proposal, and I’m also looking at David Steele’s approach to
> encryption/compression in pgbackrest. I’m beg
On Mon, Sep 12, 2022 at 03:18:59PM -0400, Tom Lane wrote:
> I spun up a 32-bit VM, since that had been on my to-do list anyway,
> and it looks like I was right:
This feedback has not been addressed and the thread is idle four
weeks, so I have marked this CF entry as RwF. Please feel free to
resub
On Thu, Sep 08, 2022 at 04:34:07PM -0700, Nathan Bossart wrote:
> On Thu, Sep 08, 2022 at 04:29:10PM -0700, Jacob Champion wrote:
>> To clarify, I agree that pg_dump should contain the core fix. What I'm
>> questioning is the addition of --dump-options to make use of that fix
>> from pg_upgrade, si
On 05.10.22 22:07, Andres Freund wrote:
0001: autoconf: Unify CFLAGS_SSE42 and CFLAGS_ARMV8_CRC32C
I wonder, there has been some work lately to use SIMD and such in other
places. Would that affect what kinds of extra CPU-specific compiler
flags and combinations we might need?
Seems fine ot
Hi,
On Tue, Sep 6, 2022 at 3:00 PM Amit Kapila wrote:
>
> On Mon, Sep 5, 2022 at 5:24 PM Tomas Vondra
> wrote:
> >
> > On 9/5/22 12:12, Amit Kapila wrote:
> > > On Mon, Sep 5, 2022 at 12:14 PM Tomas Vondra
> > > wrote:
> > >
> > > It is possible that there is some other problem here that I am
>
On Thu, Jul 21, 2022 at 10:56:41AM -0700, Nathan Bossart wrote:
> Couldn't ProcessGUCArray() use set_config_option_ext() with the context
> indicated by pg_db_role_setting? Also, instead of using PGC_USERSET in all
> the set_config_option() call sites, shouldn't we remove the "context"
> argument
On Tue, Aug 31, 2021 at 10:56:59PM -0700, Andres Freund wrote:
> I've attached the code for posterity, but the series is large enough that I
> don't think it makes sense to do that all that often... The code is at
> https://github.com/anarazel/postgres/tree/aio
I don't know what's the exact status
On Wed, Sep 21, 2022 at 12:43:15PM +0100, Simon Riggs wrote:
> Thanks for tests and review. I'm just jumping on a plane, so may not
> respond in detail until next Mon.
Okay. If you have time to address that by next CF, that would be
interesting. For now I have marked the entry as returned with
f
On Fri, Sep 16, 2022 at 12:22:08PM +1200, David Rowley wrote:
> We'd probably still want to keep preprocess_groupclause() as
> get_useful_group_keys_orderings() is not exhaustive in its search.
This thread has been idle for a few weeks now with a review posted, so
I have marked the patch as RwF.
-
On Sat, Jul 30, 2022 at 04:21:07PM +0900, Michael Paquier wrote:
> FWIW, I find the result set approach more intuitive and robust,
> particularly in the case of a sequence has non-default values
> INCREMENT and min/max values. This reduces the dependency of what an
> application needs to know abou
On Mon, Aug 29, 2022 at 01:46:25PM +0200, Daniel Gustafsson wrote:
> As written these tests aren't providing more coverage, they run more code but
> they don't ensure that the produced output is correct. If you write these
> tests with validation on the output they will be a lot more interesting.
On Wed, Oct 12, 2022 at 11:01 AM Michael Paquier wrote:
>
> This thread has been idle for 6 months now, so I have marked it as
> returned with feedback as of what looks like a lack of activity. I
> have looked at what's been proposed, and I am not really sure if the
> direction taken is correct,
On Sat, Jul 30, 2022 at 05:13:12PM -0400, Tom Lane wrote:
> If we don't do it like that, I'd vote for rejecting the patch.
Yep. Done this way.
--
Michael
signature.asc
Description: PGP signature
On Fri, Sep 02, 2022 at 05:24:58PM -0500, Justin Pryzby wrote:
> I'm not sure where to go from here.
Not sure either, but the thread has no activity for a bit more than 1
month, so marked as RwF for now.
--
Michael
signature.asc
Description: PGP signature
On Mon, Sep 19, 2022 at 02:05:39PM -0700, Jacob Champion wrote:
> It's not prevented, because a password is being used. In my tests I'm
> connecting as an unprivileged user.
>
> You're claiming that the middlebox shouldn't be doing this. If this new
> default behavior were the historical behavior,
On Mon, Mar 07, 2022 at 05:09:23PM +0100, Matthias van de Meent wrote:
> That's for the AM-internal flushing; yes. I was thinking about the AM
> api for flushing that's used when finalizing the batched insert; i.e.
> table_multi_insert_flush.
>
> Currently it assumes that all buffered tuples will
On Mon, Sep 12, 2022 at 11:47:07AM +0700, John Naylor wrote:
> I don't think this clarifies anything, it's just a rephrasing.
>
> More broadly, I think the description of varlenas in this header is at
> a kind of "local maximum" -- minor adjustments are more likely to make
> it worse. To significa
On Sun, Oct 09, 2022 at 12:24:23PM +0300, Anton A. Melnikov wrote:
> On the other hand, function_parse_error_transpose() tries to get
> the original query text (INSERT INTO test VALUES ('1') in our case) from
> the ActivePortal to clarify the location of the error.
> But in the logrep worker there
On Mon, Sep 19, 2022 at 09:15:25AM +0200, Ronan Dunklau wrote:
> You're right, I was too eager to try to raise the CPU cost proportionnally to
> the number of array scans (scalararrayop). I'd really like to understand
> where
> this equation comes from though...
So, what's the latest update he
On Wed, Aug 10, 2022 at 09:48:08AM -0400, Tom Lane wrote:
> What I'm inclined to do, rather than repeat the same finicky &
> undocumented coding pattern in one more place, is write a convenience
> function for it that can be named and documented to reflect the coding
> rule about which call sites s
On Fri, Sep 09, 2022 at 06:37:07PM +0200, Alvaro Herrera wrote:
> Would it work to use get_object_address() instead? That would save
> having to write a lookup-and-lock function with a retry loop for each
> object type.
Jeite, this thread is waiting for your input. This is a bug fix, so I
have m
On Wed, Jul 27, 2022 at 09:47:19PM -0400, Robert Haas wrote:
> On Wed, Jul 27, 2022 at 5:56 PM Tom Lane wrote:
> > Maybe we need a different function for pg_visibility to call?
> > If we want ComputeXidHorizons to serve both these purposes, then it
> > has to always deliver exactly the right answe
On Tue, Sep 13, 2022 at 05:31:05PM +0900, Kyotaro Horiguchi wrote:
> And ExportSnapshot repalces oversized subxip with overflowed.
>
> So even when GetSnapshotData() returns a snapshot with oversized
> subxip, it is saved as just "overflowed" on exporting. I don't think
> this is the expected beha
Thanks Ashutosh,
Actually we use the Postgres service offered by Azure (Flexible server).
So, I was looking at the following documentation which talks about Logical
Replication and Logical Decoding as two different methods of replication.
Here Logical replication talks about creating both Publishe
On Thu, Aug 11, 2022 at 10:40 PM wrote:
> On 2022-08-11 07:55, Thomas Munro wrote:
> >> I checked a few variants:
> >>
> >> 21.07.2022 15:11 HOME [\??\Volume{GUID}\]
> >> 09.08.2022 15:06 Test1 [\\?\Volume{GUID}\]
> >> 09.08.2022 15:06 Test2 [\\.\Volume{GUID}\]
> >> 09.0
On Wed, 12 Oct 2022 at 05:33, Vik Fearing wrote:
> On 10/12/22 04:40, David Rowley wrote:
> > I've not really done any analysis into which other window functions
> > can use this optimisation. The attached only adds support to
> > row_number()'s support function and only converts exactly "RANGE
>
Dear Önder,
Thank you for updating the patch!
> It is not about CREATE INDEX being async. It is about pg_stat_all_indexes
> being async. If we do not wait, the tests become flaky, because sometimes
> the update has not been reflected in the view immediately.
Make sense, I forgot how stats collec
On 10/12/22 04:40, David Rowley wrote:
I've not really done any analysis into which other window functions
can use this optimisation. The attached only adds support to
row_number()'s support function and only converts exactly "RANGE
UNBOUNDED PRECEDING AND CURRENT ROW" into "ROW UNBOUNDED PRECEDI
On Wed, Sep 7, 2022 at 11:06 AM kuroda.hay...@fujitsu.com
wrote:
>
> Dear Amit,
>
> Thanks for giving comments!
>
> > Did you get this new assertion failure after you applied the patch for
> > the first failure? Because otherwise, how can you reach it with the
> > same test case?
>
> The first fai
On Tue, Oct 11, 2022 at 3:06 PM Andrey Lepikhov
wrote:
> I reviewed the patch one more time. Only one question: bistate and
> ri_FdwRoutine are strongly bounded. Maybe to add some assertion on
> (ri_FdwRoutine XOR bistate) ? Just to prevent possible errors in future.
You mean the bistate member o
Over on [1], Erwin mentions that row_number() over (ORDER BY ... ROWS
UNBOUNDED PRECEDING) is substantially faster than the default RANGE
UNBOUNDED PRECEDING WindowClause options. The difference between
these options are that nodeWindowAgg.c checks for peer rows for RANGE
but not for ROWS. That w
On Wed, Oct 12, 2022 at 12:24 AM Alvaro Herrera
wrote:
> Knowing how difficult that code was, and how heroic was to change it to
> a more maintainable form, I place no blame on failing to notice that
> some small thing could have been written more easily.
Concur with that. The changes in 7fcbf6
On Wed, Oct 12, 2022 at 02:50:58PM +1300, David Rowley wrote:
> Thanks for finding that and coming up with the patch. It looks fine to
> me. Do you want to push it?
Thanks for double-checking. I'll do so shortly, I just got annoyed by
that for a few days :)
Thanks for your work on this thread to
On Fri, Sep 30, 2022 at 06:22:02PM +0800, Zhang Mingli wrote:
> In the same function, there is disorder of XLogBeginInsert and
> START_CRIT_SECTION.
>
> ```
> collectordata = ptr = (char *) palloc(collector->sumsize);
>
> data.ntuples = collector->ntuples;
>
> if (needWal)
> XLogBeginInser
On Wed, 12 Oct 2022 at 14:39, Michael Paquier wrote:
> -Wshadow=compatible-local causes one extra warning in postgres.c with
> -DWRITE_READ_PARSE_PLAN_TREES:
> postgres.c: In function ‘pg_rewrite_query’:
> postgres.c:818:37: warning: declaration of ‘query’ shadows a parameter
> [-Wshadow=compatib
On Tue, Oct 11, 2022 at 01:16:50PM +1300, David Rowley wrote:
> Aside from this issue, if anything I'd be keen to go a little further
> with this and upgrade to -Wshadow=local. The reason being is that I
> noticed that the const qualifier is not classed as "compatible" with
> the equivalently named
Hi,
On Monday, October 3, 2022 8:50 PM Melih Mutlu wrote:
> (4) Error message of the binary format copy
>
> I've gotten below message from data type contradiction (between
> integer and bigint).
> Probably, this is unclear for the users to understand the direct cause
> a
On Tue, Oct 11, 2022 at 01:51:50PM +0200, Peter Eisentraut wrote:
> Let's make a small start on this. The attached patch moves the tests of the
> md5() function to a separate test file. That would ultimately make it
> easier to maintain a variant expected file for FIPS mode where that function
>
On Tue, Oct 11, 2022 at 05:06:22PM +0200, Peter Eisentraut wrote:
> Various test suites use the "openssl" program as part of their setup. There
> isn't a way to override which openssl program is to be used, other than by
> fiddling with the path, perhaps. This has gotten increasingly problematic
>
On Tue, Oct 11, 2022 at 06:24:26PM +0200, Alvaro Herrera wrote:
> Knowing how difficult that code was, and how heroic was to change it to
> a more maintainable form, I place no blame on failing to notice that
> some small thing could have been written more easily.
+1. And even after such changes
On Tue, Oct 11, 2022 at 02:18:54PM +, Imseih (AWS), Sami wrote:
> +1 to the idea, as there are other utility statement cases
> that should be Jumbled. Here is a recent thread for jumbling
> cursors [1].
Thanks for mentioning that. With an automated way to generate this
code, cursors would be
On Wed, 12 Oct 2022 at 04:11, Bruce Momjian wrote:
> As far as I can tell, analyze updates pg_statistics values, but not
> pg_stat_all_tables.n_dead_tup and n_live_tup, which are used by
> autovacuum to trigger vacuum operations. I am afraid we have to
> recommand VACUUM ANALYZE after pg_stat_res
Hi,
On 2022-10-11 11:23:36 -0700, Andres Freund wrote:
> > + build_script:
> > +- C:\msys64\usr\bin\dash.exe -lc "cd %CIRRUS_WORKING_DIR% && ninja -C
> > %BUILD_DIR%"
> > + upload_caches: ccache
Only remembered that just after sending my email: When using b_pch=true (which
saves a lot of t
Ian Lawrence Barwick writes:
> Small patch for $subject, as the other pg_get_XXXdef() functions are
> documented
> and I was looking for this one but couldn't remember what it was called.
Seems reasonable. Pushed with minor wording adjustment.
regards, tom lane
Hi,
On 2022-10-07 20:00:56 +0300, Melih Mutlu wrote:
> Attached patch is the adjusted version to build with meson.
Thanks!
> diff --git a/.cirrus.yml b/.cirrus.yml
> index 9f2282471a..7e6ebdf7b7 100644
> --- a/.cirrus.yml
> +++ b/.cirrus.yml
> @@ -35,6 +35,7 @@ on_failure_ac: &on_failure_ac
>
On Tue, Oct 11, 2022 at 09:34:25AM +0530, Bharath Rupireddy wrote:
> now = t1;
> XLogWalRcvSendReply() /* say it ran for a minute or so for whatever reasons */
> XLogWalRcvSendHSFeedback() /* with patch walrecevier sends hot standby
> feedback more often without properly honouring
> wal_receiver_st
On Tue, Oct 11, 2022 at 02:01:07PM +0900, Michael Paquier wrote:
> Thanks, applied. It took me a few minutes to note that
> regress_regression_* is required in the object names because we need
> to use the same name for the parent role and the database, with
> "regress_" being required for the rol
On Thu, Sep 29, 2022 at 12:47 AM Amit Langote wrote:
> [ patches ]
While looking over this thread I came across this code:
/* For data reading, executor always omits detached partitions */
if (estate->es_partition_directory == NULL)
estate->es_partition_directory =
Cr
On Tue, Oct 11, 2022 at 9:58 AM Zhihong Yu wrote:
>
>
> On Tue, Oct 11, 2022 at 9:22 AM Dmitry Koval
> wrote:
>
>> Hi!
>>
>> Fixed couple warnings (for cfbot).
>>
>> --
>> With best regards,
>> Dmitry Koval
>>
>> Postgres Professional: http://postgrespro.com
>
> Hi,
> For v12-0001-PGPRO-ALTER-TA
On Thu, Sep 8, 2022 at 08:16:07PM +0300, Aleksander Alekseev wrote:
> Hi hackers,
>
> I tried to understand some implementation details of ProcArray and
> discovered that this is a bit challenging to do due to a missing
> comment for PGPROC.pgprocno. E.g. it's hard to understand why
> ProcArrayAd
Thread moved to hackers since it involves complex queries. Can someone
like Stephen comment on the existing docs and feature behavior? Thanks.
---
On Fri, Sep 16, 2022 at 11:57:25AM -0700, Chandler Gonzales wrote:
> Hi y'
On Tue, Oct 11, 2022 at 9:22 AM Dmitry Koval wrote:
> Hi!
>
> Fixed couple warnings (for cfbot).
>
> --
> With best regards,
> Dmitry Koval
>
> Postgres Professional: http://postgrespro.com
Hi,
For v12-0001-PGPRO-ALTER-TABLE-MERGE-PARTITIONS-command.patch:
+ if (equal(name, cmd->name))
+
On 2022-Oct-11, Richard Guo wrote:
> As I can see in 7fcbf6a4 ValidXLogPageHeader() is refactored as
True, but look at dfda6ebaec67 -- that changed the use of recaddr from
being built from parts (which were globals back then) into something
that was computed locally.
Knowing how difficult that c
Peter Eisentraut writes:
> On 14.09.22 06:53, Tom Lane wrote:
>> Actually ... an even-more-terrifyingly-plausible misuse is that the
>> supplied oldsize is different from the actual previous allocation.
>> We should try to check that. In MEMORY_CONTEXT_CHECKING builds
>> it should be possible to
On Tue, Oct 11, 2022 at 09:49:14AM -0400, Tom Lane wrote:
>
> If you're trying to investigate custom-plan behavior, then you
> need to supply concrete parameter values somewhere, so I think
> this approach is fine for that case. (Shoehorning parameter
> values into EXPLAIN options seems like it'd
On 14.09.22 06:53, Tom Lane wrote:
I wrote:
It kind of feels that the argument order should be pointer, oldsize, size.
It feels even more strongly that people will get the ordering wrong,
whichever we choose. Is there a way to make that more bulletproof?
Actually ... an even-more-terrifyingly
On Wed, Oct 5, 2022 at 11:07:49AM +1300, David Rowley wrote:
> On Thu, 29 Sept 2022 at 04:45, Bruce Momjian wrote:
> >
> > We have discussed the problems caused by the use of pg_stat_reset() and
> > pg_stat_reset_shared(), specifically the removal of information needed
> > by autovacuum. I don't
Dmitry Koval writes:
> Hi!
> Commit 9a374b77fb53 (Improve frontend error logging style.) replaced a
> line of file src/include/common/logging.h
> ```
> extern PGDLLIMPORT enum pg_log_level __pg_log_level;
> ```
> to
> ```
> extern enum pg_log_level __pg_log_level;
> ```
> i.e. it is rollback of c
Various test suites use the "openssl" program as part of their setup.
There isn't a way to override which openssl program is to be used, other
than by fiddling with the path, perhaps. This has gotten increasingly
problematic with some of the work I have been doing, because different
versions o
Hi!
Commit 9a374b77fb53 (Improve frontend error logging style.) replaced a
line of file src/include/common/logging.h
```
extern PGDLLIMPORT enum pg_log_level __pg_log_level;
```
to
```
extern enum pg_log_level __pg_log_level;
```
i.e. it is rollback of commit 8ec569479fc28 (Apply PGDLLIMPORT ma
> I've been thinking since the beginning of this thread that there
> was no coherent, defensible rationale being offered for jumbling
> some utility statements and not others.
+1 to the idea, as there are other utility statement cases
that should be Jumbled. Here is a recent thread for jumbling
cu
On Mon, Oct 10, 2022 at 08:34:33PM -0700, Nathan Bossart wrote:
> On Mon, Oct 10, 2022 at 02:20:37PM -0400, Bruce Momjian wrote:
> > On Fri, Oct 7, 2022 at 03:23:27PM -0700, Zhihong Yu wrote:
> >> I wonder if SAVEPOINT / subtransaction performance has been boosted since
> >> the
> >> blog was wri
>One idea would be to add a flag, say report_parallel_vacuum_progress,
>to IndexVacuumInfo struct and expect index AM to check and update the
>parallel index vacuum progress, say every 1GB blocks processed. The
>flag is true only when the leader process is vacuuming an index.
>
On Tue, Oct 11, 2022 at 7:05 PM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> On Tue, Oct 11, 2022 at 3:19 PM Richard Guo
> wrote:
> > On Tue, Oct 11, 2022 at 1:44 PM Kyotaro Horiguchi <
> horikyota@gmail.com> wrote:
> >> At Mon, 10 Oct 2022 08:53:55 +0530, Bharath Rupi
Laurenz Albe writes:
> Today you get
> test=> EXPLAIN SELECT * FROM tab WHERE col = $1;
> ERROR: there is no parameter $1
> which makes sense. Nonetheless, it would be great to get a generic plan
> for such a query.
I can see the point, but it also seems like it risks masking stupid
mistakes.
But, as follow, if txn1 not commit (just like long term readonly txn), it will
block txn2's ddl job, why alt add/drop column can not concurrently with read
only access?
txn1： long term txn not commit access t1.
txn2 waiting txn1 to commit or abort.
txn3 wait txn2...
At 2022-10-11 18:0
On Tue, Oct 11, 2022 at 08:31:53PM +0800, jiye wrote:
> But, as follow, if txn1 not commit (just like long term readonly txn), it
> will block txn2's ddl job, why alt add/drop column can not concurrently with
> read only access?
> txn1： long term txn not commit access t1.
> txn2 waiting txn1 to
Hi Kuroda Hayato,
> ===
> 01. relation.c - GetCheapestReplicaIdentityFullPath
>
> ```
> * The reason that the planner would not pick partial indexes and
> indexes
> * with only expressions based on the way currently
> baserestrictinfos are
> * formed (e.g., col_1 = $1 .
Today you get
test=> EXPLAIN SELECT * FROM tab WHERE col = $1;
ERROR: there is no parameter $1
which makes sense. Nonetheless, it would be great to get a generic plan
for such a query. Sometimes you don't have the parameters (if you grab
the statement from "pg_stat_statements", or if it is fro
On 04.10.22 17:45, Peter Eisentraut wrote:
While working on the column encryption patch, I wanted to check that
what is implemented also works in OpenSSL FIPS mode. I tried running
the normal test suites after switching the OpenSSL installation to FIPS
mode, but that failed all over the place.
On Tue, Oct 11, 2022 at 2:11 PM bt22nakamorit
wrote:
>
> 2022-10-10 16:12 Bharath Rupireddy wrote:
> > Thanks. LGTM.
> Thank you for your review!
> I have this issue posted on Commitfest 2022-11 with title "show
> walsender's connected db for ps command entry".
> May I change the status to "Ready
On Tue, Oct 11, 2022 at 3:19 PM Richard Guo wrote:
>
>
> On Tue, Oct 11, 2022 at 1:44 PM Kyotaro Horiguchi
> wrote:
>>
>> At Mon, 10 Oct 2022 08:53:55 +0530, Bharath Rupireddy
>> wrote in
>> > It looks like we have an unnecessary XLogSegNoOffsetToRecPtr() in
>> > XLogReaderValidatePageHeader()
On 2022-Oct-10, Peter Smith wrote:
> On Mon, Oct 10, 2022 at 4:04 PM Amit Kapila wrote:
> > I think the below gives accurate information:
> > WARNING: subscription was created, but is not connected
> > HINT: You should create the slot manually, enable the subscription,
> > and run %s to initiate
On Tue, Oct 11, 2022 at 4:59 PM Peter Eisentraut
wrote:
>
> On 11.10.22 05:29, Junwang Zhao wrote:
> > What do you think if we move these code into a static inline function? like:
> >
> > static inline char*
> > process_digits(char *ptr, int32 *result)
> > {
> > ...
> > }
>
> How would you handle
On Tue, Oct 11, 2022 at 05:43:03PM +0800, jiye wrote:
> As we know postgres using high level lock when do alter table or other ddl
> commands,
> It will block any dml operation, while it also will block by long term dml
> operation.
Most of the things can be already done in non-blocking (or almo
On Tue, Oct 11, 2022 at 1:44 PM Kyotaro Horiguchi
wrote:
> At Mon, 10 Oct 2022 08:53:55 +0530, Bharath Rupireddy <
> bharath.rupireddyforpostg...@gmail.com> wrote in
> > It looks like we have an unnecessary XLogSegNoOffsetToRecPtr() in
> > XLogReaderValidatePageHeader(). We pass the start LSN of
Hi,
As we know postgres using high level lock when do alter table or other ddl
commands,
It will block any dml operation, while it also will block by long term dml
operation.
Like what discuss as follow :
https://dba.stackexchange.com/questions/293992/make-alter-table-wait-for-lock-without-bl
On 10.10.22 08:41, Tom Lane wrote:
What remains is to
define when is the cutoff point between "acknowledge in v15" versus
"acknowledge in v16". I don't have a strong opinion about that,
but I'd like it to be more than 24 hours before the 15.0 wrap.
Could we make the cutoff be, say, beta1?
beta
On 11.10.22 05:29, Junwang Zhao wrote:
What do you think if we move these code into a static inline function? like:
static inline char*
process_digits(char *ptr, int32 *result)
{
...
}
How would you handle the different ways each branch checks for valid
digits and computes the value of each d
2022-10-10 16:12 Bharath Rupireddy wrote:
Thanks. LGTM.
Thank you for your review!
I have this issue posted on Commitfest 2022-11 with title "show
walsender's connected db for ps command entry".
May I change the status to "Ready for Committer"?
Best,
Tatsuhiro Nakamori
On Mon, Oct 10, 2022 at 5:40 PM Robert Haas wrote:
>
> On Mon, Oct 10, 2022 at 5:16 AM Dilip Kumar wrote:
> > I have also executed my original test after applying these patches on
> > top of the 56 bit relfilenode patch. So earlier we saw the WAL size
> > increased by 11% (66199.09375 kB to 7390
On Sun, Oct 9, 2022 at 2:42 AM Andres Freund wrote:
>
> On 2022-10-08 09:53:50 -0700, Andres Freund wrote:
> > On 2022-10-07 19:56:33 -0700, Andres Freund wrote:
> > > I'm planning to push this either later tonight (if I feel up to it after
> > > cooking dinner) or tomorrow morning PST, due to the
Hi Amit,
> Pushed.
Thanks!
> I don't have a strong opinion on whether we should be really worried
> by this. But in case we do, here is the patch.
This leaves us one patch to deal with.
--
Best regards,
Aleksander Alekseev
v4-0001-Pass-Size-size_t-as-a-2nd-argument-of-snprintf.patch
Descrip
On 04.10.22 09:41, Peter Eisentraut wrote:
Attached is a demo patch how the implementation of this change would
look like. This creates a bunch of regression test failures, but
AFAICT, those are mainly display differences and some very peculiar test
setups that are intentionally examining some
On Fri, Oct 7, 2022 at 7:17 PM Amit Langote wrote:
> On Fri, Oct 7, 2022 at 19:15 Alvaro Herrera wrote:
>> On 2022-Oct-07, Amit Langote wrote:
>> > > Thanks for the heads up. Hmm, this I am not sure how to reproduce on
>> > > my own, so I am currently left with second-guessing what may be going
On Mon, Oct 10, 2022 at 7:09 PM Amit Kapila wrote:
>
> On Tue, Sep 27, 2022 at 5:04 PM Aleksander Alekseev
> wrote:
> >
> > Hi Peter,
> >
> > > PSA patch v3 to combine the different replication origin name
> > > formatting in a single function ReplicationOriginNameForLogicalRep as
> > > suggested
100 matches
Mail list logo
