On Tue, May 12, 2020 at 09:45:45PM -0300, Euler Taveira wrote:
>> In any case, it seems to me that the comment of
>> build_replindex_scan_key needs to be updated.
>>
>> * This is not generic routine, it expects the idxrel to be replication
>> * identity of a rel and meet all limitations
On Fri, 2020-05-15 at 10:11 +0530, Amit Kapila wrote:
> Okay, changed, and pushed.
Thank you!
Yours,
Laurenz Albe
On Fri, 15 May 2020 at 13:26, Muhammad Usama wrote:
>
>
>
> On Fri, May 15, 2020 at 7:20 AM Masahiko Sawada
> wrote:
>>
>> On Fri, 15 May 2020 at 03:08, Muhammad Usama wrote:
>> >
>> >
>> > Hi Sawada,
>> >
>> > I have just done some review and testing of the patches and have
>> > a couple of
On Thu, May 14, 2020 at 7:10 PM Laurenz Albe wrote:
>
> On Thu, 2020-05-14 at 15:11 +0530, Amit Kapila wrote:
> > LGTM. I have slightly modified the commit message, see if that looks
> > fine to you.
>
> Fine with me, thanks.
>
> > This breaks the cases where a REPEATABLE READ transaction could
On Fri, 15 May 2020 at 13:26, Amit Kapila wrote:
>
> On Fri, May 15, 2020 at 9:16 AM Masahiko Sawada
> wrote:
> >
> > Hi,
> >
> > I've attached the patch for $subject. The old comment seems to be
> > borrowed from WalSndShmemInit().
> >
>
> /*
> - * Allocate and initialize walsender-related
On Fri, May 15, 2020 at 9:16 AM Masahiko Sawada
wrote:
>
> Hi,
>
> I've attached the patch for $subject. The old comment seems to be
> borrowed from WalSndShmemInit().
>
/*
- * Allocate and initialize walsender-related shared memory.
+ * Allocate and initialize replication slots' shared memory.
On Fri, May 15, 2020 at 7:20 AM Masahiko Sawada <
masahiko.saw...@2ndquadrant.com> wrote:
> On Fri, 15 May 2020 at 03:08, Muhammad Usama wrote:
> >
> >
> > Hi Sawada,
> >
> > I have just done some review and testing of the patches and have
> > a couple of comments.
>
> Thank you for reviewing!
>
On Fri, May 15, 2020 at 1:51 AM Robert Haas wrote:
>
> On Thu, May 14, 2020 at 2:18 AM Amit Kapila wrote:
> > To support that, we need to consider a few things.
> > a. Currently, we increment the command counter each time we take a key
> > share lock on a tuple during trigger execution. I am
Hi,
I've attached the patch for $subject. The old comment seems to be
borrowed from WalSndShmemInit().
Regards,
--
Masahiko Sawadahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
fix_typo.patch
Description: Binary data
On Fri, May 15, 2020 at 11:58:55AM +0900, Michael Paquier wrote:
> Let's first take one problem at a time, as I can see that your patch
> 0002 is modifying a portion of what you added in 0001, and so let's
> try to remove this WIN32 stuff from pg_regress.c.
(Please note that this is not v13
On Mon, May 11, 2020 at 05:13:54PM +0900, Kyotaro Horiguchi wrote:
> Tablespace directory cleanup is not done for all testing
> targets. Actually it is not done for the tools under bin/ except
> pg_upgrade.
Let's first take one problem at a time, as I can see that your patch
0002 is modifying a
On Fri, 15 May 2020 at 03:08, Muhammad Usama wrote:
>
>
> Hi Sawada,
>
> I have just done some review and testing of the patches and have
> a couple of comments.
Thank you for reviewing!
>
> 1- IMHO the PREPARE TRANSACTION should always use 2PC even
> when the transaction has operated on a
On Thu, May 14, 2020 at 08:00:17PM -0400, Alvaro Herrera wrote:
> + ACID
> +
> +
> + Atomicity,
> + consistency,
> + isolation, and
> + durability.
> + A set of properties of database transactions intended to guarantee
> validity
> + in concurrent operation and
Thanks for reviewing!
On Wed, May 13, 2020 at 11:27 PM Fujii Masao
wrote:
> What about the attached patch based on yours?
It looks better.
Regards,
--
Atsushi Torikoshi
On Wed, May 13, 2020 at 10:02 PM Tom Lane wrote:
> Andy Fan writes:
> >> FWIW, I got a warning for jsonpath_gram.c.
>
> Ugh. Confirmed here on Fedora 30 (bison 3.0.5).
>
> > I just found this just serval minutes ago. Upgrading your bison to the
> > latest version (3.6) is ok. I'd like we have
At Thu, 14 May 2020 11:44:01 +0500, "Andrey M. Borodin"
wrote in
> > GetMultiXactIdMembers believes that 4 is successfully done if 2
> > returned valid offset, but actually that is not obvious.
> >
> > If we add a single giant lock just to isolate ,say,
> > GetMultiXactIdMember and
Thanks everybody. I have compiled together all the suggestions and the
result is in the attached patch. Some of it is of my own devising.
* I changed "instance", and made "cluster" be mostly a synonym of that.
* I removed "global SQL object" and made "SQL object" explain it.
* Added
Hi,
I wonder if anyone has plans to try again with this optimization in v14
cycle? The patches no longer apply thanks to the incremental sort patch,
but I suppose fixing that should not be extremely hard.
The 2020-07 CF is still a couple weeks away, but it'd be good to know if
there are any
On Thu, May 14, 2020 at 4:25 PM Michael Paquier wrote:
> On Wed, May 13, 2020 at 04:48:59PM +0900, Michael Paquier wrote:
> > Still not sure that's worth bothering. So, let's wait a couple of
> > days first to see if anybody has any comments, though I'd like to just
> > go with the simplest
On Wed, May 13, 2020 at 04:48:59PM +0900, Michael Paquier wrote:
> Still not sure that's worth bothering. So, let's wait a couple of
> days first to see if anybody has any comments, though I'd like to just
> go with the simplest solution at hand and remove only the duplicated
> comment about the
Em qui., 14 de mai. de 2020 às 19:49, Mark Dilger <
mark.dil...@enterprisedb.com> escreveu:
>
>
> > On May 14, 2020, at 11:34 AM, Ranier Vilela wrote:
> >
> > Certainly.
> > In the same file you can find the appropriate use of the API.
> > ItemPointerSet(>t_self, blkno, offnum);
>
> It took a
Em qui., 14 de mai. de 2020 às 19:23, Mark Dilger <
mark.dil...@enterprisedb.com> escreveu:
>
>
> > On May 14, 2020, at 11:34 AM, Ranier Vilela wrote:
> >
> > htup->t_ctid = target_tid;
> > htup->t_ctid = newtid;
> > Both target_tid and newtid are local variable, whe loss scope, memory is
>
> On May 14, 2020, at 11:34 AM, Ranier Vilela wrote:
>
> Certainly.
> In the same file you can find the appropriate use of the API.
> ItemPointerSet(>t_self, blkno, offnum);
It took a couple reads through your patch to figure out what you were trying to
accomplish, and I think you are
On 2020-May-14, Jeremy Schneider wrote:
> "Later stored it in the table" - I'd have to double check with the other
> team, but IIUC it was application pseudo-code like this:
>
> * execute SQL "select nextval()" and store result in
> my_local_variable_unique_id
> * commit
Yes, simply
> On May 14, 2020, at 11:34 AM, Ranier Vilela wrote:
>
> htup->t_ctid = target_tid;
> htup->t_ctid = newtid;
> Both target_tid and newtid are local variable, whe loss scope, memory is
> garbage.
Ok, thanks for the concrete example of what is bothering you.
In htup_details, I see that
On Wed, May 6, 2020 at 1:52 PM Jeremy Schneider wrote:
> The behavior we're observing is that a nextval() call in a committed
>
transaction is not crash-safe. This was discovered because some
> applications were using nextval() to get a guaranteed unique sequence
> number [or so they thought],
> On May 14, 2020, at 1:02 PM, Peter Eisentraut
> wrote:
>
> On 2020-05-11 19:21, Mark Dilger wrote:
>> 1) A new module, pg_amcheck, which includes a command line client for
>> checking a database or subset of a database. Internally it functions by
>> querying the database for a list of
On Thu, May 14, 2020 at 11:01:51PM +0200, Peter Eisentraut wrote:
> On 2020-05-12 02:41, Justin Pryzby wrote:
> > I'm not opposed to including it, but I think it's still true that the user
> > doesn't need to know in advance that the error message will be additionally
> > helpful in the event of
On Thu, May 14, 2020 at 2:02 PM Peter Eisentraut
wrote:
> On 2020-05-12 02:41, Justin Pryzby wrote:
> > I'm not opposed to including it, but I think it's still true that the user
> > doesn't need to know in advance that the error message will be additionally
> > helpful in the event of
On 2020-05-12 02:41, Justin Pryzby wrote:
I'm not opposed to including it, but I think it's still true that the user
doesn't need to know in advance that the error message will be additionally
helpful in the event of corruption. If we were to include more "error" items,
we might also include
On 2020-May-14, Tom Lane wrote:
> A case could be made for doing s/async/notify/ more widely in async.c;
> for instance it's odd that the struct protected by NotifyQueueLock
> didn't get renamed to NotifyQueueControl. But that seems a bit out
> of scope for the immediate problem, and anyway I'm
I wrote:
> Digging through the existing callers of SimpleLruInit, we have
> namecontrol locksubdir
> "async" AsyncCtlLock"pg_notify"
> "clog" CLogControlLock "pg_xact"
> "commit_timestamp"
On Thu, May 14, 2020 at 2:18 AM Amit Kapila wrote:
> To support that, we need to consider a few things.
> a. Currently, we increment the command counter each time we take a key
> share lock on a tuple during trigger execution. I am really not sure
> if this is required during Copy command
On Thu, May 14, 2020 at 3:58 PM Tom Lane wrote:
> I submit that at least part of the problem is precisely one of crappy
> naming. I didn't know what OldSerXidLock did either, until yesterday
> when I dug into the code to find out. If it's named something like
> "SerialSLRULock", then at least
On 2020-05-11 19:21, Mark Dilger wrote:
1) A new module, pg_amcheck, which includes a command line client for checking
a database or subset of a database. Internally it functions by querying the
database for a list of tables which are appropriate given the command line
switches, and then
Robert Haas writes:
> That being said, my view of this system is that it's good to document
> the wait events that we have, but also that there are almost certainly
> going to be cases where we can't say a whole lot more than "go read
> the code," or at least not without an awful lot of work.
Alvaro Herrera writes:
> On 2020-May-14, Robert Haas wrote:
>> If you mean that we shouldn't have the buildfarm run the proposed heap
>> corruption checker against heap pages full of randomly-generated
>> garbage, I tend to agree. Such a test wouldn't be very stable and
>> might fail in lots of
Robert Haas writes:
> I'm confused by why SLRU statistics are reported by messages sent to
> the stats collector rather than by just directly updating shared
> memory.
It would be better to consider that as an aspect of the WIP stats
collector redesign, rather than inventing a bespoke mechanism
On Thu, May 14, 2020 at 2:54 PM Tom Lane wrote:
> Well, we could solve this problem very easily by ripping out everything
> having to do with wait-state monitoring ... and personally I'd be a lot
> in favor of that, because I haven't seen anything about either the
> design or documentation of the
On 2020-May-14, Robert Haas wrote:
> I have a question about what you mean here by "arbitrarily."
>
> If you mean that we shouldn't have the buildfarm run the proposed heap
> corruption checker against heap pages full of randomly-generated
> garbage, I tend to agree. Such a test wouldn't be very
On Thu, May 14, 2020 at 11:33 AM Robert Haas wrote:
> I have seen that, I believe. I think it's more common to fail with
> errors about not being able to palloc>1GB, not being able to look up
> an xid or mxid, etc. but I am pretty sure I've seen multiple cases
> involving seg faults, too.
Robert Haas writes:
> I tend to prefer that modules register their own tranches rather than
> having a central table someplace, because I like the idea that the
> things that a particular module knows about are contained within its
> own source files and not spread all over the code base. I think
On Thu, May 14, 2020 at 2:27 AM Fujii Masao wrote:
> Therefore what we can do right now seems to make checkpointer report the SLRU
> stats while it's running. Other issues need more time to investigate...
> Thought?
I'm confused by why SLRU statistics are reported by messages sent to
the stats
On Wed, May 13, 2020 at 7:32 PM Alvaro Herrera wrote:
> I agree that this (a test tool that exercises our code against
> arbitrarily corrupted data pages) is not going to work as a test that
> all buildfarm members run -- it seems something for specialized
> buildfarm members to run, or even
Em qui., 14 de mai. de 2020 às 15:07, Tom Lane escreveu:
> Ranier Vilela writes:
> > The patch is primarily intended to correct the use of ItemPointerData.
>
> What do you think is being "corrected" here? It looks to me like
> just some random code rearrangements that aren't even clearly
>
Em qui., 14 de mai. de 2020 às 15:03, Mark Dilger <
mark.dil...@enterprisedb.com> escreveu:
>
>
> > On May 14, 2020, at 10:40 AM, Ranier Vilela wrote:
> >
> > Hi,
> > ItemPointerData, on the contrary, from what the name says,
> > it is not a pointer to a structure, but a structure in fact.
>
>
On Wed, May 13, 2020 at 5:33 PM Peter Geoghegan wrote:
> Do you recall seeing corruption resulting in segfaults in production?
I have seen that, I believe. I think it's more common to fail with
errors about not being able to palloc>1GB, not being able to look up
an xid or mxid, etc. but I am
On Tue, May 12, 2020 at 10:54 PM Tom Lane wrote:
> I don't actually understand why the LWLock tranche mechanism is designed
> the way it is. It seems to be intended to support different backends
> having different sets of LWLocks, but I fail to see why that's a good idea,
> or even useful at
On Tue, May 12, 2020 at 11:45 AM Masahiko Sawada <
masahiko.saw...@2ndquadrant.com> wrote:
> On Thu, 30 Apr 2020 at 20:43, Masahiko Sawada
> wrote:
> >
> > On Tue, 28 Apr 2020 at 19:37, Muhammad Usama wrote:
> > >
> > >
> > >
> > > On Wed, Apr 8, 2020 at 11:16 AM Masahiko Sawada <
>
Ranier Vilela writes:
> The patch is primarily intended to correct the use of ItemPointerData.
What do you think is being "corrected" here? It looks to me like
just some random code rearrangements that aren't even clearly
bug-free, let alone being stylistic improvements.
> On May 14, 2020, at 10:40 AM, Ranier Vilela wrote:
>
> Hi,
> ItemPointerData, on the contrary, from what the name says,
> it is not a pointer to a structure, but a structure in fact.
The project frequently uses the pattern
typedef struct FooData {
...
} FooData;
typedef FooData
Hi,
ItemPointerData, on the contrary, from what the name says,
it is not a pointer to a structure, but a structure in fact.
When assigning the name of the structure variable to a pointer, it may even
work,
but, it is not the right thing to do and it becomes a nightmare,
to discover that any other
(please, the list policy is bottom-posting to keep history clean, thanks).
On Thu, 14 May 2020 07:18:33 +0500
godjan • wrote:
> -> Why do you kill -9 your standby?
> Hi, it’s Jepsen test for our HA solution. It checks that we don’t lose data
> in such situation.
OK. This test is highly
On Thu, May 14, 2020 at 07:23:05AM +0200, Fabien COELHO wrote:
>
> Hello Bruce,
>
> > > > > * 34a0a81bfb
> > > >
> > > > We already have:
> > > >
> > > > Reformat tables containing function information for better
> > > > clarity (Tom Lane)
> > > >
> > > > so it seems it is
> On May 13, 2020, at 5:36 PM, Peter Geoghegan wrote:
>
> On Wed, May 13, 2020 at 5:18 PM Mark Dilger
> wrote:
>> I am not removing any assertions. I do not propose to remove any
>> assertions. When I talk about "hardening against assertions", that is not in
>> any way a proposal to
On Thu, 2020-05-14 at 15:11 +0530, Amit Kapila wrote:
> LGTM. I have slightly modified the commit message, see if that looks
> fine to you.
Fine with me, thanks.
> This breaks the cases where a REPEATABLE READ transaction could see an
> empty table if it repeats a COPY statement and somebody
Reviewing TLS changes for v13 I came across one change which I think might be
better off with a library qualified name. The libpq frontend sslpassword hook
added in 4dc63552109f65 is OpenSSL specific, but it has a very generic name:
PQsetSSLKeyPassHook(PQsslKeyPassHook_type hook);
This
On Wed, May 13, 2020 at 9:21 AM Amit Langote wrote:
>
> Maybe I am misunderstanding you, but the more the rows to update, the
> more overhead we will be paying with the new approach.
Yes, that's right. How much is that compared to the current planning
overhead. How many rows it takes for that
On Wed, May 13, 2020 at 6:58 AM Peter Geoghegan wrote:
> Shouldn't you close out the "Should we rename
> effective_io_concurrency?" Postgres 13 open item now?
Yeah, that doesn't really seem worth the churn. I'll move it to the
resolved list in a day or two if no one shows up to argue for a
Re: Thomas Munro
> > 17:28:59 Data directory:
> > /<>/build/src/test/ldap/tmp_check/t_001_auth_node_data/pgdata
>
> I know nothing about Debian package building so I could be missing
> something about how this works, but I wonder if our script variable
> handling is hygienic enough for paths
On 14/05/2020 11:07, Daniel Gustafsson wrote:
The comment which refers to the OpenSSL PEM password callback type has a small
typo, the type is called pem_password_cb and not pem_passwd_cb (which is an
easy typo to make to make since confusingly enough the functions in OpenSSL are
called
On Tue, Aug 27, 2019 at 6:35 AM Andres Freund wrote:
> On 2019-08-26 14:09:45 -0400, Robert Haas wrote:
> > There's a comment in htup.h which says:
> >
> > * * Separately allocated tuple: t_data points to a palloc'd chunk that
> > * is not adjacent to the HeapTupleData. (This case is
On Thu, May 14, 2020 at 1:30 PM Nikita Glukhov wrote:
> I agree that this patch is an improvement.
OK, I'm going to push this patch if no objections.
(Sergey doesn't seem to continue involvement in PostgreSQL
development, so it doesn't look like we should wait for him)
--
Alexander Korotkov
On 14.05.2020 12:52, Alexander Korotkov wrote:
Nikita, what do you think?
I agree that this patch is an improvement.
--
Nikita Glukhov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Hi!
On Tue, May 12, 2020 at 12:09 AM Alvaro Herrera
wrote:
> On 2020-Mar-08, Alexander Korotkov wrote:
>
> > Show opclass and opfamily related information in psql
> >
> > This commit provides psql commands for listing operator classes, operator
> > families and its contents in psql. New
On Thu, May 14, 2020 at 2:06 AM Laurenz Albe wrote:
>
> > I wonder why you have removed (rel != NULL) check?
>
> That was just unexcusable sloppiness, nothing more.
>
LGTM. I have slightly modified the commit message, see if that looks
fine to you.
--
With Regards,
Amit Kapila.
EnterpriseDB:
On Thu, May 14, 2020 at 11:07 AM Ranier Vilela wrote:
> Em qui., 14 de mai. de 2020 às 05:49, Amit Kapila
> escreveu:
>
>> On Wed, May 13, 2020 at 7:34 PM Tom Lane wrote:
>> >
>> > Amit Kapila writes:
>> > > Now that branches are tagged, I would like to commit and backpatch
>> > > this patch
Em qui., 14 de mai. de 2020 às 05:49, Amit Kapila
escreveu:
> On Wed, May 13, 2020 at 7:34 PM Tom Lane wrote:
> >
> > Amit Kapila writes:
> > > Now that branches are tagged, I would like to commit and backpatch
> > > this patch tomorrow unless there are any more comments/objections.
> >
> >
On Wed, May 13, 2020 at 7:34 PM Tom Lane wrote:
>
> Amit Kapila writes:
> > Now that branches are tagged, I would like to commit and backpatch
> > this patch tomorrow unless there are any more comments/objections.
>
> The "quiet period" is over as soon as the tags appear in git.
>
Pushed.
--
The comment which refers to the OpenSSL PEM password callback type has a small
typo, the type is called pem_password_cb and not pem_passwd_cb (which is an
easy typo to make to make since confusingly enough the functions in OpenSSL are
called SSL_*_passwd_cb). PFA patch to fix this.
cheers
On Thu, May 14, 2020 at 11:48 AM Amit Kapila wrote:
>
> On Thu, May 14, 2020 at 12:39 AM Robert Haas wrote:
> >
> > On Tue, May 12, 2020 at 1:01 AM Amit Kapila wrote:
> > > I don't understand why we need to do something special for combo CIDs
> > > if they are not generated during this
> 14 мая 2020 г., в 11:16, Kyotaro Horiguchi
> написал(а):
>
> At Thu, 14 May 2020 10:19:42 +0500, "Andrey M. Borodin"
> wrote in
I'm looking more at MultiXact and it seems to me that we have a race
condition there.
When we create a new MultiXact we do:
1.
On 2020/05/07 13:47, Fujii Masao wrote:
On 2020/05/03 1:59, Tomas Vondra wrote:
On Sat, May 02, 2020 at 12:55:00PM +0200, Tomas Vondra wrote:
On Sat, May 02, 2020 at 03:56:07PM +0900, Fujii Masao wrote:
...
Another thing I found is; pgstat_send_slru() should be called also by
other
At Thu, 14 May 2020 10:19:42 +0500, "Andrey M. Borodin"
wrote in
> >> I'm looking more at MultiXact and it seems to me that we have a race
> >> condition there.
> >>
> >> When we create a new MultiXact we do:
> >> 1. Generate new MultiXactId under MultiXactGenLock
> >> 2. Record new mxid with
At Wed, 13 May 2020 22:40:52 -0400, Bruce Momjian wrote in
> On Thu, May 14, 2020 at 09:51:41AM +0900, Kyotaro Horiguchi wrote:
> > At Wed, 13 May 2020 11:15:18 -0400, Bruce Momjian wrote
> > in
> > > On Wed, May 13, 2020 at 11:56:33AM +0900, Kyotaro Horiguchi wrote:
> > It is just an more
On Thu, May 14, 2020 at 12:39 AM Robert Haas wrote:
>
> On Tue, May 12, 2020 at 1:01 AM Amit Kapila wrote:
> > I don't understand why we need to do something special for combo CIDs
> > if they are not generated during this operation?
>
> Hmm. Well I guess if they're not being generated then we
76 matches
Mail list logo
