On Mon, Jun 07, 2021 at 11:34:24AM -0400, Tom Lane wrote:
> Yeah, I'd include the empty-string test just because it's standard
> practice in this area of libpq. Whether those tests are actually
> triggerable in every case is obscure, but ...
Checking after a NULL string and an empty one is more l
On Thu, Jun 3, 2021 at 7:56 PM Amit Kapila wrote:
>
> On Wed, Jun 2, 2021 at 4:34 AM Peter Smith wrote:
> >
> > Please find attached the latest patch set v82*
> >
>
> Few comments on 0001:
>
> 1.
> + /*
> + * BeginTransactionBlock is necessary to balance the EndTransactionBlo
On Tue, Jun 8, 2021 at 12:32 AM Robert Haas wrote:
>
> I tried back-porting my version of this patch to 9.6 to see what would
> happen there. One problem is that some of the functions have different
> names before v10. So 9.6 needs this:
>
> -"SELECT pg_walfile_name(pg_current_wal_lsn());");
>
On Sun, Jun 06, 2021 at 03:10:07PM -0400, Tom Lane wrote:
> I wrote:
> > We could make use of COMPARE_COERCIONFORM_FIELD 100% correct by removing
> > these two tests of the funcformat value, but on the whole I doubt that
> > would be better.
>
> On still closer inspection, that seems like it'd be
At Tue, 08 Jun 2021 10:05:36 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Mon, 7 Jun 2021 15:26:05 +0500, Abbas Butt
> wrote in
> > On Mon, Jun 7, 2021 at 3:13 PM Amit Kapila wrote:
> > > I am not sure sending feedback every time before sleep is a good idea,
> > > this might lead to unnecess
On Mon, Jun 7, 2021 at 6:36 PM Etsuro Fujita wrote:
> I created a patch for that, which I'm attaching. I'm planning
> to commit the patch.
Done.
Best regards,
Etsuro Fujita
On Tue, Jun 08, 2021 at 12:46:05PM +0900, Michael Paquier wrote:
> On Mon, Jun 07, 2021 at 02:56:57PM -0400, Tom Lane wrote:
> > +1. I'd support recording the time of the last crash recovery, as
> > well as having a counter. I think an LSN would not be as useful
> > as a timestamp.
>
> One could
Yeah, it's hot these days...
At Tue, 08 Jun 2021 12:04:43 +0900 (JST), Kyotaro Horiguchi
wrote in
> (Mmm. thunderbird or gmail connects this thread to the previous one..)
>
> At Mon, 7 Jun 2021 14:20:38 -0400, Stephen Frost wrote
> in
> > Greetings,
> >
> > * Kyotaro Horiguchi (horikyota..
On Sun, Jun 06, 2021 at 02:50:19PM +0800, Julien Rouhaud wrote:
> On Sat, May 01, 2021 at 03:24:58PM +0800, Julien Rouhaud wrote:
> >
> > I'm attaching some POC patches that implement this approach to start a
> > discussion.
>
> I just noticed that the cfbot fails with the v1 patch. Attached v2
On Mon, Jun 07, 2021 at 02:56:57PM -0400, Tom Lane wrote:
> +1. I'd support recording the time of the last crash recovery, as
> well as having a counter. I think an LSN would not be as useful
> as a timestamp.
One could guess a timestamp based on a LSN, no? So I'd like to think
the opposite act
On Mon, Jun 7, 2021 at 7:29 PM Robert Haas wrote:
>
> On Fri, Jun 4, 2021 at 6:17 AM Amit Kapila wrote:
> > Thoughts?
>
> As far as I can see, trying to error out at function call time if the
> function is parallel-safe doesn't fix any problem we have, and just
> makes the design of this part of
On Mon, Jun 07, 2021 at 10:38:03AM -0400, Tom Lane wrote:
> Hmm. We do include "-lpgcommon -lpgport" when building the ecpg test
> programs on Unix, so I'd assumed that the MSVC scripts did the same.
> Is there a good reason not to make them do so?
I was looking at that this morning, and yes we n
(Mmm. thunderbird or gmail connects this thread to the previous one..)
At Mon, 7 Jun 2021 14:20:38 -0400, Stephen Frost wrote in
> Greetings,
>
> * Kyotaro Horiguchi (horikyota@gmail.com) wrote:
> > So, this is the new new thread.
>
> This is definitely not the way I would recommend starti
On Mon, Jun 07, 2021 at 02:56:57PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Fri, Jun 4, 2021 at 8:41 PM Jeff Davis wrote:
> >> Stepping back, maybe unlogged tables are the wrong level to solve this
> >> problem. We could just have a "crash counter" in pg_control that would
> >> be incr
On Mon, Jun 07, 2021 at 06:10:58PM -0400, Tom Lane wrote:
>
> I'm fairly disinclined to do anything about it though, because I'm
> afraid of the SQL committee standardizing some other syntax for the
> same idea in future (or maybe worse, commandeering the same keyword
> for some other feature). I
On Sun, Jun 06, 2021 at 11:13:40AM -0400, Tom Lane wrote:
> Julien Rouhaud writes:
>> However +1 for the patch, as it seems more consistent to always get a
>> permission failure if you're not a superuser.
>
> Yeah, it's just weird if such a check is not the first thing
> in the function. Even if
On Mon, Jun 7, 2021, at 23:26, David G. Johnston wrote:
> On Mon, Jun 7, 2021 at 1:55 PM Joel Jacobson wrote:
>> __
>> If we don't like "UNQUALIFIED" as a keyword, maybe we could reuse "PUBLIC"?
>> Or will that be confusing since "PUBLIC" is also a role_specification?
>>
>
> For me the concept r
On 2021/06/07 17:32, Kyotaro Horiguchi wrote:
I just noticed that this thread is still tied to another thread
(it's not an independent thread). To fix that, it may be better to
create a new thread again.
Mmm. Maybe my mailer automatically inserted In-Reply-To field for the
cited messsage. Do we
On Mon, 07 Jun 2021 at 19:25, Aleksander Alekseev
wrote:
> Hi Japin,
>
>> When we write a extension using C language, we often add the dynamic
> library
>> into shared_preload_libraries, however, I found that the bloom,
> btree_gist and
>> btree_gin do not follow this rule. I'm a bit confused
On Mon, Jun 07, 2021 at 03:24:33PM -0400, Tom Lane wrote:
>
> Concretely, I think the right fix is per attached.
+1, I agree that this approach is better.
At Mon, 7 Jun 2021 10:40:27 -0400, Robert Haas wrote in
> On Mon, Jun 7, 2021 at 12:57 AM Kyotaro Horiguchi
> wrote:
> > Unfortunately no. The backslashes in the binary path need to be
> > escaped. (taken from PostgresNode.pm:1008)
> >
> > > (my $perlbin = $^X) =~ s{\\}{}g if ($TestLib::wind
At Mon, 7 Jun 2021 15:26:05 +0500, Abbas Butt
wrote in
> On Mon, Jun 7, 2021 at 3:13 PM Amit Kapila wrote:
> > > The immediate cause is pg_recvlogical doesn't send a reply before
> > > sleeping. Currently it sends replies every 10 seconds intervals.
> > >
> >
> > Yeah, but one can use -s option
On Mon, Jun 7, 2021 at 4:11 PM Alvaro Herrera wrote:
> Now, if you do look at _bt_leafbuild(), it can be seen that nothing is
> done differently there either; we're not actually skipping any calls to
> tuplesort_performsort(). Any differentiation between serial/leader/
> worker cases seems to be
From: Masahiko Sawada
> I think we should not reinterpret the severity of the error and lower
> it. Especially, in this case, any kind of errors can be thrown. It
> could be such a serious error that FDW developer wants to report to
> the client. Do we lower even PANIC to a lower severity such as
In release-14.sgml:
Remove server and libpq support
for the version 2 wire protocol
(Heikki Linnakangas)
This was last used as the default in Postgres 7.2 (year 2002).
I thought the last version which used the protocol as the default was
7.3
вт, 8 июн. 2021 г. в 02:25, Thomas Munro :
> Ok, here's a new version incorporating feedback so far.
>
> 1. Invoke pg_regress directly (no make).
>
> 2. Use PG_TEST_EXTRA="wal_consistency_checking" as a way to opt in to
> the more expensive test.
>
> 3. Use parallel schedule rather than serial.
On 2018-Feb-02, Robert Haas wrote:
> Support parallel btree index builds.
While looking at a complaint related to progress report of parallel
index builds[1], I noticed this comment
+ /*
+* Execute this worker's part of the sort.
+*
+* Unlike leader and serial cases, we cannot avoi
I wrote:
> Hmm, these are atop HEAD from a week or so back. The cfbot seems to
> think they still apply. In any case, I was about to spend some effort
> on the docs, so I'll post an updated version soon (hopefully today).
Here is said update (rolled up into one patch this time; maybe that will
a
Hi,
One of the existing limitations of logical decoding / replication is
that it does no care about sequences. The annoying consequence is that
after a failover to logical replica, all the table data may be
replicated but the sequences are still at the initial values, requiring
some custom solut
Alvaro Herrera writes:
> On 2021-Jun-07, Alvaro Herrera wrote:
>> The attached patch does it. Any opinions?
> Eh, really attached.
No particular objection. I'm not sure this will behave quite the
same as simple-Query in error cases, but probably it's close enough.
I'm still wondering though w
"David G. Johnston" writes:
> On Mon, Jun 7, 2021 at 1:54 PM Mark Zellers
> wrote:
>> What if you could use the MINUS keyword in the column
>> list of a select statement to remove a column from the result set returned
>> to the client?
> I asked this a decade ago and got no useful responses.
> h
On 2021-Jun-07, Alvaro Herrera wrote:
> The attached patch does it. Any opinions?
Eh, really attached.
--
Álvaro Herrera39°49'30"S 73°17'W
"No es bueno caminar con un hombre muerto"
>From c5c6e8860e9d425ddea82e32868fedc7562ec51c Mon Sep 17 00:00:00 2001
From: Alvaro
Alvaro Herrera writes:
> The attached patch does it. Any opinions?
My opinion is there's no patch here.
regards, tom lane
On Mon, Jun 7, 2021 at 1:54 PM Mark Zellers
wrote:
> Failing that, I have a modest suggestion that I would like to start a
> discussion around. What if you could use the MINUS keyword in the column
> list of a select statement to remove a column from the result set returned
> to the client?
>
I
On Mon, Jun 7, 2021 at 1:55 PM Joel Jacobson wrote:
> If we don't like "UNQUALIFIED" as a keyword, maybe we could reuse "PUBLIC"?
> Or will that be confusing since "PUBLIC" is also a role_specification?
>
>
For me the concept resembles explicitly denoting certain schemas as being
simple tags, whi
On Mon, Jun 7, 2021 at 2:09 PM David G. Johnston
wrote:
> On Fri, Jun 4, 2021 at 9:03 AM Pavel Stehule
> wrote:
>
>> pá 4. 6. 2021 v 17:43 odesílatel Joel Jacobson
>> napsal:
>>
>>> Maybe this could work:
>>> CREATE SCHEMA schema_name UNQUALIFIED;
>>> Which would explicitly make all the objects
On Fri, Jun 4, 2021 at 9:03 AM Pavel Stehule
wrote:
> pá 4. 6. 2021 v 17:43 odesílatel Joel Jacobson napsal:
>
>> Maybe this could work:
>> CREATE SCHEMA schema_name UNQUALIFIED;
>> Which would explicitly make all the objects created in the schema
>> accessible unqualified, but also enforce ther
On 2021-May-27, Yura Sokolov wrote:
> Alvaro Herrera писал 2021-05-26 23:59:
> > I don't think they should do that. The portal remains open, and the
> > libpq interface does that. The portal gets closed at end of transaction
> > without the need for any client message. I think if the client wa
On Fri, Jun 4, 2021, at 18:03, Pavel Stehule wrote:
>
>
> pá 4. 6. 2021 v 17:43 odesílatel Joel Jacobson napsal:
>> __
>> Maybe this could work:
>> CREATE SCHEMA schema_name UNQUALIFIED;
>> Which would explicitly make all the objects created in the schema accessible
>> unqualified, but also enf
One of the friction points I have found in migrating from Oracle to PostgreSQL
is in the conversion of hierarchical queries from the Oracle START WITH/CONNECT
BY/ORDER SIBLINGS by pattern to using the ANSI recursive subquery form.
Once you wrap your head around it, the ANSI form is not so bad wi
Peter Eisentraut writes:
> On 04.06.21 23:07, Tom Lane wrote:
>> 0001 is the same patch I posted earlier, 0002 is a delta to enable
>> handling ALTER/DROP per spec.
> I checked these patches. They appear to match what was talked about. I
> didn't find anything surprising. I couldn't apply the
I wrote a script to automatically generate the node support functions
(copy, equal, out, and read, as well as the node tags enum) from the
struct definitions.
The first eight patches are to clean up various inconsistencies to make
parsing or generation easier.
The interesting stuff is in pat
On 04.06.21 23:07, Tom Lane wrote:
I wrote:
It would likely not be very hard to fix pg_dump to include explicit
IN markers. I don't think this results in a compatibility problem
for existing dumps, since they won't be taken from databases in
which there are procedures with OUT arguments.
Actu
On 07.06.21 17:27, Tom Lane wrote:
... I tend to agree with Julien's position here. It seems really ugly
to prohibit empty statements just for implementation convenience.
However, the way I'd handle it is to have the grammar remove them,
which is what it does in other contexts. I don't think
On 07.06.21 13:50, David Rowley wrote:
On Mon, 7 Jun 2021 at 23:46, Edmund Horner wrote:
On Mon, 7 Jun 2021 at 22:11, Peter Eisentraut
wrote:
This patch didn't add _outTidRangePath() even though we have outNode()
coverage for most/all path nodes. Was this just forgotten? See
attached pat
I wrote:
> ... I tend to agree with Julien's position here. It seems really ugly
> to prohibit empty statements just for implementation convenience.
> However, the way I'd handle it is to have the grammar remove them,
> which is what it does in other contexts.
Concretely, I think the right fix is
Hi,
I tried back-porting my version of this patch to 9.6 to see what would
happen there. One problem is that some of the functions have different
names before v10. So 9.6 needs this:
-"SELECT pg_walfile_name(pg_current_wal_lsn());");
+"SELECT pg_xlogfile_name(pg_current_xlog_location());"
Robert Haas writes:
> On Fri, Jun 4, 2021 at 8:41 PM Jeff Davis wrote:
>> Stepping back, maybe unlogged tables are the wrong level to solve this
>> problem. We could just have a "crash counter" in pg_control that would
>> be incremented every time a crash happened (and all unlogged tables are
>>
On Fri, Jun 4, 2021 at 8:41 PM Jeff Davis wrote:
> Stepping back, maybe unlogged tables are the wrong level to solve this
> problem. We could just have a "crash counter" in pg_control that would
> be incremented every time a crash happened (and all unlogged tables are
> reset). It might be a numbe
Greetings,
* Kyotaro Horiguchi (horikyota@gmail.com) wrote:
> So, this is the new new thread.
This is definitely not the way I would recommend starting up a new
thread as you didn't include the actual text of the prior discussion for
people to be able to read and respond to, instead making th
On Mon, Jun 7, 2021 at 12:02 PM Bossart, Nathan wrote:
> On 6/6/21, 7:14 PM, "Justin Pryzby" wrote:
> > Now, I wonder whether the startup process should also include some detail
> > about
> > "syncing data dir". It's possible to strace the process to see what it's
> > doing, but most DBA would
On 6/6/21, 7:14 PM, "Justin Pryzby" wrote:
> Now, I wonder whether the startup process should also include some detail
> about
> "syncing data dir". It's possible to strace the process to see what it's
> doing, but most DBA would probably not know that, and it's helpful to know the
> status of r
On Mon, Jun 7, 2021 at 11:27 PM Tom Lane wrote:
>
> Julien Rouhaud writes:
> > On Mon, Jun 7, 2021 at 4:52 PM Peter Eisentraut
> > wrote:
> >> Your patch filters out empty statements at the parse transformation
> >> phase, so they are no longer present when you dump the body back out.
> >> So yo
On Sat, Jun 5, 2021 at 11:03 AM Alvaro Herrera wrote:
> > This added a PQtraceSetFlags() function. We have a dozen PQset*()
> > functions,
> > but this and PQresultSetInstanceData() are the only PQSomethingSet()
> > functions. Is it okay if I rename it to PQsetTraceFlags()? I think that
> > wo
Peter Eisentraut writes:
> Patch attached. Empty host string was handled implicitly by the IP
> detection expression, but I added an explicit check for sanity. (I
> wasn't actually able to get an empty string to this point, but it's
> clearly better to be prepared for it.)
Yeah, I'd include
Julien Rouhaud writes:
> On Mon, Jun 7, 2021 at 4:52 PM Peter Eisentraut
> wrote:
>> Your patch filters out empty statements at the parse transformation
>> phase, so they are no longer present when you dump the body back out.
>> So your edits in the test expected files don't fit.
> Oh, somehow t
On 2021-Jun-07, Anton Voloshin wrote:
> Hello, hackers,
>
> Currently, REL_10_STABLE can't be compiled with gcc-10 or 11, -Werror and
> "./configure" without arguments. E.g. gcc-11 gives an error:
Hi, thanks for the report. I noticed that the commit that introduced
this (41306a511c01) was intro
On Mon, Jun 7, 2021 at 12:57 AM Kyotaro Horiguchi
wrote:
> Unfortunately no. The backslashes in the binary path need to be
> escaped. (taken from PostgresNode.pm:1008)
>
> > (my $perlbin = $^X) =~ s{\\}{}g if ($TestLib::windows_os);
> > $node_primary->append_conf(
> > 'postgresql.conf',
Michael Paquier writes:
> On Sun, Jun 06, 2021 at 05:27:49PM -0400, Tom Lane wrote:
>> So I took
>> a look at disabling GSSENC in these test cases to try to silence
>> hamerkop's test failure that way. Here's a proposed patch.
>> It relies on setenv() being available, but I think that's fine
>> b
On Fri, Jun 4, 2021 at 6:17 AM Amit Kapila wrote:
> Thoughts?
As far as I can see, trying to error out at function call time if the
function is parallel-safe doesn't fix any problem we have, and just
makes the design of this part of the system less consistent with what
we've done elsewhere. For e
Robert Haas writes:
> ... I doubt that we can get away
> with a GetCurrentTimestamp() after applying every WAL record ... that
> seems like it will be slow.
Yeah, that's going to be pretty awful even on machines with fast
gettimeofday, never mind ones where it isn't.
It should be possible to use
On Sun, Jun 6, 2021 at 6:23 PM Justin Pryzby wrote:
> Should it show the rusage ? It's shown at startup completion since 10a5b35a0,
> so it seems strange not to show it here.
I don't know, that seems like it's going to make the messages awfully
long, and I'm not sure of what use it is to see tha
On Mon, Jun 7, 2021 at 6:34 PM Amit Kapila wrote:
> On Mon, Jun 7, 2021 at 6:04 PM Dilip Kumar wrote:
> >
> > I have fixed all pending review comments and also added a test case
> which is working fine.
> >
>
> Few observations and questions on testcase:
> 1.
> +step "s1_lock_s2" { SELECT pg_adv
On Sun, Jun 6, 2021 at 11:20 PM Omar Kilani wrote:
>
> I mean, maybe it's because I've been awake since... 7am yesterday, but
> it seems to me that if Postgres fails catastrophically silently (and I
> would say "it looks like all your data in this table disappeared
> because of some arcane locale
On Mon, Jun 7, 2021 at 6:04 PM Dilip Kumar wrote:
>
> I have fixed all pending review comments and also added a test case which is
> working fine.
>
Few observations and questions on testcase:
1.
+step "s1_lock_s2" { SELECT pg_advisory_lock(2); }
+step "s1_lock_s3" { SELECT pg_advisory_lock(2);
On 6/7/21 2:11 PM, Masahiko Sawada wrote:
> On Mon, Jun 7, 2021 at 4:30 PM Masahiko Sawada wrote:
>>
>> On Mon, Jun 7, 2021 at 11:15 AM Tom Lane wrote:
>>>
>>> husky just reported $SUBJECT:
>>>
>>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=husky&dt=2021-06-05%2013%3A42%3A17
>>>
>
On Mon, Jun 7, 2021 at 8:24 AM Heikki Linnakangas wrote:
>
> On 03/06/2021 21:58, John Naylor wrote:
> > The microbenchmark is the same one you attached to [1], which I extended
> > with a 95% multibyte case.
>
> Could you share the exact test you're using? I'd like to test this on my
> old raspbe
On Mon, Jun 7, 2021 at 8:46 AM Dilip Kumar wrote:
> On Mon, 7 Jun 2021 at 8:30 AM, Amit Kapila
> wrote:
>
>> On Wed, Jun 2, 2021 at 11:52 AM Amit Kapila
>> wrote:
>> >
>> > 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 03/06/2021 21:58, John Naylor wrote:
> What test set have you been using for performance testing this? I'd like
The microbenchmark is the same one you attached to [1], which I extended
with a 95% multibyte case.
Could you share the exact test you're using? I'd like to test this on my
ol
On Mon, Jun 7, 2021 at 4:30 PM Masahiko Sawada wrote:
>
> On Mon, Jun 7, 2021 at 11:15 AM Tom Lane wrote:
> >
> > husky just reported $SUBJECT:
> >
> > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=husky&dt=2021-06-05%2013%3A42%3A17
> >
> > and I find I can reproduce that locally:
> >
>
On Mon, 7 Jun 2021 at 23:46, Edmund Horner wrote:
>
> On Mon, 7 Jun 2021 at 22:11, Peter Eisentraut
> wrote:
>>
>> This patch didn't add _outTidRangePath() even though we have outNode()
>> coverage for most/all path nodes. Was this just forgotten? See
>> attached patch.
>
>
> Yes, it looks lik
On Mon, 7 Jun 2021 at 22:11, Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> This patch didn't add _outTidRangePath() even though we have outNode()
> coverage for most/all path nodes. Was this just forgotten? See
> attached patch.
>
Yes, it looks like an omission. Thanks for spo
Hi Amit-san
From: Amit Langote
> On Fri, Jun 4, 2021 at 6:05 PM Amit Langote
> wrote:
> > On Fri, Jun 4, 2021 at 4:38 PM Amit Langote
> wrote:
> > > On Thu, Jun 3, 2021 at 8:48 PM Amit Langote
> wrote:
> > > > On Tue, Jun 1, 2021 at 5:43 PM houzj.f...@fujitsu.com
> > > > wrote:
> > > > > So,
Hi Japin,
> When we write a extension using C language, we often add the dynamic
library
> into shared_preload_libraries, however, I found that the bloom,
btree_gist and
> btree_gin do not follow this rule. I'm a bit confused with this, could
anybody
> explain it for me?
In the general case, you
Hi, hackers
When we write a extension using C language, we often add the dynamic library
into shared_preload_libraries, however, I found that the bloom, btree_gist and
btree_gin do not follow this rule. I'm a bit confused with this, could anybody
explain it for me?
Thanks in advance.
--
Regr
Second version of the patch fixes problems detected by the FDW
regression tests and shows differences of error reports in
tuple-by-tuple and batched COPY approaches.
--
regards,
Andrey Lepikhov
Postgres Professional
From 68ad02038d7477e005b65bf5aeeac4efbb41073e Mon Sep 17 00:00:00 2001
From: "A
On Mon, Jun 7, 2021 at 3:13 PM Amit Kapila wrote:
> On Mon, Jun 7, 2021 at 12:54 PM Kyotaro Horiguchi
> wrote:
> >
> > At Sat, 5 Jun 2021 16:08:00 +0500, Abbas Butt <
> abbas.b...@enterprisedb.com> wrote in
> > > Hi,
> > > I have observed the following behavior with PostgreSQL 13.3.
> > >
> > >
On Mon, Jun 7, 2021 at 12:54 PM Kyotaro Horiguchi
wrote:
>
> At Sat, 5 Jun 2021 16:08:00 +0500, Abbas Butt
> wrote in
> > Hi,
> > I have observed the following behavior with PostgreSQL 13.3.
> >
> > The WAL sender process sends approximately 500 keepalive messages per
> > second to pg_recvlogica
This patch didn't add _outTidRangePath() even though we have outNode()
coverage for most/all path nodes. Was this just forgotten? See
attached patch.
From 3c696f812d4c6f8c66bc75105c3c1af79c3b2922 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Mon, 7 Jun 2021 12:04:49 +0200
Subject: [PAT
On 03.06.21 20:14, Tom Lane wrote:
I wrote:
It looks like the immediate problem can be resolved by just adding
a check for conn->pghost not being NULL,
... scratch that. There's another problem here, which is that this
code should not be looking at conn->pghost AT ALL. That will do the
wrong
Hi hackers,
> Any opinions on the patch? Is this not worth the effort to fix or is
> there a better way to fix this?
I confirm that the bug still exists in master (be57f216). The patch
fixes it and looks good to me. I changed the wording a little and
added a regression test. The updated patch is
On Fri, Jun 4, 2021 at 12:33 AM Andrey Lepikhov
wrote:
> Good, this text is clear for me.
Cool! I created a patch for that, which I'm attaching. I'm planning
to commit the patch.
Thanks for reviewing!
Best regards,
Etsuro Fujita
note-about-sync-vs-async.patch
Description: Binary data
On Mon, Jun 7, 2021 at 10:44 AM Amit Kapila wrote:
>
> One more comment is that for HEAD, first just create a patch with
> synchronous replication-related doc changes and then write a separate
> patch for prepared transactions.
>
I noticed that docs for "Synchronous replication support for Logica
On Mon, Jun 7, 2021 at 4:52 PM Peter Eisentraut
wrote:
>
> Your patch filters out empty statements at the parse transformation
> phase, so they are no longer present when you dump the body back out.
> So your edits in the test expected files don't fit.
Oh, somehow the tests aren't failing here, I
On Thu, Jun 3, 2021 at 10:39 PM Tom Lane wrote:
>
> "Euler Taveira" writes:
> > I was checking the GRANT on pg_subscription and noticed that the command is
> > not
> > correct. There is a comment that says "All columns of pg_subscription except
> > subconninfo are readable". However, there are c
On Sun, Jun 06, 2021 at 03:52:57PM -0500, Justin Pryzby wrote:
> See also a prior discussion:
> https://www.postgresql.org/message-id/CAFiTN-sm8Dpx3q92g5ohTdZu1_wKsw96-KiEMf3SoK8DhRPfWw%40mail.gmail.com
Ah, thanks for the reference. So this was discussed but not actually
fixed. I can see the dat
On 06.06.21 09:32, Julien Rouhaud wrote:
On Sat, Jun 05, 2021 at 09:44:18PM -0700, Noah Misch wrote:
I get a NULL pointer dereference if the function body has a doubled semicolon:
create function f() returns int language sql begin atomic select 1;; end;
You don't even need a statements to
(Sorry for the noise on the old thread..)
At Mon, 07 Jun 2021 16:54:49 +0900, Tatsuro Yamada
wrote in
> On 2021/06/07 16:31, Kyotaro Horiguchi wrote:
> > At Mon, 07 Jun 2021 16:13:08 +0900, Tatsuro Yamada
> > wrote in
> >> I just noticed that this thread is still tied to another thread
> >> (i
So, this is the new new thread.
This thread should have been started here:
https://www.postgresql.org/message-id/20210531.165825.921389284096975508.horikyota.ntt%40gmail.com
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
On Wed, Jun 2, 2021 at 9:04 AM Peter Smith wrote:
>
> Please find attached the latest patch set v82*
>
Some suggested changes to the 0001 patch comments (and note also the
typo "doumentation"):
diff of before and after follows:
8c8
< built-in logical replication, we need to do the below things:
On Sat, Jun 5, 2021 at 5:41 AM Alvaro Herrera wrote:
>
> > This indicates that a toast record was present for that relation,
> > despite:
>
> Can you explain what it is you saw that indicates that a toast record
> was present for the relation? I may be misreading the code, but there's
> nothing o
On 05.06.21 14:25, David Christensen wrote:
On Jun 5, 2021, at 2:29 AM, Peter Eisentraut
wrote:
On 04.06.21 22:24, David Christensen wrote:
So what are the necessary and sufficient conditions to check at this point?
The constraint already exists, so what permissions would we need to chec
On 2021/06/07 16:31, Kyotaro Horiguchi wrote:
At Mon, 07 Jun 2021 16:13:08 +0900, Tatsuro Yamada
wrote in
I just noticed that this thread is still tied to another thread
(it's not an independent thread). To fix that, it may be better to
create a new thread again.
Mmm. Maybe my mailer automat
On 05.06.21 14:21, David Christensen wrote:
On Jun 5, 2021, at 2:30 AM, Peter Eisentraut
wrote:
On 03.06.21 22:49, David Christensen wrote:
Presented for discussion is a POC for a DELETE CASCADE functionality, which will allow
you one-shot usage of treating existing NO ACTION and RESTRICT
At Mon, 07 Jun 2021 15:57:00 +0900, Tatsuro Yamada
wrote in
> Hi Horiguchi-san,
>
> >> Regarding "test ! -f",
> >> I am wondering how many people are using the test command for
> >> archive_command. If I remember correctly, the guide provided by
> >> NTT OSS Center that we are using does not re
On Mon, Jun 7, 2021 at 11:15 AM Tom Lane wrote:
>
> husky just reported $SUBJECT:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=husky&dt=2021-06-05%2013%3A42%3A17
>
> and I find I can reproduce that locally:
>
> diff -U3
> /home/postgres/pgsql/contrib/pg_visibility/expected/pg_visib
At Mon, 07 Jun 2021 16:13:08 +0900, Tatsuro Yamada
wrote in
> I just noticed that this thread is still tied to another thread
> (it's not an independent thread). To fix that, it may be better to
> create a new thread again.
Mmm. Maybe my mailer automatically inserted In-Reply-To field for the
c
At Sat, 5 Jun 2021 16:08:00 +0500, Abbas Butt
wrote in
> Hi,
> I have observed the following behavior with PostgreSQL 13.3.
>
> The WAL sender process sends approximately 500 keepalive messages per
> second to pg_recvlogical.
> These keepalive messages are totally un-necessary.
> Keepalives sho
Hello, hackers,
Currently, REL_10_STABLE can't be compiled with gcc-10 or 11, -Werror
and "./configure" without arguments. E.g. gcc-11 gives an error:
objectaddress.c:1618:99: error: ‘typeoids’ may be used uninitialized
[-Werror=maybe-uninitialized]
1618 |
ObjectIdGetDatum(typeoid
Hi Horiguchi-san,
(To recap: In a replication set using archive, startup tries to
restore WAL files from archive before checking pg_wal directory for
the desired file. The behavior itself is intentionally designed and
reasonable. However, the restore code notifies of a restored file
regardless
100 matches
Mail list logo
