Re: automating pg_config.h.win32 maintenance

On Thu, Dec 19, 2019 at 08:31:05AM +0100, Peter Eisentraut wrote: > On 2019-12-19 04:59, Michael Paquier wrote: >> This part needs a comment. Like it is the equivalent of what >> src/common/'s Makefile does or something like that? > > This was meant to be addressed by >

Re: automating pg_config.h.win32 maintenance

On 2019-12-19 04:59, Michael Paquier wrote: On Tue, Dec 17, 2019 at 11:56:17AM +0100, Peter Eisentraut wrote: Yeah, good idea. Attached patch is refactored so all three header files managed by AC_CONFIG_HEADERS are processed the same way. Looks good. I just have one comment. + # XXX +

Re: non-exclusive backup cleanup is mildly broken

On Wed, Dec 18, 2019 at 07:43:43AM -0500, Robert Haas wrote: > On Tue, Dec 17, 2019 at 11:36 PM Fujii Masao wrote: >> If pg_abort_backup callback function can be called safely even when >> the backup is not in progress, we can just use the global variable like >> pg_abort_backup_registered to

Re: logical decoding : exceeded maxAllocatedDescs for .spill files

On Wed, Dec 18, 2019 at 12:34 PM Amit Khandekar wrote: > > On Tue, 17 Dec 2019 at 17:40, Amit Khandekar wrote: > > By the way, the backport patch is turning out to be simpler. It's > > because in pre-12 versions, the file offset is part of the Vfd > > structure, so all the offset handling is not

RE: [Proposal] Add accumulated statistics

On Sun, Dec 1, 2019 at 1:10 AM, Michael Paquier wrote: > On Wed, Oct 30, 2019 at 05:55:28AM +, > imai(dot)yoshikazu(at)fujitsu(dot)com wrote: > > And here is the patch which counts the wait event and measuring the wait > > event time. It is currently like POC and has several things to be

Re: [HACKERS] Block level parallel vacuum

On Wed, 18 Dec 2019 at 12:07, Amit Kapila wrote: > > [please trim extra text before responding] > > On Wed, Dec 18, 2019 at 12:01 PM Mahendra Singh wrote: > > > > On Tue, 10 Dec 2019 at 00:30, Mahendra Singh wrote: > > > > > > > > > 3. > > > After v35 patch, vacuum.sql regression test is taking

Re: [HACKERS] Block level parallel vacuum

On Wed, 18 Dec 2019 at 19:06, Amit Kapila wrote: > > On Wed, Dec 18, 2019 at 12:04 PM Amit Kapila wrote: > > > > On Wed, Dec 18, 2019 at 11:46 AM Masahiko Sawada > > wrote: > > > > > > On Wed, 18 Dec 2019 at 15:03, Amit Kapila wrote: > > > > > > > > I was analyzing your changes related to

Re: unsupportable composite type partition keys

On Wed, Dec 18, 2019 at 10:38 PM Tom Lane wrote: > Amit Langote writes: > > On Wed, Dec 18, 2019 at 2:12 AM Tom Lane wrote: > >> Hm. Seems like the restrictions here ought to be just about the same > >> as on index columns, no? > > > We also need to disallow self-referencing composite type in

Re: Clean up some old cruft related to Windows

At Thu, 19 Dec 2019 11:15:26 +0900, Michael Paquier wrote in > Hi all, > > As discussed here, there is in the tree a couple of things related to > past versions of Windows: > https://www.postgresql.org/message-id/201912180219susv254.ge1...@paquier.xyz > > So I have been looking at that more

Re: automating pg_config.h.win32 maintenance

On Tue, Dec 17, 2019 at 11:56:17AM +0100, Peter Eisentraut wrote: > Yeah, good idea. Attached patch is refactored so all three header files > managed by AC_CONFIG_HEADERS are processed the same way. Looks good. I just have one comment. + # XXX + open(my $f, '>>', 'src/include/pg_config.h')

Re: Read Uncommitted regression test coverage

On 12/18/19 2:17 PM, Tom Lane wrote: Mark Dilger writes: The one in src/test/isolation doesn't look very comprehensive.  I'd at least expect a test that verifies you don't get a syntax error when you request READ UNCOMMITTED isolation from SQL. The attached patch set adds a modicum of

Re: [HACKERS] Block level parallel vacuum

On Thu, 19 Dec 2019 at 11:47, Amit Kapila wrote: > > On Wed, Dec 18, 2019 at 6:02 PM Amit Kapila wrote: > > > > On Wed, Dec 18, 2019 at 3:36 PM Amit Kapila wrote: > > > > > > Few other comments which I have not fixed: > > > > > > > +/* interface function to support parallel vacuum */ > > +

Re: Proposal: Global Index

On Mon, Nov 25, 2019 at 03:44:39PM -0800, Jeremy Schneider wrote: > On 11/25/19 15:05, Jeremy Schneider wrote: > > ... the cost of doing the individual index lookups across 180 > > partitions (and 180 indexes) was very high, so they stored max and min > > txn id per partition and would generate a

Re: [HACKERS] pg_shmem_allocations view

At Wed, 18 Dec 2019 12:30:51 -0500, Robert Haas wrote in > On Wed, Dec 18, 2019 at 12:06 PM Tom Lane wrote: > > It seems like it'd be worth subdividing "" into the actual > > anonymous allocations and the allocator overhead (which is both > > padding and whatever the shmem allocator itself

Re: [HACKERS] Block level parallel vacuum

On Thu, Dec 19, 2019 at 8:17 AM Amit Kapila wrote: > > On Wed, Dec 18, 2019 at 6:02 PM Amit Kapila wrote: > > > > On Wed, Dec 18, 2019 at 3:36 PM Amit Kapila wrote: > > > > > > Few other comments which I have not fixed: > > > > > > > +/* interface function to support parallel vacuum */ > >

Re: [HACKERS] Block level parallel vacuum

On Wed, Dec 18, 2019 at 6:02 PM Amit Kapila wrote: > > On Wed, Dec 18, 2019 at 3:36 PM Amit Kapila wrote: > > > > Few other comments which I have not fixed: > > > > +/* interface function to support parallel vacuum */ > +amestimateparallelvacuum_function amestimateparallelvacuum; /* >

Re: Read Uncommitted

Hi, On 2019-12-18 18:06:21 +, Simon Riggs wrote: > On Wed, 18 Dec 2019 at 17:35, Robert Haas wrote: > > > On Wed, Dec 18, 2019 at 10:18 AM Simon Riggs > > wrote: > > > This was my first concern when I thought about it, but I realised that > > by taking a snapshot and then calculating xmin

Re: remove unnecessary table_open/close from makeArrayTypeName

On Wed, Dec 18, 2019 at 05:22:06PM -0500, Tom Lane wrote: > +1, but please collapse up the whitespace too. +1. -- Michael signature.asc Description: PGP signature

Clean up some old cruft related to Windows

Hi all, As discussed here, there is in the tree a couple of things related to past versions of Windows: https://www.postgresql.org/message-id/20191218021954.ge1...@paquier.xyz So I have been looking at that more closely, and found more: - MIN_WINNT can be removed from win32.h thanks to d9dd406

Re: Setting min/max TLS protocol in clientside libpq

Hello, On 2019/12/04 2:37, Daniel Gustafsson wrote: The attached patch implements two new connection string variables for minimum and maximum TLS protocol version, mimicking how it's done in the backend. This does duplicate a bit of code from be-secure-openssl.c to cope with older versions of

Re: [PATCH] Windows port add support to BCryptGenRandom

On Wed, Dec 18, 2019 at 09:52:07AM +0100, Juan José Santamaría Flecha wrote: > +1, there is a reference in [1] about that is possible to build PostgreSQL > using the GNU compiler tools for older versions of Windows, that should be > also updated. There is actually a little bit more which could be

Re: Read Uncommitted

On Wed, 18 Dec 2019 at 19:29, Heikki Linnakangas wrote: > On 18/12/2019 20:46, Mark Dilger wrote: > > On 12/18/19 10:06 AM, Simon Riggs wrote: > >> Just consider this part of the recovery toolkit. > > > > In that case, don't call it "read uncommitted". Call it some other > > thing entirely.

Re: Read Uncommitted

On Wed, 18 Dec 2019 at 20:36, Tom Lane wrote: > "Finnerty, Jim" writes: > > Many will want to use it to do aggregation, e.g. a much more efficient > COUNT(*), because they want performance and don't care very much about > transaction consistency. E.g. they want to compute SUM(sales) by >

Re: Read Uncommitted

On 12/18/19 2:29 PM, Heikki Linnakangas wrote: On 18/12/2019 20:46, Mark Dilger wrote: On 12/18/19 10:06 AM, Simon Riggs wrote: Just consider this part of the recovery toolkit. In that case, don't call it "read uncommitted".  Call it some other thing entirely.  Users coming from other

Re: remove unnecessary table_open/close from makeArrayTypeName

Alvaro Herrera writes: > Commit bc8036fc666a (12 years ago) seems to have introduced an > unnecessary catalog heap_open/close in order to do syscache accesses. Huh. Not sure how that got past me, but I agree it's bogus. > I presume a preliminary version of the patch used sysscans or something.

Re: Read Uncommitted regression test coverage

Mark Dilger writes: >> The one in src/test/isolation doesn't look very comprehensive.  I'd >> at least expect a test that verifies you don't get a syntax error >> when you request READ UNCOMMITTED isolation from SQL. > The attached patch set adds a modicum of test coverage for this. > Do others

remove unnecessary table_open/close from makeArrayTypeName

Commit bc8036fc666a (12 years ago) seems to have introduced an unnecessary catalog heap_open/close in order to do syscache accesses. I presume a preliminary version of the patch used sysscans or something. I don't think that's necessary, so this patch removes it. (I noticed while reading Paul

Read Uncommitted regression test coverage

Over in [1], I became concerned that, although postgres supports Read Uncommitted transaction isolation (by way of Read Committed mode), there was very little test coverage for it: On 12/18/19 10:46 AM, Mark Dilger wrote: Looking at the regression tests, I'm surprised read uncommitted gets so

Re: Read Uncommitted

On Wed, Dec 18, 2019 at 2:29 PM Heikki Linnakangas wrote: > I agree that if we have a user-exposed READ UNCOMMITTED isolation level, > it shouldn't be just a recovery tool. For a recovery tool, I think a > set-returning function as part of contrib/pageinspect, for example, > would be more

Re: backup manifests

On Tue, Dec 17, 2019 at 12:54 AM Suraj Kharage wrote: > I have implemented the simplehash in backup validator patch as Robert > suggested. Please find attached 0002 patch for the same. > > kindly review and let me know your thoughts. +#define CHECKSUM_LENGTH 256 This seems wrong. Not all

Re: Read Uncommitted

"Finnerty, Jim" writes: > Many will want to use it to do aggregation, e.g. a much more efficient > COUNT(*), because they want performance and don't care very much about > transaction consistency. E.g. they want to compute SUM(sales) by > salesperson, region for the past 5 years, and don't

Re: Restore backup file "with oids"

On Wednesday, December 18, 2019, Vladimir Koković < vladimir.koko...@a-asoft.com> wrote: > HI, > > The first thing I have to say is that I only have a plain backup file > "with oids" from "PostgreSQL 8.4.2, 32-bit", > > from which I should take the contents of some tables. > Any help from someone

Re: Restore backup file "with oids"

THE TRUTH CANNOT BE HIDDEN **Explosion in my car. https://www.docdroid.net/s11XHOS/the-truth-cannot-be-hidden.pdf On Wed, 18 Dec 2019, 18:28 gmail Vladimir Koković, < vladimir.koko...@gmail.com> wrote: > Hi, > > Is there somewhere a script that can do a restore backup file "with oids" > in

Re: inherits clause for CREATE TYPE? -

THE TRUTH CANNOT BE HIDDEN **Explosion in my car. https://www.docdroid.net/s11XHOS/the-truth-cannot-be-hidden.pdf On Wed, 18 Dec 2019, 20:06 Tom Lane, wrote: > Pavel Stehule writes: > > My idea is implement inherits clause for CREATE TYPE command. > > -1. We have enough problems dealing

Re: inherits clause for CREATE TYPE? -

THE TRUTH CANNOT BE HIDDEN **Explosion in my car. https://www.docdroid.net/s11XHOS/the-truth-cannot-be-hidden.pdf On Wed, 18 Dec 2019, 19:38 Pavel Stehule, wrote: > Hi > > I had a talk with one boy about development in plpgsql. He uses table's > functions. More times he uses returns types

Re: Read Uncommitted

Many will want to use it to do aggregation, e.g. a much more efficient COUNT(*), because they want performance and don't care very much about transaction consistency. E.g. they want to compute SUM(sales) by salesperson, region for the past 5 years, and don't care very much if some concurrent

Re: Windows port minor fixes

Em qua., 18 de dez. de 2019 às 15:59, Stephen Frost escreveu: > >Alright, well, oddly enough, *this* email included the other headers and > >appears threaded properly (in mutt, at least). > > >Did you do something different when replying to this email vs. the other > >emails you've been replying

[PATCH] remove expression always false

Hi, || curpages <= 0 expression is always false and can be safely removed. Reasons: 1. curpages is uint32 type 2. its already test if is zero before. 3. Never be negative regards, Ranier Vilela diff --git a/src/backend/access/table/tableam.c b/src/backend/access/table/tableam.c index

Re: inherits clause for CREATE TYPE? -

On Wed, Dec 18, 2019 at 12:38 PM Pavel Stehule wrote: > > Hi > > I had a talk with one boy about development in plpgsql. He uses table's > functions. More times he uses returns types based on some table type + few > attributes. Now he use a ugly hack - he create a view on table plus some >

Re: Restore backup file "with oids"

HI, The first thing I have to say is that I only have a plain backup file "with oids" from "PostgreSQL 8.4.2, 32-bit", from which I should take the contents of some tables. Any help from someone who was in a similar situation would help me a lot in resolving this situation. Thank you

Re: Read Uncommitted

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Dec 18, 2019 at 1:06 PM Simon Riggs wrote: > > Just consider this part of the recovery toolkit. > > I agree that it would be useful to have a recovery toolkit for reading > uncommitted data, but I think a lot more thought needs

Re: Minimal logical decoding on standbys

Hi, Hi, do you consistently get this failure on your machine ? I am not > able to get this failure, but I am going to analyze when/how this can > fail. Thanks > > Yes, I am getting it each time I run make -C src/test/recovery/ check PROVE_TESTS=t/018_standby_logical_decoding_xmins.pl Also, there

Re: Read Uncommitted

On 18/12/2019 20:46, Mark Dilger wrote: On 12/18/19 10:06 AM, Simon Riggs wrote: Just consider this part of the recovery toolkit. In that case, don't call it "read uncommitted". Call it some other thing entirely. Users coming from other databases may request "read uncommitted" isolation

Re: inherits clause for CREATE TYPE? -

Pavel Stehule writes: > My idea is implement inherits clause for CREATE TYPE command. -1. We have enough problems dealing with alterations of inherited rowtypes already. As long as inheritance is restricted to tables, we can use table locking to help prevent problems --- but there's no

Re: Windows port minor fixes

Greetings, * Ranier Vilela (ranier_...@hotmail.com) wrote: > De: Robert Haas > Enviado: quarta-feira, 18 de dezembro de 2019 15:44 > > >A lot of your emails, like this one, seem to be replies to other > >emails, but at least in my mail reader (gmail) something you're doing > >is causing the

Re: Read Uncommitted

On Wed, 18 Dec 2019 at 18:37, Tom Lane wrote: > Simon Riggs writes: > > So this is the same discussion as elsewhere about potentially aborted > > transactions... > > AFAIK, the worst that happens in that case is that the reading > transaction > > will end with an ERROR, similar to a

Re: Read Uncommitted

On 12/18/19 10:06 AM, Simon Riggs wrote: On Wed, 18 Dec 2019 at 17:35, Robert Haas > wrote: On Wed, Dec 18, 2019 at 10:18 AM Simon Riggs > wrote: This was my first concern when I thought about it, but I realised that by taking a

inherits clause for CREATE TYPE? -

Hi I had a talk with one boy about development in plpgsql. He uses table's functions. More times he uses returns types based on some table type + few attributes. Now he use a ugly hack - he create a view on table plus some columns - and then he use the view related type as table function result

Re: Read Uncommitted

Simon Riggs writes: > So this is the same discussion as elsewhere about potentially aborted > transactions... > AFAIK, the worst that happens in that case is that the reading transaction > will end with an ERROR, similar to a serializable error. No, the worst case is transactions trying to read

Re: Restore backup file "with oids"

On 18 December 2019 19:28:07 EET, "gmail Vladimir Koković" wrote: >Is there somewhere a script that can do a restore backup file "with >oids" in some newer DB where there is no term "with oids"? There is nothing automatic, some manual work is needed. A couple of ideas: 1. Install an older

Re: Read Uncommitted

On Wed, Dec 18, 2019 at 1:06 PM Simon Riggs wrote: > So this is the same discussion as elsewhere about potentially aborted > transactions... Yep. > AFAIK, the worst that happens in that case is that the reading transaction > will end with an ERROR, similar to a serializable error. I'm not

[PATCH] Windows port: add support to setenv function

According to [1], windows does not support setenv. With the possibility of setenv going further [2], I am submitting in this thread, the patch to add setenv support on the windows side, It is based on pre-existing functions, and seeks to correctly emulate the functioning of the POSIX setenv, but

Re: Restore backup file "with oids"

On Wed, Dec 18, 2019 at 2:28 PM gmail Vladimir Koković < vladimir.koko...@gmail.com> wrote: > Hi, > > Is there somewhere a script that can do a restore backup file "with oids" > in some newer DB where there is no term "with oids"? > > > Short answer: No! Long answer: try use the pg_dump binary

Re: client auth docs seem to have devolved

I wrote: > Magnus Hagander writes: >> This was changed by Peter in >> commit 56811e57323faa453947eb82f007e323a952e1a1 along with the >> restructuring. It used to say "the following subsections". So techically I >> think that change is correct, but that doesn't necessarily make it helpful. >> But

Re: Read Uncommitted

On Wed, 18 Dec 2019 at 17:35, Robert Haas wrote: > On Wed, Dec 18, 2019 at 10:18 AM Simon Riggs > wrote: > > This was my first concern when I thought about it, but I realised that > by taking a snapshot and then calculating xmin normally, this problem would > go away. > > Why? As soon as a

RE: Windows port minor fixes

De: Robert Haas Enviado: quarta-feira, 18 de dezembro de 2019 15:44 >A lot of your emails, like this one, seem to be replies to other >emails, but at least in my mail reader (gmail) something you're doing >is causing the threading to get broken, so it's very hard to know what >this is replying

Re: Read Uncommitted

On Wed, Dec 18, 2019 at 10:18 AM Simon Riggs wrote: > This was my first concern when I thought about it, but I realised that by > taking a snapshot and then calculating xmin normally, this problem would go > away. Why? As soon as a transaction aborts, the TOAST rows can be vacuumed away, but

Re: [HACKERS] pg_shmem_allocations view

On Wed, Dec 18, 2019 at 12:06 PM Tom Lane wrote: > It seems like it'd be worth subdividing "" into the actual > anonymous allocations and the allocator overhead (which is both > padding and whatever the shmem allocator itself eats). Maybe call > the latter "". After which, I'd be tempted to

Restore backup file "with oids"

Hi, Is there somewhere a script that can do a restore backup file "with oids" in some newer DB where there is no term "with oids"? Vladimir Koković, DP senior(69) Serbia, Belgrade, 18.December 2019

Re: [HACKERS] pg_shmem_allocations view

Robert Haas writes: > On Wed, Dec 18, 2019 at 10:59 AM Alvaro Herrera > wrote: >> Can we please stop splitting this error message in two? >> >> +errmsg("materialize mode required, but it is not " \ >> + "allowed in this context"))); >> >> (What's with the

Re: [HACKERS] pg_shmem_allocations view

On Wed, Dec 18, 2019 at 10:59 AM Alvaro Herrera wrote: > On 2019-Dec-18, Robert Haas wrote: > > - code: Declare values/nulls arrays only once at function scope > > instead of 3x, and tighten up code, per Andres and self-review. > > Really small nit: I'd rather have the "nulls" assignment in all

Re: tableam vs. TOAST

On Tue, Dec 17, 2019 at 4:12 PM Robert Haas wrote: > Hearing no further comments, I went ahead and pushed 0002 today. That > turned out to have a bug, so I pushed a fix for that. Hopefully the > buildfarm will agree that it's fixed. > > Meanwhile, here are the remaining patches again, rebased

Re: archive status ".ready" files may be created too early

On 12/17/19, 2:26 AM, "Kyotaro Horiguchi" wrote: > But I think I found a corner case where the patch doesn't work. As I > mentioned in another message, if WAL buffer was full, > AdvanceXLInsertBuffer calls XLogWrite to write out the victim buffer > regardless whether the last record in the page

Re: Unix-domain socket support on Windows

On 2019-12-18 15:24, Hamlin, Garick L wrote: On Wed, Dec 18, 2019 at 02:52:15PM +0100, Peter Eisentraut wrote: To implement this, tweak things so that setting DEFAULT_PGSOCKET_DIR to "" has the desired effect. This mostly already worked like that; only a few places needed to be adjusted.

Re: Windows port minor fixes

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Dec 17, 2019 at 9:06 AM Ranier Vilela wrote: > > De: Michael Paquier > > Enviadas: Terça-feira, 17 de Dezembro de 2019 04:45 > > >And if you actually group things together so as any individual looking > > >at your patches does not

Re: [HACKERS] pg_shmem_allocations view

On 2019-Dec-18, Robert Haas wrote: > - code: Declare values/nulls arrays only once at function scope > instead of 3x, and tighten up code, per Andres and self-review. Really small nit: I'd rather have the "nulls" assignment in all cases even when the previous value is still valid. This tight

Re: Request to be allotted a project or a feature in pipeline

Greetings, * Utsav Parmar (utsavp0...@gmail.com) 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. Neat! > As it may turn out, I've got a college project in my

Re: allow_system_table_mods and DROP RULE

On Wed, Dec 18, 2019 at 3:56 AM Peter Eisentraut wrote: > As a curious omission, DROP RULE does not check allow_system_table_mods. > Creating and renaming a rule does, and also creating, renaming, and > dropping a trigger does. The impact of this is probably nil in > practice, but for

Re: Request to be allotted a project or a feature in pipeline

On Mon, Dec 16, 2019 at 6:12 AM Utsav Parmar wrote: > As it may turn out, I've got a college project in my curriculum this semester > under “Software Development Practice”, and I'd like to work upon a project > and/or a feature in pipeline spanning over 3 months in PostgreSQL > organization as

Re: Windows port minor fixes

On Tue, Dec 17, 2019 at 9:06 AM Ranier Vilela wrote: > De: Michael Paquier > Enviadas: Terça-feira, 17 de Dezembro de 2019 04:45 > >And if you actually group things together so as any individual looking > >at your patches does not have to figure out which piece applies to > >what, that's also

Re: [HACKERS] pg_shmem_allocations view

On Fri, Nov 15, 2019 at 2:59 PM Tom Lane wrote: > I didn't really read the patch in any detail, but those things > hopped out at me. Thanks for the reviews. Here is a new version. Changes: - doc: Add an entry to the table of system views, per Tom. - doc: Wrap reference to "" in tags, per

Re: Allow cluster owner to bypass authentication

Greetings, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 2019-12-17 05:40, Stephen Frost wrote: > >* 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

Re: psql's EDITOR behavior on Windows

On Wed, Dec 18, 2019 at 4:11 PM Tom Lane wrote: > > I wrote: > > Pavlo Golub writes: > >> I cannot find the reason why EDITOR value on Windows is quoted. > > > The comment you quoted explains it: apparently people expect > > paths-with-spaces to work in that value without any manual quoting. > >

Re: Read Uncommitted

On Wed, 18 Dec 2019 at 14:06, Tom Lane wrote: > Simon Riggs writes: > > I present a patch to allow READ UNCOMMITTED that is simple, useful and > > efficient. > > Won't this break entirely the moment you try to read a tuple containing > toasted-out-of-line values? There's no guarantee that the

Re: Read Uncommitted

On Wed, 18 Dec 2019 at 12:11, Konstantin Knizhnik wrote: As far as I understand with "read uncommitted" policy we can see two > versions of the same tuple if it was updated by two transactions both of > which were started before us and committed during table traversal by > transaction with "read

Re: psql's EDITOR behavior on Windows

I wrote: > Pavlo Golub writes: >> I cannot find the reason why EDITOR value on Windows is quoted. > The comment you quoted explains it: apparently people expect > paths-with-spaces to work in that value without any manual quoting. Actually, after digging in the git history and archives, the

Re: psql's EDITOR behavior on Windows

Pavlo Golub writes: > I cannot find the reason why EDITOR value on Windows is quoted. The comment you quoted explains it: apparently people expect paths-with-spaces to work in that value without any manual quoting. > One may force quote env var if he wants to. Given the lack of prior

Re: Unix-domain socket support on Windows

On Wed, Dec 18, 2019 at 02:52:15PM +0100, Peter Eisentraut wrote: > To implement this, tweak things so that setting DEFAULT_PGSOCKET_DIR > to "" has the desired effect. This mostly already worked like that; > only a few places needed to be adjusted. Notably, the reference to >

Re: jacana seems to be failing in recoverycheck from last few runs

Amit Kapila writes: > I think previously also the same test failed but not as consistently > as it is now. I see that consistently the same test case is failing. Yeah, this is already being discussed over in the -bugs thread.

Re: Allow cluster owner to bypass authentication

On Tue, Dec 17, 2019 at 5:27 AM Peter Eisentraut wrote: > I realize that there are a number of facilities nowadays to do enhanced > security setups. But let's consider what 99% of users are using. If > the database server runs as user X and you are logged in as user X, you > should be able to

Re: Read Uncommitted

Simon Riggs writes: > I present a patch to allow READ UNCOMMITTED that is simple, useful and > efficient. Won't this break entirely the moment you try to read a tuple containing toasted-out-of-line values? There's no guarantee that the toast-table entries haven't been vacuumed away. I suspect

psql's EDITOR behavior on Windows

Hello. I cannot find the reason why EDITOR value on Windows is quoted. It should not be. One may force quote env var if he wants to. Right now, for example, one cannot use sublime, since to use it in a proper way you should SET EDITOR="C:\Program Files\Sublime\subl.exe" --wait The problem can

Re: Unix-domain socket support on Windows

Next patch: This allows building *with* Unix-domain socket support but *without* a default Unix socket path. This is needed because on Windows we don't have a good default location like "/tmp" and we probably don't want Unix sockets by default at run time so that older Windows versions

Re: unsupportable composite type partition keys

Amit Langote writes: > On Wed, Dec 18, 2019 at 2:12 AM Tom Lane wrote: >> Hm. Seems like the restrictions here ought to be just about the same >> as on index columns, no? > We also need to disallow self-referencing composite type in the case > of partitioning, because otherwise it leads to

Re: [HACKERS] Block level parallel vacuum

On Wed, Dec 18, 2019 at 6:04 PM Amit Kapila wrote: > On Wed, Dec 18, 2019 at 6:01 PM Prabhat Sahu < > prabhat.s...@enterprisedb.com> wrote: > >> Hi all, >> >> While testing on v36 patch with gist index, I came across below >> segmentation fault. >> >> > It seems you forgot to apply the Gist

Re: non-exclusive backup cleanup is mildly broken

On Tue, Dec 17, 2019 at 11:36 PM Fujii Masao wrote: > If pg_abort_backup callback function can be called safely even when > the backup is not in progress, we can just use the global variable like > pg_abort_backup_registered to register the callback function only > on first call. In this way,

Re: [HACKERS] Block level parallel vacuum

On Wed, Dec 18, 2019 at 6:01 PM Prabhat Sahu wrote: > Hi all, > > While testing on v36 patch with gist index, I came across below > segmentation fault. > > It seems you forgot to apply the Gist index patch as mentioned by Masahiko-San. You need to first apply the patch at

Re: [HACKERS] Block level parallel vacuum

On Wed, Dec 18, 2019 at 3:36 PM Amit Kapila wrote: > > Few other comments which I have not fixed: > +/* interface function to support parallel vacuum */ +amestimateparallelvacuum_function amestimateparallelvacuum; /* can be NULL */ } IndexAmRoutine; One more thing, why have you removed

Re: [HACKERS] Block level parallel vacuum

Hi all, While testing on v36 patch with gist index, I came across below segmentation fault. -- PG Head+ v36_patch create table tab1(c1 int, c2 text PRIMARY KEY, c3 bool, c4 timestamp without time zone, c5 timestamp with time zone, p point); create index gist_idx1 on tab1 using gist(p); create

Re: Read Uncommitted

On 18.12.2019 13:01, Simon Riggs wrote: I present a patch to allow READ UNCOMMITTED that is simple, useful and efficient.  This was previously thought to have no useful definition within PostgreSQL, though I have identified a use case for diagnostics and recovery that merits adding a short

jacana seems to be failing in recoverycheck from last few runs

I think previously also the same test failed but not as consistently as it is now. I see that consistently the same test case is failing. Dec 17 01:35:33 t/010_logical_decoding_timelines# Looks like you planned 13 tests but ran 9. Dec 17 01:35:33 # Looks like your test exited with 255 just

RE: [PATCH] Windows port add support to BCryptGenRandom

De: Michael Paquier Enviadas: Quarta-feira, 18 de Dezembro de 2019 02:19 >This looks like a leftover of d9dd406, which has made the code to >require C99. As we don't support compilation with Windows XP and >require Windows 7, we should be able to remove all the dance around >MIN_WINNT in win32.h,

RE: [Proposal] Level4 Warnings show many shadow vars

De: Michael Paquier Enviadas: Quarta-feira, 18 de Dezembro de 2019 01:18 >Committed that part. Thanks. >Let's take one example. The changes in pg_dump/ like >/progname/prog_name/ have just been done in haste, without actual >thoughts about how the problem ought to be fixed. And in this case,

RE: [PATCH] Fix possible underflow in expression (maxoff - 1)

De: Thomas Munro Enviado: quarta-feira, 18 de dezembro de 2019 00:18 >If you're working on/with static code analysis tools, I have some >requests :-) How could we automate the discovery of latch wait >programming mistakes? I doubt that static analysis can help with this problem. This seems to

Optimizing TransactionIdIsCurrentTransactionId()

TransactionIdIsCurrentTransactionId() doesn't seem to be well optimized for the case when an xid has not yet been assigned, so for read only transactions. A patch for this is attached. -- Simon Riggshttp://www.2ndQuadrant.com/ PostgreSQL Solutions

Re: [HACKERS] Block level parallel vacuum

On Wed, Dec 18, 2019 at 12:04 PM Amit Kapila wrote: > > On Wed, Dec 18, 2019 at 11:46 AM Masahiko Sawada > wrote: > > > > On Wed, 18 Dec 2019 at 15:03, Amit Kapila wrote: > > > > > > I was analyzing your changes related to ReinitializeParallelDSM() and > > > it seems like we might launch more

Re: Collation versions on Windows (help wanted, apply within)

On Tue, Dec 17, 2019 at 1:40 AM Juan José Santamaría Flecha wrote: > 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

Read Uncommitted

I present a patch to allow READ UNCOMMITTED that is simple, useful and efficient. This was previously thought to have no useful definition within PostgreSQL, though I have identified a use case for diagnostics and recovery that merits adding a short patch to implement it. My docs for this are

Re: [Proposal] Level4 Warnings show many shadow vars

On 2019-Dec-18, Michael Paquier wrote: > Let's take one example. The changes in pg_dump/ like > /progname/prog_name/ have just been done in haste, without actual > thoughts about how the problem ought to be fixed. And in this case, > something which could be more adapted is to remove the

allow_system_table_mods and DROP RULE

As a curious omission, DROP RULE does not check allow_system_table_mods. Creating and renaming a rule does, and also creating, renaming, and dropping a trigger does. The impact of this is probably nil in practice, but for consistency we should probably add that. The patch is pretty simple.

  1   2   >