Hi,
commit a31ad27fc5d introduced required_relids field. By default, it
links to the clause_relids.
It works good while we do not modify clause_relids or required_relids.
But in the case of modification such initialization demands us to
remember, that this field is shared. And we need to do bm
On Thu, 11 Jul 2019 at 10:22, David Rowley wrote:
> So it seems that the plan is to insist that TIDs are tuple identifiers
> for all table AMs, for now. If that changes in the future, then so be
> it, but I don't think that's cause for delaying any work on TID Range
> Scans. Also from scanning a
On Mon, Jul 15, 2019 at 5:12 PM Tom Lane wrote:
> Thomas Munro writes:
> > 42 Doc
> [...] I see a lot more than 42 such commit messages in the past
> year, so not sure what you were counting?
I would have tried to exclude the first line messages if I'd thought
of that. But anyway, the r
Hello pgdevs,
sorry if this has been already discussed, but G did not yield anything
convincing about that.
While looking at HASH partitioning and creating a few ones, it occured to
me that while RANGE and LIST partitions cannot be guessed easily, it would
be easy to derive HASH partitione
On Fri, Jul 12, 2019 at 1:25 PM Thomas Munro wrote:
> Here is a small patch extracted from the undo log patch set that I'd
> like to discuss separately and commit soon. [...]
Pushed.
--
Thomas Munro
https://enterprisedb.com
Thomas Munro writes:
> Here are the tags that people have used in the past year, in commit messages:
> 763 Author
>9 Authors
> 144 Backpatch-through
> 55 Backpatch
> 14 Bug
> 14 Co-authored-by
> 27 Diagnosed-By
> 1593 Discussion
> 42 Doc
> 284
Hello Thomas,
+extern bool pg_strtoint64(const char *str, bool errorOK, int64 *result);
+extern uint64 pg_strtouint64(const char *str, char **endptr, int base);
One of these things is not like the other.
Indeed.
I agree that it is unfortunate, and it was bothering me a little as well.
Let'
On Fri, Jul 12, 2019 at 1:25 PM Michael Paquier wrote:
> On Thu, Jul 11, 2019 at 09:44:07AM -0400, Tom Lane wrote:
> > I thought we *did* have an agreement, to wit using
> >
> > Discussion: https://postgr.es/m/
> >
> > to link to relevant mail thread(s). Some people use more tags
> > but that see
Hi
pá 12. 7. 2019 v 15:10 odesílatel Fabien COELHO
napsal:
>
> Hello Pavel,
>
> > rebased patch attached
>
> I prefer patches with a number rather than a date, if possible. For one
> thing, there may be several updates in one day.
>
> About this version (20180708, probably v3): applies cleanly,
Thanks, Thomas.
On Mon, Jul 8, 2019 at 6:47 AM Thomas Munro wrote:
> On Mon, Feb 18, 2019 at 7:39 PM Hubert Zhang wrote:
> > Based on the assumption we use smgr as hook position, hook API option1
> or option2 which is better?
> > Or we could find some balanced API between option1 and option2?
>
Hi
I noticed the documentation for pg_hba.conf:
https://www.postgresql.org/docs/current/auth-pg-hba-conf.html
says:
you will need to signal the postmaster (using pg_ctl reload or kill -HUP) to
make it re-read the file.
It would be useful to mention pg_reload_conf() as another option
Hello hackers,
Here's a quick update at the end of the second week of CF1.
status | w1 | w2
+-+-
Committed | 32 | 41
Moved to next CF | 5 | 6
Needs review | 146 | 128
Ready for Committer| 7 | 9
Rejec
On 7/14/19 9:40 PM, Peter Eisentraut wrote:
On 2019-07-13 17:13, Fabien COELHO wrote:
What about avoiding a redirection with something like:
Datum (* const pg_random_uuid)(PG_FUNCTION_ARGS) = gen_random_uuid;
That seems very confusing.
Dunno. Possibly. The user does not have to look at the
On Tue, May 14, 2019 at 12:54 PM Andrew Alsup wrote:
> On 3/5/19 5:35 PM, Nikita Glukhov wrote:
> > Attached 36th version of the patches rebased onto jsonpath v36.
> While testing this patch a found a few issues:
>
> [1] I was not able to apply the patch to the current HEAD. However, it
> applies
On Sun, Jul 14, 2019 at 02:38:40PM -0400, James Coleman wrote:
On Tue, Jul 9, 2019 at 10:54 AM Tomas Vondra
wrote:
On Tue, Jul 09, 2019 at 09:28:42AM -0400, James Coleman wrote:
>On Mon, Jul 8, 2019 at 9:37 PM Tomas Vondra
> wrote:
>>
>> On Mon, Jul 08, 2019 at 12:07:06PM -0400, James Coleman
On Mon, 15 Jul 2019 at 11:46, Thomas Munro wrote:
>
> On Tue, Jul 2, 2019 at 12:17 AM Sergei Kornilov wrote:
> > This change is discussed as open item for pg12. Seems we have nor
> > objections nor agreement. I attached updated version due merge conflict.
> >
> > > Per discussion started here:
On Sun, Jul 14, 2019 at 12:13:45PM -0400, Joe Conway wrote:
On 7/13/19 5:58 PM, Tomas Vondra wrote:
On Sat, Jul 13, 2019 at 02:41:34PM -0400, Joe Conway wrote:
[2] also says provides additional support for AES 256. It also mentions
CBC versus XTS -- I came across this elsewhere and it bears dis
On Mon, 15 Jul 2019 at 12:59, Thomas Munro wrote:
> In the category "doing more tricks with our existing btrees", which
> includes all that difficult stuff like skip scans and incremental
> sort, here's an easier planner-only one: if you have a unique index
> on (a) possibly "including" (b) and y
On Sun, Jul 14, 2019 at 3:22 AM Fabien COELHO wrote:
> Here is the updated patch on which I checked "make check-world".
Thanks! So, we're moving pg_strtouint64() to a place where frontend
code can use it, and getting rid of some duplication. I like it. I
wanted this once before myself[1].
+ex
OK, attached is a sequence of WIP fixes for the issues discussed here.
1) using column-specific collations (instead of type/default ones)
The collations patch is pretty simple, but I'm not sure it actually does
the right thing, particularly during estimation where it uses collation
from the Var
Hello,
In the category "doing more tricks with our existing btrees", which
includes all that difficult stuff like skip scans and incremental
sort, here's an easier planner-only one: if you have a unique index
on (a) possibly "including" (b) and you have a pathkey (a, b), you can
use an index [onl
On Tue, Jul 2, 2019 at 12:17 AM Sergei Kornilov wrote:
> This change is discussed as open item for pg12. Seems we have nor objections
> nor agreement. I attached updated version due merge conflict.
>
> > Per discussion started here:
> > https://www.postgresql.org/message-id/CA%2BTgmoZWSLUjVcc9KB
On Mon, Jul 15, 2019 at 7:56 AM Konstantin Knizhnik
wrote:
> Can you please explain me more precisely how to reproduce the problem
> (how to configure postgres and how to connect to it)?
Maybe it's just that postmaster.c's ConnCreate() always allocates a
struct for port->gss if the feature is ena
On Mon, Jul 1, 2019 at 6:21 AM Thomas Munro wrote:
>
> Hi Matheus,
>
> As the commitfest is starting, could you please send a rebased patch?
>
>
Hi all,
Glad to start working on that again... Follows the rebased version (at
5925e55498).
Thank you all.
Best regards,
--
Matheus de Oliveira
diff
On 14.07.2019 8:03, Thomas Munro wrote:
On Tue, Jul 9, 2019 at 8:30 AM Konstantin Knizhnik
wrote:
Rebased version of the patch is attached.
Thanks for including nice documentation in the patch, which gives a
good overview of what's going on. I haven't read any code yet, but I
took it for a
On Tue, Jul 9, 2019 at 10:54 AM Tomas Vondra
wrote:
>
> On Tue, Jul 09, 2019 at 09:28:42AM -0400, James Coleman wrote:
> >On Mon, Jul 8, 2019 at 9:37 PM Tomas Vondra
> > wrote:
> >>
> >> On Mon, Jul 08, 2019 at 12:07:06PM -0400, James Coleman wrote:
> >> > ...
> >> >
> >> >I guess I'm still not fo
I think making ERROR a reserved word is a terrible idea, and we don't
need it for this feature anyway. Use a new option in the parenthesized
options list instead.
error_limit being an integer, please don't use it as a boolean:
if (cstate->error_limit)
...
Add an explicit comparison to zer
On 7/13/19 5:58 PM, Tomas Vondra wrote:
> On Sat, Jul 13, 2019 at 02:41:34PM -0400, Joe Conway wrote:
>>[2] also says provides additional support for AES 256. It also mentions
>>CBC versus XTS -- I came across this elsewhere and it bears discussion:
>>
>>"Currently, the following pairs of encryptio
On 2019-07-13 17:13, Fabien COELHO wrote:
>>> What about avoiding a redirection with something like:
>>>
>>> Datum (* const pg_random_uuid)(PG_FUNCTION_ARGS) = gen_random_uuid;
>>
>> That seems very confusing.
>
> Dunno. Possibly. The user does not have to look at the implementation, and
> probab
On 7/13/19 2:41 PM, Joe Conway wrote:
> [2]
> https://www.postgresql.org/message-id/20190708194733.cztnwhqge4acepzw%40development
BTW I managed to mess up this link. This is what I intended to link
there (from Tomas):
[2] https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html
I am sure
Hi
> Sergei> PS: my note about comments in tests from my previous review is
> Sergei> actual too.
>
> I changed the comment when committing it.
Great, thank you!
regards, Sergei
> "Sergei" == Sergei Kornilov writes:
Sergei> PS: my note about comments in tests from my previous review is
Sergei> actual too.
I changed the comment when committing it.
--
Andrew (irc:RhodiumToad)
Hello Karl,
It really works in research papers: "Theorem X can be proven by
applying Proposition Y. See Figure 2 for details. Algorithm Z
describes whatever, which is listed in Table W..."
I've not thought about it before but I suppose the difference is between
declarative and descriptive,
Hello Thomas,
Thanks for the feedback.
+ the account branch has a 15% probability to be in the same branch
as the teller (unless
I would say "... has a 15% probability of being in the same ...". The
same wording appears further down in the comment.
Fixed.
I see that the parameters you p
Hi,
sorry for answering a bit later than I hoped. Here is my review so far:
Contents
==
This patch starts to address in my opinion one of COPY's shortcoming, which
is error handling. PK and exclusion errors are taken care of, but not
(yet?) other types of errors.
Documentation is upd
35 matches
Mail list logo
