> > This has been hanging around for a while. I guess the reason it hasn't
> > got much attention is that on its own it's not terribly useful.
> > However, when you consider that it's a sensible prelude to setting a
> > more secure default for auth in initdb (I'd strongly advocate
> > SCRAM-SHA-256
Hi,
I wonder if it's worthwhile to fix the following not-so-friendly error message:
create index on foo ((row(a)));
ERROR: column "" has pseudo-type record
For example, the attached patch makes it this:
create index on foo ((row(a)));
ERROR: column "row" has pseudo-type record
Note that "row
At Tue, 17 Dec 2019 15:11:55 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Tue, 17 Dec 2019 11:46:03 +0900, Fujii Masao wrote
> in
> PREPARE. The attached does that and changes the if condition of
> cancel_before_shmem_exit into assertion.
The patch can cause removal of a wrong cleanup functi
On Mon, Dec 16, 2019 at 01:12:27PM +0100, Peter Eisentraut wrote:
> OK, here is an updated patch set that has all defines in one big Perl hash,
> and also requires that all symbols in pg_config.h.in are accounted for.
> (The indentation is from pgperltidy.)
The patch looks pretty clean. I have a
At Tue, 17 Dec 2019 11:46:03 +0900, Fujii Masao wrote
in
> On Tue, Dec 17, 2019 at 4:19 AM Robert Haas wrote:
> >
> > On Sun, Dec 15, 2019 at 8:44 PM Kyotaro Horiguchi
> > wrote:
> > > However I don't object to the restriction, couldn't we allow the
> > > cancel_before_shmem_exit to search for
Hi,
> I think that what we should actually do here is try to use simplehash.
>> Right now, it won't work for frontend code, but I posted some patches
>> to try to address that issue:
>>
>>
>> https://www.postgresql.org/message-id/CA%2BTgmob8oyh02NrZW%3DxCScB%2B5GyJ-jVowE3%2BTWTUmPF%3DFsGWTA%40mai
On Fri, Dec 13, 2019 at 10:28:33AM +0100, Josef Šimánek wrote:
> I have prepared patch to improve documentation for REINDEX. It
> should be more inline with another documentation pages.
>
> You can see the change applied in attached file. Patch can be found at
> https://github.com/simi/postgres/pu
On Mon, Dec 16, 2019 at 12:22:18PM +0900, Fujii Masao wrote:
> > +Detection of WAL records having references to invalid pages during
> > +recovery causes PostgreSQL to report
> > +an error, aborting the recovery. Setting
> > Well, that's not really an error. This triggers a
Hi Michael,
On Mon, Dec 9, 2019 at 11:57 AM Michael Paquier wrote:
> On Fri, Dec 06, 2019 at 06:03:12PM +0900, Amit Langote wrote:
> > Sorry I don't understand this. Do you mean we should rename the
> > routines left behind in tupconvert.c? For example,
> > convert_tuples_by_name() doesn't real
On Mon, Dec 16, 2019 at 03:09:51PM +0100, Laurenz Albe wrote:
> Code review is definitely part of software development practice, and
> reading and understanding the code of experienced developers can teach
> you a lot. Another nice aspect is that this is an activity that can easily
> be adjusted t
On Mon, Dec 16, 2019 at 07:57:10PM +0100, Juan José Santamaría Flecha wrote:
> If you want to address 2 unrelated issues, it makes little sense to use a
> single thread and 3 patches.
And if you actually group things together so as any individual looking
at your patches does not have to figure out
On Mon, Dec 16, 2019 at 8:53 AM Amit Kapila wrote:
>
> On Sun, Dec 15, 2019 at 8:51 AM Robert Haas wrote:
> >
> > On Thu, Dec 12, 2019 at 9:23 PM Amit Kapila wrote:
> > > Do you think we need such an Assert after having StaticAssert for
> > > (THRESHOLD_SUBTRANS_CLOG_OPT <= PGPROC_MAX_CACHED_SUB
On Mon, Dec 16, 2019 at 11:40:07AM +0900, Michael Paquier wrote:
> As the concepts behind cancel_pressed and CancelRequested are
> different, we need to keep cancel_pressed and make psql use it. And
> the callback used for WIN32 also needs to set the flag. I also think
> that we should do a better
Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> The idea is that if you connect over a Unix-domain socket and the local
> (effective) user is the same as the server's (effective) user, then
> access should be granted immediately without any checking of
> pg_hba.conf. Bec
On Mon, Dec 16, 2019 at 9:16 PM Jehan-Guillaume de Rorthais
wrote:
>
> On Mon, 16 Dec 2019 13:27:43 +0100
> Peter Eisentraut wrote:
>
> > On 2019-12-16 11:11, Amit Kapila wrote:
> > > I agree that this is a timing issue. I also don't see a way to write
> > > a reproducible test for this. Howeve
On Tue, Dec 17, 2019 at 03:57:56AM +, Ranier Vilela wrote:
> Windows Vista I believe.
> https://github.com/openssl/openssl/blob/master/crypto/rand/rand_win.c
> is the primary font and have more information.
So, this basically matches with what the MS documents tell us, and my
impression: this
On Thu, Aug 15, 2019 at 9:07 PM Peter Eisentraut
wrote:
>
> This is an implementation of the idea I mentioned in [0].
>
> The naming and description perhaps isn't ideal yet but it works in
> principle.
>
> The idea is that if you connect over a Unix-domain socket and the local
> (effective) user i
Andres Freund writes:
> For the specific case of RelationInitIndexAccessInfo(), allocations that
> commonly live for the rest of the backend's life and are frequent enough
> of them to matter, it might be worth micro-optimizing the
> allocations. E.g. not doing ~7 separate allocations within a few
De: Michael Paquier
Enviadas: Terça-feira, 17 de Dezembro de 2019 03:43
Para: Ranier Vilela
Cc: pgsql-hackers@lists.postgresql.org
Assunto: Re: [PATCH] Windows port add support to BCryptGenRandom
>And looking at this page, it is said that the minimum version
>supported by this function is Windows
On Mon, Dec 16, 2019 at 09:18:10PM +, Ranier Vilela wrote:
> According to microsoft documentation at:
> https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptgenrandom
> The function CryptGenRandom is deprecated, and may can be removed in future
> release.
> This patch a
De: Michael Paquier
Enviadas: Terça-feira, 17 de Dezembro de 2019 00:36
>Hmm. In the case of this logic, we are referring to the current end
>of WAL with endptr, and what you are calling the startptr is really
>the redo LSN of the last checkpoint in all the routines which are now
>confused with R
According to [1], windows does not support setenv, so for the patch to work
[3], would need to add it.
With the possibility of setenv going further [2], I am submitting in this
thread, the patch to add setenv support on the windows side, avoiding starting
a new trhead.
It is based on pre-existi
On Mon, Nov 25, 2019 at 9:22 AM Dilip Kumar wrote:
>
> In logical decoding, while sending the changes to the output plugin we
> need to arrange them in the LSN order. But, if there is only one
> transaction which is a very common case then we can avoid building the
> binary heap. A small patch i
On Tue, Dec 17, 2019 at 4:19 AM Robert Haas wrote:
>
> On Sun, Dec 15, 2019 at 8:44 PM Kyotaro Horiguchi
> wrote:
> > However I don't object to the restriction, couldn't we allow the
> > cancel_before_shmem_exit to search for the given entry looping over
> > the before_shmem_exit array? If we don
Hi,
On 2019-12-17 01:12:43 +0100, Tomas Vondra wrote:
> On Mon, Dec 16, 2019 at 03:35:12PM -0800, Andres Freund wrote:
> > But what if we had a new type of memory context that did not itself
> > manage memory underlying allocations, but instead did so via the parent?
> > If such a context tracked
Hi,
On 2019-12-16 18:58:36 -0500, Tom Lane wrote:
> Andres Freund writes:
> > But what if we had a new type of memory context that did not itself
> > manage memory underlying allocations, but instead did so via the parent?
> > If such a context tracked all the live allocations in some form of lis
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> It's been project policy since 2001 to avoid setenv(), and I notice
>> that src/port/win32env.c lacks support for setenv(), making it
>> pretty doubtful that the call has the semantics one would wish
>> on Windows.
> Yeah, that doe
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I noticed while investigating [1] that we have one single solitary
> use of setenv(3) in our code base, in secure_open_gssapi().
>
> It's been project policy since 2001 to avoid setenv(), and I notice
> that src/port/win32env.c lacks support for
From: Andres Freund
> We waste a lot of space due to all these small contexts. Even leaving
> aside the overhead of the context and its blocks - not insignificant -
> they are mostly between ~1/2 a ~1/4 empty.
>
>
> But what if we had a new type of memory context that did not itself
> manage mem
On Mon, Dec 09, 2019 at 05:11:10PM -0500, Tom Lane wrote:
> Alvaro Herrera writes:
>> We have a not-consistently-used convention that names in CamelCase are
>> used for global variables. Naming a function parameter in that style
>> seems pointlessly confusing. I would rather use redorecptr as To
On Mon, Dec 16, 2019 at 03:35:12PM -0800, Andres Freund wrote:
Hi,
I was responding to a question about postgres' per-backend memory usage,
making me look at the various contexts below CacheMemoryContext. There
is pretty much always a significant number of contexts below, one for
each index:
Andres Freund writes:
> I was responding to a question about postgres' per-backend memory usage,
> making me look at the various contexts below CacheMemoryContext. There
> is pretty much always a significant number of contexts below, one for
> each index:
> index info: 2048 total in 2 blocks;
Hi,
I was responding to a question about postgres' per-backend memory usage,
making me look at the various contexts below CacheMemoryContext. There
is pretty much always a significant number of contexts below, one for
each index:
CacheMemoryContext: 524288 total in 7 blocks; 8680 free (0 chunk
I noticed while investigating [1] that we have one single solitary
use of setenv(3) in our code base, in secure_open_gssapi().
It's been project policy since 2001 to avoid setenv(), and I notice
that src/port/win32env.c lacks support for setenv(), making it
pretty doubtful that the call has the se
On Tue, Dec 17, 2019 at 10:53 AM Tomas Vondra
wrote:
> Interestingly enough, I ran into the same ERROR (not sure if the same
> root cause) while investigating bug #16104 [1], i.e. on a much simpler
> query (single join).
>
> This This particular machine is a bit smaller (only 8GB of RAM and less
>
Ranier Vilela writes:
> According to the documentation at:
> https://wiki.sei.cmu.edu/confluence/display/c/POS34-C.+Do+not+call+putenv%28%29+with+a+pointer+to+an+automatic+variable+as+the+argument
> "Using setenv() is easier and consequently less error prone than using
> putenv()."
> putenv is pr
According to the documentation at:
https://wiki.sei.cmu.edu/confluence/display/c/POS34-C.+Do+not+call+putenv%28%29+with+a+pointer+to+an+automatic+variable+as+the+argument
"Using setenv() is easier and consequently less error prone than using
putenv()."
putenv is problematic and error prone, better
Mark Dilger writes:
> Please see the man page for putenv. Are you certain it is safe to
> free the string passed to putenv after putenv returns? I think this
> may be implemented differently on various platforms.
POSIX requires the behavior the glibc man page describes:
The putenv() functi
On Mon, Dec 16, 2019 at 12:49:06PM -0600, Justin Pryzby wrote:
A customer's report query hit this error.
ERROR: could not resize shared memory segment "/PostgreSQL.2011322019" to
134217728 bytes: No space left on device
I found:
https://www.postgresql.org/message-id/flat/CAEepm%3D2D_JGb8X%3DLa
Robert Haas writes:
> On Mon, Dec 16, 2019 at 12:00 PM Tom Lane wrote:
>> What I'd like, in order to make progress with the planner rewrite,
>> is that all four Vars in the tlist have varno 3, showing that
>> they are (potentially) semantically distinct from the Vars in
>> the JOIN ON clause (whi
On 12/16/19 1:22 PM, Ranier Vilela wrote:
Hi,
On exec.c, have two memory leaks, and a possible access beyond heap bounds, the
patch tries to fix them.
According to documentation at:
https://en.cppreference.com/w/c/experimental/dynamic/strdup
"The returned pointer must be passed to free to avo
Forget Mkvcbuild_v1.patch
regards,
Ranier Vileladiff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm
index 275f3bb699..33dc9bf5ad 100644
--- a/src/tools/msvc/Mkvcbuild.pm
+++ b/src/tools/msvc/Mkvcbuild.pm
@@ -65,7 +65,7 @@ my @frontend_uselibpgcommon = (
my $frontend_extralibs =
Hi,
On exec.c, have two memory leaks, and a possible access beyond heap bounds, the
patch tries to fix them.
According to documentation at:
https://en.cppreference.com/w/c/experimental/dynamic/strdup
"The returned pointer must be passed to free to avoid a memory leak. "
regards,
Ranier Vileladiff
Hi,
According to microsoft documentation at:
https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptgenrandom
The function CryptGenRandom is deprecated, and may can be removed in future
release.
This patch add support to use BCryptGenRandom.
BCryptGenRandom apparently works
Peter Eisentraut writes:
> I want to address the issue that calling a record-returning function
> always requires specifying a result column list, even though there are
> cases where the function could be self-aware enough to know the result
> column list of a particular call. For example, mo
On Mon, Dec 16, 2019 at 12:00 PM Tom Lane wrote:
> What I'd like, in order to make progress with the planner rewrite,
> is that all four Vars in the tlist have varno 3, showing that
> they are (potentially) semantically distinct from the Vars in
> the JOIN ON clause (which'd have varnos 1 and 2 in
On Sun, Dec 15, 2019 at 8:44 PM Kyotaro Horiguchi
wrote:
> However I don't object to the restriction, couldn't we allow the
> cancel_before_shmem_exit to search for the given entry looping over
> the before_shmem_exit array? If we don't do that, an assrtion is needed
> instead.
>
> Since pg_stop_b
Hi
po 16. 12. 2019 v 19:53 odesílatel Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> napsal:
> I want to address the issue that calling a record-returning function
> always requires specifying a result column list, even though there are
> cases where the function could be self-aware enough
On Mon, Dec 16, 2019 at 6:34 PM Ranier Vilela
wrote:
>
> Considering that postgres only supports windows versions that have the new
> API, it would be good to make the replace.
>
>
That is not actually the case. If you check the _WIN32_WINNT logic
in src/include/port/win32.h you can see that depe
I want to address the issue that calling a record-returning function
always requires specifying a result column list, even though there are
cases where the function could be self-aware enough to know the result
column list of a particular call. For example, most of the functions in
contrib/ta
A customer's report query hit this error.
ERROR: could not resize shared memory segment "/PostgreSQL.2011322019" to
134217728 bytes: No space left on device
I found:
https://www.postgresql.org/message-id/flat/CAEepm%3D2D_JGb8X%3DLa-0PX9C8dBX9%3Dj9wY%2By1-zDWkcJu0%3DBQbA%40mail.gmail.com
work_me
Hi,
According to microsoft documentation at:
https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptgenrandom
The function CryptGenRandom is deprecated, and may can be removed in future
release.
Considering that postgres only supports windows versions that have the new API,
To summarize possible enhancements to the current patch:
a- Don't hide failed attempted connections when defaults are used.
b- Attempt to connect via other common socket locations "/tmp".
c- New: Display the complete command used once a successful connection
has been made, so running plain psql wo
Tom, Chris, thank you for your responses.
> There's an excellent manpage for psql, which can also be found online:
> https://www.postgresql.org/docs/current/app-psql.html
> I'm a little confused as to why people don't read the documentation and
> turn to the 'net - that's bound to dig up a lot of
I started to think a little harder about the rough ideas I sketched
yesterday in [1] about making the planner deal with outer joins in
a less ad-hoc manner. One thing that emerged very quickly is that
I was misremembering how the parser creates join alias Vars.
Consider for example
create table t
Hi,
When exporting data with psql -c "..." >file or select ... \g file inside
psql,
post-creation output errors are silently ignored.
The problem can be seen easily by creating a small ramdisk and
filling it over capacity:
$ sudo mount -t tmpfs -o rw,size =1M tmpfs /mnt/ramdisk
$ psql -d postg
On Mon, 16 Dec 2019 13:27:43 +0100
Peter Eisentraut wrote:
> On 2019-12-16 11:11, Amit Kapila wrote:
> > I agree that this is a timing issue. I also don't see a way to write
> > a reproducible test for this. However, I could reproduce it via
> > debugger consistently by following the below step
On Fri, 13 Dec 2019 12:10:07 +0530
vignesh C wrote:
> On Fri, Dec 6, 2019 at 5:30 PM Amit Kapila wrote:
> >
> > On Mon, Nov 25, 2019 at 8:25 PM Jehan-Guillaume de Rorthais
> > wrote:
> > >
> > > On Wed, 6 Nov 2019 14:34:38 +0100
> > > Peter Eisentraut wrote:
> > >
> > > > On 2019-11-05 17:
John Naylor writes:
> Traditionally, when Bison generates the header file, it starts
> numbering named tokens at 258, so that numbers below 256 can be used
> for character literals. Then, during parsing, the external token
> number or character literal is mapped to Bison's internal token number
>
> On 5 Dec 2019, at 16:13, Robert Haas wrote:
>
> On Tue, Dec 3, 2019 at 6:41 PM Daniel Gustafsson wrote:
>> Attached is a rebased v14 patchset on top of maser. The Global Barriers
>> patch
>> is left as a prerequisite, but it will obviously be dropped, or be
>> significantly changed, once the
> On 16 Dec 2019, at 15:47, Alvaro Herrera wrote:
> Please, where did you find this "form"?
It seems to be from the wiki:
https://wiki.postgresql.org/wiki/Submitting_a_Patch#Patch_submission
cheers ./daniel
Hello,
On 2019-Dec-15, Tomas Zubiri wrote:
> Attached you will find my patch. Below you can find the form required
> for submitting patches.
>
> Project name: Not sure, psql?
> Uniquely identifiable file name, so we can tell the difference between
> your v1 and v24:
> [...]
Please, where did yo
Tomas Zubiri writes:
> The problem was that running the command psql without arguments
> returned the following
> error message:
> psql: could not connect to server: No such file or directory
> Is the server running locally and accepting
> connections on Unix domain socket "/var/run/postgr
On Sun, 2019-12-15 at 21:56 +0530, Utsav Parmar wrote:
> I'm Utsav Parmar, pursuing my B. Tech in Computer Engineering. I like to work
> on new technologies
> and am currently looking for open-source projects to contribute to.
>
> As it may turn out, I've got a college project in my curriculum th
Thomas Munro writes:
> Thanks. That didn't work but helped me find my way to
> C:\msys64\usr\bin. That version of bison complains about our grammar
> using deprecated directives, but that's a matter for another day.
Oh, that's a known issue on late-model bison. The problem is that the
option s
On 2019-12-14 03:13, Euler Taveira wrote:
Using the regression test example, table tab_fk_ref have columns id
and bid. If you add a trigger "BEFORE UPDATE OF bid" into subscriber
that fires on replica, it will always fire even if you are **not**
changed bid in publisher. In logical replication pr
On Thu, Dec 12, 2019 at 7:51 AM asaba.takan...@fujitsu.com <
asaba.takan...@fujitsu.com> wrote:
> 2. I have a question about copy meta-command.
> When I executed copy meta-command, output wasn't displayed.
> Does it correspond to copy meta-command?
>
>
Fixed
regards
Surafel
diff --git a/doc/src/s
## Tomas Zubiri (m...@tomaszubiri.com):
> The problem was that running the command psql without arguments
There's an excellent manpage for psql, which can also be found online:
https://www.postgresql.org/docs/current/app-psql.html
In there you'll find a section "Connecting to a Database", with t
On Mon, Dec 16, 2019 at 1:26 AM Thomas Munro wrote:
> On Wed, Nov 27, 2019 at 10:38 AM Peter Eisentraut
>
> Would you mind posting the full output of the above query (with
> showing) on a Windows system after running initdb with the -v2 patch,
> so we can see how the collations look?
>
>
Sure, y
On 2019-12-16 11:11, Amit Kapila wrote:
I agree that this is a timing issue. I also don't see a way to write
a reproducible test for this. However, I could reproduce it via
debugger consistently by following the below steps. I have updated a
few comments and commit messages in the attached pat
On 2019-12-16 01:26, Thomas Munro wrote:
While wondering about that, I noticed the "C.UTF-8" encoding (here on
a glibc system):
postgres=# \pset null
Null display is "".
postgres=# select collname, collprovider, collencoding, collcollate,
collctype, collversion from pg_collation ;
collname
On 2019-12-13 14:56, Tom Lane wrote:
One thing that disturbs me slightly is that the plan seems to be to
not mention variables in this list at all if they're to be undefined
on Windows. I realize that we've frequently done that by omission in
pg_config.h.win32, but I don't think it's good practi
On Mon, Dec 16, 2019 at 3:26 PM Amit Khandekar wrote:
>
> On Sat, 14 Dec 2019 at 11:59, Amit Kapila wrote:
> >
> > I have also made minor changes related to below code in patch:
> > - else if (readBytes != sizeof(ReorderBufferDiskChange))
> > +
> > + file->curOffset += readBytes;
> > +
> > + if (
To whom it may concern,
I'm Utsav Parmar, pursuing my B. Tech in Computer Engineering. I like to
work on new technologies and am currently looking for open-source projects
to contribute to.
As it may turn out, I've got a college project in my curriculum this
semester under “Software Development P
Hello, this week I decided to pursue an error a bit further than
usual, even after having fixed it for myself, I found that I could fix
it for future newcomers, especially those running
containerized distributions.
The problem was that running the command psql without arguments
returned the follow
On Fri, Dec 13, 2019 at 12:10 PM vignesh C wrote:
>
> I have made changes to fix the comment provided. The patch for the
> same is attached. Could not add a test case for this scenario is based
> on timing issue.
> Thoughts?
>
I agree that this is a timing issue. I also don't see a way to write
On Sat, 14 Dec 2019 at 11:59, Amit Kapila wrote:
>
> On Thu, Dec 12, 2019 at 9:50 PM Amit Khandekar wrote:
> >
> > Attached is a v4 patch that also addresses your code comments so far.
> > I have included the test case in 006_logical_decoding.pl. I observed
> > that the test case just adds only a
On 2019-12-16 05:39, Andrew Dunstan wrote:
On Wed, Oct 30, 2019 at 10:32 PM Peter Eisentraut
wrote:
To move this topic a long, I'll submit some preparatory patches in a
committable order.
First is the patch to deal with getpeereid() that was already included
in the previous patch series. Thi
On Fri, Dec 13, 2019 at 7:17 PM Etsuro Fujita wrote:
> I noticed this in the regression test while polishing the PWJ-enhancement
> patch:
>
> -- partitionwise join can not be applied for a join between list and range
> -- partitioned tables
> EXPLAIN (COSTS OFF)
> SELECT t1.a, t1.c, t2.b, t2.c FR
79 matches
Mail list logo
