> 19 авг. 2021 г., в 23:19, Mark Dilger
> написал(а):
>
>
>
>> On Aug 19, 2021, at 10:57 AM, Peter Geoghegan wrote:
>>
>> High
>> verbosity makes a lot of sense here.
>
> Works for me. We could create another function, "verify_heapam_full"
> perhaps, that returns additional columns
On Fri, Aug 20, 2021 at 11:33:33AM +0800, Paul Guo wrote:
> On Tue, Aug 17, 2021 at 3:47 PM Michael Paquier wrote:
> > + fsync_fname("global/pg_control", false);
> > + fsync_fname("backup_label", false);
> > + if (access("recovery.conf", F_OK) == 0)
> > + fsync_fname("recovery.conf",
On Thu, Aug 19, 2021 at 10:04 PM Andrey Borodin
wrote:
> I just want to note, that on your screenshot unpatched version runs 400K
> tps, while patched runs 280K tps. I see the dates are different and this
> effect is not observed in [0]. Probably, you run tests on different
> machines.
> 20 авг. 2021 г., в 09:45, Nikolay Samokhvalov написал(а):
>
> The patches changing the SLRU algorithm and adding GUCs to control the buffer
> sizes look really promising. Optimization in this area would really help
> those who use SAVEPOINTs. I suspect, we have a lot of such users – ORMs
Thanks for reviewing, please see the replies below.
On Tue, Aug 17, 2021 at 3:47 PM Michael Paquier wrote:
>
> On Thu, Aug 05, 2021 at 06:18:03PM +0800, Paul Guo wrote:
> > I modified the copy_file_range() patch using the below logic:
> >
> > If the first call of copy_file_range() fails with
Corey Huinker writes:
> In src/backend/access/transam/xact.c, I'm noticing a code style
> inconsistency.
> [ to wit, local variable alias for CurrentTransactionState or not ]
> Is this something worth standardizing, and if so, which style do we like
> better?
I can't get excited about changing
I'm using an ongoing patch review to educate myself on parts of the
codebase.
In src/backend/access/transam/xact.c, I'm noticing a code style
inconsistency.
In some cases, a function will declare a variable of some struct pointer
type, assign it to a globally declared struct, and then use it
At Thu, 19 Aug 2021 20:29:42 +0900, Fujii Masao
wrote in
> On 2021/08/19 17:03, Kyotaro Horiguchi wrote:
> > Hello.
> > While I was examining message translation for PG14, I found some
> > messages that would need to be fixed.
> > 0001 is a fix for perhaps-leftovers of the recent message
On 2021/08/20 11:07, Mahendra Singh Thalor wrote:
1)
Resets statistics for a single table or index in the current database
- to zero.
+ to zero. The input can be a shared table also
I think, above comment should be modified. Maybe, we can modify it as "If input
is a
On Fri, 20 Aug 2021 at 07:37, Mahendra Singh Thalor wrote:
>
> On Fri, 20 Aug 2021 at 06:32, Sadhuprasad Patro wrote:
> >
> > > If we do support resetting the stats for shared tables in
> > > 'pg_stat_reset', which is for DB level,
> > > then the stats of shared tables will be reseted in other
On Fri, 20 Aug 2021 at 06:32, Sadhuprasad Patro wrote:
>
> > If we do support resetting the stats for shared tables in
> > 'pg_stat_reset', which is for DB level,
> > then the stats of shared tables will be reseted in other instances as
> > well, which seems to be not correct.
> > So we need to
> If we do support resetting the stats for shared tables in
> 'pg_stat_reset', which is for DB level,
> then the stats of shared tables will be reseted in other instances as
> well, which seems to be not correct.
> So we need to provide some way to reset the stats for shared tables to
> customers.
On Thu, Jul 08, 2021 at 09:58:35AM -0400, Bruce Momjian wrote:
> On Thu, Jul 8, 2021 at 02:33:33PM +0200, Filip Janus wrote:
>> I am a new maintainer of PostgreSQL in Fedora and RHEL. Currently, I am
>> solving
>> usage SHA-1 for key-derivation in pgcrypto (the s2k-digest-algo). In the
>>
On Thu, 2021-08-19 at 13:49 -0400, John Naylor wrote:
> I had a couple further thoughts:
>
> 1. The coding historically used normal comparison and branching for
> everything, but recently it only does that to detect control
> characters, and then goes through a binary search (and with this
>
On Thu, Aug 19, 2021 at 10:34:04AM -0400, Tom Lane wrote:
> Ranier Vilela writes:
>> C needs readability, not fewer lines.
>> Aside from horrible code, it doesn't improve 0.1% on anything.
>> I think it's a bad idea and I'm strongly against it.
>
> Same here. We have thirty-ish years worth of
On Thu, Aug 19, 2021 at 05:20:52AM -0700, Andres Freund wrote:
> Done.
Thanks. There does not seem to be anything left here, so I have
marked this open item as fixed.
--
Michael
signature.asc
Description: PGP signature
On Thu, Aug 5, 2021 at 4:12 PM Andres Freund wrote:
> I have wondered before whether we should have syscache definitions
generate
> code specific to each syscache definition. I do think that'd give a good
bit
> of performance boost. But I don't see a trivial way to get there without
> notational
On Thu, Aug 19, 2021 at 3:44 PM David Christensen <
david.christen...@crunchydata.com> wrote:
> Functionality-wise, any thoughts on the overall approach or the specific
> patch?
>
If this information was exposed only by an addition to pg_settings, and
thus not changeable via a GUC or affecting
> Hi,
> For parse_special_int():
>
> + * true. If it's not found, return false and retval is set to 0.
> ...
> + /* don't touch the return value in other case */
> + return false;
>
> It seems the two comments are not consistent with each other (retval is not
> set in case no entry is found).
On Thu, Aug 19, 2021 at 3:17 PM David Christensen <
david.christen...@crunchydata.com> wrote:
> -hackers,
>
> Enclosed, find a POC patch that implements "special values" for int GUCs.
> We have quite a few GUCs
> with values that have special meaning atop other settings. I have
> attempted to
While poking at a report of slow regexp matching [1], I happened
to notice that citerdissect and creviterdissect are being remarkably
stupid about how to backtrack after a match failure. Specifically,
having used the DFA logic to identify K possible submatches, they
then start the slow recursive
On 8/20/21 12:09 AM, David Christensen wrote:
> -hackers,
>
> Enclosed, find a POC patch that implements "special values" for int GUCs. We
> have quite a few GUCs
> with values that have special meaning atop other settings. I have attempted
> to identify these and
> make it so you can specify
-hackers,
Enclosed, find a POC patch that implements "special values" for int GUCs. We
have quite a few GUCs
with values that have special meaning atop other settings. I have attempted to
identify these and
make it so you can specify a symbol name for these values instead of just
relying on
On 8/19/21, 5:42 AM, "Dipesh Pandit" wrote:
>> Should we have XLogArchiveNotify(), writeTimeLineHistory(), and
>> writeTimeLineHistoryFile() enable the directory scan instead? Else,
>> we have to exhaustively cover all such code paths, which may be
>> difficult to maintain. Another reason I am
Jesper, please don't confuse my ramblings with Simon's initial proposal.
As I understand, the original proposal was just about adding a new
wire protocol message type, which then could be used for emitting
custom messages by middleware support extension - likely loaded as a
preloaded shared
On Thu, Aug 19, 2021 at 11:40:44AM -0400, Chapman Flack wrote:
> I'm in sympathy with all of those points. I've never believed that the
> arbitrary separation of declaration from use that was forced by C < 99
> made anything more readable. If the project were started now from scratch,
> I would be
On Thu, 19 Aug 2021 at 19:04, Jesper Pedersen
wrote:
> Should the middleware guess the client driver based on the startup
> message ? Or are you thinking about having a class identifier group for
> each client driver and then a massive "switch/case" inside each middleware ?
The question is how
On Thu, Aug 19, 2021 at 05:20:52AM -0700, Andres Freund wrote:
> On 2021-08-19 01:10:55 -0700, Andres Freund wrote:
> > On 2021-08-19 17:05:01 +0900, Michael Paquier wrote:
> > > Okay. Would you like to write a patch then?
> >
> > I'll push something in a bit...
>
> Done.
Thanks. I was kind
On Wed, Aug 18, 2021 at 11:08:57PM -0400, Tom Lane wrote:
> Peter Smith writes:
> > On Thu, Aug 19, 2021 at 4:29 AM Justin Pryzby wrote:
> >> - state->oneCol = (origTupdesc->natts == 1) ? true : false;
> >> + state->oneCol = origTupdesc->natts == 1;
>
> FWIW, I am definitely not a
> On Aug 19, 2021, at 10:57 AM, Peter Geoghegan wrote:
>
> High
> verbosity makes a lot of sense here.
Works for me. We could create another function, "verify_heapam_full" perhaps,
that returns additional columns matching those from pageinspect's
heap_page_items():
OUT lp smallint,
On 16.08.21 22:06, John Naylor wrote:
Peter, does the combining char table exclude values > 0x for size
reasons, correctness, or some other consideration?
I don't remember a reason, other than perhaps making the generated table
match the previous manual table in scope. IIRC, the
Hi,
On 8/19/21 1:13 PM, Simon Riggs wrote:
We need to be able to send the middleware a message. Replies can be
sent as NoticeResponse, if needed, which already exists.
Yeah, but you need the client driver - of all languages - to understand
that notice. And, if different middleware uses
On Thu, Aug 19, 2021 at 10:49 AM Mark Dilger
wrote:
> There was some disagreement during the development of verify_heapam on this
> point. We went with the idea that the user could find and inspect the
> corrupt data with another tool if they had the (blockno, offnum, attnum)
> information.
I wrote:
> On Sun, Aug 15, 2021 at 10:45 PM Michael Paquier
wrote:
> >
> > On Thu, Aug 12, 2021 at 05:13:31PM -0400, John Naylor wrote:
> > > I'm a bit concerned about the build dependencies not working right,
but
> > > it's not clear it's even due to the patch. I'll spend some time
> > >
> On Aug 19, 2021, at 10:17 AM, Andrey Borodin wrote:
>
> It would be great to see relation, block, offset, xmin\xmax and, probably,
> flags whenever ERRCODE_DATA_CORRUPTED\ERRCODE_INDEX_CORRUPTED is used. Iif
> it's possible to extract this information, of cause. This is needed
>
Peter Geoghegan writes:
> On Thu, Aug 19, 2021 at 9:38 AM Alvaro Herrera
> wrote:
>> A customer recently hit this error message:
>>
>> ERROR: t_xmin is uncommitted in tuple to be updated
>>
>> This was not very informative, so without any clues, we had to let it
>> go. But it did occur to me
> 19 авг. 2021 г., в 21:37, Alvaro Herrera написал(а):
>
> A customer recently hit this error message:
>
> ERROR: t_xmin is uncommitted in tuple to be updated
Sorry for one more message, it occurred to me only after sending previous one
that I know this exact message.
We encountered this
> 19 авг. 2021 г., в 21:44, Peter Geoghegan написал(а):
>
> I think that this is a very good idea. Ideally this stuff would be
> more standardized.
+1
It would be great to see relation, block, offset, xmin\xmax and, probably,
flags whenever ERRCODE_DATA_CORRUPTED\ERRCODE_INDEX_CORRUPTED is
On Thu, 19 Aug 2021 at 17:42, Jesper Pedersen
wrote:
> I would say that this is a PostgreSQL protocol v4 thing, as there is a
> bit more to it.
>
>
> There is a need to trigger middleware functionality, but you need to
> query the middleware stack first on what it supports - failover, load
>
On 2021/08/11 13:56, Fujii Masao wrote:
Yes, but I was thinking that's a bug that we should fix.
IOW, I was thinking that, in v13, both connection and disconnection delays
should be measured whether -C is specified or not, *per spec*.
But, in v13, the disconnection delays are not measured in
On Wed, Aug 11, 2021 at 10:30 AM Mahendra Singh Thalor
wrote:
>
> On Wed, 11 Aug 2021 at 09:17, Dilip Kumar wrote:
> >
> > On Tue, Aug 10, 2021 at 10:49 PM Mahendra Singh Thalor
> > wrote:
> >
> > > I checked this and found that we already have one process "stats
> > > collector" and in v02
On Thu, Aug 19, 2021 at 9:38 AM Alvaro Herrera wrote:
> A customer recently hit this error message:
>
> ERROR: t_xmin is uncommitted in tuple to be updated
>
> This was not very informative, so without any clues, we had to let it
> go. But it did occur to me that we can improve this message so
Hi Simon,
On 8/19/21 4:33 AM, Simon Riggs wrote:
The current FE/BE protocol assumes that the client is talking to the
server directly. If middleware wants to do something like load
balancing, the only current option is to inspect the incoming commands
and take action from that. That approach
A customer recently hit this error message:
ERROR: t_xmin is uncommitted in tuple to be updated
This was not very informative, so without any clues, we had to let it
go. But it did occur to me that we can improve this message so that we
know details such as the TID and the relation that caused
Chapman Flack writes:
> I'm in sympathy with all of those points. I've never believed that the
> arbitrary separation of declaration from use that was forced by C < 99
> made anything more readable. If the project were started now from scratch,
> I would be all in favor of declaring at first use.
On 2021/08/11 21:14, torikoshia wrote:
As far as I looked into, pg_log_current_plan() can call InstrEndLoop() through
ExplainNode().
I added a flag to ExplainState to avoid calling InstrEndLoop() when
ExplainNode() is called from pg_log_current_plan().
Thanks for updating the patch!
I
On Thu, 19 Aug 2021 at 10:58, Hannu Krosing wrote:
>
> Actually the way I have been thinking about this would be a message
>
> "Hey replica x.x.x.x, please take over the write head role"
>
> Which would
>
> 1. cause the replica x.x.x.x to self-promote at this point-in-WAL
> 1A - optionally the
On Thu, 19 Aug 2021 at 10:33, Hannu Krosing wrote:
>
> Need for this does come up quite often so I very much support this.
>
> In addition to keeping a registry there likely need to be some other
> "generally agreed" rules as well, like
> * it being safe to ignore any and all of the middleware
On 08/19/21 09:38, Ranier Vilela wrote:
>> 2. Declarations are closer to the actual usage. This is advised by the
>> "Code Complete" book [2] and has the following advantages:
>>a. This limits variable scope to what is necessary. Which in turn makes
>> the mental model you have to keep of a
On 2021-Aug-19, Magnus Hagander wrote:
> Another thing I've noticed in more and more other products is to be
> able to log as json, which is then later thrown into a central logging
> system somewhere. Basically like csv, but with the schema defined in
> each row. Yes, a lot more overhead, but
Ranier Vilela writes:
> Em qui., 19 de ago. de 2021 às 08:50, Jelte Fennema <
> jelte.fenn...@microsoft.com> escreveu:
>> ## Why would we want this?
>> 1. It removes 23328 lines of code that don't have any impact on how the
>> code behaves [1]. This is roughly 2.7% of all the lines of code in the
On Thu, Aug 19, 2021 at 3:04 PM Alvaro Herrera wrote:
>
> On 2021-Aug-13, Ronan Dunklau wrote:
>
> > ereport(NOTICE,
> > (errmsg("My log message")),
> > (errtag("EMITTER", "MYEXTENSION")),
> > (errtag("MSG-ID", "%d", error_message_id))
> > );
>
> Interesting idea. I agree this would be
I spent some time looking at this patch.
Generally it looks like a good idea. These stable functions will be
evaluated at the execution time and replaced with constants. I am not
sure whether the nodes saved in the param_list may not get the same
treatment. Have you verified that?
Also the new
Em qui., 19 de ago. de 2021 às 09:21, Masahiko Sawada
escreveu:
> Hi all ,
>
> It's reported on pgsql-bugs[1] that I/O timings in EXPLAIN don't show
> the one for temp files. I think it's not a bug but could be an item
> for PG15. As mentioned on that thread, this would be useful for users
> in
Em qui., 19 de ago. de 2021 às 08:50, Jelte Fennema <
jelte.fenn...@microsoft.com> escreveu:
> ## What is this?
>
> It's a draft patch that replaces code like this:
> ```c
> pg_file_unlink(PG_FUNCTION_ARGS)
> {
> char *filename;
> requireSuperuser();
> filename =
On Thu, Aug 19, 2021 at 9:14 PM Amit Kapila wrote:
>
> On Thu, Aug 19, 2021 at 12:47 PM Masahiko Sawada
> wrote:
> >
> > On Tue, Aug 17, 2021 at 12:00 PM Greg Nancarrow wrote:
> > >
> >
> > > Another comment on the 0001 patch: as there is now a mix of setting
> > > "apply_error_callback_arg"
On Thu, Aug 19, 2021 at 8:20 PM Andres Freund wrote:
>
> On 2021-08-19 01:10:55 -0700, Andres Freund wrote:
> > On 2021-08-19 17:05:01 +0900, Michael Paquier wrote:
> > > Okay. Would you like to write a patch then?
> >
> > I'll push something in a bit...
>
> Done.
Thanks!
On 2021-Aug-13, Ronan Dunklau wrote:
> ereport(NOTICE,
> (errmsg("My log message")),
> (errtag("EMITTER", "MYEXTENSION")),
> (errtag("MSG-ID", "%d", error_message_id))
> );
Interesting idea. I agree this would be useful.
> Please find attached a very small POC patch to better demonstrate
Hi,
On 2021-08-19 14:47:42 +0200, Matthias van de Meent wrote:
> I tried to implement this 'compact attribute access descriptor' a few
> months ago in my effort to improve btree index performance.
cool
> The patch allocates an array of 'TupleAttrAlignData'-structs at the
> end of the
On Thu, 19 Aug 2021 at 13:44, Andres Freund wrote:
>
> > Another fun thing --- and, I fear, another good argument against just
> > raising NAMEDATALEN --- is what about TupleDescs, which last I checked
> > used an array of fixed-width pg_attribute images. But maybe we could
> > replace that with
Hi,
Thanks for the feedback.
> Should we have XLogArchiveNotify(), writeTimeLineHistory(), and
> writeTimeLineHistoryFile() enable the directory scan instead? Else,
> we have to exhaustively cover all such code paths, which may be
> difficult to maintain. Another reason I am bringing this up
Hi all ,
It's reported on pgsql-bugs[1] that I/O timings in EXPLAIN don't show
the one for temp files. I think it's not a bug but could be an item
for PG15. As mentioned on that thread, this would be useful for users
in a case where temp buffers I/O used most of the time. So I've
written the
On 2021-08-19 01:10:55 -0700, Andres Freund wrote:
> On 2021-08-19 17:05:01 +0900, Michael Paquier wrote:
> > Okay. Would you like to write a patch then?
>
> I'll push something in a bit...
Done.
On Thu, Aug 19, 2021 at 12:47 PM Masahiko Sawada wrote:
>
> On Tue, Aug 17, 2021 at 12:00 PM Greg Nancarrow wrote:
> >
>
> > Another comment on the 0001 patch: as there is now a mix of setting
> > "apply_error_callback_arg" members directly and also through inline
> > functions, it might look
## What is this?
It's a draft patch that replaces code like this:
```c
pg_file_unlink(PG_FUNCTION_ARGS)
{
char *filename;
requireSuperuser();
filename = convert_and_check_filename(PG_GETARG_TEXT_PP(0));
```
With this shorter version:
```c
pg_file_unlink(PG_FUNCTION_ARGS)
{
requireSuperuser();
Hi,
On 2021-08-18 10:21:03 -0400, Tom Lane wrote:
> Anyway, this whole argument could be rendered moot if we could convert
> name to a variable-length type. That would satisfy *both* sides of
> the argument, since those who need long names could have them, while
> those who don't would see net
On 2021/08/19 17:03, Kyotaro Horiguchi wrote:
Hello.
While I was examining message translation for PG14, I found some
messages that would need to be fixed.
0001 is a fix for perhaps-leftovers of the recent message cleanups
related to "positive integer"(fd90f6ba7a).
There are still other
Hi,
Sorry for being late. I had a vaccination.
I'm not sure about the rule that stderr should be removed
even if the pre-compiling state, but anyway I agree that
the warned case is not expected.
The wrong message is perfectly fault...
I confirmed your commit and I think it's OK. Thanks!
Best
On 2021/08/05 12:18, kuroda.hay...@fujitsu.com wrote:
Dear Hackers, Tom,
(I changed subject because this is no longer postgres_fdw's patch)
What would be better to think about is how to let users specify this
kind of behavior for themselves. I think it's possible to set
application_name
Em qui., 19 de ago. de 2021 às 07:50, Zhihong Yu
escreveu:
>
>
> On Thu, Aug 19, 2021 at 2:52 AM Alexander Pyhalov <
> a.pyha...@postgrespro.ru> wrote:
>
>> Hi.
>>
>> The attached patches allow pushing down
>> current_timestamp/localtimestamp/current_time/localtime and now() to
>> remote
On Thu, Aug 19, 2021 at 2:52 AM Alexander Pyhalov
wrote:
> Hi.
>
> The attached patches allow pushing down
> current_timestamp/localtimestamp/current_time/localtime and now() to
> remote PostgreSQL server as locally computed parameters.
> The idea is based on oracle_fdw behavior.
>
> Examples.
>
Zhihong Yu писал 2021-08-19 13:22:
Hi,
For 0002 patch:
+ /* now() is stable, but we can ship it as it's replaced by
parameter */
+ return !(func_volatile(func_id) == PROVOLATILE_IMMUTABLE ||
func_id == F_NOW);
Did you mean to say 'now() is unstable' ?
No, it's stable, not immutable, so
On Thu, Aug 19, 2021 at 2:52 AM Alexander Pyhalov
wrote:
> Hi.
>
> The attached patches allow pushing down
> current_timestamp/localtimestamp/current_time/localtime and now() to
> remote PostgreSQL server as locally computed parameters.
> The idea is based on oracle_fdw behavior.
>
> Examples.
>
Actually the way I have been thinking about this would be a message
"Hey replica x.x.x.x, please take over the write head role"
Which would
1. cause the replica x.x.x.x to self-promote at this point-in-WAL
1A - optionally the old write head becomes a replica (it should
mention it in message
Hi.
The attached patches allow pushing down
current_timestamp/localtimestamp/current_time/localtime and now() to
remote PostgreSQL server as locally computed parameters.
The idea is based on oracle_fdw behavior.
Examples.
\d test
Foreign table "public.test"
One more set of "standard middleware messages" clients/middleware
could turn on could be reporting LSNs
* various local LSNs for progress of WAL persisting
* reporting replication state of some or all replicas
-
Hannu Krosing
Google Cloud - We have a long list of planned contributions and
Need for this does come up quite often so I very much support this.
In addition to keeping a registry there likely need to be some other
"generally agreed" rules as well, like
* it being safe to ignore any and all of the middleware messages (at
least with no degradation from the state of not
On Thu, Aug 19, 2021 9:48 AM Masahiko Sawada wrote:
>
> I've attached the updated version patches that incorporated all comments I
> got so far unless I'm missing something. Please review them.
Thanks for the new version patches.
The v9-0001 patch looks good to me and I will start to review
The current FE/BE protocol assumes that the client is talking to the
server directly. If middleware wants to do something like load
balancing, the only current option is to inspect the incoming commands
and take action from that. That approach performs poorly and has
proven difficult to maintain,
On 2021-08-19 17:05:01 +0900, Michael Paquier wrote:
> Okay. Would you like to write a patch then?
I'll push something in a bit...
- Andres
On Thu, Aug 19, 2021 at 03:29:40PM +0800, Julien Rouhaud wrote:
> On Thu, Aug 19, 2021 at 3:05 PM Michael Paquier wrote:
> >
> > The thread of this open item is now idle for 10 days and there does
> > not seem to be a lot of progress. Bruce, this is assigned to you.
> > Are you planning to look
Hello.
While I was examining message translation for PG14, I found some
messages that would need to be fixed.
0001 is a fix for perhaps-leftovers of the recent message cleanups
related to "positive integer"(fd90f6ba7a).
0002 is a fix for a maybe-mistake in message convention of a recent
fix in
> On Wed, Aug 11, 2021 at 03:14:11PM +0900, Michael Paquier wrote:
> > I would just tweak the comment block at the top of what's being
> > changed, as per the attached. Please let me know if there are any
> > objections.
>
> And applied as of 710796f.
Thanks for your comment and commit.
I've
On Thu, Aug 19, 2021 at 2:06 PM Amit Kapila wrote:
>
> On Wed, Aug 18, 2021 at 12:12 PM Masahiko Sawada
> wrote:
> >
> > On Wed, Aug 18, 2021 at 3:15 PM Amit Kapila wrote:
> > >
> > > On Wed, Aug 18, 2021 at 10:00 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Wed, Aug 18, 2021 at 12:02
> On 19 Aug 2021, at 05:08, Tom Lane wrote:
>
> Peter Smith writes:
>> On Thu, Aug 19, 2021 at 4:29 AM Justin Pryzby wrote:
>>> - state->oneCol = (origTupdesc->natts == 1) ? true : false;
>>> + state->oneCol = origTupdesc->natts == 1;
>
> FWIW, I am definitely not a fan of
On Thu, Aug 19, 2021 at 4:51 PM Amit Kapila wrote:
>
> The action in apply_dispatch is always a single byte so not sure why
> we need %d here. Also, if it is used as %c before the patch then I
> think it is better not to change it in this patch.
>
As I explained before, the point is that all the
On Thu, Aug 19, 2021 at 3:05 PM Michael Paquier wrote:
>
> The thread of this open item is now idle for 10 days and there does
> not seem to be a lot of progress. Bruce, this is assigned to you.
> Are you planning to look at it?
I'm really sorry for the lack of answer on my side, I had too many
On Tue, Aug 17, 2021 at 12:00 PM Greg Nancarrow wrote:
>
> On Thu, Aug 12, 2021 at 3:54 PM Masahiko Sawada wrote:
> >
> > I've attached the updated patches. FYI I've included the patch
> > (v8-0005) that fixes the assertion failure during shared fileset
> > cleanup to make cfbot tests happy.
> >
On Thu, Aug 19, 2021 at 3:51 PM Amit Kapila wrote:
>
> On Mon, Aug 16, 2021 at 8:33 AM Greg Nancarrow wrote:
> >
> > On Mon, Aug 16, 2021 at 6:24 AM Masahiko Sawada
> > wrote:
> > >
> > > Therefore, perhaps a message like "... in transaction 740 with commit
> > > timestamp 2021-08-10
On Thu, Aug 19, 2021 at 2:18 PM Greg Nancarrow wrote:
>
> On Thu, Aug 19, 2021 at 11:48 AM Masahiko Sawada
> wrote:
> >
> > I've attached the updated version patches that incorporated all
> > comments I got so far unless I'm missing something. Please review
> > them.
> >
>
> The comments I made
On Mon, Aug 09, 2021 at 11:29:24AM +0800, Julien Rouhaud wrote:
> Ah indeed! This was quite a long thread so I didn't try to see when
> that changed. I also now realize that I made a typo in the patch
> where I s/loop/look/ which was then changed to s/look/lock/. The
> comment should be
On Wed, Aug 18, 2021 at 02:30:31PM +0900, Kyotaro Horiguchi wrote:
> The "Start-LSN" above is the beginning of timeline 2, not the
> backup-start LSN. The segment had been removed by the checkpoint.
Good catch. That's broken, and I find cleaner the logic to compare
the TLI numbers rather than
On Mon, Aug 16, 2021 at 8:33 AM Greg Nancarrow wrote:
>
> On Mon, Aug 16, 2021 at 6:24 AM Masahiko Sawada wrote:
> >
> > Therefore, perhaps a message like "... in transaction 740 with commit
> > timestamp 2021-08-10 14:44:38.058174+05:30" is better in terms of
> > consistency with other
On Thu, 19 Aug 2021 at 00:20, Andy Fan wrote:
> In the current master, the result is:
>
> empno | salary | c | dr
> ---++---+
> 8 | 6000 | 4 | 1
> In the patched version， the result is:
>
> empno | salary | c | dr
> ---++---+
> 8 | 6000 | 1 | 1
94 matches
Mail list logo
