On Tue, Jun 1, 2021, at 18:05, Pavel Stehule wrote:
> I learned programming on Orafce, and I didn't expect any success, so I
> designed it quickly, and the placing of old Orafce's functions to schemas is
> messy.
>
> I am sure, if I started again, I would never use pg_catalog or public schema.
On Tue, Jun 1, 2021 at 3:39 PM Dilip Kumar wrote:
>
> On Tue, Jun 1, 2021 at 12:29 PM tanghy.f...@fujitsu.com
> > I noticed that in case1, ExtractReplicaIdentity function returned NULL on
> > HEAD. But after your fix, it didn’t return NULL. There is no problem with
> > this case on HEAD, but th
On Wed, Jun 2, 2021 at 11:38 AM Dilip Kumar wrote:
>
> On Wed, Jun 2, 2021 at 11:25 AM Amit Kapila wrote:
> >
> > On Tue, Jun 1, 2021 at 5:23 PM Dilip Kumar wrote:
> > >
> > > On Tue, Jun 1, 2021 at 12:25 PM Amit Kapila
> > > wrote:
> > >
> > > > >
> > > > > IMHO, as I stated earlier one way t
On Wed, Jun 2, 2021 at 5:20 PM Michael Paquier wrote:
> Note: FreeBSD 13~ has support for copy_file_range(), nice.. Adding
> Thomas in CC in case I am missing something.
Yeah, so at least in theory Linux and FreeBSD can now both do tricks
like pushing copies down to network filesystems, COW file
On Wed, Jun 2, 2021 at 3:33 PM Bharath Rupireddy
wrote:
>
> > + /* If connect option is supported, the others also need to be. */
> > + Assert((supported_opts & SUBOPT_CONNECT) == 0 ||
> > +((supported_opts & SUBOPT_ENABLED) != 0 &&
> > + (supported_opts & SUBOPT_CREATE_SLOT) != 0 &&
> > + (su
On Wed, Jun 2, 2021 at 11:25 AM Amit Kapila wrote:
>
> On Tue, Jun 1, 2021 at 5:23 PM Dilip Kumar wrote:
> >
> > On Tue, Jun 1, 2021 at 12:25 PM Amit Kapila wrote:
> >
> > > >
> > > > IMHO, as I stated earlier one way to fix this problem is that we add
> > > > the spec abort operation (DELETE +
On Tue, Jun 1, 2021 at 9:05 PM Peter Eisentraut
wrote:
>
> On 01.06.21 06:01, Amit Kapila wrote:
> > But, won't that be costly in cases where we have errors in the
> > processing of very large transactions? Subscription has to process all
> > the data before it gets an error. I think we can even i
On Tue, Jun 1, 2021 at 5:23 PM Dilip Kumar wrote:
>
> On Tue, Jun 1, 2021 at 12:25 PM Amit Kapila wrote:
>
> > >
> > > IMHO, as I stated earlier one way to fix this problem is that we add
> > > the spec abort operation (DELETE + XLH_DELETE_IS_SUPER flag) to the
> > > queue, maybe with action name
On Wed, Jun 2, 2021 at 9:07 AM Peter Smith wrote:
>
> On Wed, Jun 2, 2021 at 12:55 AM Bharath Rupireddy
> wrote:
> >
> > On Mon, May 24, 2021 at 7:04 AM Michael Paquier wrote:
> > > Please see a3dc926 and the surrounding discussion for reasons why we've
> > > been using bitmaps for option pars
On Wed, Jun 2, 2021 at 6:33 AM Michael Paquier wrote:
>
> On Wed, Jun 02, 2021 at 12:30:55PM +1200, Thomas Munro wrote:
> > I wondered if we could find a way to make identifiers that regular
> > queries are prohibited from using, at least by documentation. You
> > could take advantage of the vari
On Fri, May 28, 2021 at 05:30:51AM +, Paul Guo wrote:
> Did some small modification and rebased the code. See attached for the new
> version.
Regarding patch 0002, I find the inter-dependencies between
write_target_range() and copy_target_range() a bit confusing. There
is also a bit of dupli
On Thu, May 27, 2021 at 10:29:14AM -0400, Greg Sabino Mullane wrote:
> I was originally on the fence about including this as well, but it seems
> like since the database is shut down and already in a consistent state,
> there seems no advantage to syncing if we have not made any changes. Things
> a
On Wed, Jun 02, 2021 at 01:37:51AM +, houzj.f...@fujitsu.com wrote:
> In the latest HEAD branch, I found some places were using
> appendStringInfo/appendPQExpBuffer() when they could have been using
> appendStringInfoString/ appendPQExpBufferStr() instead. I think we'd better
> fix these places
On Tue, Jun 1, 2021 at 8:01 PM Dilip Kumar wrote:
>
>
> The attached patch fixes by queuing the spec abort change and cleaning
> up the toast hash on spec abort. Currently, in this patch I am
> queuing up all the spec abort changes, but as an optimization we can
> avoid
> queuing the spec abort f
On Wed, Jun 2, 2021 at 12:55 AM Bharath Rupireddy
wrote:
>
> On Mon, May 24, 2021 at 7:04 AM Michael Paquier wrote:
> > Please see a3dc926 and the surrounding discussion for reasons why we've
> > been using bitmaps for option parsing lately.
>
> Thanks for the suggestion. Here's a WIP patch imp
On Tue, Jun 01, 2021 at 10:14:49AM +0900, Michael Paquier wrote:
> Okay, applied this stuff to 12 and 13 to take care of the build
> failures with hamerkop. The ECPG tests should also turn back to green
> there.
hamerkop has reported back, and things are now good on those
branches. Now for the r
On Thu, May 27, 2021 at 03:52:06PM -0700, Peter Geoghegan wrote:
> On Thu, May 27, 2021 at 1:29 PM Tom Lane wrote:
>> Yeah. My belief here is that users might bother to change
>> default_toast_compression, or that we might do it for them in a few
>> years, but the gains from doing so are going to
On 2021/05/31 17:18, Kyotaro Horiguchi wrote:
Sorry for missing this.
At Mon, 31 May 2021 12:52:54 +0900, Fujii Masao
wrote in
On 2021/05/19 19:24, Fujii Masao wrote:
On 2021/05/19 16:43, Kyotaro Horiguchi wrote:
+1 for adding some tests for pg_wal_replay_pause() but the test seems
like
On Thu, May 27, 2021 at 04:17:58PM -0400, Tom Lane wrote:
> BTW, perhaps I should clarify my goal here: it's to cut off expending
> further effort on this feature during v14.
No disagreement here.
> If we can decide that the
> existing performance situation is acceptable, I'm content with that
>
On Tue, Jun 1, 2021 at 6:14 PM Michael Paquier wrote:
> On Tue, Jun 01, 2021 at 10:32:59AM -0700, Zhihong Yu wrote:
> > It seems error code checking in pgtls_init() should follow the same
> > convention as PG codebase adopts - i.e. the non-zero error code should be
> > returned (instead of hard c
Hi all,
While looking at a separate issue, I have noticed that TestLib.pm is
lagging behind in terms of environment variables it had better mask to
avoid failures:
https://www.postgresql.org/message-id/ylxjfov3teapi...@paquier.xyz
Once I began playing with the variables not covered yet, and teste
Hi,
In the latest HEAD branch, I found some places were using
appendStringInfo/appendPQExpBuffer() when they could have been using
appendStringInfoString/ appendPQExpBufferStr() instead. I think we'd better
fix these places in case other developers will use these codes as a reference,
though, it s
On Tue, Jun 01, 2021 at 10:32:59AM -0700, Zhihong Yu wrote:
> It seems error code checking in pgtls_init() should follow the same
> convention as PG codebase adopts - i.e. the non-zero error code should be
> returned (instead of hard coded -1).
>
> Please see the attached patch.
I don't see the p
Hi.
The documentation of ALTER SUBSCRIPTION REFRESH PUBLICATION [1] says:
--
REFRESH PUBLICATION
Fetch missing table information from publisher. This will start
replication of tables that were added to the subscribed-to
publications since the last invocation of REFRESH PUBLICATION or si
On Wed, Jun 02, 2021 at 12:30:55PM +1200, Thomas Munro wrote:
> I wondered if we could find a way to make identifiers that regular
> queries are prohibited from using, at least by documentation. You
> could take advantage of the various constraints on unquoted
> identifiers in the standard (for ex
On Wed, Jun 2, 2021 at 2:02 AM Bharath Rupireddy
wrote:
> PSA v3 patch. I added a commit message and made some cosmetic adjustments.
Reminds me of this fun topic in Lisp:
https://en.wikipedia.org/wiki/Hygienic_macro#Strategies_used_in_languages_that_lack_hygienic_macros
I wondered if we could f
I wrote:
> It's possible that we could revert proargtypes and still accommodate
> the spec's definition for ALTER/DROP ROUTINE/PROCEDURE. I'm imagining
> some rules along the line of:
> 1. If arg list contains any parameter modes, then it must be PG
> syntax, so interpret it according to our tradi
On Mon, May 31, 2021 at 9:16 PM Amit Kapila wrote:
>
> On Fri, May 28, 2021 at 11:55 AM Amit Kapila wrote:
> >
> > One minor comment for 0001.
> > * Special case: if when tables were specified but copy_data is
> > + * false then it is safe to enable two_phase up-front because
> > + * those tables
Peter Eisentraut writes:
> So while I understand the argument of
> - Function signatures should work consistently with procedure signatures.
> I find the arguments of
> - Procedure signatures should match the SQL standard, and
> - Signature for invoking should match signature for calling.
> a more
On 31.05.21 22:25, Tom Lane wrote:
I wrote:
Peter Eisentraut writes:
I don't see that.
It's under CREATE PROCEDURE. 11.60 SR 20 says
Oh... just noticed something else relevant to this discussion: SR 13
in the same section saith
13) If R is an SQL-invoked function, then no
in NPL
Peter Eisentraut writes:
> On 31.05.21 16:16, Andrew Dunstan wrote:
>> make SKIPDOCS=1 world
>> make SKIPDOCS=1 install-world
> Maybe this should be configure option? That's generally where you set
> what you want to build or not build. (That might also make the
> buildfarm integration easier
On 31.05.21 16:16, Andrew Dunstan wrote:
make SKIPDOCS=1 world
make SKIPDOCS=1 install-world
Maybe this should be configure option? That's generally where you set
what you want to build or not build. (That might also make the
buildfarm integration easier, since there are already f
I wrote:
> I think a preferable fix involves making sure that the correct
> record-type typmod is propagated to record_in in this context.
> Alternatively, maybe we could insert the foreign table's rowtype
> during execution of the input operation, without touching the
> plan as such.
Here's a dra
On Fri, May 28, 2021 at 2:05 AM Kyotaro Horiguchi
wrote:
> Mmmm. That looks like meaning that we don't intend to support the
> Dilip's case, and means that we support the use of
> archive-command-copies-only-other-than-wal-segments?
Actually, I think Dilip's case ought to be supported, but I als
Alexander Pyhalov writes:
> Tom Lane писал 2021-06-01 21:19:
>> ISTM that using a specific rowtype rather than RECORD would be
>> quite disastrous from the standpoint of bloating the number of
>> distinct resjunk columns we need for a partition tree with a
>> lot of children. Maybe we'll have to
On 5/31/21 4:25 PM, Tom Lane wrote:
>
> Oh... just noticed something else relevant to this discussion: SR 13
> in the same section saith
>
> 13) If R is an SQL-invoked function, then no
> in NPL shall contain a .
>
> In other words, the spec does not have OUT or INOUT parameters for
> functi
s/Node/Note/
Other than that, +1 to the patch and +1 to backpatching.
The new status of this patch is: Waiting on Author
rebased and alphabetized
>From c1420e17cc2036d4bf3a6c1f9366bf1cd03bd831 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Sun, 15 Nov 2020 16:54:53 -0600
Subject: [PATCH v5] create table (like .. including ACCESS METHOD)
---
doc/src/sgml/ref/create_table.sgml| 22 ++-
Tom Lane писал 2021-06-01 21:19:
Alexander Pyhalov writes:
What about the following patch?
ISTM that using a specific rowtype rather than RECORD would be
quite disastrous from the standpoint of bloating the number of
distinct resjunk columns we need for a partition tree with a
lot of children
Alexander Pyhalov writes:
> What about the following patch?
ISTM that using a specific rowtype rather than RECORD would be
quite disastrous from the standpoint of bloating the number of
distinct resjunk columns we need for a partition tree with a
lot of children. Maybe we'll have to go that way,
"David G. Johnston" writes:
> When this discussion concludes a review of the compatibility sections of
> the create/drop “routine” reference pages would be appreciated.
Good idea, whichever answer we settle on. But it's notable that
the existing text gives no hint that the rules are different
fo
Hi,
It seems error code checking in pgtls_init() should follow the same
convention as PG codebase adopts - i.e. the non-zero error code should be
returned (instead of hard coded -1).
Please see the attached patch.
Thanks
tls-init-error-handling.patch
Description: Binary data
út 1. 6. 2021 v 17:57 odesílatel Joel Jacobson napsal:
> On Tue, Jun 1, 2021, at 14:41, Pavel Stehule wrote:
>
> út 1. 6. 2021 v 13:13 odesílatel Joel Jacobson napsal:
>
> I don't agree. If an extension provides functionality that is supposed to
> be used by all parts of the system, then I think
Amit Langote писал 2021-06-01 15:47:
Perhaps, we can get away with adding the wholerow Var with the target
relation's reltype when the target foreign table is not a "child"
relation, but the root target relation itself. Maybe like the
attached?
Hi.
I think the patch fixes this issue, but it
On Tue, Jun 1, 2021, at 14:41, Pavel Stehule wrote:
> út 1. 6. 2021 v 13:13 odesílatel Joel Jacobson napsal:
>> __I don't agree. If an extension provides functionality that is supposed to
>> be used by all parts of the system, then I think the 'public' schema is a
>> good choice.
>
> I disagree
On 01.06.21 06:01, Amit Kapila wrote:
But, won't that be costly in cases where we have errors in the
processing of very large transactions? Subscription has to process all
the data before it gets an error. I think we can even imagine this
feature to be extended to use commitLSN as a skip candidat
On Mon, May 24, 2021 at 7:04 AM Michael Paquier wrote:
> Please see a3dc926 and the surrounding discussion for reasons why we've
> been using bitmaps for option parsing lately.
Thanks for the suggestion. Here's a WIP patch implementing the
subscription command options as bitmaps similar to what
On Tue, Jun 1, 2021 at 5:22 PM Dilip Kumar wrote:
>
> On Tue, Jun 1, 2021 at 12:25 PM Amit Kapila wrote:
>
> > >
> > > IMHO, as I stated earlier one way to fix this problem is that we add
> > > the spec abort operation (DELETE + XLH_DELETE_IS_SUPER flag) to the
> > > queue, maybe with action name
On Mon, May 31, 2021 at 04:16:52PM -0400, Stephen Frost wrote:
> Greetings,
>
> * Andres Freund (and...@anarazel.de) wrote:
> > On 2021-05-27 17:00:23 -0400, Bruce Momjian wrote:
> > > If you go in that direction, you should make sure pg_upgrade preserves
> > > what you use (it does not preserve r
On Tue, Jun 1, 2021 at 5:24 PM Bernd Helmle wrote:
>
> Am Dienstag, dem 01.06.2021 um 13:13 +0530 schrieb Bharath Rupireddy:
> > I used MyProcPid which seems more random than MyBackendId (which is
> > just a number like 1,2,3...). Even with this, someone could argue
> > that
> > they can look at t
Hi,
On Tue, Jun 1, 2021 at 1:04 AM Alexander Pyhalov
wrote:
>
> Alexander Pyhalov писал 2021-05-31 15:39:
> > Hi.
> >
> > There's issue with join pushdown after
> >
> > commit 86dc90056dfdbd9d1b891718d2e5614e3e432f35
> > Author: Tom Lane
> > Date: Wed Mar 31 11:52:34 2021 -0400
> >
> ...
> > Y
út 1. 6. 2021 v 13:13 odesílatel Joel Jacobson napsal:
> On Tue, Jun 1, 2021, at 12:55, Pavel Stehule wrote:
>
>
>
> út 1. 6. 2021 v 12:53 odesílatel Joel Jacobson napsal:
>
> On Tue, Jun 1, 2021, at 10:44, Pavel Stehule wrote:
>
> Operators use schemas too. I cannot imagine any work with opera
Hi Soumyadeep, Jacob,
> Thanks for the review!
I came across this patch and noticed that it rotted a little, especially
after removing inheritance_planner() in 86dc9005. I managed to resolve the
conflicts on current `master` (eb89cb43), see the attached patch. The code
compiles but doesn't pass t
On Mon, May 31, 2021 at 4:16 PM Stephen Frost wrote:
> There did seem to generally be some usefulness to having relfilenodes
> preserved across major version upgrades beyond TDE and that's a pretty
> independent project that could be tackled independently of TDE efforts.
+1.
--
Robert Haas
EDB:
On Tue, Jun 1, 2021 at 6:56 PM Amit Kapila wrote:
> On Mon, May 31, 2021 at 8:51 AM Amit Langote wrote:
> > On Thu, May 27, 2021 at 3:36 PM Amit Kapila wrote:
> > > Why do we need to move send_relation_and_attrs() call? I think it
> > > doesn't matter much either way but OTOH, in the existing co
I noticed that 428b260f87e8 (v12) broke the cases where a parent
foreign table has row marks assigned. Specifically, the following
Assert added to expand_inherited_rtentry() by that commit looks bogus
in this regard:
/* The old PlanRowMark should already have necessitated adding TID */
Assert(old
Am Dienstag, dem 01.06.2021 um 13:13 +0530 schrieb Bharath Rupireddy:
> I used MyProcPid which seems more random than MyBackendId (which is
> just a number like 1,2,3...). Even with this, someone could argue
> that
> they can look at the backend PID, use it in the materialized view
> names just to
On Tue, Jun 1, 2021 at 12:25 PM Amit Kapila wrote:
> >
> > IMHO, as I stated earlier one way to fix this problem is that we add
> > the spec abort operation (DELETE + XLH_DELETE_IS_SUPER flag) to the
> > queue, maybe with action name
> > "REORDER_BUFFER_CHANGE_INTERNAL_SPEC_ABORT" and as part of
On Tue, Jun 1, 2021, at 12:55, Pavel Stehule wrote:
>
>
> út 1. 6. 2021 v 12:53 odesílatel Joel Jacobson napsal:
>> On Tue, Jun 1, 2021, at 10:44, Pavel Stehule wrote:
>>> Operators use schemas too. I cannot imagine any work with operators with
>>> the necessity of explicit schemas.
>>
>> I t
út 1. 6. 2021 v 12:53 odesílatel Joel Jacobson napsal:
> On Tue, Jun 1, 2021, at 10:44, Pavel Stehule wrote:
>
> Operators use schemas too. I cannot imagine any work with operators with
> the necessity of explicit schemas.
>
>
> I thought operators are mostly installed in the public schema, in w
On Tue, Jun 1, 2021, at 10:44, Pavel Stehule wrote:
> Operators use schemas too. I cannot imagine any work with operators with the
> necessity of explicit schemas.
I thought operators are mostly installed in the public schema, in which case
that wouldn't be a problem, or am I missing something
On Tue, Jun 1, 2021 at 12:29 PM tanghy.f...@fujitsu.com
wrote:
>
> Hi
>
>
>
> I have some questions with your patch. Here are two cases I used to check the
> bug.
>
>
>
> Case1(PK toasted_key is short), data could be synchronized on HEAD.
>
> ---
>
> INSERT INTO toasted_key(toasted_ke
On Mon, May 31, 2021 at 8:51 AM Amit Langote wrote:
>
> On Thu, May 27, 2021 at 3:36 PM Amit Kapila wrote:
> > On Fri, May 21, 2021 at 1:12 PM Amit Langote
> > wrote:
> > >
> >
> > Why do we need to move send_relation_and_attrs() call? I think it
> > doesn't matter much either way but OTOH, in
On Tue, Jun 1, 2021 at 1:24 PM Masahiko Sawada wrote:
>
> On Tue, Jun 1, 2021 at 2:28 PM Amit Kapila wrote:
> >
> > On Tue, Jun 1, 2021 at 10:07 AM Masahiko Sawada
> > wrote:
> > >
> > > On Tue, Jun 1, 2021 at 1:01 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Tue, Jun 1, 2021 at 12:55 AM Pe
On Mon, May 31, 2021 at 3:34 PM houzj.f...@fujitsu.com
wrote:
>
>
> Attaching v6 patchset.
> And I registered it in CF https://commitfest.postgresql.org/33/3143/,
> comments are welcome.
>
The latest patchset has some documentation updates. I'd like to
suggest a couple of documentation tweaks (th
On Fri, May 28, 2021 at 10:53 PM Etsuro Fujita wrote:
> On Fri, May 28, 2021 at 5:29 PM Kyotaro Horiguchi
> wrote:
> > The patch drops some "= NULL" (initial) initializations when
> > nasyncplans == 0. AFAICS makeNode() fills the returned memory with
> > zeroes but I'm not sure it is our conventi
út 1. 6. 2021 v 8:59 odesílatel Joel Jacobson napsal:
> On Sun, May 30, 2021, at 09:54, Pavel Stehule wrote:
>
> Maybe inverted design can work better - there can be GUC -
> "qualified_names_required" with a list of schemas without enabled implicit
> access.
>
> The one possible value can be "all
Hi Amit-san
From: Amit Langote
Sent: Thursday, May 27, 2021 4:46 PM
> Hou-san,
>
> On Thu, May 27, 2021 at 3:56 PM houzj.f...@fujitsu.com
> wrote:
> > From: Amit Langote
> > Sent: Thursday, May 27, 2021 1:54 PM
> > > On Thu, May 27, 2021 at 11:47 AM houzj.f...@fujitsu.com
> > > wrote:
> > > >
On Tue, Jun 1, 2021 at 9:19 AM Noah Misch wrote:
>
> On Thu, Apr 08, 2021 at 11:41:17AM +0200, Magnus Hagander wrote:
> > I've applied this patch with some minor changes.
Thanks for taking a look at this function.
> I wondered if the new pg_wait_for_backend_termination() could replace
> regress.
On Tue, Jun 1, 2021 at 2:28 PM Amit Kapila wrote:
>
> On Tue, Jun 1, 2021 at 10:07 AM Masahiko Sawada wrote:
> >
> > On Tue, Jun 1, 2021 at 1:01 PM Amit Kapila wrote:
> > >
> > > On Tue, Jun 1, 2021 at 12:55 AM Peter Eisentraut
> > > wrote:
> > > >
> > > > On 27.05.21 12:04, Amit Kapila wrote:
On Tue, Jun 1, 2021 at 7:11 AM Michael Paquier wrote:
>
> On Fri, May 21, 2021 at 03:56:31PM +0530, Bharath Rupireddy wrote:
> > On Fri, May 21, 2021 at 6:08 AM Michael Paquier wrote:
> >> I am not sure that I see the point of using a random() number here
> >> while the backend ID, or just the PI
On Mon, May 31, 2021 at 09:07:38PM -0400, Tom Lane wrote:
> Michael Paquier writes:
>>> Agreed, that seems bogus.
>
>> There may be others, and I have not checked yet. I'd rather do a
>> backpatch for this part, would you agree?
>
> +1
Playing with all those variables and broken values here an
Hi.
The attached PG docs patch about catalog deadlocks was previously
implemented in another thread [1], but it seems more relevant to this
one.
PSA.
--
[1]
https://www.postgresql.org/message-id/CAA4eK1K%2BSeT31pxwL5iTvXq%3DJhZpG_cUJLFhiz-eD%2BJr-WAPeg%40mail.gmail.com
Kind Regards,
Peter
On Sun, May 30, 2021, at 09:54, Pavel Stehule wrote:
> Maybe inverted design can work better - there can be GUC -
> "qualified_names_required" with a list of schemas without enabled implicit
> access.
>
> The one possible value can be "all".
>
> The advantage of this design can be the possibili
74 matches
Mail list logo
