On Wed, Jul 7, 2021 at 11:25 PM Matthias van de Meent
wrote:
>
> On Wed, 7 Jul 2021 at 13:47, Masahiko Sawada wrote:
> >
> > Hi all,
> >
> > Index vacuuming is one of the most time-consuming processes in lazy
> > vacuuming. lazy_tid_reaped() is a large part among them. The attached
> > the flame
On Thu, Jul 08, 2021 at 12:49:25AM -0400, Tom Lane wrote:
> Since we're already past beta2, I'm not sure that's a good idea. We
> can't really treat pageinspect 1.9 as something that the world has
> never seen.
Yeah, that's why I would object to new changes in 1.9 and
REL_14_STABLE. So my take
Justin Pryzby writes:
> On Thu, Jul 08, 2021 at 01:15:12PM +0900, Michael Paquier wrote:
>> Changes in the object set of an extension requires a new SQL script
>> that changes the objects to reflect the change. So, in this case,
>> what you need to do is to create pageinspect--1.9--1.10.sql,
Hi Tomas and Justin,
On 2021/06/07 4:47, Tomas Vondra wrote:
Here's a slightly more complete patch, tweaking the regression tests a
bit to detect this.
I tested your patch on PG14beta2 and PG15devel.
And they work fine.
===
All 209 tests passed.
===
On Thu, 8 Jul 2021 at 13:31, David Rowley wrote:
> It feels like if we're going to fix this negative rounding thing then
> we should maybe do it and backpatch a fix then rebase this work on top
> of that.
Here's a patch which I believe makes pg_size_pretty() and
pg_size_pretty_numeric() match in
On Thu, Jul 08, 2021 at 01:15:12PM +0900, Michael Paquier wrote:
> On Thu, Jul 08, 2021 at 09:12:26AM +0530, Bharath Rupireddy wrote:
> > +1. int32 makes sense because the maximum allowed block size is 32768
> > and smallint with range -32768 to +32767 can't hold it. Internally,
> > lower, upper,
On Thu, Jul 08, 2021 at 09:12:26AM +0530, Bharath Rupireddy wrote:
> +1. int32 makes sense because the maximum allowed block size is 32768
> and smallint with range -32768 to +32767 can't hold it. Internally,
> lower, upper, special are treated as unit16. I looked at the patch,
> how about using
Hello Michael,
06.07.2021 11:33, Michael Paquier wrote:
> On Sun, Mar 14, 2021 at 06:00:00PM +0300, Alexander Lakhin wrote:
>> I believe that the patch attached to [1] should fix this issue. The
>> patch still applies to master and makes the demotest (attached to [2])
>> pass. Also I've prepared
On Wednesday, June 30, 2021 7:43 PM vignesh C wrote:
> Thanks for reporting this issue, the attached v9 patch fixes this issue. This
> also fixes the other issue you reported at [1].
Hi,
I had a look at the patch, please consider following comments.
(1)
- if
On Thu, Jul 8, 2021 at 6:26 AM Quan Zongliang wrote:
>
> If the block size is 32k, the function page_header of the pageinspect
> module returns negative numbers:
>
> postgres=# select * from page_header(get_raw_page('t1',0));
> lsn| checksum | flags | lower | upper | special | pagesize |
On Wed, June 30, 2021 10:06 (GMT+9), Masahiko Sawada wrote:
> I've attached the new version patch that incorporates the comments from
> Fujii-san and Ikeda-san I got so far. We launch a resolver process per foreign
> server, committing prepared foreign transactions on foreign servers in
>
Hi, I was wondering if/when a subset of cols is specified then does
that mean it will be possible for the table to be replicated to a
*smaller* table at the subscriber side?
e.g Can a table with 7 cols replicated to a table with 2 cols?
table tab1(a,b,c,d,e,f,g) --> CREATE PUBLICATION pub1 FOR
On Thu, Jul 8, 2021 at 6:24 AM Peter Smith wrote:
> OK. I created a new thread called "parse_subscription_options -
> suggested improvements" here [1]
Thanks. I closed the CF entry for this thread.
Regards,
Bharath Rupireddy.
On Thu, 08 Jul 2021 at 01:32, Ranier Vilela wrote:
>>OTOH, when I execute ALTER SUBSCRIPTION ... SET (slot_name=''), it doesn't
> complain. However,
>>SELECT select pg_create_logical_replication_slot('', 'pgoutput') complains
> slot name is too
>>short. Although, the slot will be created at
On Thu, 8 Jul 2021 at 01:32, Dean Rasheed wrote:
> Hmm, this looked easy, but...
>
> It occurred to me that there ought to be regression tests for the edge
> cases where it steps from one unit to the next. So, in the style of
> the existing regression tests, I tried the following:
>
> SELECT
On Thu, Jul 8, 2021 at 10:34 AM Euler Taveira wrote:
>
> Greg, I like your suggestion and already integrate it (I replaced
> ExecAllocTableSlot() with MakeSingleTupleTableSlot() because we don't need the
> List).
Yes I agree, I found the same thing, it's not needed.
>I'm still working on a new
If the block size is 32k, the function page_header of the pageinspect
module returns negative numbers:
postgres=# select * from page_header(get_raw_page('t1',0));
lsn| checksum | flags | lower | upper | special | pagesize |
version | prune_xid
On Wed, Jul 7, 2021 at 1:35 PM Bharath Rupireddy
wrote:
>
> On Wed, Jul 7, 2021 at 5:33 AM Peter Smith wrote:
> > PSA my patch which includes all the fixes mentioned above.
>
> I agree with Amit to start a separate thread to discuss these points.
> IMO, we can close this thread. What do you
This is a re-posting of my original mail from here [1]
Created this new discussion thread for it as suggested here [2]
[1]
https://www.postgresql.org/message-id/CAHut%2BPtT0--Tf%3DK_YOmoyB3RtakUOYKeCs76aaOqO2Y%2BJt38kQ%40mail.gmail.com
[2]
On Wed, Jul 7, 2021, at 2:24 AM, Greg Nancarrow wrote:
> I found that with the call to ExecInitExtraTupleSlot() in
> pgoutput_row_filter(), then the performance of pgoutput_row_filter()
> degrades considerably over the 100,000 invocations, and on my system
> it took about 43 seconds to filter and
Hello Fabien,
I attached the updated patch (v14)!
On Wed, 30 Jun 2021 17:33:24 +0200 (CEST)
Fabien COELHO wrote:
> >> --report-latencies -> --report-per-command: should we keep supporting
> >> the previous option?
> >
> > Ok. Although now the option is not only for latencies, considering users
On Wed, Jul 7, 2021 at 1:24 PM Peter Geoghegan wrote:
> I wonder how much it would help to break up that loop into two loops.
> Make the callback into a batch operation that generates state that
> describes what to do with each and every index tuple on the leaf page.
> The first loop would build
Thanks!
In this version of the patch, calls to malloc have been removed.
Hopefully MAX_PATH is long enough for filenames.
How does that cope with durable_rename_excl() where rename() is used
on Windows? The problems that 909b449 has somewhat "fixed" were
annoying for the users as it
On Thu, Jul 8, 2021 at 10:12 AM Daniel Gustafsson wrote:
> Spotted a few random typos in comments while reading code, will apply these
> tomorrow or so unless there are objections.
LGTM.
Spotted a few random typos in comments while reading code, will apply these
tomorrow or so unless there are objections.
--
Daniel Gustafsson https://vmware.com/
assorted-typos.patch
Description: Binary data
> On 7 Jul 2021, at 21:12, Dagfinn Ilmari Mannsåker wrote:
> Here's a patch to convert the remaining ones.
I haven't tested it yet, but +1 on the idea of cleaning these up making the
codebase consistent.
--
Daniel Gustafsson https://vmware.com/
> On 3 Jun 2021, at 04:07, Thomas Munro wrote:
> Here's a patch to remove the misleading comments.
While not an expert in the area; reading the referenced commit and the code
with the now removed comments, I think this is correct.
--
Daniel Gustafsson https://vmware.com/
On Wed, Jul 7, 2021 at 4:47 AM Masahiko Sawada wrote:
> Currently, the TIDs of dead tuples are stored in an array that is
> collectively allocated at the start of lazy vacuum and TID lookup uses
> bsearch(). There are the following challenges and limitations:
>
> 1. Don't allocate more than 1GB.
> On 6 Jul 2021, at 17:08, vignesh C wrote:
> The patch was not applying on the head because of the recent commit
> "8aafb02616753f5c6c90bbc567636b73c0cbb9d4", attached patch which is
> rebased on HEAD.
I sort of like the visual cue of seeing ereport(ERROR .. since it makes it
clear it will
Tom Lane writes:
> David Christensen writes:
>> Enclosed is the patch to change the return type to numeric, as well as one
>> for expanding units to
>> add PB and EB.
>
> Can we really get away with changing the return type? That would
> by no stretch of the imagination be free; one could
David Christensen writes:
> Enclosed is the patch to change the return type to numeric, as well as one
> for expanding units to
> add PB and EB.
Can we really get away with changing the return type? That would
by no stretch of the imagination be free; one could expect breakage
of a few user
Alexander Pyhalov writes:
> The following test case makes postgresql backend crash. The trigger is
> incorrect, but this didn't crash postgresql before
Yup, that's a silly oversight. Fixed, thanks for the report!
regards, tom lane
Hi hackers,
We've had node-casting versions of the list extraction macros since
2017, but several cases of the written-out version have been added since
then (even by Tom, who added the l*_node() macros).
Here's a patch to convert the remaining ones. The macros were
back-patched to all
Hello,
(I hope it's okay to ask general internals questions here; if this list is
strictly for development, I'll keep my questions on -general but since I'm
asking about internal behavior, this seemed more appropriate.)
I was playing around with inspecting TOAST tables in order to understand
the
On Wed, 7 Jul 2021 at 18:57, Zhihong Yu wrote:
>
> + (errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
> +errmsg("value overflows numeric format")));
>
> Here is an example of existing error message which I think is more readable
> than 'overflows numeric
Le 07/07/2021 à 18:55, Gilles Darold a écrit :
Le 07/07/2021 à 18:50, Gilles Darold a écrit :
Great, I changing the state in the commitfest to "Ready for committers".
I'm attaching the v5 patch again as it doesn't appears in the Latest
attachment list in the commitfest.
And the review
st 7. 7. 2021 v 20:03 odesílatel Jacob Champion
napsal:
> On Mon, 2021-04-05 at 14:07 +0900, Kyotaro Horiguchi wrote:
> > At Fri, 2 Apr 2021 11:51:26 +0200, Pavel Stehule <
> pavel.steh...@gmail.com> wrote in
> > > with this patch, the formatting is correct
> >
> > I think the hardest point of
David G. Johnston writes:
> Having the defined FK behaviors be more readily changeable, while not
> mitigating this need, is IMO a more important feature to implement. If
> there is a reason that cannot be implemented (besides no one has bothered
> to take the time) then I would consider that
On Mon, 2021-04-05 at 14:07 +0900, Kyotaro Horiguchi wrote:
> At Fri, 2 Apr 2021 11:51:26 +0200, Pavel Stehule
> wrote in
> > with this patch, the formatting is correct
>
> I think the hardest point of this issue is that we don't have a
> reasonable authoritative source that determines
On Wed, Jul 7, 2021 at 10:37 AM Dean Rasheed
wrote:
> On Thu, 1 Jul 2021 at 14:17, Dean Rasheed
> wrote:
> >
> > On Tue, 29 Jun 2021 at 12:08, Dean Rasheed
> wrote:
> > >
> > > Numeric x^y is supported for x < 0 if y is an integer, but this
> > > currently fails if y is outside the range of an
David Rowley writes:
> On Wed, 7 Jul 2021 at 02:46, David Christensen
> wrote:
>> if we do decide to expand the units table there will be a
>> few additional changes (most significantly, the return value of
>> `pg_size_bytes()` will need to switch
>> to `numeric`).
>
> I wonder if it's worth
On Thu, 1 Jul 2021 at 14:17, Dean Rasheed wrote:
>
> On Tue, 29 Jun 2021 at 12:08, Dean Rasheed wrote:
> >
> > Numeric x^y is supported for x < 0 if y is an integer, but this
> > currently fails if y is outside the range of an int32
>
> I've been doing some more testing of this, and I spotted
>OTOH, when I execute ALTER SUBSCRIPTION ... SET (slot_name=''), it doesn't
complain. However,
>SELECT select pg_create_logical_replication_slot('', 'pgoutput') complains
slot name is too
>short. Although, the slot will be created at publisher, and validate the
slot name, IMO, we
>can also
On 2021-Jul-07, Boris Kolpackov wrote:
> // Try to minimize the chance of blocking the server by first processing
> // the result and then sending more queries.
> //
> if (FD_ISSET (sock, ))
> {
> if (PQconsumeInput (conn) == 0)
> assert (false);
>
> while
Le 07/07/2021 à 18:50, Gilles Darold a écrit :
Great, I changing the state in the commitfest to "Ready for committers".
I'm attaching the v5 patch again as it doesn't appears in the Latest
attachment list in the commitfest.
--
Gilles Darold
MigOps Inc
diff --git
Le 07/07/2021 à 17:39, Alexander Pyhalov a écrit :
Hi.
Gilles Darold писал 2021-07-07 15:02:
Le 22/06/2021 à 15:39, Alexander Pyhalov a écrit :
Seino Yuki писал 2021-06-22 16:03:
On 2021-06-16 01:29, Alexander Pyhalov wrote:
Hi.
Ashutosh Bapat писал 2021-06-15 16:24:
Looks quite useful to
Domingo Alvarez Duarte writes:
> What if the generated parser/lexer be present in the tarball distributions ?
It is. The discussion here is about developer convenience (how painful
is it to read or modify a rule) versus developer convenience (what hoops
have you got to jump through to install a
Hi.
Gilles Darold писал 2021-07-07 15:02:
Le 22/06/2021 à 15:39, Alexander Pyhalov a écrit :
Seino Yuki писал 2021-06-22 16:03:
On 2021-06-16 01:29, Alexander Pyhalov wrote:
Hi.
Ashutosh Bapat писал 2021-06-15 16:24:
Looks quite useful to me. Can you please add this to the next
commitfest?
"jian...@fujitsu.com" writes:
> When I used COPY FROM command on windows, I found that If the line data ends
> with a backslash and carriage return/newlines(\r\n),COPY FROM mishandle the
> line .
> As a result, there were unexpected data loaded into database.
If what you're saying is that
I understand the concerns but I would not qualify it as "minor
developer-convenience feature".
I'm not impartial because the initial suggestion was mine, just to add
more options to be considered:
What if the generated parser/lexer be present in the tarball distributions ?
Cheers !
On
On 2021-Jul-07, Boris Kolpackov wrote:
> Alvaro Herrera writes:
>
> > On 2021-Jul-07, Boris Kolpackov wrote:
> >
> > > I don't get any difference in behavior with this patch. That is, I
> > > still get the unexpected NULL result. Does it make a difference for
> > > your reproducer?
> >
> >
Peter Eisentraut writes:
> The clobbering doesn't actually happen unless you turn on
> CLOBBER_FREED_MEMORY, so it would be good to keep that separate.
Fair point. What do you think of the alternative proposals
"debug_flush_caches", "debug_discard_caches", etc?
ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> Peter Eisentraut writes:
>> On 04.07.21 17:58, Tom Lane wrote:
>>> When is "some time now"?
>> release 2.5 (2011-05-14)
> Do we support building on RHEL6? It only ships bison 2.4, so that would
> mean people building on
Alvaro Herrera writes:
> On 2021-Jul-07, Boris Kolpackov wrote:
>
> > I don't get any difference in behavior with this patch. That is, I
> > still get the unexpected NULL result. Does it make a difference for
> > your reproducer?
>
> Yes, the behavior changes for my repro. Is it possible for
On Wed, 2021-07-07 at 14:08 +0900, Michael Paquier wrote:
> On Tue, Jul 06, 2021 at 06:20:49PM +, Jacob Champion wrote:
> > On Mon, 2021-07-05 at 17:17 +0900, Michael Paquier wrote:
> >
> > > Hmm. Does the RFCs tell us anything about that?
> >
> > Just in general terms:
> >
> > >Each
On Wed, 2021-07-07 at 01:42 -0400, Tom Lane wrote:
> Michael Paquier writes:
> > It seems to me that this does not address yet the problems with the
> > palloc/pstrdup in jsonapi.c though, which would need to rely on
> > malloc() if we finish to use this code in libpq. I am not sure yet
> > that
On Wed, 7 Jul 2021 at 13:47, Masahiko Sawada wrote:
>
> Hi all,
>
> Index vacuuming is one of the most time-consuming processes in lazy
> vacuuming. lazy_tid_reaped() is a large part among them. The attached
> the flame graph shows a profile of a vacuum on a table that has one index
> and 80
On Wed, Jul 7, 2021 at 8:45 PM Jim Mlodgenski wrote:
>
> The test module is very useful to show how to use the hook but it isn't
> very useful to the general user like most other things in contrib. It probably
> fits better in src/test/modules
I agree that it's not useful at all to eventually
Hi.
The following test case makes postgresql backend crash. The trigger is
incorrect, but this didn't crash postgresql before
commit 86dc90056dfdbd9d1b891718d2e5614e3e432f35 (HEAD)
Author: Tom Lane
Date: Wed Mar 31 11:52:34 2021 -0400
Rework planning and execution of UPDATE and
Hi, hackers
The documentation [1] says:
When dropping a subscription that is associated with a replication slot on the
remote host (the normal state), DROP SUBSCRIPTION will connect to the remote
host and try to drop the replication slot as part of its operation. This is
necessary so that the
On Wed, 07 Jul 2021 21:50:16 +0900 (JST)
Tatsuo Ishii wrote:
> >> Well, "that's very little, let's ignore it" is not technically a right
> >> direction IMO.
> >
> > Hmmm, It seems to me these failures are ignorable because with regard to
> > failures
> > due to -T they occur only the last
On Wed, 7 Jul 2021 at 03:47, David Rowley wrote:
>
> Updated patch attached.
>
Hmm, this looked easy, but...
It occurred to me that there ought to be regression tests for the edge
cases where it steps from one unit to the next. So, in the style of
the existing regression tests, I tried the
> On 7 Jul 2021, at 04:23, Gurjeet Singh wrote:
> I'm not able to come up with an exact situation to prove this, but
> this behaviour seems potentially dangerous. The user might mix the
> --sync-only option with other options, but would be extremely
> surprised if those other options didn't take
>You can check the more details in the attached patch. Any feedback is
welcome.
I have tiny comments about your patch:
1. name of file is uniquekey.c?
+ * pathkeys.c
+ * Utilities for maintaining uniquekey.
2. Variable "PathKey *pathkey" at function: add_uniquekey_for_uniqueindex,
can have
Peter Eisentraut writes:
> On 04.07.21 17:58, Tom Lane wrote:
>> Domingo Alvarez Duarte writes:
>>> Here https://gist.github.com/mingodad/49291e0e9505522c66fcd3fcea4a939d I
>>> posted the postgresql-13.3/src/backend/parser/gram.y with positional
>>> references by named references that is
On Wed, Jul 7, 2021 at 8:57 PM Fujii Masao wrote:
>
> Pushed. Thanks!
Thanks!
On 2021/07/07 18:09, Julien Rouhaud wrote:
On Thu, Jul 1, 2021 at 4:28 PM Fujii Masao wrote:
I'm fine with this. So what about the following diff? I added tag.
pg_stat_statements.track_planning controls whether
planning operations and duration are tracked by the module.
>> Well, "that's very little, let's ignore it" is not technically a right
>> direction IMO.
>
> Hmmm, It seems to me these failures are ignorable because with regard to
> failures
> due to -T they occur only the last transaction of each client and do not
> affect
> the result such as TPS and
On Wed, Jul 7, 2021 at 5:26 AM Julien Rouhaud wrote:
>
> Also, if this patch is eventually committed and having some code to
> experience the hook is wanted it would probably be better to have a
> very naive parser (based on a few strcmp() calls or something like
> that) to validate the behavior
On 7/7/21 2:53 AM, Jakub Wartak wrote:
Hi, Asking out of pure technical curiosity about "the rhinoceros" - what kind
of animal is it ? Physical box or VM? How one could get dmidecode(1) / dmesg(1) / mcelog
(1) from what's out there (e.g. does it run ECC or not ?)
Rhinoceros is just a VM on
On Fri, Jun 4, 2021 at 10:23 PM Alvaro Herrera wrote:
>
> On 2021-Jun-04, Bharath Rupireddy wrote:
>
> > On Fri, Jun 4, 2021 at 8:58 PM Alvaro Herrera
> > wrote:
>
> > > I would suggest that the best way forward in this area is to rebase both
> > > there patches on current master.
> >
> >
On Thu, May 27, 2021 at 10:28 PM Bharath Rupireddy
wrote:
> I'm not taking the patch, attaching v5 again here to make cfbot happy
> and for further review.
Attaching v6 patch rebased onto the latest master.
Regards,
Bharath Rupireddy.
v6-0001-Improve-publication-error-messages.patch
Le 22/06/2021 à 15:39, Alexander Pyhalov a écrit :
Seino Yuki писал 2021-06-22 16:03:
On 2021-06-16 01:29, Alexander Pyhalov wrote:
Hi.
Ashutosh Bapat писал 2021-06-15 16:24:
Looks quite useful to me. Can you please add this to the next
commitfest?
Addded to commitfest. Here is an
Hi all,
Index vacuuming is one of the most time-consuming processes in lazy
vacuuming. lazy_tid_reaped() is a large part among them. The attached
the flame graph shows a profile of a vacuum on a table that has one index
and 80 million live rows and 20 million dead rows, where
lazy_tid_reaped()
On Sun, 4 Jul 2021 at 22:38, David Rowley wrote:
> I could do with a 2nd opinion about if we should just adjust the
> maximum value for the autovacuum_work_mem GUC to 1GB in master.
>
> I'm also not sure if since we'd not backpatch the GUC max value
> adjustment if we need to document the upper
On 2021-Jul-07, Boris Kolpackov wrote:
> I don't get any difference in behavior with this patch. That is, I
> still get the unexpected NULL result. Does it make a difference for
> your reproducer?
Yes, the behavior changes for my repro. Is it possible for you to
share a full program I can
On Wed, 07 Jul 2021 16:11:23 +0900 (JST)
Tatsuo Ishii wrote:
> > Indeed, as Ishii-san pointed out, some users might not want to terminate
> > retrying transactions due to -T. However, the actual negative effect is only
> > printing the number of failed transactions. The other result that users
On Wed, 7 Jul 2021 at 04:00, Yura Sokolov wrote:
>
> Anyway, excuse me for heating this discussion cause of such
> non-essential issue.
> I'll try to control myself and don't proceed it further.
>
Whilst it has been interesting learning and discussing all these
different techniques, I think it's
Alvaro Herrera writes:
> Can you please try with this patch?
I don't get any difference in behavior with this patch. That is, I
still get the unexpected NULL result. Does it make a difference for
your reproducer?
Le mardi 6 juillet 2021, 17:37:53 CEST James Coleman a écrit :
> Yes and no. When incremental sort has to do a full sort there will
> always be at least 2 attributes. But in prefix sort mode (see
> prefixsort_state) only non-presorted columns are sorted (i.e., if
> given a,b already sorted by a,
Thanks for the review Jim!
On Wed, Jul 7, 2021 at 3:26 AM Jim Mlodgenski wrote:
>
> On Sat, Jun 12, 2021 at 4:29 AM Julien Rouhaud wrote:
>
> The patches all build properly and pass all regressions tests.
Note that the cfbot reports a compilation error on windows. That's on
the grammar
On Thu, Jul 1, 2021 at 4:28 PM Fujii Masao wrote:
>
> I'm fine with this. So what about the following diff? I added
> tag.
>
> pg_stat_statements.track_planning controls whether
> planning operations and duration are tracked by the module.
> Enabling this parameter may
On Tue, Jul 6, 2021 at 5:34 PM David Rowley wrote:
>
> On Sun, 4 Jul 2021 at 02:08, Andy Fan wrote:
> > I'd start to work on UniqueKey again, it would be great that we can target
> > it
> > to PG 15. The attached patch is just for the notnull_attrs. Since we can't
> > say
> > a column is
On Wed, 7 Jul 2021 at 00:06, Greg Nancarrow wrote:
> I think if you're going to reject this patch, a brief comment should
> be added to that code to justify why that existing superfluous check
> is worthwhile.
It seems strange to add a comment to explain why it's there. If we're
going to the
On 04.07.21 22:27, Tom Lane wrote:
I do agree with the "debug_" prefix given that it's now visible to
users. However, it doesn't seem that hard to save some space in
the rest of the name. The word "system" is adding nothing of value,
and the word "always" seems rather confusing --- if it does
On 04.07.21 17:58, Tom Lane wrote:
Domingo Alvarez Duarte writes:
Here https://gist.github.com/mingodad/49291e0e9505522c66fcd3fcea4a939d I
posted the postgresql-13.3/src/backend/parser/gram.y with positional
references by named references that is supported by bison for some time now.
When is
> On 6 Jul 2021, at 23:59, Alvaro Herrera wrote:
> Failures now look like this, respectively:
>
> Bailout called. Further testing stopped: failed to execute command "finitdb
> -D
> /home/alvherre/Code/pgsql-build/master/src/test/recovery/tmp_check/t_019_replslot_limit_primary_data/pgdata
>
On Wed, Jul 7, 2021 at 1:41 PM David Rowley wrote:
> On Fri, 2 Jul 2021 at 12:41, Amit Langote wrote:
> > I'll mark the CF entry as WoA, unless you'd rather I just mark it RwF.
>
> I've set it to waiting on author. It was still set to needs review.
Sorry it slipped my mind to do that and
Hello.
At Tue, 6 Jul 2021 20:42:23 +0800, "zwj" <757634...@qq.com> wrote in
> But I wonder whether it is necessary or not while my file system can protect
> the blocks of database to be torn. And I read a comment in
> functionMarkBufferDirtyHint:
>
> /*
> * If we need to protect hint bit
> Indeed, as Ishii-san pointed out, some users might not want to terminate
> retrying transactions due to -T. However, the actual negative effect is only
> printing the number of failed transactions. The other result that users want
> to
> know, such as tps, are almost not affected because they
Hi
When I used COPY FROM command on windows, I found that If the line data ends
with a backslash and carriage return/newlines(\r\n),COPY FROM mishandle the
line .
As a result, there were unexpected data loaded into database.
The following case can reproduce this issue.
Hi, Asking out of pure technical curiosity about "the rhinoceros" - what kind
of animal is it ? Physical box or VM? How one could get dmidecode(1) / dmesg(1)
/ mcelog (1) from what's out there (e.g. does it run ECC or not ?)
-J.
> -Original Message-
> From: Alvaro Herrera
> Sent:
On Tue, Jul 6, 2021 at 6:33 PM Amit Kapila wrote:
>
> On Tue, Jul 6, 2021 at 12:30 PM Masahiko Sawada wrote:
> >
> > On Mon, Jul 5, 2021 at 6:46 PM Amit Kapila wrote:
> > >
> > > On Thu, Jul 1, 2021 at 6:31 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Thu, Jul 1, 2021 at 12:56 PM Amit
93 matches
Mail list logo
