On Sat, Nov 7, 2020 at 9:27 AM vignesh C wrote:
>
> Yes the test will fail if it takes more than the max_attempts as there
> is a like statement immediately after the loop:
> like($first_logfile, qr/\Q$expect_log_msg\E/,
> 'found expected log file content')
Fabien COELHO writes:
>> Any suggestions are welcome!
> Use ppoll, and start more threads but not too many?
Does ppoll exist on Windows?
There was a prior thread on this topic, which seems to have drifted off
into the sunset:
https://www.postgresql.org/message-id/flat/BL0PR1901MB1985F219C46C61
On Sat, Nov 07, 2020 at 12:49:43AM -0300, Alvaro Herrera wrote:
> In 0001, I propose changing messages that were introduced as different
> for parallel vacuum workers. Frankly I don't understand why we are
> bragging about the vacuum being done in a parallel worker; does the user
> care? It seem
On Sat, Nov 7, 2020 at 10:00 AM Peter Smith wrote:
>
> Hello Osumi-san.
>
> I have checked the latest v17 patch w.r.t. to my previous comments.
>
> The v17 patch applies cleanly.
>
> make check is successful.
>
> The regenerated docs look OK.
>
> I have no further review comments, so have flagged
Hello Osumi-san.
I have checked the latest v17 patch w.r.t. to my previous comments.
The v17 patch applies cleanly.
make check is successful.
The regenerated docs look OK.
I have no further review comments, so have flagged this v17 as "ready
for committer" - https://commitfest.postgresql.org/3
On Thu, Nov 5, 2020 at 9:50 AM Bharath Rupireddy
wrote:
>
> On Thu, Nov 5, 2020 at 7:55 AM Euler Taveira
> wrote:
> >
> > No. Don't worry with translations during the development. Make sure to
> > follow
> > the instructions provided here [1]. Translations are coordinated in a
> > different
>
I propose to apply the following changes to messages in pg13.
In 0001, I propose changing messages that were introduced as different
for parallel vacuum workers. Frankly I don't understand why we are
bragging about the vacuum being done in a parallel worker; does the user
care? It seems to me t
Tomas Vondra writes:
> We should probably include instructions what to do about the BRIN
> data corruption fixed by 7577dd8480 - a query to list might be
> affected by the bug and should be rebuilt.
Do you have some suggested text?
regards, tom lane
On 2020-Oct-24, Justin Pryzby wrote:
> On Fri, Oct 23, 2020 at 12:29:40AM -0500, Justin Pryzby wrote:
> > Now that I look, it seems like this is calling PQexec(), which sends a
> > single,
> > "simple" libpq message with:
> > |CREATE TABLE ..; ALTER TABLE .. ATTACH PARTITION;
> > ..which is tran
On Thu, Nov 05, 2020 at 09:16:10AM +0900, Michael Paquier wrote:
> No arguments against this point either. If you consider all that, the
> switch can be done with the attached, with the change for pg_dump
> included. I have reorganized the list in variable_is_guc_list_quote()
> alphabetically whi
On Sat, Nov 07, 2020 at 09:29:30AM +0900, Michael Paquier wrote:
> Thanks John. Both look right to me. I'll apply both in a bit.
Done that now. Just for the note: you forgot to run pgperltidy.
--
Michael
signature.asc
Description: PGP signature
On Fri, Nov 06, 2020 at 06:20:00PM -0400, John Naylor wrote:
> There is a latent bug in the way code pairs for recomposition are sorted
> due to a copy-pasto on my part. Makes no difference now, but it could in
> the future. While looking, it seems pg_bswap.h should actually be
> backend-only. Bot
On Fri, 06 Nov 2020 17:07:12 -0500
Tom Lane wrote:
> See
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=c66a3225e07b5098a796f24588a6b81bfdedd2fd
>
> Please send any corrections by Sunday.
>
We should probably include instructions what to do about the BRIN
data corrupti
On Thu, 5 Nov 2020 18:16:04 -0300
Alvaro Herrera wrote:
> On 2020-Nov-05, Tomas Vondra wrote:
>
> > On 11/5/20 6:17 PM, Alvaro Herrera wrote:
>
> > > There are recent changes in vacuum for temp tables (commit
> > > 94bc27b57680?) that would maybe make this stable enough, without
> > > having
On 2020-Nov-06, Michael Paquier wrote:
> On Thu, Nov 05, 2020 at 02:36:06PM -0600, Justin Pryzby wrote:
> > Seems to be missing.
>
> Any code paths calling index_get_partition() is in tablecmds.c,
> involving commands that are not that hot with such lookups, but that
> could be an issue if this g
Hi, hacker
I met an error as below when I use ecpg
a.pgc:5: ERROR: invalid bit string literal
a.pgc:5: ERROR: internal error: unreachable state; please report this to
the test source is attached.
After investigating the code, I think the process of pgc.l is:
Step 1: {xbstart}, addlitchar('b
There is a latent bug in the way code pairs for recomposition are sorted
due to a copy-pasto on my part. Makes no difference now, but it could in
the future. While looking, it seems pg_bswap.h should actually be
backend-only. Both fixed in the attached.
--
John Naylor
EnterpriseDB: http://www.ent
See
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=c66a3225e07b5098a796f24588a6b81bfdedd2fd
Please send any corrections by Sunday.
regards, tom lane
Hello Marina,
While trying to test a patch that adds a synchronization barrier in pgbench
[1] on Windows,
Thanks for trying that, I do not have a windows setup for testing, and the
sync code I wrote for Windows is basically blind coding:-(
I found that since the commit "Use ppoll(2), if a
Hello
> I'm wondering if it's safe to allow restore_command to be emptied during
> archive recovery. Even when it's emptied, archive recovery can proceed
> by reading WAL files from pg_wal directory. This is the same behavior as
> when restore_command is set to, e.g., /bin/false.
I am always conf
On Nov 4, 2020, at 5:09 AM, Daniel Gustafsson wrote:
> (sorry for slow response). You are absolutely right, the has_password flag
> must be tracked per connection in PGconn. The attached v17 implements this as
> well a frontend bugfix which caused dropped connections and some smaller
> fixups
Hi Marina,
Nice catch.
>rc/bin/pgbench/pgbench.c, the function add_socket_to_set:
>if (fd < 0 || fd >= FD_SETSIZE)
>{
>/*
>* Doing a hard exit here is a bit grotty, but it doesn't seem worth
>* complicating the API to make it less grotty.
>*/
>pg_log_fatal("too many client connections for select()
Hello, hackers!
While trying to test a patch that adds a synchronization barrier in
pgbench [1] on Windows, I found that since the commit "Use ppoll(2), if
available, to wait for input in pgbench." [2] I cannot use a large
number of client connections in pgbench on my Windows virtual machines
On Fri, Nov 06, 2020 at 01:51:26PM +, Anastasia Lubennikova wrote:
> I wonder why this patch hangs so long without a review. Maybe it will help to
> move discussion forward, if you provide more examples of queries that can
> benefit from this imporovement?
Thanks for looking.
The explanatio
On 2020/11/05 12:12, Kyotaro Horiguchi wrote:
At Wed, 4 Nov 2020 21:16:29 +0530, Bharath Rupireddy
wrote in
On Wed, Nov 4, 2020 at 2:36 PM Fujii Masao wrote:
Regarding other two patches, I think that it's better to use MyLatch
rather than MyProc->procLatch or walrcv->latch in WaitLatch()
On 2020/11/06 21:36, Sergei Kornilov wrote:
Hello
Currently when restore_command is not set, archive recovery fails
at the beginning. With the patch, how should we treat the case where
retore_command is reset to empty during archive recovery? We should
reject that change of restore_command?
Status update for a commitfest entry.
This thread was inactive for a while and from the latest messages, I see that
the patch needs some further work.
So I move it to "Waiting on Author".
The new status of this patch is: Waiting on Author
On 2020/10/31 2:06, John Naylor wrote:
On Fri, Oct 30, 2020 at 12:48 PM Tom Lane mailto:t...@sss.pgh.pa.us>> wrote:
John Naylor mailto:john.nay...@enterprisedb.com>> writes:
> Okay, along those lines here's a patch using "this view" in a new
paragraph
> for simplicity.
B
Status update for a commitfest entry.
According to CFbot this patch fails to apply. Richard, can you send an update,
please?
Also, I see that the thread was inactive for a while.
Are you going to continue this work? I think it would be helpful, if you could
write a short recap about current sta
On Fri, Nov 6, 2020 at 4:54 PM Thomas Munro wrote:
> On Fri, Nov 6, 2020 at 9:48 PM Andy Fan wrote:
> > I have 2 ideas about this. One is in the Read Committed level, we can
> advance xmin
> > aggressively. suppose it started at t1, and complete a query at t2. the
> xmin should
> > be t1 curr
Status update for a commitfest entry
According to cfbot, the patch fails to apply. Could you please send a rebased
version?
I wonder why this patch hangs so long without a review. Maybe it will help to
move discussion forward, if you provide more examples of queries that can
benefit from this
On Fri, Nov 06, 2020 at 01:31:44PM +0100, Magnus Hagander wrote:
> I think the defensive-in-code instead of defensive-in-docs is a really
> strong argument, so I have pushed it as such.
Fine by me. Thanks for the commit.
--
Michael
signature.asc
Description: PGP signature
On Thu, Nov 5, 2020 at 9:16 AM David Pirotte wrote:
>
> On Tue, Nov 3, 2020 at 7:19 AM Dave Cramer wrote:
>>
>> David,
>>
>> On Thu, 24 Sep 2020 at 00:22, Michael Paquier wrote:
>>>
>>> On Tue, Sep 08, 2020 at 12:18:23PM -0700, Andres Freund wrote:
>>> > A test verifying that a non-transactional
On Thu, Nov 5, 2020 at 2:20 PM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2020-11-05 12:59, John Naylor wrote:
> > I think we're talking past eachother. Here's a concrete example:
> >
> > #define BKI_ROWTYPE_OID(oid,oidmacro)
> > #define DECLARE_TOAST(name,toastoid,indexoid)
Hello
> Currently when restore_command is not set, archive recovery fails
> at the beginning. With the patch, how should we treat the case where
> retore_command is reset to empty during archive recovery? We should
> reject that change of restore_command?
Good point. I think we should reject that
On Fri, Nov 6, 2020 at 12:08 PM Daniel Gustafsson wrote:
>
> > On 6 Nov 2020, at 00:36, Michael Paquier wrote:
>
> > I still don't see the point of this extra complexity, as
> > USE_OPENSSL_RANDOM implies USE_OPENSSL,
>
> As long as we're sure that we'll remember to fix this when that assumption
On Tue, Aug 18, 2020 at 3:22 AM Andres Freund wrote:
>
> Hi,
>
> On 2020-08-17 14:05:37 +0300, Heikki Linnakangas wrote:
> > On 14/04/2020 22:04, Teja Mupparti wrote:
> > > Thanks Kyotaro and Masahiko for the feedback. I think there is a
> > > consensus on the critical-section around truncate,
> >
On Fri, Nov 6, 2020 at 11:10 AM Thomas Munro wrote:
>
> On Fri, Nov 6, 2020 at 5:09 PM Amit Kapila wrote:
> >
> > It is not very clear to me how this argument applies to the patch
> > in-discussion where we are relying on the cached value of blocks
> > during recovery. I understand your point tha
On Thu, Nov 5, 2020 at 2:13 PM Kyotaro Horiguchi
wrote:
>
> At Thu, 5 Nov 2020 11:48:24 +0530, Amit Kapila
> wrote in
> > On Thu, Nov 5, 2020 at 9:44 AM Masahiko Sawada
> > wrote:
> > >
> > > On Thu, Nov 5, 2020 at 11:18 AM Kyotaro Horiguchi
> > > wrote:
> > > > As another issue, just replace
> On 6 Nov 2020, at 00:36, Michael Paquier wrote:
> I still don't see the point of this extra complexity, as
> USE_OPENSSL_RANDOM implies USE_OPENSSL,
As long as we're sure that we'll remember to fix this when that assumption no
longer holds (intentional or unintentional) then it's fine to skip
On Fri, Nov 6, 2020 at 9:48 PM Andy Fan wrote:
> I have 2 ideas about this. One is in the Read Committed level, we can
> advance xmin
> aggressively. suppose it started at t1, and complete a query at t2. the xmin
> should
> be t1 currently. Can we advance the xmin to t2 since it is read comm
Since the impact of the long transaction is huge in postgresql, for example
a long transaction by incident, tables may become very huge and it can't
become small again even the transaction is completed unless a vacuum full
is used.
I have 2 ideas about this. One is in the Read Committed level,
On 06/11/2020 10:24, Kyotaro Horiguchi wrote:
Thank you for the comment!
First off, I thought that I managed to eliminate the degradation
observed on the previous versions, but significant degradation (1.1%
slower) is still seen in on case.
One thing to keep in mind with micro-benchmarks like
me> First off, I thought that I managed to eliminate the degradation
me> observed on the previous versions, but significant degradation (1.1%
me> slower) is still seen in on case.
While trying benchmarking with many patterns, I noticed that it slows
down catcache search significantly to call CatCa
Thank you for the comment!
First off, I thought that I managed to eliminate the degradation
observed on the previous versions, but significant degradation (1.1%
slower) is still seen in on case.
Anyway, before sending the new patch, let met just answer for the
comments.
At Thu, 5 Nov 2020 11:09:
Hello
On Friday, November 6, 2020 2:25 PM Peter Smith wrote:
> > > Yes, OK. But it might be simpler still just to it like:
> > > "CREATE OR REPLACE TRIGGER works only for replacing a regular (not
> > > constraint) trigger with another regular trigger."
> > Yeah, this kind of supplementary words
46 matches
Mail list logo
