Hello,
I found that using "BEGIN ISOLATINO LEVEL SERIALIZABLE" in a pipline with
prepared statement makes pgbench abort.
$ cat pipeline.sql
\startpipeline
begin isolation level repeatable read;
select 1;
end;
\endpipeline
$ pgbench -f pipeline.sql -M prepared -t 1
pgbench (15devel)
sta
On Fri, 16 Jul 2021 at 14:06, Amit Kapila wrote:
> On Fri, Jul 9, 2021 at 8:20 AM Japin Li wrote:
>>
>> On Thu, 08 Jul 2021 at 18:17, Amit Kapila wrote:
>> > On Thu, Jul 8, 2021 at 3:43 PM Japin Li wrote:
>>
>> Please consider review v3 patch. v3-0001 adds slot_name verification in
>> parse_s
On Wed, Jul 14, 2021 at 2:03 PM Peter Smith wrote:
>
> On Wed, Jul 14, 2021 at 4:23 PM Amit Kapila wrote:
> >
> > On Mon, Jul 12, 2021 at 9:14 AM Peter Smith wrote:
> > >
> > > On Sun, Jul 11, 2021 at 8:20 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Fri, Jul 9, 2021 at 4:43 AM Peter Smith
On Fri, Jul 9, 2021 at 8:20 AM Japin Li wrote:
>
> On Thu, 08 Jul 2021 at 18:17, Amit Kapila wrote:
> > On Thu, Jul 8, 2021 at 3:43 PM Japin Li wrote:
>
> Please consider review v3 patch. v3-0001 adds slot_name verification in
> parse_subscription_options() and comments for why we need disable s
On Fri, 16 Jul 2021 at 01:02, Ronan Dunklau wrote:
> The approach of building a pathkey for the first order by we find, then
> appending to it as needed seems sensible but I'm a bit worried about users
> starting to rely on this as an optimization. Even if we don't document it,
> people may start
On Fri, Jul 16, 2021 at 10:11 AM Dilip Kumar wrote:
>
> On Fri, Jul 16, 2021 at 8:57 AM Amit Kapila wrote:
> >
> > On Wed, Jul 14, 2021 at 4:30 PM Dilip Kumar wrote:
> > >
> > > On Wed, Jul 14, 2021 at 3:58 PM Tomas Vondra
> > > wrote:
> > > >
> > > > Is there some reasonable rule which of the
Have you considered shift-based DFA for a portable implementation
https://gist.github.com/pervognsen/218ea17743e1442e59bb60d29b1aa725 ?
Vladimir
>
On Fri, Jul 16, 2021 at 1:04 AM Dean Rasheed wrote:
> Having pushed [1], I started looking at this, and I think it's mostly
> in good shape.
Thanks a lot for taking a look at this.
> Since we're improving the CREATE COLLATION errors, I think it's also
> worth splitting out the error for LOCALE +
On Fri, Jul 16, 2021 at 08:59:11AM +0900, Michael Paquier wrote:
> --compress is used and the sync fails for a non-compressed segment.
> Looking at the code it is pretty obvious that open_walfile() is
> getting confused with the handling of an existing .partial segment
> while walmethods.c uses dir
On Fri, Jul 16, 2021 at 8:57 AM Amit Kapila wrote:
>
> On Wed, Jul 14, 2021 at 4:30 PM Dilip Kumar wrote:
> >
> > On Wed, Jul 14, 2021 at 3:58 PM Tomas Vondra
> > wrote:
> > >
> > > Is there some reasonable rule which of the old/new tuples (or both) to
> > > use for the WHERE condition? Or maybe
Hi,
I noticed that anti-virus software slow down the open().
I stopped the anti-virus software and re-run the test.
(Average of 10 times)
master: 1924tps
Hold_xlogreader.patch: 1993tps (+3.5%)
Read_from_walbuffer.patch: 1954tps(+1.5%)
Therefore, the effect of my patch is limited.
I'm sorry for
On Wed, Jul 14, 2021 at 8:17 PM vignesh C wrote:
>
> Thanks for your comments, the attached v11 patch fixes the issues.
>
Thanks for your work on this.
I have some minor review comments on the documentation:
(1) wrong link (uses altersubscription instead of alterpublication)
doc/src/sgml/catalo
rebased.
Also, there were two redundant checks for multiple SET ACCESS METHOD commands.
But one of them wasn't hit if the ALTER was setting the current AM due to the
no-op test.
I think it's better to fail in every case, and not just sometimes (especially
if we were to use ERRCODE_SYNTAX_ERROR).
On Fri, 16 Jul 2021 at 02:53, Ronan Dunklau wrote:
> Please find attached a v9 just moving the flag setting to ExecInitSort, and my
> apologies if I misunderstood your point.
I took this and adjusted a few things and ended up with the attached patch.
The changes are fairly minor. I made the brac
On Wed, Jul 14, 2021 at 4:30 PM Dilip Kumar wrote:
>
> On Wed, Jul 14, 2021 at 3:58 PM Tomas Vondra
> wrote:
> >
> > Is there some reasonable rule which of the old/new tuples (or both) to
> > use for the WHERE condition? Or maybe it'd be handy to allow referencing
> > OLD/NEW as in triggers?
>
>
Hi Vignesh.
FYI - Because the other patch [1] was pushed ahead of this one, I
think your patch now needs to be updated for the new message types
that were introduced.
--
[1]
https://github.com/postgres/postgres/commit/a8fd13cab0ba815e9925dc9676e6309f699b5f72#diff-331c33fd11c3ed85f9dbfead93f1
Hello,
I attached the updated patch.
On Tue, 13 Jul 2021 15:50:52 +0900
Yugo NAGATA wrote:
> > >> > I'm a little hesitant about how to count and report such unfinished
> > >> > because of bench timeout transactions, though. Not counting them seems
> > >> > to be the best option.
> > > I will
On Thu, Jul 15, 2021 at 4:30 AM Euler Taveira wrote:
>
> On Wed, Jul 14, 2021, at 8:21 AM, Greg Nancarrow wrote:
>
> Some minor v19 patch review points you might consider for your next
> patch version:
>
> Greg, thanks for another review. I agree with all of these changes. It will be
> in the next
On Fri, 16 Jul 2021 at 02:53, Ronan Dunklau wrote:
>
> Le jeudi 15 juillet 2021, 16:19:23 CEST David Rowley a écrit :>
> > Ronan's latest results plus John's make me think there's no need to
> > separate out the node function as I did in v8. However, I do think v6
> > could learn a little from v8
On Wed, Jul 14, 2021 at 07:42:33AM +0200, Laurenz Albe wrote:
> Besides, schemas are not physical, but logical containers. So I see a point
> in
> measuring the storage used in a certain tablespace, but not so much by all
> objects
> in a certain schema. It might be useful for accounting purpos
Em qui., 15 de jul. de 2021 às 10:04, Ranier Vilela
escreveu:
> Em qui., 15 de jul. de 2021 às 10:01, Aleksander Alekseev <
> aleksan...@timescale.com> escreveu:
>
>> Thanks, David.
>>
>> > I lost where. Can you show me?
>>
>> See the attached warnings.txt.
>>
> Thank you.
>
>
>>
>> > But the ben
On Thu, Jul 15, 2021 at 09:35:52PM +0900, Michael Paquier wrote:
> For this one, I'll try to test harder on my own host. I am curious to
> see if the other Windows members running the TAP tests have anything
> to say. Looking at the code of zlib, this would come from gz_zero()
> in gzflush(), whi
I noticed that the previous Read_from_walbuffer.patch has a mistake in
xlogreader.c.
Could you please use the attached v2 patch?
The performance result of the previous mail is the result of v2 patch.
Regards,
Ryohei Takahashi
v2-Read_from_walbuffer.patch
Description: v2-Read_from_walbuffer.pa
On Thursday, July 15, 2021, Jan Wieck wrote:
> On 7/15/21 4:24 PM, David G. Johnston wrote:
>
> OK, especially as this seems useful outside of pg_upgrade, and if done
>> separately is something pg_upgrade could just run as part of its new
>> cluster evaluation scripts. Knowing whether an extensi
On 7/15/21 4:24 PM, David G. Johnston wrote:
OK, especially as this seems useful outside of pg_upgrade, and if done
separately is something pg_upgrade could just run as part of its new
cluster evaluation scripts. Knowing whether an extension is outdated
doesn't require the old cluster.
Know
> On Jul 15, 2021, at 3:32 PM, Tomas Vondra
> wrote:
>
> I think it's mostly futile to list all the possible issues this might have
> caused - if you skip arbitrary decoded changes, that can trigger pretty much
> any bug in reorder buffer. But those bugs can be triggered by various other
>
Hi,
I think it's mostly futile to list all the possible issues this might
have caused - if you skip arbitrary decoded changes, that can trigger
pretty much any bug in reorder buffer. But those bugs can be triggered
by various other issues, of course.
It's hard to say what was the cause, but
I wrote:
> To simplify the constants, I do shift down to uint32, and I didn't bother
working around that. v16alpha regressed on worst-case input, so for v16beta
I went back to earlier coding for the one-byte ascii check. That helped,
but it's still slower than v14.
It occurred to me that I could
> On Jul 15, 2021, at 1:51 PM, Mark Dilger wrote:
>
> one common error I see
Another common error is of the form
ERROR: could not map filenode "base/16384/16413" to relation OID
resulting from a ddl statement having not been written correctly, I think.
This, too, has shown up in
> On Jul 15, 2021, at 1:03 PM, Mark Dilger wrote:
>
> Skipping some writes while not others easily creates a variety of failures,
> and for brevity I won't post a patch to demonstrate that here.
If anybody is curious, one common error I see when simulating a close()
skipping partial changes
On Thu, Jul 15, 2021 at 11:52 AM Dave Cramer
wrote:
>
> On Thu, 15 Jul 2021 at 14:31, David G. Johnston <
> david.g.johns...@gmail.com> wrote:
>
>>
>> Yep, and IIUC running "CREATE EXTENSION pg_stat_statements VERSION
>> '1.5';" works correctly in v13 as does executing
>>
> While it does work the
Hackers,
I believe there is a hazard in reorderbuffer.c if a call to write() buffers
data rather than flushing it to disk, only to fail when flushing the data
during close(). The relevant code is in ReorderBufferSerializeTXN(), which
iterates over changes for a transaction, opening transient f
> On 15 Jul 2021, at 04:51, houzj.f...@fujitsu.com wrote:
> On July 15, 2021 5:35 AM Daniel Gustafsson wrote:
>> Out of curiosity, how many columns are "many columns"?
>
> I tried dump 10 table definitions while each table has 1000 columns
> (maybe not real world case).
While unlikely to be com
On Mon, 31 May 2021 at 15:10, vignesh C wrote:
>
> On Sat, May 29, 2021 at 9:20 PM Bharath Rupireddy
> wrote:
> >
> > Thanks. PSA v3 patch.
>
> Thanks for the updated patch, the changes look good to me.
>
Hi,
Having pushed [1], I started looking at this, and I think it's mostly
in good shape.
On 7/15/21 12:26 PM, Alexander Korotkov wrote:
> On Thu, Jul 15, 2021 at 6:47 PM Tom Lane wrote:
>> Yeah, that seems pretty horrid. I still don't like the way the
>> array casts were done, but I'd be okay with pushing the unnest
>> addition.
>
> +1 for just unnest().
...which was my original as
On Thu, Jul 15, 2021 at 8:25 AM Zhihong Yu wrote:
>
>
> On Thu, Jul 15, 2021 at 7:49 AM Andrey Lepikhov
> wrote:
>
>> On 6/7/21 13:49, Hywel Carver wrote:
>> > On Mon, Jul 5, 2021 at 2:20 PM Andrey Lepikhov
>> > mailto:a.lepik...@postgrespro.ru>> wrote:
>> > Looking through the email chain, a pr
On Wed, Jul 14, 2021 at 02:05:29PM +0900, Ian Lawrence Barwick wrote:
> 2021年7月14日(水) 12:07 Justin Pryzby :
> >
> > \db+ and \l+ show sizes of tablespaces and databases, so I was surprised in
> > the
> > past that \dn+ didn't show sizes of schemas. I would find that somewhat
> > convenient, and I
On Thu, Jul 15, 2021 at 4:35 PM Tom Lane wrote:
>
> Magnus Hagander writes:
> > Putting it in the tarball making script certainly works for me,
> > though, if that's what people prefer. And that does away with the
> > "clean" part as that one blows away the whole directory between each
> > run.
>
On Thu, 15 Jul 2021 at 14:31, David G. Johnston
wrote:
> On Thu, Jul 15, 2021 at 11:14 AM Jan Wieck wrote:
>
>> On 7/15/21 1:10 PM, David G. Johnston wrote:
>> > ... But while
>> > PostgreSQL doesn't really have a choice here - it cannot be expected to
>> > subdivide itself - extensions (at leas
Hi,
On 2021-07-15 13:59:26 -0400, Bruce Momjian wrote:
> On Wed, Jul 14, 2021 at 07:17:47PM -0700, Andres Freund wrote:
> > FWIW, I don't think hardware tls acceleration is a particularly crucial
> > thing
> > for now. Outside of backups it's rare to have the symmetric encryption part
> > of
> >
On Thu, Jul 15, 2021 at 11:14 AM Jan Wieck wrote:
> On 7/15/21 1:10 PM, David G. Johnston wrote:
> > ... But while
> > PostgreSQL doesn't really have a choice here - it cannot be expected to
> > subdivide itself - extensions (at least external ones - PostGIS is one I
> > have in mind presently) -
On Thu, Jul 15, 2021 at 02:14:28PM -0400, Jan Wieck wrote:
> On 7/15/21 1:10 PM, David G. Johnston wrote:
> > ... But while PostgreSQL doesn't really have a choice here - it cannot
> > be expected to subdivide itself - extensions (at least external ones -
> > PostGIS is one I have in mind presently
On 7/15/21 1:10 PM, David G. Johnston wrote:
... But while
PostgreSQL doesn't really have a choice here - it cannot be expected to
subdivide itself - extensions (at least external ones - PostGIS is one I
have in mind presently) - can and often do attempt to support multiple
versions of Postgre
On Thu, Jul 15, 2021 at 1:10 AM Amit Khandekar
wrote:
> - check_ascii() seems to be used only for 64-bit chunks. So why not
> remove the len argument and the len <= sizeof(int64) checks inside the
> function. We can rename it to check_ascii64() for clarity.
Thanks for taking a look!
Well yes, b
On Wed, Jul 14, 2021 at 07:17:47PM -0700, Andres Freund wrote:
> FWIW, I don't think hardware tls acceleration is a particularly crucial thing
> for now. Outside of backups it's rare to have the symmetric encryption part of
> tls be the problem these days thanks, to the AES etc functions in most of
On Thu, Jul 15, 2021 at 9:58 AM Jan Wieck wrote:
> On 7/15/21 12:46 PM, David G. Johnston wrote:
>
> > I am an application developer who operates on the principle of "change
> > only one thing at a time".
>
> Which pg_upgrade by definition isn't. It is bringing ALL the changes
> from one major ve
On Thu, Jul 15, 2021 at 10:19 AM David Rowley wrote:
>
> On Fri, 16 Jul 2021 at 01:44, James Coleman wrote:
> >
> > On Wed, Jul 14, 2021 at 9:22 PM David Rowley wrote:
> > >
> > > On Thu, 15 Jul 2021 at 12:30, Ranier Vilela wrote:
> > > >
> > > > Em qua., 14 de jul. de 2021 às 21:21, David Rowl
On 7/15/21 12:46 PM, David G. Johnston wrote:
I am an application developer who operates on the principle of "change
only one thing at a time".
Which pg_upgrade by definition isn't. It is bringing ALL the changes
from one major version to the target version, which may be multiple at
once. In
On Thu, Jul 15, 2021 at 9:36 AM Jan Wieck wrote:
>
> I am a bit confused here. From the previous exchange I get the feeling
> that you haven't created and maintained a single extension that survived
> a single version upgrade of itself or PostgreSQL (in the latter case
> requiring code changes to
Hi,
I've been investigating hash indexes and have what I think is a clear
picture in my head, so time for discussion.
It would be very desirable to allow Hash Indexes to become Primary Key
Indexes, which requires both
amroutine->amcanunique = true;
amroutine->amcanmulticol = true;
Every othe
On 7/15/21 12:31 PM, Robert Eckhardt wrote:
I don’t know if this is a terrible flaw in pg_upgrade, it is a
terrible flaw in the overall Postgres experience.
+1 (that is the actual problem here)
--
Jan Wieck
On 7/15/21 12:25 PM, David G. Johnston wrote:
I would say that it probably should be "--upgrade-extension=aaa
--upgrade_extension=bbb" though if we are going to the effort to offer
something.
I am a bit confused here. From the previous exchange I get the feeling
that you haven't created and
On Thu, 15 Jul 2021 at 12:25, David G. Johnston
wrote:
> On Thu, Jul 15, 2021 at 9:16 AM Dave Cramer wrote:
>
>> Eh, and
>>> pg_upgrade [other switches] --upgrade-extensions
>>> sounds good too ...
>>>
>>
>> Ultimately I believe this is the solution, however we still need to teach
>> extension
On Thu, Jul 15, 2021 at 8:43 AM Dave Cramer
mailto:davecra...@gmail.com>> wrote:
On Thu, 15 Jul 2021 at 11:29, David G. Johnston
mailto:david.g.johns...@gmail.com>> wrote:
I’m not familiar with what hoops extensions jump through to facilitate upgrades
but even if it was as simple as “create ex
On Thu, Jul 15, 2021 at 6:47 PM Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2021-Jun-19, Tom Lane wrote:
> >> I'd say let's sit on the unnest code for a little bit and see what
> >> happens.
>
> > ... So, almost a month has gone by, and we still don't have multirange
> > unnest(). Looking at
On Thu, Jul 15, 2021 at 9:16 AM Dave Cramer wrote:
> Eh, and
>> pg_upgrade [other switches] --upgrade-extensions
>> sounds good too ...
>>
>
> Ultimately I believe this is the solution, however we still need to teach
> extensions how to upgrade themselves or emit a message saying they can't,
>
On Thu, 15 Jul 2021 at 12:13, Alvaro Herrera
wrote:
> On 2021-Jul-15, Alvaro Herrera wrote:
>
> > On 2021-Jul-15, Dave Cramer wrote:
> >
> > > Well IMHO the status quo is terrible. Perhaps you have a suggestion on
> how
> > > to make it better ?
> >
> > I thought the suggestion of having pg_upgra
On Thu, Jul 15, 2021 at 8:43 AM Dave Cramer wrote:
>
> On Thu, 15 Jul 2021 at 11:29, David G. Johnston <
> david.g.johns...@gmail.com> wrote:
>
>>
>> I’m not familiar with what hoops extensions jump through to facilitate
>> upgrades but even if it was as simple as “create extension upgrade” I
>>
On 2021-Jul-15, Alvaro Herrera wrote:
> On 2021-Jul-15, Dave Cramer wrote:
>
> > Well IMHO the status quo is terrible. Perhaps you have a suggestion on how
> > to make it better ?
>
> I thought the suggestion of having pg_upgrade emit a file with a list of
> all extensions needing upgrade in eac
On 2021-Jul-15, Dave Cramer wrote:
> Well IMHO the status quo is terrible. Perhaps you have a suggestion on how
> to make it better ?
I thought the suggestion of having pg_upgrade emit a file with a list of
all extensions needing upgrade in each database was a fairly decent one.
--
Álvaro Herre
Alvaro Herrera writes:
> On 2021-Jun-19, Tom Lane wrote:
>> I'd say let's sit on the unnest code for a little bit and see what
>> happens.
> ... So, almost a month has gone by, and we still don't have multirange
> unnest(). Looking at the open items list, it doesn't look like we have
> anything
The patch does not apply on Head anymore, could you rebase and post a
patch. I'm changing the status to "Waiting for Author".
Ok. I noticed. The patch got significantly broken by the watch pager
commit. I also have to enhance the added tests (per Peter request).
--
Fabien.
On Mon, Jul 12, 2021 at 11:47:27AM +1200, David Rowley wrote:
> On Mon, 12 Jul 2021 at 03:22, Justin Pryzby wrote:
> > |This is useful if only a small percentage of rows is checked on
> > |the inner side and is controlled by > |linkend="guc-enable-resultcache"/>.
>
> You
On Thu, 15 Jul 2021 at 11:29, David G. Johnston
wrote:
> On Thursday, July 15, 2021, Dave Cramer wrote:
>
>>
>> I'm thinking at this point we need something a bit more sophisticated like
>>
>> ALTER EXTENSION ... UPGRADE. And the extension knows how to upgrade
>> itself.
>>
>
> I’m not familiar
John Naylor writes:
> If no one else has anything, I think this is ready for commit.
Pushed, after adopting the suggestion to dispense with
isSharedObjectPinned.
regards, tom lane
On 2021/07/09 22:44, Masahiko Sawada wrote:
On Fri, Jul 9, 2021 at 3:26 PM Fujii Masao wrote:
As far as I read the code, keep using old API for foreign subtransaction doesn't
cause any actual bug. But it's just strange and half-baked to manage top and
sub transaction in the differenet layer
On 2021-Jun-19, Tom Lane wrote:
> Alexander Korotkov writes:
> > I also don't feel comfortable hurrying with unnest part to beta2.
> > According to the open items wiki page, there should be beta3. Does
> > unnest part have a chance for beta3?
>
> Hm. I'd prefer to avoid another forced initdb a
On Thursday, July 15, 2021, Dave Cramer wrote:
>
> I'm thinking at this point we need something a bit more sophisticated like
>
> ALTER EXTENSION ... UPGRADE. And the extension knows how to upgrade itself.
>
I’m not familiar with what hoops extensions jump through to facilitate
upgrades but even
On Thu, 15 Jul 2021 at 11:15, David G. Johnston
wrote:
> On Thursday, July 15, 2021, David G. Johnston
> wrote:
>
>> On Thursday, July 15, 2021, Dave Cramer wrote:
>>
>>>
>>> Install any custom shared object files (or DLLs) used by the old
>>> cluster
>>> into the new cluster, e.g.,
On Thu, Jul 15, 2021 at 7:49 AM Andrey Lepikhov
wrote:
> On 6/7/21 13:49, Hywel Carver wrote:
> > On Mon, Jul 5, 2021 at 2:20 PM Andrey Lepikhov
> > mailto:a.lepik...@postgrespro.ru>> wrote:
> > Looking through the email chain, a previous version of this patch added
> > ~0.6% to planning time in
On Thursday, July 15, 2021, Dave Cramer wrote:
> Well clearly my suggestion was not clear if you interpreted that as over
> writing them with versions from an older version of PostgreSQL.
>
>>
>>
Ignoring my original interpretation as being moot; the section immediately
preceding your edit says t
On Thursday, July 15, 2021, David G. Johnston
wrote:
> On Thursday, July 15, 2021, Dave Cramer wrote:
>
>>
>> Install any custom shared object files (or DLLs) used by the old
>> cluster
>> into the new cluster, e.g., pgcrypto.so,
>> whether they are from contrib
>> - or som
On Thu, 15 Jul 2021 at 11:01, David G. Johnston
wrote:
> On Thursday, July 15, 2021, Dave Cramer wrote:
>
>>
>> As a first step I propose the following
>>
>> diff --git a/doc/src/sgml/ref/pgupgrade.sgml
>> b/doc/src/sgml/ref/pgupgrade.sgml
>> index a83c63cd98..f747a4473a 100644
>> --- a/doc/src/
On Thursday, July 15, 2021, Dave Cramer wrote:
>
> As a first step I propose the following
>
> diff --git a/doc/src/sgml/ref/pgupgrade.sgml b/doc/src/sgml/ref/pgupgrade.
> sgml
> index a83c63cd98..f747a4473a 100644
> --- a/doc/src/sgml/ref/pgupgrade.sgml
> +++ b/doc/src/sgml/ref/pgupgrade.sgml
>
Le jeudi 15 juillet 2021, 16:19:23 CEST David Rowley a écrit :>
> Ronan's latest results plus John's make me think there's no need to
> separate out the node function as I did in v8. However, I do think v6
> could learn a little from v8. I think I'd rather see the sort method
> determined in Exec
On 6/7/21 13:49, Hywel Carver wrote:
On Mon, Jul 5, 2021 at 2:20 PM Andrey Lepikhov
mailto:a.lepik...@postgrespro.ru>> wrote:
Looking through the email chain, a previous version of this patch added
~0.6% to planning time in the worst case tested - does that meet the
"essentially free" requireme
On Fri, Jul 09, 2021 at 09:24:19PM +0530, Bharath Rupireddy wrote:
> I've always had a hard time distinguishing various types of
> processes/terms used in postgres. I look at the source code every time
> to understand them, yet I don't feel satisfied with my understanding.
> I request any hacker (h
Em qui., 15 de jul. de 2021 às 11:19, David Rowley
escreveu:
> On Fri, 16 Jul 2021 at 01:44, James Coleman wrote:
> >
> > On Wed, Jul 14, 2021 at 9:22 PM David Rowley
> wrote:
> > >
> > > On Thu, 15 Jul 2021 at 12:30, Ranier Vilela
> wrote:
> > > >
> > > > Em qua., 14 de jul. de 2021 às 21:21,
On Wed, Jul 14, 2021 at 09:45:12PM +0530, vignesh C wrote:
> On Sat, Jun 26, 2021 at 2:52 AM Bruce Momjian wrote:
> >
> > On Wed, May 26, 2021 at 05:02:01PM -0400, Bruce Momjian wrote:
> > > For these reasons, if we decide to go in the direction of using a
> > > non-LSN nonce, I no longer plan to
Magnus Hagander writes:
> Putting it in the tarball making script certainly works for me,
> though, if that's what people prefer. And that does away with the
> "clean" part as that one blows away the whole directory between each
> run.
Actually, we *have* to do it over there, because what that sc
On Thu, Jul 15, 2021 at 6:21 AM Ibrar Ahmed wrote:
> Based on last comments of Paul and David S I am changing the status to
> "Waiting on Author".
I thought the subject was quite out of date, so I sent my last patch
here:
https://www.postgresql.org/message-id/CA%2BrenyUApHgSZF9-nd-a0%2BOPGharLQ
On Tue, Jul 13, 2021 at 3:00 AM Stephen Frost wrote:
>
> Greetings,
>
> * Bharath Rupireddy (bharath.rupireddyforpostg...@gmail.com) wrote:
> > I've always had a hard time distinguishing various types of
> > processes/terms used in postgres. I look at the source code every time
> > to understand t
On Mon, Jul 12, 2021 at 9:26 PM Bharath Rupireddy
wrote:
>
> Hi,
>
> As suggested in [1], starting a new thread for discussing $subject
> separately. {pre, post}_auth_delay waiting logic currently uses
> pg_usleep which can't detect postmaster death. So, there are chances
> that some of the backe
On Mon, Jul 12, 2021 at 10:11 PM Bharath Rupireddy
wrote:
>
> On Mon, Jul 12, 2021 at 9:20 PM Fujii Masao
> wrote:
> > +
> > + Avoid Using non-negative Word in Error
> > Messages
> > +
> > +
> > +Do not use non-negative word in error messages as it
> > looks
> > +ambiguous. Inst
Em qua., 14 de jul. de 2021 às 22:22, David Rowley
escreveu:
> On Thu, 15 Jul 2021 at 12:30, Ranier Vilela wrote:
> >
> > Em qua., 14 de jul. de 2021 às 21:21, David Rowley
> escreveu:
> >> But, in v8 there is no additional branch, so no branch to mispredict.
> >> I don't really see how your ex
On Fri, 16 Jul 2021 at 01:44, James Coleman wrote:
>
> On Wed, Jul 14, 2021 at 9:22 PM David Rowley wrote:
> >
> > On Thu, 15 Jul 2021 at 12:30, Ranier Vilela wrote:
> > >
> > > Em qua., 14 de jul. de 2021 às 21:21, David Rowley
> > > escreveu:
> > >> But, in v8 there is no additional branch,
On Thu, Jul 15, 2021 at 3:53 PM Tom Lane wrote:
>
> Magnus Hagander writes:
> > On Thu, Jul 15, 2021 at 1:40 PM Josef Šimánek
> > wrote:
> >> The only problem I do see is adding "git" as a new dependency. That
> >> can potentially cause troubles.
>
> > But only for *creating* the tarballs, and
Magnus Hagander writes:
> On Thu, Jul 15, 2021 at 1:40 PM Josef Šimánek wrote:
>> The only problem I do see is adding "git" as a new dependency. That
>> can potentially cause troubles.
> But only for *creating* the tarballs, and not for using them. I'm not
> sure what the usecase would be to cr
On 2021/07/07 16:11, Kyotaro Horiguchi wrote:
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
function MarkBufferDirtyHint:
/
‐‐‐ Original Message ‐‐‐
On Thursday, July 15th, 2021 at 14:35, Michael Paquier
wrote:
> On Thu, Jul 15, 2021 at 08:35:27PM +0900, Michael Paquier wrote:
>
> > 2. curculio:
> > Looking at the OpenBSD code (usr.bin/compress/main.c), long options
> > are supported, where --version do
On Wed, Jul 14, 2021 at 9:22 PM David Rowley wrote:
>
> On Thu, 15 Jul 2021 at 12:30, Ranier Vilela wrote:
> >
> > Em qua., 14 de jul. de 2021 às 21:21, David Rowley
> > escreveu:
> >> But, in v8 there is no additional branch, so no branch to mispredict.
> >> I don't really see how your explana
On Fri, Apr 9, 2021 at 4:54 PM David Steele wrote:
> On 4/8/21 7:40 PM, Paul A Jungwirth wrote:
> > On Thu, Apr 8, 2021 at 7:22 AM David Steele wrote:
> >>
> >> Paul, you can submit to the next CF when you are ready with a new patch.
> >
> > Thanks David! I've made a lot of progress but still ne
On Thu, Jul 15, 2021 at 11:32 AM Andrey Lepikhov
wrote:
> On 5/7/21 23:15, Zhihong Yu wrote:
> > On Mon, Jul 5, 2021 at 2:57 AM Andrey Lepikhov
> > mailto:a.lepik...@postgrespro.ru>> wrote:
> > +* Can't imagine situation when join relation already
> > exists. But in
> > +*
Em qui., 15 de jul. de 2021 às 10:01, Aleksander Alekseev <
aleksan...@timescale.com> escreveu:
> Thanks, David.
>
> > I lost where. Can you show me?
>
> See the attached warnings.txt.
>
Thank you.
>
> > But the benchmark came from:
> > pgbench -i -p 5432 -d postgres
> > pgbench -c 50 -T 300 -S
On Thu, Jul 15, 2021 at 2:35 PM Etsuro Fujita
wrote:
> On Thu, Jul 15, 2021 at 4:17 AM Ibrar Ahmed wrote:
> > On Wed, Jul 14, 2021 at 1:41 AM Tom Lane wrote:
> >> Seems to just need an update of the expected-file to account for test
> >> cases added recently. (I take no position on whether the
Le mardi 13 juillet 2021, 06:44:12 CEST David Rowley a écrit :
> I've attached the updated patches.
The approach of building a pathkey for the first order by we find, then
appending to it as needed seems sensible but I'm a bit worried about users
starting to rely on this as an optimization. Even
Thanks, David.
> I lost where. Can you show me?
See the attached warnings.txt.
> But the benchmark came from:
> pgbench -i -p 5432 -d postgres
> pgbench -c 50 -T 300 -S -n
I'm afraid this tells nothing unless you also provide the
configuration files and the hardware description, and also some
i
Em qui., 15 de jul. de 2021 às 09:45, David Rowley
escreveu:
> On Thu, 15 Jul 2021 at 23:38, Aleksander Alekseev
> wrote:
> > I'm updating the status to "Ready for Committer".
>
> I think that might be a bit premature. I can't quite see how changing
> the pids List to a const List makes any sen
On Thu, 15 Jul 2021 at 23:38, Aleksander Alekseev
wrote:
> I'm updating the status to "Ready for Committer".
I think that might be a bit premature. I can't quite see how changing
the pids List to a const List makes any sense, especially when the
code goes and calls lappend_int() on it to assign
Hello Vignesh,
thank you for your interest!
From: vignesh C
Sent: Thursday, July 15, 2021 14:08
To: Arne Roland
Cc: Zhihong Yu; Alvaro Herrera; Pg Hackers
Subject: Re: Rename of triggers for partitioned tables
> The patch does not apply on Head anymore, could you rebase and post a
> patch. I'm
1 - 100 of 144 matches
Mail list logo
