Hi,
On Mon, May 17, 2021 at 3:07 PM houzj.f...@fujitsu.com
wrote:
>
> Hi
>
> After 86dc900, In " src/include/nodes/pathnodes.h ",
> I noticed that it uses the word " partitioned UPDATE " in the comment above
> struct RowIdentityVarInfo.
>
> But, it seems " inherited UPDATE " is used in the rest
Hi
After 86dc900, In " src/include/nodes/pathnodes.h ",
I noticed that it uses the word " partitioned UPDATE " in the comment above
struct RowIdentityVarInfo.
But, it seems " inherited UPDATE " is used in the rest of places.
Is it better to keep them consistent by using " inherited UPDATE " ?
B
On Mon, May 17, 2021 at 6:42 AM Michael Paquier wrote:
>
> Hi all,
>
> I have bumped into $subject while playing with this feature, and this
> can be really useful to be able to reset the compression method for
> all the tables at restore.
This makes sense
The patch is simple but that's perhap
> On Mon, May 17, 2021 at 09:33:27AM +0900, Tatsuo Ishii wrote:
>> Me too. Let's backpatch.
>
> A README is not directly user-facing, it is here for developers, so I
> would not really bother with a backpatch. Now it is not a big deal to
> do so either, so that's not a -1 from me, more a +0, for
On Mon, May 17, 2021 at 10:09 AM Dilip Kumar wrote:
>
> On Mon, May 17, 2021 at 8:50 AM Kyotaro Horiguchi
> wrote:
> >
> > Before the commit expectedTLEs is always initialized with just one
> > entry for the TLI of the last checkpoint record.
>
> Right
>
> > (1) If XLogFileReadAnyTLI() found the
On Mon, May 17, 2021 at 9:06 AM Amit Kapila wrote:
>
> On Thu, May 13, 2021 at 7:06 PM vignesh C wrote:
> >
> > On Thu, May 13, 2021 at 4:41 PM Michael Paquier wrote:
>
> Few comments:
> 1.
> + # Ensure a transactional logical decoding message shows up on the slot
> + $node_subscriber->safe_psql
On Mon, May 17, 2021 at 09:33:27AM +0900, Tatsuo Ishii wrote:
> Me too. Let's backpatch.
A README is not directly user-facing, it is here for developers, so I
would not really bother with a backpatch. Now it is not a big deal to
do so either, so that's not a -1 from me, more a +0, for "please fee
> On Mon, 17 May 2021 at 16:45, Tatsuo Ishii wrote:
>> Would you like to push the patch?
>
> Yeah, I can. I was just letting it sit for a while to see if anyone
> else had an opinion about backpatching.
Ok.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanes
On Sat, May 15, 2021 at 12:00:37PM -0400, Robert Haas wrote:
> Oh, I didn't notice previously that Justin's proposal was to make the
> functions return NULL. He's correct that this is consistent with other
> cases, and if we go that way, then these queries need to be updated. I
> had just been imag
On Mon, Apr 5, 2021 at 3:31 PM Jaime Casanova
wrote:
>
> Hi,
>
> When AV worker items where introduced 4 years ago, i was suggested that
> it could be used for other things like cleaning the pending list of GIN
> index when it reaches gin_pending_list_limit instead of making user
> visible operati
On Mon, 17 May 2021 at 16:45, Tatsuo Ishii wrote:
> Would you like to push the patch?
Yeah, I can. I was just letting it sit for a while to see if anyone
else had an opinion about backpatching.
David
David,
>> Thanks for working on that. I had a look and wondered if it might be
>> better to go into slightly less details about the exact atomic
>> function to use. The wording there might lead you to believe you can
>> just call the atomic function on the non-atomic variable.
>>
>> It might be
On Mon, May 17, 2021 at 8:50 AM Kyotaro Horiguchi
wrote:
>
> Before the commit expectedTLEs is always initialized with just one
> entry for the TLI of the last checkpoint record.
Right
> (1) If XLogFileReadAnyTLI() found the segment but no history file
> found, that is, using the dummy TLE-list,
On Fri, 7 May 2021 14:14:16 +0900
Yugo NAGATA wrote:
> On Mon, 26 Apr 2021 16:03:48 +0900
> Yugo NAGATA wrote:
>
> > On Mon, 26 Apr 2021 15:46:21 +0900
> > Yugo NAGATA wrote:
> >
> > > On Tue, 20 Apr 2021 09:51:34 +0900
> > > Yugo NAGATA wrote:
> > >
> > > > On Mon, 19 Apr 2021 17:40:31 -04
On Thu, Apr 29, 2021 at 04:56:42PM +0200, Magnus Hagander wrote:
> I definitely use it all the time to monitor autovacuum all the time.
> The others as well regularly, but autovacuum continuously. I also see
> a lot of people doing things like "from pg_stat_activity where query
> like '%mytablename
> Please add it to the July commitfest: https://commitfest.postgresql.org/33/
Added a commitfest entry https://commitfest.postgresql.org/33/3121/
Thanks & Regards,
Nitin Jadhav
On Mon, May 17, 2021 at 7:05 AM David Rowley wrote:
>
> On Mon, 17 May 2021 at 06:23, Nitin Jadhav
> wrote:
> >
> > >
At Mon, 17 May 2021 13:01:04 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Mon, 17 May 2021 12:20:12 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > Assuming that we keep expectedTLEs synced with recoveryTargetTLI,
> > rescanLatestTimeLine updates the list properly so no need to worry
> > about
At Mon, 17 May 2021 12:20:12 +0900 (JST), Kyotaro Horiguchi
wrote in
> Assuming that we keep expectedTLEs synced with recoveryTargetTLI,
> rescanLatestTimeLine updates the list properly so no need to worry
> about the future. So the issue would be in the past timelines. After
> reading the che
On Thu, May 13, 2021 at 7:06 PM vignesh C wrote:
>
> On Thu, May 13, 2021 at 4:41 PM Michael Paquier wrote:
> >
> > On Thu, May 13, 2021 at 04:14:55PM +0530, vignesh C wrote:
> > > +$node_publisher->wait_for_catchup('tap_sub');
> > > +
> > > # Ensure a transactional logical decoding message show
On Sun, May 16, 2021 at 11:17:46PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > OK, I moved the entry into 'data types', and listed two entries instead
> > of one:
>
> >
> > Allow extensions and built-in data types to implement subscripting (Tom
> > Lane)
> >
>
> Bette
On Sun, May 16, 2021 at 04:23:02PM -0400, Tom Lane wrote:
> And the reason oldestXID contains that is that pg_upgrade applied
> pg_resetwal, which does this:
>
> /*
> * For the moment, just set oldestXid to a value that will force
> * immediate autovacuum-for-w
At Sat, 15 May 2021 10:55:05 +0530, Dilip Kumar wrote
in
> On Sat, May 15, 2021 at 3:58 AM Robert Haas wrote:
> >
> > I did notice, but keep in mind that this was more than 8 years ago.
> > Even if Heikki is reading this thread, he may not remember why he
> > changed 1 line of code one way rath
Bruce Momjian writes:
> OK, I moved the entry into 'data types', and listed two entries instead
> of one:
>
> Allow extensions and built-in data types to implement subscripting (Tom
> Lane)
>
Better, but Dmitry Dolgov gets the credit not me.
>
> Previou
On Sun, May 16, 2021 at 08:39:33PM +0800, Julien Rouhaud wrote:
> Le dim. 16 mai 2021 à 11:23, Alvaro Herrera a écrit
> :
>
> On 2021-May-15, Bruce Momjian wrote:
>
> > On Sat, May 15, 2021 at 05:32:58PM -0400, Bruce Momjian wrote:
>
> > > I also added Alvaro as an author of the co
On Sat, May 15, 2021 at 07:01:25PM -0400, Álvaro Herrera wrote:
> On 2021-May-15, Bruce Momjian wrote:
>
> > On Sat, May 15, 2021 at 02:21:59PM -0400, Álvaro Herrera wrote:
>
> > > I wonder why the initial line says "query hash" instead of "query
> > > identifier". Do we want to say "hash" every
On Sat, May 15, 2021 at 11:23:25PM -0400, Álvaro Herrera wrote:
> On 2021-May-15, Bruce Momjian wrote:
>
> > On Sat, May 15, 2021 at 05:32:58PM -0400, Bruce Momjian wrote:
>
> > > I also added Alvaro as an author of the compute_query_id item.
> >
On Sat, May 15, 2021 at 07:16:18PM -0400, Álvaro Herrera wrote:
> On 2021-May-10, Bruce Momjian wrote:
>
> > I have committed the first draft of the PG 14 release notes. You can
> > see the most current build of them here:
> >
> > https://momjian.us/pgsql_docs/release-14.html
>
> Thanks fo
On Sat, May 15, 2021 at 10:27:08PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > I, um, again think that the item should not be primarily about JSONB,
> > but about our (IMO groundbreaking) extensible subscripting work.
>
> +1. Extensible subscripting is THE feature here, using it for json
>
>
> So now you have to figure out
> what the selectivity of that is after the application of the partially
> redundant IN clauses.
>
Would marking the new added RestrictInfo.norm_selec > 1 be OK?
clause_selectivity_ext
/*
* If the clause is marked redundant, always return 1.0.
On Sat, May 15, 2021 at 07:05:35PM -0400, Álvaro Herrera wrote:
> On 2021-May-12, Bruce Momjian wrote:
>
> > OK, updated text:
> >
> >
> >
> >
> >
> > Change the default of the password_encryption server parameter
> > to scram-sha-256 (Peter Eisentraut)
> >
> >
On Sat, May 15, 2021 at 02:22:24PM -0400, Andrew Dunstan wrote:
> PostgresNode is currently able to create nodes suitable for upgrade down
> to release 10. If we add '-w' to the 'pg_ctl start' flags that can
> extend down to release 9.5. (Just tested) I think we should do that
> forthwith. '-w' is
At Sat, 15 May 2021 11:35:13 -0300, Ranier Vilela wrote
in
> Em sex., 14 de mai. de 2021 às 19:52, Tom Lane escreveu:
>
> > I wrote:
> > > So the question for us is whether it's worth trying to make pgreadlink
> > > conform to the letter of the POSIX spec in this detail. TBH, I can't
> > > ge
On Mon, 17 May 2021 at 06:23, Nitin Jadhav
wrote:
>
> > Hm. If Oracle does that, then there's an argument for us doing it
> > too. I can't get hugely excited about it, but maybe someone else
> > cares enough to prepare a patch.
>
> Thanks for the confirmation. Attached patch supports these forma
From: Bharath Rupireddy
> This can be useful in situations like where there are many remote
> postgres servers that are connected to a single coordinator on which
> foreign tables are defined for each of the remote tables. In this
> case, the DBA (or whoever is responsible to do that job) doesn't
Hi all,
I have bumped into $subject while playing with this feature, and this
can be really useful to be able to reset the compression method for
all the tables at restore. The patch is simple but that's perhaps too
late for 14, so I am adding it to the next CF.
Thanks,
--
Michael
diff --git a/
From: Phil Godfrin
My question is - how does the call to GetConnection() know what port to use?
Lets say we're using PGBouncer to connect on the local server at port 6432, but
there is no pgbouncer listening at the foreign server, what port gets passed?
My first thought is whatever the client c
> Thanks for working on that. I had a look and wondered if it might be
> better to go into slightly less details about the exact atomic
> function to use. The wording there might lead you to believe you can
> just call the atomic function on the non-atomic variable.
>
> It might be best just to
I think you were thinking that the jit_inline_above_cost=0 for queries within
plpgsql functions is pathological and not a useful test case, since the
function can be called an arbitrarily large number of times, but the jit
context can't be reset mid-query due to nonzero reference count.
I think yo
On Mon, 17 May 2021 at 01:29, Tatsuo Ishii wrote:
> Yes, we'd better to fix them. Attached is a propsal for these.
Thanks for working on that. I had a look and wondered if it might be
better to go into slightly less details about the exact atomic
function to use. The wording there might lead yo
Hi,
On 2021-05-16 18:42:53 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Why would it not be safe?
>
> I'm just wondering about the catalog tuples set up by pg_upgrade
> itself. If they're all frozen then they probably don't matter to
> this, but it might take some thought.
There shouldn'
Andres Freund writes:
> On 2021-05-16 18:21:21 -0400, Tom Lane wrote:
>> Hm, yeah. I'm not sure if transferring the value forward from the
>> old cluster is entirely safe, but if it is, that seems like a
>> promising route to a fix. (We should still have more sanity checking
>> around the Global
Hi,
On 2021-05-16 18:21:21 -0400, Tom Lane wrote:
> Peter Geoghegan writes:
> > On Sun, May 16, 2021 at 1:23 PM Tom Lane wrote:
> >> And the reason oldestXID contains that is that pg_upgrade applied
> >> pg_resetwal, which does this:
> >> * For the moment, just set oldestXid to a value that will
Hi,
On 2021-05-16 16:23:02 -0400, Tom Lane wrote:
> And the reason oldestXID contains that is that pg_upgrade applied
> pg_resetwal, which does this:
>
> /*
> * For the moment, just set oldestXid to a value that will force
> * immediate autovacuum-for-wraparou
Peter Geoghegan writes:
> On Sun, May 16, 2021 at 1:23 PM Tom Lane wrote:
>> And the reason oldestXID contains that is that pg_upgrade applied
>> pg_resetwal, which does this:
>> * For the moment, just set oldestXid to a value that will force
>> * immediate autovacuum-for-wraparound.
> This same
Greetings!
Let say I have a foreign server using the reference postgres_fdw defined
without a port number:
CREATE SERVER /dat_server/ FOREIGN DATA WRAPPER /postgres_fdw/ OPTIONS (
|/host '172.1.1.1', dbname 'dbover_der'/| )
Naturally the tables in question are setup using a foreign table
d
On Sun, May 16, 2021 at 1:23 PM Tom Lane wrote:
> it gets an insane value:
>
> oldestfxid 18446744071709568230, latest_completed 16613, oldestxid 2294983910
>
> And the reason oldestXID contains that is that pg_upgrade applied
> pg_resetwal, which does this:
>
> /*
> * For the mom
I wrote:
> What I do have that's new is that *I can reproduce it*, at long last.
I see what's happening, but I'm not quite sure where we should fix it.
> I do not have a lot of idea why, but I see something that is
> probably a honkin' big clue:
> 2021-05-15 17:28:05.965 EDT [2469444] LOG: HeapT
> Hm. If Oracle does that, then there's an argument for us doing it
> too. I can't get hugely excited about it, but maybe someone else
> cares enough to prepare a patch.
Thanks for the confirmation. Attached patch supports these format
patterns. Kindly review and let me know if any changes are r
On Sun, May 16, 2021 at 10:00 AM Justin Pryzby wrote:
> On Sat, May 15, 2021 at 02:40:45PM +0530, Nitin Jadhav wrote:
> > While working on [1], I observed that extra memory is allocated in
> > [1]
> https://mail.google.com/mail/u/2/#search/multi+column+list/KtbxLxgZZTjRxNrBWvmHzDTHXCHLssSprg?comp
Nitin Jadhav writes:
> Thanks for the explanation. I also feel that we may not support every
> case-variant. But the other reason which triggered me to think in the
> other way is, as mentioned in commit [1] where this feature was added,
> says that these format patterns are compatible with Oracle
On Sat, May 15, 2021 at 02:40:45PM +0530, Nitin Jadhav wrote:
> While working on [1], I observed that extra memory is allocated in
> [1]
> https://mail.google.com/mail/u/2/#search/multi+column+list/KtbxLxgZZTjRxNrBWvmHzDTHXCHLssSprg?compose=CllgCHrjDqKgWCBNMmLqhzKhmrvHhSRlRVZxPCVcLkLmFQwrccpTpqLNg
> AFAICS, table 9.26 specifically shows which case-variants are supported.
> If there are some others that happen to work, we probably shouldn't
> remove them for fear of breaking poorly-written apps ... but that does
> not imply that we need to support every case-variant.
Thanks for the explanati
Nitin Jadhav writes:
> While understanding the behaviour of the to_char() function as
> explained in [1], I observed that some patterns related to time zones
> do not display values if we mention in lower case. As shown in the
> sample output [2], time zone related patterns TZH, TZM and OF outputs
Hi Hackers,
While understanding the behaviour of the to_char() function as
explained in [1], I observed that some patterns related to time zones
do not display values if we mention in lower case. As shown in the
sample output [2], time zone related patterns TZH, TZM and OF outputs
proper values wh
I'm resending this because I failed to reply to all.
On Sat, May 8, 2021 at 12:55 AM Etsuro Fujita wrote:
> On Fri, May 7, 2021 at 2:12 AM Stephen Frost wrote:
> > In order to ensure that the data being returned from a foreign server
> > is consistent, postgres_fdw will only open one connection
Hi,
On Fri, May 14, 2021 at 9:00 PM Zhihong Yu wrote:
> Searching postgres codebase reveals the following (partial) examples:
>
> bool is_varlena
> bool is_leaf
>
> I think these are more intuitive.
>
> If you think is_in_async_mode is too long, how about naming the parameter
> is_async ?
Sorry
> Yeah looks like a typo to me.
Ok.
> I wonder if we also need to fix this part:
>
>> either one does their writes. Eventually we might be able to use an atomic
>> fetch-and-add instruction for this specific case on architectures that
>> support
>> it, but we can't rely on that being available
On Mon, 17 May 2021 at 00:11, Tatsuo Ishii wrote:
> I think there is a typo in src/backend/storage/lmgr/README.barrier.
> Attached patch should fix it.
Yeah looks like a typo to me.
I wonder if we also need to fix this part:
> either one does their writes. Eventually we might be able to use an
Le dim. 16 mai 2021 à 11:23, Alvaro Herrera a
écrit :
> On 2021-May-15, Bruce Momjian wrote:
>
> > On Sat, May 15, 2021 at 05:32:58PM -0400, Bruce Momjian wrote:
>
> > > I also added Alvaro as an author of the compute_query_id item.
> > --
I think there is a typo in src/backend/storage/lmgr/README.barrier.
Attached patch should fix it.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jpdiff --git a/src/backend/storage/lmgr/README.barrier b/src/backend/stora
On Sat, May 15, 2021 at 6:41 PM Fabien COELHO wrote:
> The issue is non-deterministically triggered in contrib checks, either in
> int or ltree, but not elsewhere. This suggests issues specific to these
> modules, or triggered by these modules. Hmmm…
Hmm, yeah. A couple of different ways that lt
61 matches
Mail list logo
