On Wed, Sep 29, 2021 12:34 PM Amit Kapila
> On Wed, Sep 29, 2021 at 9:07 AM houzj.f...@fujitsu.com
> wrote:
> >
> > On Tues, Sep 28, 2021 10:46 PM vignesh C wrote:
> > > Attached v34 patch has the changes for the same.
> >
> > 3)
> > + /*
> > +* Check if setting the relation to a d
On Wednesday, September 29, 2021 2:59 PM Greg Nancarrow
wrote:
> On Tue, Sep 28, 2021 at 8:04 PM Amit Kapila
> wrote:
> >
> > > Another idea could be to have a separate view, say
> > > pg_stat_subscription_xact but I'm not sure it's a better idea.
> > >
> >
> > Yeah, that is another idea but I a
On Wed, Sep 29, 2021 at 3:16 PM Amit Kapila wrote:
>
> 4.
> + /*
> + * Check if setting the relation to a different schema will result in the
> + * publication having schema and same schema's table in the publication.
> + */
> + if (stmt->objectType == OBJECT_TABLE)
> + {
> + ListCell *lc;
> + L
Thomas Munro wrote:
> On Wed, Sep 29, 2021 at 8:18 AM Antonin Houska wrote:
> > I'm just trying to use the existing infrastructure: the effect of DROP TABLE
> > also appear to be performed by the checkpointer. However I don't know why
> > the
> > unlinks need to be performed by the checkpointer
Hi,
Thank you, Amit-san and Sawada-san for the discussion.
On Tuesday, September 28, 2021 7:05 PM Amit Kapila
wrote:
> > Another idea could be to have a separate view, say
> > pg_stat_subscription_xact but I'm not sure it's a better idea.
> >
>
> Yeah, that is another idea but I am afraid that
On Tue, Sep 28, 2021 at 8:04 PM Amit Kapila wrote:
>
> > Another idea could be to have a separate
> > view, say pg_stat_subscription_xact but I'm not sure it's a better
> > idea.
> >
>
> Yeah, that is another idea but I am afraid that having three different
> views for subscription stats will be t
hi
ne 26. 9. 2021 v 6:05 odesílatel wenjing napsal:
>
>
> 2021年9月23日 21:55，Tony Zhu 写道：
>
> Hi Wenjing
>
> we have reviewed the code, and done the regression tests, all tests is
> pass, we believe the feature code quality is ready for production ; and I
> will change the status to "Ready for
On Tue, Sep 28, 2021 at 8:15 PM vignesh C wrote:
>
> On Mon, Sep 27, 2021 at 12:15 PM houzj.f...@fujitsu.com
> wrote:
>
> Attached v34 patch has the changes for the same.
>
Few comments on v34-0001-Added-schema-level-support-for-publication
===
2021-09-28 22:55 に shinya11.k...@nttdata.com さんは書きました:
-Original Message-
From: bt21tanigaway
Sent: Tuesday, September 28, 2021 5:06 PM
To: Fujii Masao ;
pgsql-hackers@lists.postgresql.org
Subject: Re: (LOCK TABLE options) “ONLY” and “NOWAIT” are not yet
implemented
2021-09-28 17:03 に b
On Wed, Sep 29, 2021 at 9:07 AM houzj.f...@fujitsu.com
wrote:
>
> On Tues, Sep 28, 2021 10:46 PM vignesh C wrote:
> > Attached v34 patch has the changes for the same.
>
> 3)
> + /*
> +* Check if setting the relation to a different schema will result in
> the
> +* publicatio
On Tue, Sep 28, 2021 at 7:39 PM Andrew Dunstan wrote:
>
>
> On 9/24/21 12:46 PM, Bharath Rupireddy wrote:
> > Hi,
> >
> > I'm trying to set up a postgres server with version 11 in targeted
> > recovery mode (for the first time after my journey started with
> > postgres) and I came across the expla
On Tues, Sep 28, 2021 10:46 PM vignesh C wrote:
> Attached v34 patch has the changes for the same.
Thanks for updating the patch.
Here are a few comments.
1)
+ * ALL TABLES IN SCHEMA schema [[, ...]
[[ -> [
2)
+ /* ALTER PUBLICATION ... ADD/DROP TABLE/ALL TABLES IN SCHEMA par
On Wed, Aug 4, 2021 at 3:22 AM Robert Haas wrote:
> It's not really clear to me what problem is at hand. The problems that
> the tombstone system created for the async I/O stuff weren't really
> explained properly, IMHO. And I don't think the current system is all
> that ugly. it's not the most be
On Monday, Tuesday, September 28, 2021 10:49 PM, vignesh C
wrote:
>
> Yes this should not be supported, we should throw an error in this case.
> This is handled in the v34 patch attached at [1].
> [1] - https://www.postgresql.org/message-
> id/CALDaNm2Z9TfuoCf09YGKfwy7F1NwC4iCXJGTaZS%3DchH6VHtad
On Tue, Sep 28, 2021 at 03:00:13PM -0400, Tom Lane wrote:
> Should we back-patch 0002? I'm inclined to think so. Should
> we then also back-patch enablement of the bloom test? Less
> sure about that, but I'd lean to doing so. A test that appears
> to be there but isn't actually invoked is prett
On Tue, Sep 28, 2021 at 04:15:22PM +0200, Magnus Hagander wrote:
> Is there a reason the "only" is missing from the -s option? AFAIK that's
> what it means, so the attached patch should be correct?
I cannot think of a reason. This seems historically inherited from
pg_dump, and the option got adde
On Fri, Mar 5, 2021 at 11:02 AM Thomas Munro wrote:
> This is a WIP with an open question to research: what could actually
> break if we did this?
I thought this part of bgwriter.c might be a candidate:
if (FirstCallSinceLastCheckpoint())
{
/*
* After any che
On Tue, Sep 28, 2021 at 12:30:10PM +0900, Michael Paquier wrote:
> 0001 is in a rather commitable shape, and I have made the code
> consistent with HEAD. However, I think that its handling of
> _get_osfhandle() is clunky for 64-bit compilations as long is 32b in
> WIN32 but intptr_t is platform-de
Hi Magnus!
I found other functions that we should add "pg_catalog" prefix in
describe.c. This fix is similar to the following commit.
Yup, that's correct. Applied and backpatched to 14 (but it won't be in the 14.0
release).
Thank you!
Regards,
Tatsuro Yamada
On Wed, Sep 29, 2021 at 8:18 AM Antonin Houska wrote:
> I'm just trying to use the existing infrastructure: the effect of DROP TABLE
> also appear to be performed by the checkpointer. However I don't know why the
> unlinks need to be performed by the checkpointer.
For DROP TABLE, we leave an empt
On Tue, Sep 28, 2021 at 02:36:52PM +0900, Michael Paquier wrote:
> I wrote that a bit too quickly. After looking at it, what we could
> use to parse the handle pointer is scanint8() instead, even if that's
> a bit ugly. I also found the code a bit confused regarding "fd", that
> could be manipula
I noticed that some test scripts, instead of using wait_for_catchup
to wait for replication catchup, use ad-hoc code like
my $primary_lsn =
$primary->safe_psql('postgres', 'select pg_current_wal_lsn()');
$standby->poll_query_until('postgres',
qq{SELECT '$primary_lsn'::pg_lsn <= pg_last_w
> On 29/09/2021, at 2:33 AM, Daniel Gustafsson wrote:
>
>> On 28 Sep 2021, at 05:15, Daniel Fone wrote:
>>
>>> On 26/09/2021, at 12:09 AM, Daniel Gustafsson wrote:
>>>
>>> Upgrading our crypt_blowfish.c to the upstream 1.3 version would be the
>>> correct
>>> fix IMO, but since we have a fe
[ redirect to -hackers ]
I wrote:
>> Christophe Pettus writes:
>>> A bit more poking revealed the reason: The ON HOLD cursor's query is
>>> executed at commit time (which is, logically, not interruptible), but
>>> that's all wrapped in the single statement outside of a transaction.
>> Hmm ...
Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > On Tue, Sep 21, 2021 at 10:07:55AM +0200, Dmitry Dolgov wrote:
> > On Tue, 21 Sep 2021 09:00 Antonin Houska, wrote:
> >
> > > Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > >
> > > > Yep, makes sense, thanks. I have few more questions:
> > > >
>
Mark Dilger writes:
> Perhaps having the bloom index messed up answers that, though. I think it
> should be easy enough to get the path to the heap main table fork and the
> bloom main index fork for both the primary and standby and do a filesystem
> comparison as part of the wal test. That w
> On Sep 28, 2021, at 11:07 AM, Mark Dilger
> wrote:
>
> Looking closer at the TAP test, it's not ORDERing the result set from the
> SELECTs on either node, but it is comparing the sets for stringwise equality,
> which is certainly order dependent.
Taking the output from the buildfarm page
Mark Dilger writes:
> Looking closer at the TAP test, it's not ORDERing the result set from the
> SELECTs on either node, but it is comparing the sets for stringwise equality,
> which is certainly order dependent.
Well, it's forcing a bitmap scan, so what we're getting is the native
ordering of
On Tue, 2021-09-28 at 18:08 +, Jacob Champion wrote:
> > | authn authz
> > -+---
> > envvar | PGAUTHUSERPGUSER
> > conninfo | authuser user
> > frontend | conn->pgauthuser conn->pguser backend | port->auth_user
I wrote:
> So there's more than one symptom, but in any case it seems like
> we have an issue in WAL replay. I wonder whether it's bloom's fault
> or a core bug.
Actually ... I bet it's just the test script's fault. It waits for the
standby to catch up like this:
my $caughtup_query =
On Tue, 2021-09-28 at 18:02 +, Jacob Champion wrote:
> On Tue, 2021-09-28 at 15:38 +0200, Magnus Hagander wrote:
> > I'm a bit hesitant about the ldapuser libpq parameter. Do we really
> > want to limit ourselves to just ldap, if we allow this? I mean, why
> > not allow say radius or pam to als
> On Sep 28, 2021, at 10:27 AM, Tom Lane wrote:
>
> I wonder whether it's bloom's fault
> or a core bug.
Looking closer at the TAP test, it's not ORDERing the result set from the
SELECTs on either node, but it is comparing the sets for stringwise equality,
which is certainly order dependent
On Tue, 2021-09-28 at 15:38 +0200, Magnus Hagander wrote:
> I'm a bit hesitant about the ldapuser libpq parameter. Do we really
> want to limit ourselves to just ldap, if we allow this? I mean, why
> not allow say radius or pam to also specify a different username for
> the external system? If we w
I wrote:
> So that's the same hardware, and identical PG source tree, and different
> results. This seems to leave only two theories standing:
I forgot theory 3: it's intermittent. Apparently the probability has
dropped a lot since 2018, but behold:
https://buildfarm.postgresql.org/cgi-bin/show
"Drouvot, Bertrand" writes:
> Does it make sense (as it is currently) to set the ActiveSnapshot to
> NULL and not ensuring the same is done for ActivePortal->portalSnapshot?
I think that patch is just a kluge :-(
After tracing through this I've figured out what is happening, and
why you need to
On Thu, Mar 25, 2021 at 11:15:10AM -0400, David Steele wrote:
> On 1/26/21 11:29 AM, Surafel Temesgen wrote:
> >
> > On Mon, Jan 25, 2021 at 2:39 PM Kyotaro Horiguchi
> > mailto:horikyota@gmail.com>> wrote:
> >
> > Sorry for the dealy. I started to look this.
> >
> > Hi kyotaro,
> > Than
On Tue, Sep 28, 2021 at 6:14 AM Daniel Gustafsson wrote:
>
> Since it's not actually libpq which calls exit (no such patch would ever be
> committed), I think it would be clearer to indicate that a library linked to
> is
> the culprit. How about something like "libpq must not be linked against
On 9/28/21 11:04 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 9/27/21 5:54 PM, Tom Lane wrote:
>>> Currently enum_in() is marked as stable, on the reasonable grounds
>>> that it depends on system catalog contents. However, after the
>>> discussion at [1] I'm wondering why it wouldn't be p
On 09.09.21 16:08, Vik Fearing wrote:
Even without that point, this patch *is* going to break valid queries,
because every one of those cases is a valid number-followed-by-identifier
today,
Ah, true that. So if this does go in, we may as well add the
underscores at the same time.
Yeah, loo
On 07.09.21 13:50, Zhihong Yu wrote:
On 16.08.21 17:32, John Naylor wrote:
> The one thing that jumped out at me on a cursory reading is
> the {integer} rule, which seems to be used nowhere except to
> call process_integer_literal, which must then inspect the token
text to
PostGIS has a very similar thing: ST_Transform is marked as immutable but
does depend on contents of spatial_ref_sys table. Although it is shipped
with extension and almost never changes incompatibly, there are scenarios
where it breaks: dump/restore + index or generated column can fail the
import
Andrew Dunstan writes:
> On 9/27/21 5:54 PM, Tom Lane wrote:
>> Currently enum_in() is marked as stable, on the reasonable grounds
>> that it depends on system catalog contents. However, after the
>> discussion at [1] I'm wondering why it wouldn't be perfectly safe,
>> and useful, to mark it as i
On Tue, Sep 28, 2021 at 8:06 AM Nitin Jadhav
wrote:
> I thought mentioning the unit in milliseconds and the example in
> seconds would confuse the user, so I changed the example to
> milliseconds.The message behind the above description looks good to me
> however I feel some sentences can be expla
On Tue, Sep 28, 2021 at 4:35 PM tanghy.f...@fujitsu.com
wrote:
>
> On Monday, September 27, 2021 1:32 PM, vignesh C wrote:
>
> >Attached v33 patch has the preprocess_pubobj_list review comment fix
> >suggested by Alvaro at [1]. The
> >v33-0006-Alternate-grammar-for-ALL-TABLES-IN-SCHEMA.patch patc
On Mon, Sep 27, 2021 at 4:51 PM Greg Nancarrow wrote:
>
> On Mon, Sep 27, 2021 at 2:32 PM vignesh C wrote:
> >
> > Attached v33 patch has the preprocess_pubobj_list review comment fix
> > suggested by Alvaro at [1].
>
> In the v33-0003 patch, there's a couple of error-case tests that have
> comme
On Mon, Sep 27, 2021 at 2:46 PM Greg Nancarrow wrote:
>
> On Mon, Sep 27, 2021 at 2:32 PM vignesh C wrote:
> >
> > Attached v33 patch has the preprocess_pubobj_list review comment fix
> > suggested by Alvaro at [1].
>
> A minor point I noticed in the v33-0002 patch, in the code added to
> the lis
> On Tue, Sep 21, 2021 at 10:07:55AM +0200, Dmitry Dolgov wrote:
> On Tue, 21 Sep 2021 09:00 Antonin Houska, wrote:
>
> > Dmitry Dolgov <9erthali...@gmail.com> wrote:
> >
> > > Yep, makes sense, thanks. I have few more questions:
> > >
> > > * The use case with orphaned files is working somewhat d
On Mon, Sep 27, 2021 at 2:14 AM Tatsuro Yamada <
tatsuro.yamada...@nttcom.co.jp> wrote:
> Hi,
>
> I found other functions that we should add "pg_catalog" prefix in
> describe.c. This fix is similar to the following commit.
>
Hi!
Yup, that's correct. Applied and backpatched to 14 (but it won't be
A coworker has a space in a Postgres password and noticed .pgpass
didn't work; escaping it fixed the issue. That requirement wasn't
documented (despite other escaping requirements being documented), so
I've attached a patch to add that comment.
Thanks,
James Coleman
v1-0001-Document-spaces-in-.p
Reindexdb help has this for selection of what to reindex:
-s, --system reindex system catalogs
-S, --schema=SCHEMA reindex specific schema(s) only
-t, --table=TABLEreindex specific table(s) only
Is there a reason the "only" is missing from the -s option?
On 9/24/21 12:46 PM, Bharath Rupireddy wrote:
> Hi,
>
> I'm trying to set up a postgres server with version 11 in targeted
> recovery mode (for the first time after my journey started with
> postgres) and I came across the explanation at [1] in PG 12 and newer
> versions that we have a clear diff
Amit Kapila wrote:
> On Mon, Sep 20, 2021 at 10:55 AM Antonin Houska wrote:
> >
> > Amit Kapila wrote:
> >
> > > On Thu, Sep 9, 2021 at 8:33 PM Antonin Houska wrote:
> >
> > > > The problem of the temporary undo log is that it's loaded into local
> > > > buffers
> > > > and that backend can e
On 30.08.21 21:00, Mark Dilger wrote:
The attached patch changes both contrib/amcheck/ and src/bin/pg_amcheck/ to
allow checking sequences. In both cases, the changes required are fairly
minor, though they both entail some documentation changes.
It seems fairly straightforward that if a user
On 9/27/21 10:20 PM, Tom Lane wrote:
> Michael Paquier writes:
>> On Mon, Sep 27, 2021 at 04:19:27PM -0400, Tom Lane wrote:
>>> I tried the same thing (i.e., re-enable bloom's TAP test) on my laptop
>>> just now, and it passed fine. The laptop is not exactly the same
>>> as longfin was in 2018,
>-Original Message-
>From: bt21tanigaway
>Sent: Tuesday, September 28, 2021 5:06 PM
>To: Fujii Masao ;
>pgsql-hackers@lists.postgresql.org
>Subject: Re: (LOCK TABLE options) “ONLY” and “NOWAIT” are not yet
>implemented
>
>2021-09-28 17:03 に bt21tanigaway さんは書きました:
>> 2021-09-28 16:36 に Fuj
On 9/27/21 5:54 PM, Tom Lane wrote:
> Currently enum_in() is marked as stable, on the reasonable grounds
> that it depends on system catalog contents. However, after the
> discussion at [1] I'm wondering why it wouldn't be perfectly safe,
> and useful, to mark it as immutable.
>
> Here's my reas
2021-09-28 17:06 に bt21tanigaway さんは書きました:
2021-09-28 17:03 に bt21tanigaway さんは書きました:
2021-09-28 16:36 に Fujii Masao さんは書きました:
On 2021/09/28 16:13, bt21tanigaway wrote:
Hi,
(LOCK TABLE options) “ONLY” and “NOWAIT” are not yet implemented in
tab-complete. I made a patch for these options.
T
On Fri, Sep 3, 2021 at 11:53 AM Daniel Gustafsson wrote:
>
> > On 1 Sep 2021, at 12:28, Bharath Rupireddy
> > wrote:
> >
> > On Wed, Sep 1, 2021 at 1:56 PM Daniel Gustafsson wrote:
> >> A v2 with the above fixes is attached.
> >
> > Thanks for the updated patch. Here are some comments:
> >
> >
On Wed, Sep 1, 2021 at 8:43 PM Jacob Champion wrote:
>
> On Wed, 2021-09-01 at 15:42 +, Jacob Champion wrote:
> > The cfbot found a failure in postgres_fdw, which I completely neglected
> > in my design. I think the desired functionality should be to allow the
> > ldapuser connection option du
> On 27 Sep 2021, at 23:54, Tom Lane wrote:
> So it seems like the results of
> enum_in() are immutable for as long as anybody could care about them,
> and that's good enough.
+1. I can't think of a situation where this wouldn't hold.
--
Daniel Gustafsson https://vmware.com/
> On 28 Sep 2021, at 05:15, Daniel Fone wrote:
>
> Hi Daniel,
>
> Thanks for the feedback.
>
>> On 26/09/2021, at 12:09 AM, Daniel Gustafsson wrote:
>>
>> But 2b and 2a hashes aren't equal, although very similar. 2a should have the
>> many-buggy to one-correct collision safety and 2b hashes
On Fri, Sep 10, 2021 at 1:44 AM Jacob Champion wrote:
>
> On Wed, 2021-09-08 at 18:51 +, Jacob Champion wrote:
> > I still owe you that overall review. Hoping to get to it this week.
>
> And here it is. I focused on things other than UnwrapProxyConnection()
> for this round, since I think that
> On 28 Sep 2021, at 00:55, Rachel Heaton wrote:
> While developing I got this error and it was difficult to figure out what was
> going on.
>
> Thanks to Jacob, I was able to learn the context of the failure, so we
> created this small patch.
I can see that, and I think this patch makes se
> That's really not what I'm complaining about. I think if we're going
> to give an example at all, 10ms is a better example than 100ms,
> because 10s is a value that people are more likely to find useful. But
> I'm not sure that it's necessary to mention a specific value, and if
> it is, I think i
On Tue, Sep 28, 2021 at 5:21 PM Tomas Vondra
wrote:
> >> Yeah, if it is losing in some cases then it is definitely good to know
> >> the reason, I was just looking into the performance numbers shared by
> >> Tomas in query-results, I can see the worst case is
> >> with 1000 rows, 10 columns an
On 9/28/21 12:53 PM, Amit Kapila wrote:
On Tue, Sep 28, 2021 at 12:19 PM Dilip Kumar wrote:
On Mon, Sep 27, 2021 at 10:52 PM Robert Haas wrote:
And most of the time, that's probably a good bet. But, if you do
somehow hit the losing case repeatedly, then you could see a
significant regressi
On Monday, September 27, 2021 1:32 PM, vignesh C wrote:
>Attached v33 patch has the preprocess_pubobj_list review comment fix
>suggested by Alvaro at [1]. The
>v33-0006-Alternate-grammar-for-ALL-TABLES-IN-SCHEMA.patch patch has
>the grammar changes as suggested by Alvaro at [1]. If we agree this
On Tue, Sep 28, 2021 at 12:19 PM Dilip Kumar wrote:
>
> On Mon, Sep 27, 2021 at 10:52 PM Robert Haas wrote:
>
> >
> > And most of the time, that's probably a good bet. But, if you do
> > somehow hit the losing case repeatedly, then you could see a
> > significant regression. And that might explai
On Tue, Sep 28, 2021 at 11:35 AM Masahiko Sawada wrote:
>
> On Tue, Sep 28, 2021 at 1:54 PM Amit Kapila wrote:
> >
> > >
> > > Then, if, we proceed in this direction,
> > > the place to implement those stats
> > > would be on the LogicalRepWorker struct, instead ?
> > >
> >
> > Or, we can make ex
On Tue, 28 Sep 2021 02:09:11 +0100, Bruce Momjian said:
> I don't think public CA's are not a good idea for complex setups since
> they open the ability for an external party to create certificates that
> are trusted by your server's CA, e.g., certificate authentication.
I'm not arguing for, and
On Mon, 27 Sept 2021 at 23:34, Bruce Momjian wrote:
> On Sun, Sep 5, 2021 at 10:51:42PM +0800, Sasasu wrote:
> > Hi, community,
> >
> > It looks like we are still considering AES-CBC, AES-XTS, and
> AES-GCM(-SIV).
> > I want to say something that we don't think about.
> >
> > For AES-CBC, the IV
On 20.07.21 13:57, Peter Eisentraut wrote:
Perhaps we should change the script or Makefile so that it doesn't
create all the maps in one go?
I agree, either comment it better or just write one file at a time.
I'll take another look at that.
Here is a patch that does it one file (pair) at a
2021-09-28 17:03 に bt21tanigaway さんは書きました:
2021-09-28 16:36 に Fujii Masao さんは書きました:
On 2021/09/28 16:13, bt21tanigaway wrote:
Hi,
(LOCK TABLE options) “ONLY” and “NOWAIT” are not yet implemented in
tab-complete. I made a patch for these options.
Thanks for the patch!
The patch seems to forg
2021-09-28 16:36 に Fujii Masao さんは書きました:
On 2021/09/28 16:13, bt21tanigaway wrote:
Hi,
(LOCK TABLE options) “ONLY” and “NOWAIT” are not yet implemented in
tab-complete. I made a patch for these options.
Thanks for the patch!
The patch seems to forget to handle the tab-completion for
"LOCK ON
On 2021/09/28 16:13, bt21tanigaway wrote:
Hi,
(LOCK TABLE options) “ONLY” and “NOWAIT” are not yet implemented in
tab-complete. I made a patch for these options.
Thanks for the patch!
The patch seems to forget to handle the tab-completion for
"LOCK ONLY IN".
Regards,
--
Fujii Masao
Adv
Hi,
(LOCK TABLE options) “ONLY” and “NOWAIT” are not yet implemented in
tab-complete. I made a patch for these options.
regards,
Koyu Tanigawa
diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
index 5cd5838668..12c55f5904 100644
--- a/src/bin/psql/tab-complete.c
+++ b/src/
76 matches
Mail list logo
