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 ./danie
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.
--
W
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.
> >
> > The
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 t
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: h
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 commands
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
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 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 depr
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 SSL_*_pas
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 like
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
renam
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 ove
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 I
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 tru
> 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 remove
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 cov
(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 usefu
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 e
> 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 *
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 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 <
> masahiko.saw
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 all.
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 pret
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.
>
> Th
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
> bug-
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 somet
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 co
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 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. Unfortun
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 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
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 f
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 lo
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.
Can
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 call
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 so
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 executi
I wrote:
> Digging through the existing callers of SimpleLruInit, we have
> namecontrol locksubdir
> "async" AsyncCtlLock"pg_notify"
> "clog" CLogControlLock "pg_xact"
> "commit_timestamp"
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 n
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 the
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 corruption.
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 co
> 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 ta
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], t
> 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 struc
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 inse
> 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(&heapTuple->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
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
> garba
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(&heapTuple->t_self, blkno, offnum);
>
> It
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 s
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 solu
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 plan
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 definition
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 RecordNewMul
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
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 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 eve
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 singl
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 po
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 materi
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 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 rea
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 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, 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 shar
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 s
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 co
On Fri, 2020-05-15 at 10:11 +0530, Amit Kapila wrote:
> Okay, changed, and pushed.
Thank you!
Yours,
Laurenz Albe
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 associate
Hi,
I have just noticed that pg_bsd_indent complains since
-Wimplicit-fallthrough=3 has been added to the default set of switches
if available.
Something like the attached is fine to take care of those warnings,
but what's our current patching policy for this tool?
Thanks,
--
Michael
diff --git
On 2020/04/15 5:33, Andrew Dunstan wrote:
On 4/14/20 4:09 PM, Alvaro Herrera wrote:
On 2020-Apr-14, Andrew Dunstan wrote:
OK, but I think if we're putting a timestamp string in ISO-8601 format
in the manifest it should be in UTC / Zulu time, precisely to avoid
these issues. If that's too m
On Fri, May 15, 2020 at 8:03 AM Michael Paquier wrote:
>
> Hi,
>
> I have just noticed that pg_bsd_indent complains since
> -Wimplicit-fallthrough=3 has been added to the default set of switches
> if available.
Oh Indeed.
> Something like the attached is fine to take care of those warnings,
> bu
On 2020/05/05 12:16, Bruce Momjian wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:
https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.
Many
74 matches
Mail list logo
