Hello, Julien.
> I rebased the pathset in attached v9. Please double check that I didn't miss
> anything in the rebase.
Thanks a lot for your help.
> I will let you mark the patch as Ready for Committer once you validate that
> the
> rebase was ok.
Yes, rebase looks good.
Best regards,
Micha
On Wed, Jan 26, 2022 at 1:43 PM David G. Johnston
wrote:
>
> On Tue, Jan 25, 2022 at 9:16 PM Amit Kapila wrote:
>>
>> On Wed, Jan 26, 2022 at 9:36 AM Masahiko Sawada
>> wrote:
>> > On Wed, Jan 26, 2022 at 12:54 PM Amit Kapila
>> > wrote:
>>
>> > > >
>> > > > Probably, we also need to consider
On Wed, Jan 26, 2022 at 12:13:03PM +0530, Bharath Rupireddy wrote:
> I see. IMHO, we can fix the issue reported here then.
Yes.
--
Michael
signature.asc
Description: PGP signature
On Wed, Jan 26, 2022 at 12:04 PM Michael Paquier wrote:
>
> On Wed, Jan 26, 2022 at 08:09:16AM +0530, Bharath Rupireddy wrote:
> > Will that patch set fix the issue reported here?
>
> Looking at [1], the area of CreateCheckPoint() is left untouched.
>
> [1]:
> https://www.postgresql.org/message-i
On Wed, Jan 26, 2022 at 08:09:16AM +0530, Bharath Rupireddy wrote:
> Will that patch set fix the issue reported here?
Looking at [1], the area of CreateCheckPoint() is left untouched.
[1]:
https://www.postgresql.org/message-id/52bc9ccd-8591-431b-0086-15d9acf25...@iki.fi
--
Michael
signature.as
On Tue, Jan 25, 2022 at 09:44:26PM -0600, Justin Pryzby wrote:
> It seems like an arbitrary and short-sighted policy to expose a handful of
> flags in the view for the purpose of retiring ./check_guc, but not expose
> other
> flags, because we thought we knew that no user could ever want them.
>
On Tue, Jan 25, 2022 at 12:00 PM vignesh C wrote:
> Thanks for the comments, attached v17 patch has the fix for the same.
Have a minor comment on v17:
can we modify the elog(LOG, to new style ereport(LOG, ?
+ elog(LOG_SERVER_ONLY, "current backtrace:%s", errtrace.data);
/*--
* New-styl
On 2022-01-26 13:17, Fujii Masao wrote:
Hi,
pg_log_backend_memory_contexts() should be designed not to send the
messages about the memory contexts to the client regardless of
client_min_messages. But I found that the message "logging memory
contexts of PID %d" can be sent to the client because i
On Wed, Jan 26, 2022 at 10:46 AM Bharath Rupireddy
wrote:
>
> On Wed, Jan 26, 2022 at 9:48 AM Fujii Masao
> wrote:
> >
> > Hi,
> >
> > pg_log_backend_memory_contexts() should be designed not to send the
> > messages about the memory contexts to the client regardless of
> > client_min_messages.
On Wed, Jan 26, 2022 at 10:46 AM Bharath Rupireddy
wrote:
>
> On Wed, Jan 26, 2022 at 9:48 AM Fujii Masao
> wrote:
> >
> > Hi,
> >
> > pg_log_backend_memory_contexts() should be designed not to send the
> > messages about the memory contexts to the client regardless of
> > client_min_messages.
On Wed, Jan 26, 2022 at 9:48 AM Fujii Masao wrote:
>
> Hi,
>
> pg_log_backend_memory_contexts() should be designed not to send the messages
> about the memory contexts to the client regardless of client_min_messages.
> But I found that the message "logging memory contexts of PID %d" can be sent
On 2022-01-25 18:33:55 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-01-25 12:45:15 -0500, Tom Lane wrote:
> >> I guess next steps are to revert f032f63e7 and then retry e0e567a10
> >> with that change. Who's going to do the honors?
>
> > I assume Peter is done working for the day.
On Tue, Jan 25, 2022 at 9:16 PM Amit Kapila wrote:
> On Wed, Jan 26, 2022 at 9:36 AM Masahiko Sawada
> wrote:
> > On Wed, Jan 26, 2022 at 12:54 PM Amit Kapila
> wrote:
>
> > > >
> > > > Probably, we also need to consider the case where the tablesync
> worker
> > > > entered an error loop and th
Hi,
pg_log_backend_memory_contexts() should be designed not to send the messages about the
memory contexts to the client regardless of client_min_messages. But I found that the
message "logging memory contexts of PID %d" can be sent to the client because
it's ereport()'d with LOG level instead
On Wed, Jan 26, 2022 at 9:36 AM Masahiko Sawada wrote:
>
> On Wed, Jan 26, 2022 at 12:54 PM Amit Kapila wrote:
> >
> >
> > I think it is okay to clear after the first successful application of
> > any transaction. What I was not sure was about the idea of giving
> > WARNING/ERROR if the first xac
On Wed, Jan 26, 2022 at 7:05 AM David G. Johnston
wrote:
>
> On Tue, Jan 25, 2022 at 8:33 AM Masahiko Sawada wrote:
>>
>> Given that we cannot use rely on the pg_stat_subscription_workers view
>> for this purpose, we would need either a new sub-system that tracks
>> each logical replication statu
On Wed, Jan 26, 2022 at 12:54 PM Amit Kapila wrote:
>
> On Wed, Jan 26, 2022 at 8:55 AM Masahiko Sawada wrote:
> >
> > On Wed, Jan 26, 2022 at 11:51 AM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, Jan 26, 2022 at 11:28 AM Amit Kapila
> > > wrote:
> > > >
> > > > IIUC, the proposal is to com
On Wed, Jan 26, 2022 at 8:55 AM Masahiko Sawada wrote:
>
> On Wed, Jan 26, 2022 at 11:51 AM Masahiko Sawada
> wrote:
> >
> > On Wed, Jan 26, 2022 at 11:28 AM Amit Kapila
> > wrote:
> > >
> > > IIUC, the proposal is to compare the skip_xid with the very
> > > transaction the apply worker receiv
On Wed, Jan 26, 2022 at 09:54:43AM +0900, Michael Paquier wrote:
> On Tue, Jan 25, 2022 at 12:07:51PM -0600, Justin Pryzby wrote:
> > On Tue, Jan 25, 2022 at 11:47:14AM +0100, Peter Eisentraut wrote:
> >> Does this stuff have any value for users? I'm worried we are exposing a
> >> bunch of stuff t
On Thu, Jan 22, 2022 at 7:12 PM Amit Kapila wrote:
> Now, one idea to solve this problem could be that whenever we skip
> sending any change we do try to update the plugin progress via
> OutputPluginUpdateProgress(for walsender, it will invoke
> WalSndUpdateProgress), and there it tries to process
On Wed, Jan 26, 2022 at 11:51 AM Masahiko Sawada wrote:
>
> On Wed, Jan 26, 2022 at 11:28 AM Amit Kapila wrote:
> >
> > On Tue, Jan 25, 2022 at 8:39 PM Masahiko Sawada
> > wrote:
> > >
> > > On Tue, Jan 25, 2022 at 11:58 PM David G. Johnston
> > > wrote:
> > > >
> > > > On Tue, Jan 25, 2022 at
Hi,
In a thread about sequences and sync replication [1], I've explained
that the issue we're observing is due to not waiting for WAL at commit
if the transaction only did nextval(). In which case we don't flush WAL
in RecordTransactionCommit, we don't wait for sync replica, etc. The WAL
may
On Monday, January 24, 2022 4:38 PM Peter Smith wrote:
>
> Thanks for all the patches!
>
> Here are my review comments for v69-0001
>
> ~~~
>
> 1. src/backend/executor/execReplication.c CheckCmdReplicaIdentity call to
> RelationBuildPublicationDesc
>
> + /*
> + * It is only safe to execute U
On Wed, Jan 26, 2022 at 11:28 AM Amit Kapila wrote:
>
> On Tue, Jan 25, 2022 at 8:39 PM Masahiko Sawada wrote:
> >
> > On Tue, Jan 25, 2022 at 11:58 PM David G. Johnston
> > wrote:
> > >
> > > On Tue, Jan 25, 2022 at 7:47 AM Masahiko Sawada
> > > wrote:
> > >>
> > >> Yeah, I think it's a good
On Wed, Jan 26, 2022 at 6:28 AM Michael Paquier wrote:
>
> On Tue, Jan 25, 2022 at 07:20:05PM +, Bossart, Nathan wrote:
> > I looked into removing the "shutdown" variable in favor of using
> > "flags" everywhere, but the patch was quite messy and repetitive. I
> > think another way to make th
On Wed, Jan 26, 2022 at 7:31 AM David G. Johnston
wrote:
>
> On Mon, Jan 24, 2022 at 12:59 AM David G. Johnston
> wrote:
>>
>
> So my more detailed goal would be to get rid of PG_RE_THROW();
>
I don't think that will be possible, consider the FATAL/PANIC error
case. Also, there are reasons why
On Tue, Jan 25, 2022 at 8:39 PM Masahiko Sawada wrote:
>
> On Tue, Jan 25, 2022 at 11:58 PM David G. Johnston
> wrote:
> >
> > On Tue, Jan 25, 2022 at 7:47 AM Masahiko Sawada
> > wrote:
> >>
> >> Yeah, I think it's a good idea to clear the subskipxid after the first
> >> transaction regardless
On Mon, Jan 24, 2022 at 12:59 AM David G. Johnston <
david.g.johns...@gmail.com> wrote:
>
> > 5(out). wait for the user to manually restart the replication stream
>>
>> Do you mean that there always is user intervention after error so the
>> replication stream can resume?
>>
>
> That is my working
On Wed, Jan 26, 2022 at 09:44:48AM +0900, Michael Paquier wrote:
> Yes, this is going to need an adjustment of @logfiles in
> TestUpgrade.pm, with the addition of
> "$tmp_data_dir/pg_update_output.d/log/*.log" to be consistent with the
> data fetched for the tests of older branches.
Bleh. This wo
On Tuesday, January 25, 2022 6:44 PM, Julien Rouhaud wrote:
> Thanks for updating the patch. When you do so, please check and update the
> commitfest entry accordingly to make sure that people knows it's ready for
> review. I'm switching the entry to Needs Review.
>
Thanks for your reminder. I
On Tue, Jan 25, 2022 at 09:52:12PM +0530, tushar wrote:
> C) -R option is silently ignoring
>
> go to /tmp/pp folder and extract it - there is no "standby.signal" file and
> if we start cluster against this data directory,it will not be in slave
> mode.
Yeah, I don't think it's good to silently i
On Tue, Jan 25, 2022 at 03:54:52AM +, Shinoda, Noriyoshi (PN Japan FSIP)
wrote:
> Michael, I am proposing to that we remove this message as part of
> this commit:
>
> -pg_log_info("no value specified for compression
> level, switching to default");
>
> I think most people wo
On Tue, Jan 25, 2022 at 03:14:13PM -0500, Robert Haas wrote:
> On Sat, Jan 22, 2022 at 12:47 AM Michael Paquier wrote:
>> Also, having this enum in walmethods.h is perhaps not the best place
>> either, even more if you plan to use that in pg_basebackup for the
>> server-side compression. One idea
On Tue, Jan 25, 2022 at 6:18 PM Peter Eisentraut
wrote:
>
> On 25.01.22 03:54, Amit Kapila wrote:
> >> I don't think this functionality allows a nonprivileged user to do
> >> anything they couldn't otherwise do. You can create inconsistent data
> >> in the sense that you can choose not to apply c
On Tue, Jan 25, 2022 at 07:20:05PM +, Bossart, Nathan wrote:
> I looked into removing the "shutdown" variable in favor of using
> "flags" everywhere, but the patch was quite messy and repetitive. I
> think another way to make things less confusing is to replace
> "shutdown" with an inverse var
On Tue, Jan 25, 2022 at 12:07:51PM -0600, Justin Pryzby wrote:
> On Tue, Jan 25, 2022 at 11:47:14AM +0100, Peter Eisentraut wrote:
>> Does this stuff have any value for users? I'm worried we are exposing a
>> bunch of stuff that is really just for internal purposes. Like, what value
>> does showi
On Tue, Jan 25, 2022 at 10:45:29AM -0600, Justin Pryzby wrote:
> Andrew: you wanted to accommodate any change on the build client, right ?
Yes, this is going to need an adjustment of @logfiles in
TestUpgrade.pm, with the addition of
"$tmp_data_dir/pg_update_output.d/log/*.log" to be consistent wit
On Wed, Jan 26, 2022 at 12:59 PM Tom Lane wrote:
> Any possibility that it's out-of-disk-space?
Erm, yeah that's embarrassing, it could well be that. I've just given
it some more room.
On 1/25/22 10:18, Peter Eisentraut wrote:
On 15.01.22 23:57, Tomas Vondra wrote:
This approach (and also my previous proposal) seems to assume that
the value returned from nextval() should not be used until the
transaction executing that nextval() has been committed successfully.
But I'm not
Robert Haas writes:
> On Tue, Jan 25, 2022 at 5:34 AM Peter Eisentraut
> wrote:
>> Which part exactly? There are several different changes proposed here.
> I was just going based on the description of the feature in your
> original post. If someone is hoping that int4in() will accept only
> ^\d
Thomas Munro writes:
> I don't know what's going on here yet, but I noticed a $SUBJECT about
> half the time on my machine eelpout, starting 2-3 weeks ago. It fails
> like:
> Bailout called. Further testing stopped: system initdb failed
> https://buildfarm.postgresql.org/cgi-bin/show_history.
Andres Freund writes:
> On 2022-01-25 12:45:15 -0500, Tom Lane wrote:
>> I guess next steps are to revert f032f63e7 and then retry e0e567a10
>> with that change. Who's going to do the honors?
> I assume Peter is done working for the day. I'm stuck in meetings and stuff
> for another 2-3 hours.
Hi,
I don't know what's going on here yet, but I noticed a $SUBJECT about
half the time on my machine eelpout, starting 2-3 weeks ago. It fails
like:
Bailout called. Further testing stopped: system initdb failed
https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=eelpout&br=REL_14_STA
I spent some time contemplating my navel about the concerns I raised
upthread about double-quoted identifiers. I concluded that the reason
things don't work well in that area is that we're trying to get all the
work done by applying quote_ident() on the backend side and then
ignoring quoting consi
On Tue, Jan 25, 2022 at 3:38 PM Mikhail Dobrinin
wrote:
> Hello,
>
> I have come across some missing documentation that I think could benefit
> the community.
>
> Several functions like `jsonb_exists`, `jsonb_exists_any`,
> `jsonb_exists_all` have existed for many PG versions but were not
> docum
Hello pgsql-hackers,
When dropping a partitioned index, the locking order starts with the
partitioned table, then its partitioned index, then the partition
indexes dependent on that partitioned index, and finally the dependent
partition indexes' parent tables. This order allows a deadlock
scenario
Hello,
I have come across some missing documentation that I think could benefit
the community.
Several functions like `jsonb_exists`, `jsonb_exists_any`,
`jsonb_exists_all` have existed for many PG versions but were not
documented. They are equivalent to `?`, `?|`, and `?&` operators. But some
JD
On Wed, 2022-01-19 at 10:01 +0100, Daniel Gustafsson wrote:
> > On 18 Jan 2022, at 17:37, Jacob Champion wrote:
> >
> > On Wed, 2021-12-15 at 23:10 +0100, Daniel Gustafsson wrote:
> > > I've attached a v50 which fixes the issues found by Joshua upthread, as
> > > well as
> > > rebases on top of
On Tue, Jan 25, 2022 at 8:33 AM Masahiko Sawada
wrote:
> Given that we cannot use rely on the pg_stat_subscription_workers view
> for this purpose, we would need either a new sub-system that tracks
> each logical replication status so the system can set the error XID to
> subskipxid, or to wait f
Hi,
On 2022-01-25 12:45:15 -0500, Tom Lane wrote:
> As of now, 92 buildfarm animals have reported results from f032f63e7.
> Every single one of them reports that all the different methods you
> tested give the same answer. So it looks to me like we should just
> go with get_config_var('INCLUDEPY'
On Wed, 26 Jan 2022 at 05:32, Tom Lane wrote:
> Therefore, what I think could be useful is some very-late-stage
> assertion check (probably in createplan.c) verifying that the
> child of a Gather is parallel-aware. Or maybe the condition
> needs to be more general than that, but anyway the idea i
> On Jan 25, 2022, at 12:44 PM, Stephen Frost wrote:
>
> As I mentioned in the patch review, having a particular bit set doesn't
> necessarily mean you should be able to pass it on- the existing object
> GRANT system distinguishes those two and it seems like we should too.
> In other words, I'
On Wed, 26 Jan 2022 at 07:12, Robert Haas wrote:
> wouldn't this same consideration apply to a very large number of other
> places in the code base?
All of the other places are handled. See locations with "keep compiler quiet".
This one is the only one that generates a warning:
basebackup_gzip.
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Jan 24, 2022, at 2:21 PM, Stephen Frost wrote:
> > Being able to create and drop users is, in fact, effectively a
> > superuser-only task today. We could throw out the entire idea of role
> > ownership, in fact, as being ent
On Tue, Jan 25, 2022 at 2:30 PM Robert Haas wrote:
>
> On Mon, Jan 24, 2022 at 11:14 PM Dilip Kumar wrote:
> > I think we need to make different priority
> > queues based on different factors, for example 1 queue for wraparound
> > risk and another for bloat risk.
>
> I don't see why we want mul
On Tue, Jan 25, 2022 at 11:30 AM Robert Haas wrote:
> But your broader point that we need to consider how much bloat
> represents a problem is a really good one. In the past, one rule that
> I've thought about is: if we're vacuuming a table and we're not going
> to finish before it needs to be vac
Hi Tom, Andres,
Any additional feedback for this patch?
Thanks,
Geoff Blake
On Sat, Jan 22, 2022 at 12:47 AM Michael Paquier wrote:
> Also, having this enum in walmethods.h is perhaps not the best place
> either, even more if you plan to use that in pg_basebackup for the
> server-side compression. One idea is to rename this enum to
> DataCompressionMethod, moving it into
On Tue, Jan 25, 2022 at 8:42 AM Dagfinn Ilmari Mannsåker
wrote:
> I just noticed there was a superfluous [ in the SGM documentation, and
> that the short form was missing the [{client|server}-] part. Updated
> patch attaced.
Committed, thanks.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Thu, 6 Jan 2022 at 14:56, Tomas Vondra wrote:
>
>
> Not sure I understand. I wasn't suggesting any user-defined filtering,
> but something done by default, similarly to what we do for regular MCV
> lists, based on frequency. We'd include frequent paths while excluding
> rare ones.
>
> So no nee
On 1/25/22, 12:01 AM, "Michael Paquier" wrote:
> So, where are we on this patch? It looks like there is an agreement
> that MaxBackends is used widely enough that it justifies the use of a
> separate function to set and get a better value computed. There may
> be other parameters that could use
On Mon, Jan 24, 2022 at 11:14 PM Dilip Kumar wrote:
> I think we need some more parameters to compare bloat vs wraparound.
> I mean in one of your examples in the 2nd paragraph we can say that
> the need-to-start of table A is earlier than table B so it's kind of
> simple. But when it comes to wr
On Sun, Jan 02, 2022 at 01:07:29PM +0100, Fabien COELHO wrote:
> One liner doc improvement to tell that creation time is only available on
> windows.
> It is indeed not available on Linux.
The change is about the "isflag" flag, not creation time.
Returns a record containing the file's s
On Mon, Jan 24, 2022 at 5:21 PM Stephen Frost wrote:
> This is an argument to drop the role ownership concept, as I view it.
> Privileges are driven by membership today and inventing some new independent
> way to do that is increasing confusion, not improving things. I disagree
> that adding
On 2022-Jan-24, Peter Eisentraut wrote:
> +decinteger {decdigit}(_?{decdigit})*
> +hexinteger 0[xX](_?{hexdigit})+
> +octinteger 0[oO](_?{octdigit})+
> +bininteger 0[bB](_?{bindigit})+
I think there should be test cases for literals that these seemingly
str
On Tue, Jan 25, 2022 at 5:34 AM Peter Eisentraut
wrote:
> On 24.01.22 19:53, Robert Haas wrote:
> > On Mon, Jan 24, 2022 at 3:41 AM Peter Eisentraut
> > wrote:
> >> Rebased patch set
> >
> > What if someone finds this new behavior too permissive?
>
> Which part exactly? There are several differe
On Tue, Jan 25, 2022 at 4:20 AM David Rowley wrote:
> On Tue, 25 Jan 2022 at 09:14, Robert Haas wrote:
> > src/backend/replication/basebackup_gzip.c | 309
> > ++
>
> This could do with the attached. MSVC compilers need a bit more
> reassurance that ereport/elog ERROR
On Tue, Jan 25, 2022 at 11:47:14AM +0100, Peter Eisentraut wrote:
> On 25.01.22 02:07, Justin Pryzby wrote:
> > +CREATE TABLE pg_settings_flags AS SELECT name, category,
> > + 'NO_SHOW_ALL' =ANY(flags) AS no_show_all,
> > + 'NO_RESET_ALL' =ANY(flags) AS no_reset_all,
> > + 'NOT_IN_SAMPLE'
On 1/24/22, 8:42 PM, "Amul Sul" wrote:
> On Tue, Jan 25, 2022 at 10:08 AM Michael Paquier wrote:
>>
>> On Wed, Dec 01, 2021 at 07:09:34PM +, Bossart, Nathan wrote:
>> > The patch no longer applied, so I went ahead and rebased it.
>>
>> This was on the CF stack for some time, so applied. I ha
I wrote:
> It's a little bit too soon to decide that INCLUDEPY is reliably equal
> to that, but if it still looks that way tomorrow, I'll be satisfied.
As of now, 92 buildfarm animals have reported results from f032f63e7.
Every single one of them reports that all the different methods you
tested g
On Tue, 25 Jan 2022 at 03:50, Tomas Vondra
wrote:
>
> On 1/23/22 01:24, Nikita Glukhov wrote:
> > Hi!
> >
> > I am glad that you found my very old patch interesting and started to
> > work on it. We failed to post it in 2016 mostly because we were not
> > satisfied with JSONB storage. Also we de
On Mon, Jan 24, 2022 at 10:59:40AM +0900, Michael Paquier wrote:
> On Thu, Jan 20, 2022 at 07:51:37PM +0900, Michael Paquier wrote:
> > Neat idea. That would work fine for my case. So I am fine to stick
> > with this suggestion.
>
> I have been looking at this idea, and the result is quite nice
> On Jan 24, 2022, at 2:21 PM, Stephen Frost wrote:
>
> To push back on the original “tenant” argument, consider that one of the
> bigger issues in cloud computing today is exactly the problem that the cloud
> managers can potentially gain access to the sensitive data of their tenants
> and
Ashutosh Bapat писал 2022-01-25 17:08:
This code was written long ago. So I may have some recollection
errors. But AFAIR, the reasons we wanted to avoid repeated
estimation/planning for the same foreign join rel were
1. If use_remote_estimate = true, we fetch EXPLAIN output from the
foreign serve
Yura Sokolov writes:
> В Вт, 25/01/2022 в 21:20 +1300, David Rowley пишет:
>> The reason I didn't think it was worth adding a new test was that no
>> tests were added in the original commit. Existing tests did cover it,
> Existed tests didn't catched the issue. It is pitty fix is merged
> withou
On 1/22/22 12:03 AM, Robert Haas wrote:
I committed the base backup target patch yesterday, and today I
updated the remaining code in light of Michael Paquier's commit
5c649fe153367cdab278738ee4aebbfd158e0546. Here is the resulting patch.
Thanks Robert, I tested against the latest PG Head and f
> On Jan 24, 2022, at 10:55 PM, Fujii Masao wrote:
>
> +1
>
> One of "mischiefs" I'm thinking problematic is that users with CREATEROLE can
> give any predefined role that they don't have, to other users including
> themselves. For example, users with CREATEROLE can give
> pg_execute_serve
Peter Eisentraut writes:
> On 16.01.22 23:53, Tom Lane wrote:
>> I think a possible fix is:
>>
>> 1. Before entering the PG_TRY block, check for active subtransaction(s)
>> and immediately throw a Python error if there is one. (This corresponds
>> to the existing errors "cannot commit while a su
On Wed, Jan 26, 2022 at 12:14 AM David G. Johnston
wrote:
>
>
> On Tue, Jan 25, 2022 at 8:09 AM Masahiko Sawada wrote:
>>
>> On Tue, Jan 25, 2022 at 11:58 PM David G. Johnston
>> wrote:
>> >
>> > On Tue, Jan 25, 2022 at 7:47 AM Masahiko Sawada
>> > wrote:
>> >>
>> >> Yeah, I think it's a good
On Tue, Jan 25, 2022 at 8:09 AM Masahiko Sawada
wrote:
> On Tue, Jan 25, 2022 at 11:58 PM David G. Johnston
> wrote:
> >
> > On Tue, Jan 25, 2022 at 7:47 AM Masahiko Sawada
> wrote:
> >>
> >> Yeah, I think it's a good idea to clear the subskipxid after the first
> >> transaction regardless of w
On Tue, Jan 25, 2022 at 11:58 PM David G. Johnston
wrote:
>
> On Tue, Jan 25, 2022 at 7:47 AM Masahiko Sawada wrote:
>>
>> Yeah, I think it's a good idea to clear the subskipxid after the first
>> transaction regardless of whether the worker skipped it.
>>
>
> So basically instead of stopping the
On Tue, Jan 25, 2022 at 7:47 AM Masahiko Sawada
wrote:
> Yeah, I think it's a good idea to clear the subskipxid after the first
> transaction regardless of whether the worker skipped it.
>
>
So basically instead of stopping the worker with an error you suggest
having the worker continue applying
On Tue, Jan 25, 2022 at 11:40 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 24.01.22 22:23, Dmitry Koval wrote:
>
Thanks for looking into this.
> > +/*
> > + * Windows will use hyphens between language and territory, where POSIX
> > + * uses an underscore. Simply make it
On Tue, Jan 25, 2022 at 11:35 PM David G. Johnston
wrote:
>
> On Tue, Jan 25, 2022 at 5:52 AM Peter Eisentraut
> wrote:
>>
>> On 25.01.22 06:18, Amit Kapila wrote:
>> > I think to avoid this we can send a message to clear this (at least to
>> > clear XID in the view) after skipping the xact but
On Tue, Jan 25, 2022 at 5:52 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 25.01.22 06:18, Amit Kapila wrote:
> > I think to avoid this we can send a message to clear this (at least to
> > clear XID in the view) after skipping the xact but there is no
> > guarantee that it w
Hi,
On Wed, Jan 12, 2022 at 04:57:27PM +0800, Julien Rouhaud wrote:
>
> The cfbot reports that this patch doesn't apply anymore:
> http://cfbot.cputube.org/patch_36_3195.log
>
> > patching file src/backend/utils/adt/ri_triggers.c
> > Hunk #1 succeeded at 93 (offset 3 lines).
> > Hunk #2 FAILED a
Hi,
On Wed, Jan 12, 2022 at 02:16:35PM +0800, Julien Rouhaud wrote:
>
> On Mon, Nov 29, 2021 at 11:04 PM Kuntal Ghosh
> wrote:
> >
> > You also need to update the documentation.
>
> You also need to update rules.sql: https://cirrus-ci.com/task/6145265819189248
There has been multiple comments
On 16.01.22 23:53, Tom Lane wrote:
I think a possible fix is:
1. Before entering the PG_TRY block, check for active subtransaction(s)
and immediately throw a Python error if there is one. (This corresponds
to the existing errors "cannot commit while a subtransaction is active"
and "cannot roll
This code was written long ago. So I may have some recollection
errors. But AFAIR, the reasons we wanted to avoid repeated
estimation/planning for the same foreign join rel were
1. If use_remote_estimate = true, we fetch EXPLAIN output from the
foreign server for various pathkeys. Fetching EXPLAIN
On Sat, Jan 22, 2022 at 10:28 AM David G. Johnston
wrote:
>
>
>
> On Saturday, January 22, 2022, James Coleman wrote:
>>
>> On Sat, Jan 22, 2022 at 12:35 AM David G. Johnston
>> wrote:
>> >
>> > On Fri, Jan 21, 2022 at 5:14 PM James Coleman wrote:
>> >>
>> >>
>> >> > Really? That's horrid, bec
Dagfinn Ilmari Mannsåker writes:
> "Shinoda, Noriyoshi (PN Japan FSIP)" writes:
>
>> Hi,
>> Thank you for committing a great feature. I have tested the committed
>> features.
>> The attached small patch fixes the output of the --help message. In the
>> previous commit, only gzip and none were
"Shinoda, Noriyoshi (PN Japan FSIP)" writes:
> Hi,
> Thank you for committing a great feature. I have tested the committed
> features.
> The attached small patch fixes the output of the --help message. In the
> previous commit, only gzip and none were output, but in the attached
> patch, clien
On 25.01.22 06:18, Amit Kapila wrote:
I think to avoid this we can send a message to clear this (at least to
clear XID in the view) after skipping the xact but there is no
guarantee that it will be received by the stats collector.
Additionally, the worker can periodically (say after every N (100,
On 25.01.22 03:54, Amit Kapila wrote:
I don't think this functionality allows a nonprivileged user to do
anything they couldn't otherwise do. You can create inconsistent data
in the sense that you can choose not to apply certain replicated data.
I thought this will be the only primary way to s
Le jeudi 20 janvier 2022, 08:36:46 CET Ronan Dunklau a écrit :
> Le jeudi 20 janvier 2022, 02:31:15 CET David Rowley a écrit :
> > On Tue, 18 Jan 2022 at 19:45, Julien Rouhaud wrote:
> > > I'm also a bit confused about which patch(es) should actually be
> > > reviewed
> > > in that thread. My und
Hi,
On Tue, Jan 25, 2022 at 07:21:01PM +0800, Julien Rouhaud wrote:
> >
> > I'll move entry back to "Ready for Committer" once it passes tests.
>
> It looks like you didn't fetch the latest upstream commits in a while as this
> version is still conflicting with 7a5f6b474 (Make logical decoding a
Hi Andrei,
On Tue, Jan 25, 2022 at 02:58:17PM +0300, Andrei Zubkov wrote:
>
> Of course we can replace old min/max metrics with the new "aux" min/max
> metrics. It seems reasonable to me because they will have the same
> behavior until we touch reset_aux. I think we can assume that min/max
> data
Hi, hackers
ACL lists in tables may potentially be large in size. I suggest adding TOAST
support for system tables, namely pg_class, pg_attribute and
pg_largeobject_metadata, for they include ACL columns.
In commit 96cdeae0 these tables were missed because of possible conflicts with
VACUUM FU
Hi Julien,
Tue, 2022-01-25 at 18:08 +0800, Julien Rouhaud wrote:
>
> Are those 4 new counters really worth it?
>
> The min/max were added to make pg_stat_statements a bit more useful
> if you
> have nothing else using that extension. But once you setup a tool
> that
> snapshots the metrics regu
Hi,
On Tue, Jan 25, 2022 at 3:31 PM Andres Freund wrote:
>
> Hi,
>
> I was looking the shared memory stats patch again. The rebase of which
> collided fairly heavily with the addition of pg_stat_subscription_workers.
>
> I'm concerned about the design of pg_stat_subscription_workers. The view was
1 - 100 of 123 matches
Mail list logo
