On 2021/09/08 21:32, kuroda.hay...@fujitsu.com wrote:
Dear Horiguchi-san,
Thank you for reviewing! I attached the fixed version.
Thanks for updating the patch!
+ for (i = n - 1; i >= 0; i--)
+ {
+ if (strcmp(keywords[i], "application_name")
On 08.09.21 04:04, Kyotaro Horiguchi wrote:
At Tue, 7 Sep 2021 11:22:24 +0200, Peter Eisentraut
wrote in
On 30.08.21 04:13, Kyotaro Horiguchi wrote:
+ else if (IsA(obj, Integer))
+ _outInteger(str, (Integer *) obj);
+ else if (IsA(obj, Float))
+ _outFlo
čt 9. 9. 2021 v 8:23 odesílatel Dinesh Chemuduru
napsal:
>
>
> On Thu, 9 Sept 2021 at 11:07, Pavel Stehule
> wrote:
>
>> Hi
>>
>> I tested the last patch, and I think I found unwanted behavior.
>>
>> The value of PG_SQL_TEXT is not empty only when the error is related to
>> the parser stage. Whe
Hi
On Thursday, September 2, 2021 11:23 AM I wrote:
> I've made a new patch to extend pg_stat_subscription as suggested in [1] to
> have columns xact_commit, xact_error and independent xact_abort mentioned
> in [2].
> Also, during discussion, we touched a topic if we should include data sizes
> f
On Thu, Sep 9, 2021 at 11:43 AM Peter Smith wrote:
>
> PSA my new incremental patch (v28-0002) that introduces row filter
> validation for the publish mode "delete". The validation requires that
> any columns referred to in the filter expression must also be part of
> REPLICA IDENTITY or PK.
>
> [
Le mercredi 8 septembre 2021, 11:51:31 CEST Peter Eisentraut a écrit :
> On 01.09.21 10:00, Ronan Dunklau wrote:
> > In-core it would open up the possibility to split log messages into
> > different fields, for example the different statistics reported in the
> > logs by VACUUM / ANALYZE VERBOSE an
I changed the implementation about this problem:
a) if the cancel query interrupt is from db for some reason, such as recovery
conflict, then handle it immediately, and cancel request is treated as
terminate request;
b) if the cancel query interrupt is from client, then ignore as original way
It looks like this patch rotted a little and needs to be rebased. Please see
http://cfbot.cputube.org/
The new status of this patch is: Waiting on Author
It looks like this patch needs to be updated. According to
http://cfbot.cputube.org/ it applies but doesn't pass any tests. Changing the
status to save time for reviewers.
The new status of this patch is: Waiting on Author
> It was intentional, because all internal callers of LookupFuncName only
> want to see functions. See the last few messages in the referenced
> discussion thread:
>
> https://www.postgresql.org/message-id/flat/3742981.1621533210%40sss.pgh.pa.us
Thank you for the clarification.
--
Regards, Sven
On 07.09.21 20:31, Tom Lane wrote:
torikoshia writes:
While working on [1], we found that EXPLAIN(VERBOSE) to CTE with SEARCH
BREADTH FIRST ends up ERROR.
Yeah. It's failing here:
* We're deparsing a Plan tree so we don't have a CTE
* list. But t
> [schema-variables-20210909.patch]
Hi Pavel,
The patch applies and compiles fine but 'make check' for the
assert-enabled fails on 131 out of 210 tests.
(while compiling HEAD checks run without errors for both assert-disabled
and assert-enabled)
Erik Rijkers
te
Hi
čt 9. 9. 2021 v 12:21 odesílatel Erik Rijkers napsal:
> > [schema-variables-20210909.patch]
>
> Hi Pavel,
>
> The patch applies and compiles fine but 'make check' for the
> assert-enabled fails on 131 out of 210 tests.
>
This morning I tested it.
On Tue, Sep 7, 2021 at 2:02 PM Drouvot, Bertrand wrote:
>
> On 9/7/21 9:11 AM, Drouvot, Bertrand wrote:
> >
>
> Please find enclosed patch v2 (for the master branch) implementing the
> modified approach of option 2) proposed by Amit.
>
The patch looks good to me. I have made a minor modification
Le 09/09/2021 à 11:40, Pavel Stehule a écrit :
Hi
čt 9. 9. 2021 v 12:21 odesílatel Erik Rijkers <mailto:e...@xs4all.nl>> napsal:
> [schema-variables-20210909.patch]
Hi Pavel,
The patch applies and compiles fine but 'make check' for the
assert-enabled f
Hi,
The attached patch adds a small test for recovery_end_command execution.
Currently, patch tests execution of recovery_end_command by creating
dummy file, I am not wedded only to this approach, other suggestions
also welcome.
Also, we don't have a good test for archive_cleanup_command as well
Em qui., 9 de set. de 2021 às 03:45, Anton Voloshin <
a.volos...@postgrespro.ru> escreveu:
> Hello hackers,
>
> In pg_import_system_collations() there is this fragment of code:
>
> enc = pg_get_encoding_from_locale(localebuf, false);
> if (enc < 0)
> {
> /* error message printed by pg_get_
I was wondering what happens when the 32 TiB per table limit is
reached, so I faked 32767 1 GiB sparse files using dd and then tried
inserting more rows.
On a cassert-enabled build I got:
TRAP: FailedAssertion("tagPtr->blockNum != P_NEW", File:
"./build/../src/backend/storage/buffer/buf_table.c"
On 08.09.21 21:07, Andres Freund wrote:
There of course is historical raisins for things happening in initdb - the
setup logic didn't use to be C. But now that it is C, it seems a bit absurd to
read bootstrap data in initdb, write the data to a pipe, and then read it
again in the backend. It for
On 9/8/21 11:44 PM, Michael Paquier wrote:
> On Thu, Sep 09, 2021 at 02:35:52AM +, wangsh.f...@fujitsu.com wrote:
>> Do you mean changing the action of canonicalize_path(), like remove all the
>> (..) ?
>>
>> I'm willing to fix this problem.
> Looking at canonicalize_path(), we have already
On 27.08.21 12:37, Vik Fearing wrote:
It seems like this should error to me:
CREATE ACCESS METHOD heapdup TYPE TABLE HANDLER heap_tableam_handler;
CREATE TABLE likeam1() USING heap;
CREATE TABLE likeam2() USING heapdup;
CREATE TABLE likeamlike(
LIKE likeam1 INCLUDING ACCESS METHOD,
LIK
Dear Fujii-san,
Thank you for reviewing!
> postgres_fdw gets out of the loop after processing appname even
> when buf.data is '\0'. Is this expected behavior? Because of this,
> when postgres_fdw.application_name = '%b', unprocessed appname
> of the server object is used.
In this case, I expecte
On Thu, Sep 9, 2021 at 7:52 AM Christoph Berg
wrote:
> Shouldn't the cassert build raise the ERROR instead as well?
We should definitely get an ERROR in both cases, not an assertion
failure. Exactly which ERROR we get seems negotiable.
--
Robert Haas
EDB: http://www.enterprisedb.com
Christoph Berg writes:
> I was wondering what happens when the 32 TiB per table limit is
> reached, so I faked 32767 1 GiB sparse files using dd and then tried
> inserting more rows.
> On a cassert-enabled build I got:
> TRAP: FailedAssertion("tagPtr->blockNum != P_NEW", File:
> "./build/../src
Re: Tom Lane
> Can you provide a stack trace from that?
PG log:
TRAP: FailedAssertion("tagPtr->blockNum != P_NEW", File:
"./build/../src/backend/storage/buffer/buf_table.c", Line: 125)
postgres: 13/main: cbe postgres [local]
INSERT(ExceptionalCondition+0x7d)[0x558b6223d44d]
postgres: 13/main: c
On 9/8/21 3:14 PM, Tom Lane wrote:
> Vik Fearing writes:
>
>> Is there any hope of adding the optional underscores? I see a potential
>> problem there as SELECT 1_a; is currently parsed as SELECT 1 AS _a; when
>> it should be parsed as SELECT 1_ AS a; or perhaps even as an error since
>> 0x1_a w
Christoph Berg writes:
>> Can you provide a stack trace from that?
> #2 0x558b6223d46e in ExceptionalCondition
> (conditionName=conditionName@entry=0x558b623b2577 "tagPtr->blockNum != P_NEW",
> errorType=errorType@entry=0x558b6229b016 "FailedAssertion",
> fileName=fileName@entry=0x5
On Sun, Sep 5, 2021 at 10:58 PM Masahiko Sawada wrote:
>
> On Fri, Sep 3, 2021 at 3:46 PM Greg Nancarrow wrote:
> >
> > On Mon, Aug 30, 2021 at 5:07 PM Masahiko Sawada
> > wrote:
> > >
> > > I've attached rebased patches. 0004 patch is not the scope of this
> > > patch. It's borrowed from anoth
On Fri, Aug 27, 2021 at 4:10 PM Andres Freund wrote:
> On Fri, Aug 27, 2021, at 13:07, Robert Haas wrote:
> > On Fri, Aug 27, 2021 at 3:24 PM Andres Freund wrote:
> > > I wonder if we could improve the situation somewhat by using the
> > > non-blocking
> > > pqcomm functions in a few select plac
Anton Voloshin writes:
> In pg_import_system_collations() there is this fragment of code:
> enc = pg_get_encoding_from_locale(localebuf, false);
> if (enc < 0)
> {
> /* error message printed by pg_get_encoding_from_locale() */
> continue;
> }
> However, false passed to pg_get_encodin
On Wed, Sep 8, 2021 at 12:20 PM Ranier Vilela wrote:
> Olá Oswaldo,
> Sinto, mas essa lista não é o local apropriado para essas questões.
> Por favor encaminhar essas questões para:
> https://www.postgresql.org/list/pgsql-general/
The Portuguese list might be a better choice:
https://www.postgre
On 2021/09/08 22:41, Fujii Masao wrote:
So probably we reached the consensus that something like the attached patch
(XLogArchiveCheckDone_walfile_xlog_switch.patch) is enough for the corner
case where walreceiver fails to create .ready file of WAL file including
XLOG_SWITCH?
I attached the pa
On 09/09/2021 21:51, Tom Lane wrote:
What you propose to do here would promote this case from
ought-to-be-DEBUG1 to WARNING, which seems to me to be way too much in the
user's face. Or, if there actually is a case for complaining, then all
those messages ought to be WARNING not DEBUG1. ...
Assu
On Thu, Sep 09, 2021 at 09:50:46AM +, Aleksander Alekseev wrote:
> It looks like this patch needs to be updated. According to
> http://cfbot.cputube.org/ it applies but doesn't pass any tests. Changing the
> status to save time for reviewers.
>
> The new status of this patch is: Waiting on A
On Thu, Sep 2, 2021 at 5:42 AM Tom Lane wrote:
> The real reason that this hasn't gotten committed is that I remain
> pretty uncomfortable about whether it's an acceptable solution to
> the problem. Suddenly asking people to plaster COLLATE clauses
> on all their textual remote columns seems like
On 9/8/21 5:48 PM, Andres Freund wrote:
> Hi,
>
> On September 8, 2021 1:24:00 PM PDT, Andrew Dunstan
> wrote:
>> On 9/8/21 3:07 PM, Andres Freund wrote:
>>> There of course is historical raisins for things happening in initdb - the
>>> setup logic didn't use to be C. But now that it is C, it s
Etsuro Fujita writes:
> On Thu, Sep 2, 2021 at 5:42 AM Tom Lane wrote:
>> The real reason that this hasn't gotten committed is that I remain
>> pretty uncomfortable about whether it's an acceptable solution to
>> the problem. Suddenly asking people to plaster COLLATE clauses
>> on all their text
čt 9. 9. 2021 v 13:17 odesílatel Gilles Darold napsal:
> Le 09/09/2021 à 11:40, Pavel Stehule a écrit :
>
> Hi
>
> čt 9. 9. 2021 v 12:21 odesílatel Erik Rijkers napsal:
>
>> > [schema-variables-20210909.patch]
>>
>> Hi Pavel,
>>
>> The patch
On 2021/09/08 23:40, Fujii Masao wrote:
Agreed. Since it's hard to imagine the issue happens in practice,
we don't need to bother back-patch to the stable branches.
So I'm thinking to commit the patch to 15dev and 14.
Pushed. Thanks!
Regards,
--
Fujii Masao
Advanced Computing Technology Ce
We don't actually prevent you from scrolling a NO SCROLL cursor:
regression=# begin;
BEGIN
regression=*# declare c no scroll cursor for select * from int8_tbl;
DECLARE CURSOR
regression=*# fetch all from c;
q1|q2
--+---
> On Sep 8, 2021, at 6:44 AM, Amul Sul wrote:
>
> Here is the rebased version.
v33-0004
This patch moves the include of "catalog/pg_control.h" from transam/xlog.c into
access/xlog.h, making pg_control.h indirectly included from a much larger set
of files. Maybe that's ok. I don't know.
On 9/9/21 7:10 PM, Tom Lane wrote:
> We don't actually prevent you from scrolling a NO SCROLL cursor:
>
> There are probably specific cases where you do get an error,
> but we don't have a blanket you-can't-do-that check. Should we?
I would say yes. NO SCROLL means no scrolling; or at least sh
Vik Fearing writes:
> On 9/9/21 7:10 PM, Tom Lane wrote:
>> There are probably specific cases where you do get an error,
>> but we don't have a blanket you-can't-do-that check. Should we?
> I would say yes. NO SCROLL means no scrolling; or at least should.
> On the other hand, if there is no op
On Thu, Sep 9, 2021 at 1:42 PM Mark Dilger wrote:
> v33-0006:
>
> The new code comments in brin.c and elsewhere should use the verb "require"
> rather than "have", otherwise "building indexes" reads as a noun phrase
> rather than as a gerund: /* Building indexes will have an XID */
Honestly tha
On Wed, May 12, 2021 at 10:19:17PM +0900, Amit Langote wrote:
> (Sorry about being very late to this thread.)
>
> > Would it be unreasonable of us to ask for a worked-out example making
> > use of the proposed hook? That'd go a long way towards resolving the
> > question of whether you can do any
Anton Voloshin writes:
> On 09/09/2021 21:51, Tom Lane wrote:
>> Assuming we don't want to change pg_get_encoding_from_locale()'s API,
>> the simplest fix is to duplicate its error message, so more or less
>>
>> if (enc < 0)
>> {
>> -/* error message printed by pg_get_encoding_from_locale
> On Sep 9, 2021, at 11:21 AM, Robert Haas wrote:
>
> They have to check whether WAL has become prohibited
> and error out if so, and they need to do so before entering the
> critical section - because if the problem were detected for the first
> time inside the critical section it would escal
I wrote:
> [ pokes at it some more ... ] Hm, we let you do this:
> ...
> which definitely flies in the face of the fact that we disallow
> combining SCROLL and FOR UPDATE:
> regression=*# declare c scroll cursor for select * from int8_tbl for update;
> ERROR: DECLARE SCROLL CURSOR ... FOR UPDATE
On 09/09/2021 17:25, Tom Lane wrote:
Having done that, the check in md.c could be reduced to an Assert,
although there's something to be said for leaving it as-is as an
extra layer of defense.
Some operations call smgrextend() directly, like B-tree index creation.
We don't want those operation
On 9/8/21, 10:49 AM, "Dipesh Pandit" wrote:
> Updated log level to DEBUG3 and rebased the patch. PFA patch.
Thanks for the new patch.
+ * by checking the availability of next WAL file. "xlogState" specifies the
+ * segment number and timeline ID corresponding to the next WAL file.
"xlogState" p
On 9/7/21, 11:38 PM, "Julien Rouhaud" wrote:
> On Wed, Sep 8, 2021 at 6:36 AM Bossart, Nathan wrote:
>>
>> I'd like to gauge interest in parallelizing the archiver process.
>> [...]
>> Based on previous threads I've seen, I believe many in the community
>> would like to replace archive_command en
On 9/8/21, 6:49 AM, "Bharath Rupireddy"
wrote:
> How about we create a new extension, called pg_walinspect (synonymous
> to pageinspect extension) with a bunch of SQL-callable functions that
> get the raw WAL records or stats out of a running postgres database
> instance in a more structured way
I wrote:
> The reason for this behavior is that the only-scan-forward check
> is in the relatively low-level function PortalRunSelect, which
> is passed a "forward" flag and a count. The place that interprets
> FETCH_ABSOLUTE and friends is DoPortalRunFetch, and what it's doing
> in this particula
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 piece is looking solid.
> + if (port->isProxy)
> + {
On 2021/09/09 21:36, kuroda.hay...@fujitsu.com wrote:
In this case, I expected to use fallback_application_name instead of appname,
but I missed the case where appname was set as a server option.
Maybe we should do continue when buf.data is \0.
Yes.
+ /*
+
On Thu, Sep 09, 2021 at 11:17:01AM +0900, Michael Paquier wrote:
> I was thinking to track stderr as a case where no bits are set in the
> flags for the area of the destinations, but that's a bit crazy if we
> have a lot of margin in what can be stored. I have looked at that and
> finished with th
On 2021/09/07 2:02, Fujii Masao wrote:
Even if we do this while NOT in standby mode, ISTM that this function doesn't
return with a valid errmsg_buf because it's reset. So probably the comment
should be updated as follows?
-
We don't do this while not in standby mode bec
On Thu, Sep 09, 2021 at 10:49:46PM +, Bossart, Nathan wrote:
> +1
A backend approach has the advantage that you can use the proper locks
to make sure that a segment is not recycled or removed by a concurrent
checkpoint, so that would be reliable.
--
Michael
signature.asc
Description: PGP sig
On Thu, Sep 09, 2021 at 09:53:22PM +, Bossart, Nathan wrote:
> For 0002, I have two small concerns. My first concern is that it
> might be confusing to customers when the runtime GUCs cannot be
> returned for a running server. We have the note in the docs, but if
> you're encountering it on t
On 9/9/21, 7:03 PM, "Michael Paquier" wrote:
> As far as the behavior is documented, I'd be fine with the approach to
> keep the code in its simplest shape. I agree that the message is
> confusing, still it is not wrong either as we try to query a run-time
> parameter, but we need the lock.
That
From Wed, Sept 8, 2021 7:44 PM vignesh C wrote:
> Modified
> Thanks for the comments, the attached v26 patch has the changes for the same.
Hi,
Thanks for updating the patch, I have a suggestion for the gram.y.
Currently, we have the following two members in PublicationObjSpec to
distinguish
be
From Friday, September 10, 2021 10:33 AM Hou Zhijie
wrote:
> From Wed, Sept 8, 2021 7:44 PM vignesh C wrote:
> > Modified
> > Thanks for the comments, the attached v26 patch has the changes for the
> same.
>
> Hi,
>
> Thanks for updating the patch, I have a suggestion for the gram.y.
>
> Curre
Dear Fujii-san,
Thank you for quick reviewing!
> We can simplify the code as follows.
>
> if (values[i] != '\0')
> break;
Fixed. And type mismatching was also fixed.
> IMO it's better to use process_padding() to process log_line_prefix and
> postgres_fdw.application in the same w
>From Friday, September 10, 2021 11:24 AM kuroda.hay...@fujitsu.com
>
> > We can simplify the code as follows.
> >
> > if (values[i] != '\0')
> > break;
>
> Fixed. And type mismatching was also fixed.
>
> > IMO it's better to use process_padding() to process log_line_prefix
> > and
On Wed, Sep 01, 2021 at 04:39:43PM -0400, Sehrope Sarkuni wrote:
> This version splits out the existing csvlog code into its own file and
> centralizes the common helpers into a new elog-internal.h so that they're
> only included by the actual write_xyz sources.
>
> That makes the elog.c changes i
Dear Hou,
> I found one minor thing in the patch.
Thanks!
> Is it better to use Abs(padding) here ?
> Although some existing codes are using " padding > 0 ? padding : -padding ".
+1, fixed.
And I found that some comments were not added above padding calculation,
so added.
Best Regards,
Hayato
On Tue, Sep 7, 2021 at 7:00 PM Alexander Lakhin wrote:
> 07.09.2021 09:05, Michael Paquier wrote:
> > On Tue, Sep 07, 2021 at 09:00:01AM +0300, Alexander Lakhin wrote:
> >> The new approach looks very promising. Knowing that the file is really
> >> in the DELETE_PENDING state simplifies a lot.
> >
On Fri, Sep 10, 2021 at 6:30 AM Bossart, Nathan wrote:
>
> Thanks for chiming in. I'm planning to work on a patch next week.
Great news!
About the technical concerns:
> I'm currently thinking of
> something a bit like autovacuum_max_workers, but the archive workers
> would be created once and
On Fri, Sep 10, 2021 at 8:54 AM houzj.f...@fujitsu.com
wrote:
>
> From Friday, September 10, 2021 10:33 AM Hou Zhijie
> wrote:
>
> Besides, If we don't want to use a new flag to distinguish tablename and
> schemaname,
> We can only check the NodeTag to distinguish the difference.
>
> Attach two
On Mon, Jul 19, 2021 at 01:24:03PM +0530, Dilip Kumar wrote:
> On Sun, Jul 18, 2021 at 9:15 PM Dilip Kumar wrote:
> >
> > On Wed, Jul 14, 2021 at 5:35 PM vignesh C wrote:
> > >
> > > On Thu, May 6, 2021 at 7:24 PM Dilip Kumar wrote
> > >
> > > The patch does not apply on Head anymore, could you
On Fri, 10 Sep 2021 at 10:40 AM, Jaime Casanova <
jcasa...@systemguards.com.ec> wrote:
> On Mon, Jul 19, 2021 at 01:24:03PM +0530, Dilip Kumar wrote:
> > On Sun, Jul 18, 2021 at 9:15 PM Dilip Kumar
> wrote:
> > >
> > > On Wed, Jul 14, 2021 at 5:35 PM vignesh C wrote:
> > > >
> > > > On Thu, May
> 8 сент. 2021 г., в 03:36, Bossart, Nathan написал(а):
>
> Anyway, I'm curious what folks think about this. I think it'd help
> simplify server administration for many users.
BTW this thread is also related [0].
My 2 cents.
It's OK if external tool is responsible for concurrency. Do we wan
From Friday, September 10, 2021 1:10 PM Amit Kapila
wrote:
> On Fri, Sep 10, 2021 at 8:54 AM Hou zhijie wrote:
> >
> > From Friday, September 10, 2021 10:33 AM Hou
> Zhijie wrote:
> >
> > Besides, If we don't want to use a new flag to distinguish tablename and
> schemaname,
> > We can only check
On Fri, Sep 10, 2021 at 1:28 PM Andrey Borodin wrote:
>
> It's OK if external tool is responsible for concurrency. Do we want this
> complexity in core? Many users do not enable archiving at all.
> Maybe just add parallelism API for external tool?
> It's much easier to control concurrency in exte
> 10 сент. 2021 г., в 10:52, Julien Rouhaud написал(а):
>
> On Fri, Sep 10, 2021 at 1:28 PM Andrey Borodin wrote:
>>
>> It's OK if external tool is responsible for concurrency. Do we want this
>> complexity in core? Many users do not enable archiving at all.
>> Maybe just add parallelism AP
On Fri, Sep 10, 2021 at 2:03 PM Andrey Borodin wrote:
>
> > 10 сент. 2021 г., в 10:52, Julien Rouhaud написал(а):
> >
> > Yes, but it also means that it's up to every single archiving tool to
> > implement a somewhat hackish parallel version of an archive_command,
> > hoping that core won't break
> 10 сент. 2021 г., в 11:11, Julien Rouhaud написал(а):
>
> On Fri, Sep 10, 2021 at 2:03 PM Andrey Borodin wrote:
>>
>>> 10 сент. 2021 г., в 10:52, Julien Rouhaud написал(а):
>>>
>>> Yes, but it also means that it's up to every single archiving tool to
>>> implement a somewhat hackish para
On 10/09/2021 01:37, Tom Lane wrote:
Another approach we could take is to deem the comment incorrect and
just remove it, codifying the current behavior of silently ignoring
unrecognized encodings. The reason that seems like it might be
appropriate is that the logic immediately below this bit sil
On Fri, Sep 10, 2021 at 01:07:00PM +0900, Michael Paquier wrote:
> Forking a bit this thread while looking at 0002 that adds new tests
> for csvlog. While I agree that it would be useful to have more
> coverage with the syslogger message chunk protocol in this area, I
> think that having a separat
79 matches
Mail list logo
