Dear Hackers.
> Specifically in this case- I went back and tried to figure out what
> other database systems have an "encrypt EVERYTHING" option. I didn't
> have much luck finding one though. So I think we need to ask ourselves-
> the "check box" that we're trying to check off with TDE, do the
On Thu, Aug 22, 2019 at 09:06:06PM +0900, Kyotaro Horiguchi wrote:
> At Mon, 19 Aug 2019 23:03:14 -0700, Noah Misch wrote in
> <20190820060314.ga3086...@rfd.leadboat.com>
> > On Mon, Aug 19, 2019 at 06:59:59PM +0900, Kyotaro Horiguchi wrote:
> > > At Sat, 17 Aug 2019 20:52:30 -0700, Noah Misch w
On Sat, Aug 24, 2019 at 11:23:32PM +0800, movead...@highgo.ca wrote:
> Thanks and I just do it, it is
> https://commitfest.postgresql.org/24/2258/
Your patch has forgotten to update the alternate output in
float4-misrounded-input.out.
--
Michael
signature.asc
Description: PGP signature
On Sun, Aug 25, 2019 at 05:10:47PM +0200, Julien Rouhaud wrote:
> I did some searching, and oid2name.c is also missing this.
And pgbench, no?
--
Michael
signature.asc
Description: PGP signature
On Sun, Aug 25, 2019 at 10:34:29PM +0200, David Fetter wrote:
> I meant to ask whether, in addition to pg_dump and pg_rewind, there
> are other things that should ignore statement_timeout settings.
Sure. Please note that I am not sure if it is worth bothering about
all the code paths which emit S
Hi Tom,
> On 19/08/2019, at 3:00 AM, Tom Lane wrote:
>
> Peter Eisentraut writes:
>> What I don't like about the syntax is that it kind of breaks the
>> notional processing model of INSERT in a fundamental way.
>
> Agreed. I really don't like that this only works for a VALUES-like case
> (and
I'm not sure but maybe this is useful ?
|(gdb) p VfdCache[2397]
|$9 = {fd = -1, fdstate = 0, resowner = 0x24f93e0, nextFree = 2393,
lruMoreRecently = 0, lruLessRecently = 2360, seekPos = 73016512, fileSize = 0,
fileName = 0x0, fileFlags = 2, fileMode = 384}
Knowing this report, very possibly th
Dear Hackers.
It's been a long time since I sent a mail.
On Sat, Aug 24, 2019 at 9:27 AM Bruce Momjian wrote:
> On Fri, Aug 23, 2019 at 10:35:17AM -0400, Stephen Frost wrote:
> > > Agreed. The features of other databases are a clear source for what we
> > > should consider and run through the u
On Mon, Aug 26, 2019 at 01:09:19PM +1200, Thomas Munro wrote:
> On Sun, Aug 25, 2019 at 3:15 PM Peter Geoghegan wrote:
> > I was reminded of this issue from last year, which also appeared to
> > involve BufFileClose() and a double-free:
> >
> > https://postgr.es/m/87y3hmee19@news-spur.riddles.
On 25/08/2019 21:14, Tom Lane wrote:
> Vik Fearing writes:
>> EXPLAIN (COSTS OFF) SELECT * FROM pg_am WHERE amname LIKE '%t%';
>> QUERY PLAN
>> ---
>> Seq Scan on pg_am
>> Filter: (amname ~~ '%t%'::text)
>> (2 rows)
>> Why don't we conver
On Mon, Aug 26, 2019 at 1:44 PM Justin Pryzby wrote:
> On Mon, Aug 26, 2019 at 01:09:19PM +1200, Thomas Munro wrote:
> > On Sun, Aug 25, 2019 at 3:15 PM Peter Geoghegan wrote:
> > > I was reminded of this issue from last year, which also appeared to
> > > involve BufFileClose() and a double-free:
On Mon, 26 Aug 2019 at 01:42, Tom Lane wrote:
> Vik Fearing writes:
> > On 25/08/2019 18:59, Tom Lane wrote:
> >> Vik Fearing writes:
> >>> Is there a reason why the serial pseudotypes still behave as they did
> >>> pre-v10 and don't map to GENERATED BY DEFAULT AS IDENTITY these days?
>
> >> Ba
On Sun, Aug 25, 2019 at 3:15 PM Peter Geoghegan wrote:
> I was reminded of this issue from last year, which also appeared to
> involve BufFileClose() and a double-free:
>
> https://postgr.es/m/87y3hmee19@news-spur.riddles.org.uk
>
> That was a BufFile that was under the control of a tuplestore
On Sun, Aug 25, 2019 at 1:56 PM Tom Lane wrote:
> Hmm, so that would exclude the optimization for numeric, float4/float8,
> and nondeterministic text collations. Anything else?
Any pseudo-type whose output function could possibly be dependent on
the output function of another type (in case it ha
On Sun, Aug 25, 2019 at 2:55 PM Peter Geoghegan wrote:
> I suppose that we'd add something new to CREATE OPERATOR CLASS to make
> this work? My instinct is to avoid adding things that are only
> meaningful for a single AM to interfaces like CREATE OPERATOR CLASS,
> but the system already has numer
On Sun, Aug 25, 2019 at 2:40 PM Tom Lane wrote:
> > I was thinking of stashing an "equality is precise" flag in the
> > metapage of each nbtree index, since we will only determine this once,
> > at CREATE INDEX time.
>
> Sure.
I suppose that we'd add something new to CREATE OPERATOR CLASS to make
Peter Geoghegan writes:
> I was thinking of stashing an "equality is precise" flag in the
> metapage of each nbtree index, since we will only determine this once,
> at CREATE INDEX time.
Sure.
> That would make it fairly natural for the
> planner to ask about the "equality is precise"-ness of th
On Sun, Aug 25, 2019 at 2:18 PM Peter Geoghegan wrote:
> > Indeed, we run up against this sort of thing all the time in, eg, planner
> > optimizations. I think some sort of "equality is precise" indicator
> > would be really useful for a lot of things.
>
> The case that I happened to think of was
I wrote a prototype quality patch that implements what I call
"classic" suffix truncation. That is, the patch makes nbtree leaf page
splits generate a short prefix datum for the new high key for
variable-length datatypes, generated using new opclass infrastructure.
This is useful for string-like da
Peter Geoghegan writes:
> We don't need to be able to assume that binary equality is exactly the
> same thing as opclass equality at the level of individual tuples. We
> only need to be able to assume that the user cannot observe any
> differences when they are shown output for two datums that are
I wrote:
> I'm very hesitant to apply a volatile-qualification approach to
> eliminate those issues, for fear of pessimizing performance-critical
> code on more modern platforms. I wonder whether there is a reasonable
> way to tell at compile time if we have a platform with 80-bit math.
Hmmm ...
On Sun, Aug 25, 2019 at 04:30:38PM -0400, Tom Lane wrote:
> David Fetter writes:
> > Is pg_rewind the only thing that this hits?
>
> pg_dump has forced statement_timeout to 0 for ages. If pg_rewind
> is also likely to have a long-running transaction, I don't see any
> good reason for it not to d
David Fetter writes:
> Is pg_rewind the only thing that this hits?
pg_dump has forced statement_timeout to 0 for ages. If pg_rewind
is also likely to have a long-running transaction, I don't see any
good reason for it not to do likewise.
regards, tom lane
Anastasia's nbtree deduplication patch [1] has an open problem that I
would like to find a solution for: it currently assumes that there is
no difference between binary equality and opclass equality. That won't
work for opclasses such as btree/numeric, because compressing equal
numeric datums could
Andrew Dunstan writes:
> On 8/20/19 8:59 AM, Peter Eisentraut wrote:
>> Running the regression tests on mingw32, I get the following diff in
>> circle.out:
>> - | <(3,5),0> | <(1,2),3> | 0.60555127546399
>> + | <(3,5),0> | <(1,2),3> | 0.605551275463989
> I complained
On Fri, Aug 23, 2019 at 10:05:02AM +0200, Alexander Kukushkin wrote:
> Hi,
>
> It is quite common to set a global statement_timeout to a few seconds
> (or minutes) in postgresql.conf in order to avoid hitting a production
> server with slow/bad queries.
True!
Is pg_rewind the only thing that thi
> I've pushed your original patch (with some comment-tweaking).
> It seems unlikely to break anything.
Thanks!
Quentin Rameau writes:
> Another better way, I think, to fix this is to check for optopt
> instead, which would be set to the option which caused the error, which
> if empty means there isn't an error.
Meh. We don't use optopt at all today, and I don't especially want
to start doing so. A patch
> Another better way, I think, to fix this is to check for optopt
> instead, which would be set to the option which caused the error, which
> if empty means there isn't an error.
>
> Patch attached.
Actually OpenBSD seems to set optopt to '?' by default, so the updated
attached patch ensure we st
Vik Fearing writes:
> EXPLAIN (COSTS OFF) SELECT * FROM pg_am WHERE amname LIKE '%t%';
> QUERY PLAN
> ---
> Seq Scan on pg_am
> Filter: (amname ~~ '%t%'::text)
> (2 rows)
> Why don't we convert that back to LIKE?
Trying to do so would m
> > “If the option was the last character in the string pointed to by an
> > element of argv, then optarg shall contain the next element of argv,
> > and optind shall be incremented by 2. If the resulting value of optind
> > is greater than argc, this indicates a missing option-argument, and
> > ge
On Sun, Aug 25, 2019 at 8:39 PM Julien Rouhaud wrote:
> On Sun, Aug 25, 2019 at 4:30 PM Tom Lane wrote:
> >
> > Peter Eisentraut writes:
> > > I propose the attached patch to make pg_upgrade error out on too many
> > > command-line arguments. This makes it match the behavior of other
> > > Pos
This is a minor gripe in the grand scheme of things, but I'm a little
annoyed that we accept standard SQL but then don't spit it back out.
For example:
```
EXPLAIN (COSTS OFF) SELECT * FROM pg_am WHERE amname LIKE '%t%';
QUERY PLAN
---
On 25/08/2019 19:42, Tom Lane wrote:
> Vik Fearing writes:
>> On 25/08/2019 18:59, Tom Lane wrote:
>>> Vik Fearing writes:
Is there a reason why the serial pseudotypes still behave as they did
pre-v10 and don't map to GENERATED BY DEFAULT AS IDENTITY these days?
>>> Backwards compatibil
Vik Fearing writes:
> On 25/08/2019 18:59, Tom Lane wrote:
>> Vik Fearing writes:
>>> Is there a reason why the serial pseudotypes still behave as they did
>>> pre-v10 and don't map to GENERATED BY DEFAULT AS IDENTITY these days?
>> Backwards compatibility?
> With what?
Applications that expec
On 25/08/2019 18:59, Tom Lane wrote:
> Vik Fearing writes:
>> Is there a reason why the serial pseudotypes still behave as they did
>> pre-v10 and don't map to GENERATED BY DEFAULT AS IDENTITY these days?
> Backwards compatibility?
With what? We don't support downgrading and I wouldn't expect t
Vik Fearing writes:
> Is there a reason why the serial pseudotypes still behave as they did
> pre-v10 and don't map to GENERATED BY DEFAULT AS IDENTITY these days?
Backwards compatibility?
regards, tom lane
Quentin Rameau writes:
>> Um ... so how would control get there with optind too large?
> That's from the getopt specification[0]:
> “If the option was the last character in the string pointed to by an
> element of argv, then optarg shall contain the next element of argv,
> and optind shall be in
Is there a reason why the serial pseudotypes still behave as they did
pre-v10 and don't map to GENERATED BY DEFAULT AS IDENTITY these days?
I'm hoping it's just an oversight and I can help "fix" it, but maybe
there is an actual reason for it to be this way?
--
Vik Fearing
> > Um ... so how would control get there with optind too large?
Sorry, I missed the simple explanation for that:
As option 'h' is missing an argument, getopt(_long) returns the
character '?' which is switched on through variable c, and the program
jumps to the '?' case handling.
Hello Tom,
> > When passing an argument option with a missing argument, strcmp
> > would be called with the argv terminating NULL.
>
> Um ... so how would control get there with optind too large?
That's from the getopt specification[0]:
“If the option was the last character in the string poin
On Sun, Aug 25, 2019 at 4:30 PM Tom Lane wrote:
>
> Peter Eisentraut writes:
> > I propose the attached patch to make pg_upgrade error out on too many
> > command-line arguments. This makes it match the behavior of other
> > PostgreSQL programs.
>
> +1 ... are we missing this anywhere else?
I d
Peter Eisentraut writes:
> I can confirm that SET extra_float_digits TO -1 in circle.sql fixes the
> original complaint.
Cool. It did on dromedary, but that doesn't necessarily prove much
about other compilers :-(
> I don't understand this stuff enough to be able to provide a good source
> code
Quentin Rameau writes:
> When passing an argument option with a missing argument, strcmp would
> be called with the argv terminating NULL.
Um ... so how would control get there with optind too large?
What test case/platform are you considering?
(There really shouldn't be *any* case where getopt
Peter Eisentraut writes:
> I propose the attached patch to make pg_upgrade error out on too many
> command-line arguments. This makes it match the behavior of other
> PostgreSQL programs.
+1 ... are we missing this anywhere else?
regards, tom lane
When passing an argument option with a missing argument, strcmp would
be called with the argv terminating NULL.
---
src/bin/psql/startup.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/bin/psql/startup.c b/src/bin/psql/startup.c
index 4730c73396..cffbfc864e 100644
--
Hello
Thank you! It seems the most appropriate option for this test is to change
@contrib_excludes
Done in attached patch, will check appveyor reaction.
regards, Sergeidiff --git a/src/test/modules/Makefile b/src/test/modules/Makefile
index 60d6d7be1b..ab3fc91fae 100644
--- a/src/test/modules/Ma
The following bug has been logged on the website:
Bug reference: 15977
Logged by: mtlh kdvt
Email address: emuser20140...@gmail.com
PostgreSQL version: 12beta3
Operating system: Windows
Description:
When a ROLLBACK AND CHAIN command is executed in the implicit transaction
On Sun, Aug 25, 2019 at 10:52 AM Peter Eisentraut
wrote:
>
> I propose the attached patch to make pg_upgrade error out on too many
> command-line arguments. This makes it match the behavior of other
> PostgreSQL programs.
>
> See [0] for an issue related to the lack of this check:
+1
I propose the attached patch to make pg_upgrade error out on too many
command-line arguments. This makes it match the behavior of other
PostgreSQL programs.
See [0] for an issue related to the lack of this check:
[0]:
https://www.postgresql.org/message-id/871sdbzizp.fsf%40jsievers.enova.com
--
On 2019-08-23 15:50, Tom Lane wrote:
> Peter Eisentraut writes:
>> The circle.sql file already has SET extra_float_digits TO 0, and a few
>> other files have other settings with different values. Are we content
>> to use various numbers until it works in each case, or should we try to
>> use some
51 matches
Mail list logo
