Re: [bug fix] Produce a crash dump before main() on Windows

On Wed, Sep 11, 2019 at 01:55:45PM +0900, Michael Paquier wrote: > Okay, so this means that the service state of the parent is inherited > and that we can rely on that. I was not sure about that. Got it > now. Now, there are cases where it is possible to start an app > without using a service

Re: [PATCH][DOC] Fix for PREPARE TRANSACTION doc and postgres_fdw message.

Hello. At Wed, 6 Nov 2019 20:13:10 +0900, Etsuro Fujita wrote in > Hi Michael-san, > > On Wed, Nov 6, 2019 at 4:35 PM Michael Paquier wrote: > > On Wed, Nov 06, 2019 at 03:12:04PM +0900, Etsuro Fujita wrote: > > > On Wed, Nov 6, 2019 at 1:13 PM Michael Paquier > > > wrote: > > >>

Re: Application name for pg_basebackup and friends

On Sat, Nov 02, 2019 at 04:45:40PM +0900, Michael Paquier wrote: > On Thu, Oct 31, 2019 at 03:10:35PM +0200, Heikki Linnakangas wrote: >> You can already set application name with the environment variable or on the >> database connections string: >> >> pg_receivewal -D /wal -d "host=myhost

Re: Remove configure --disable-float4-byval and --disable-float8-byval

On Fri, Nov 01, 2019 at 09:41:58PM -0700, Peter Geoghegan wrote: > On Fri, Nov 1, 2019 at 7:47 PM Michael Paquier wrote: >> I don't agree as well with the line of arguments to just remove 32b >> support. > > Clearly you didn't read what I actually wrote, Michael. Sorry, that was an

Re: tableam vs. TOAST

On Thu, Nov 7, 2019 at 10:57 AM Prabhat Sahu wrote: > > > > On Tue, Nov 5, 2019 at 4:48 PM Ashutosh Sharma wrote: >> >> From the stack trace shared by Prabhat, I understand that the checkpointer >> process panicked due to one of the following two reasons: >> >> 1) The fsync() failed in the

Re: Keep compiler silence (clang 10, implicit conversion from 'long' to 'double' )

At Wed, 6 Nov 2019 13:56:46 +0900, Yuya Watari wrote in > Hello Tom, Thomas, and Andrew, > > > Tom> That commit presumes that floats follow the IEEE bitwise > > Tom> representation, I think; > > > > Correct. (It notably does _not_ make any assumptions about how floating > > point arithmetic

Re: dropdb --force

čt 7. 11. 2019 v 6:56 odesílatel Amit Kapila napsal: > On Thu, Nov 7, 2019 at 10:46 AM Pavel Stehule > wrote: > > > > čt 7. 11. 2019 v 3:42 odesílatel Amit Kapila > napsal: > >> > >> On Wed, Nov 6, 2019 at 11:46 PM Pavel Stehule > wrote: > >> > > >> > st 6. 11. 2019 v 14:59 odesílatel Tom

Re: dropdb --force

On Thu, Nov 7, 2019 at 10:46 AM Pavel Stehule wrote: > > čt 7. 11. 2019 v 3:42 odesílatel Amit Kapila napsal: >> >> On Wed, Nov 6, 2019 at 11:46 PM Pavel Stehule >> wrote: >> > >> > st 6. 11. 2019 v 14:59 odesílatel Tom Lane napsal: >> >> >> >> Amit Kapila writes: >> >> > I think there is

Re: [proposal] recovery_target "latest"

At Thu, 7 Nov 2019 02:28:39 +0300, Grigory Smolkin wrote in > On 11/6/19 1:55 PM, Grigory Smolkin wrote: > > > > On 11/6/19 12:56 PM, Fujii Masao wrote: > >> On Wed, Nov 6, 2019 at 6:33 PM Grigory Smolkin > >> wrote: > >>> > >>> On 11/6/19 10:39 AM, Peter Eisentraut wrote: > This seems to

Re: Reorderbuffer crash during recovery

On Thu, Nov 7, 2019 at 9:55 AM vignesh C wrote: > > On Wed, Nov 6, 2019 at 5:41 PM Dilip Kumar wrote: > > > > On Wed, Nov 6, 2019 at 5:20 PM vignesh C wrote: > > > > > > Hi, > > > > > > I found couple of crashes in reorderbuffer while review/testing of > > > logical_work_mem and logical

Re: tableam vs. TOAST

On Tue, Nov 5, 2019 at 4:48 PM Ashutosh Sharma wrote: > From the stack trace shared by Prabhat, I understand that the checkpointer > process panicked due to one of the following two reasons: > > 1) The fsync() failed in the first attempt itself and the reason for the > failure was not due to

Re: dropdb --force

čt 7. 11. 2019 v 3:42 odesílatel Amit Kapila napsal: > On Wed, Nov 6, 2019 at 11:46 PM Pavel Stehule > wrote: > > > > st 6. 11. 2019 v 14:59 odesílatel Tom Lane napsal: > >> > >> Amit Kapila writes: > >> > I think there is still a window where the same problem can happen, say > >> > the

Re: Attempt to consolidate reading of XLOG page

On Fri, Oct 04, 2019 at 12:11:11PM +0200, Antonin Houska wrote: > This is the next version. So... These are the two last bits to look at, reducing a bit the code size: 5 files changed, 396 insertions(+), 419 deletions(-) And what this patch set does is to refactor the routines we use now in

Re: Using multiple extended statistics for estimates

Hello. At Wed, 6 Nov 2019 20:58:49 +0100, Tomas Vondra wrote in > >Here is a slightly polished v2 of the patch, the main difference being > >that computing clause_attnums was moved to a separate function. > > > > This time with the attachment ;-) This patch is a kind of straight-forward,

Re: Reorderbuffer crash during recovery

On Wed, Nov 6, 2019 at 5:41 PM Dilip Kumar wrote: > > On Wed, Nov 6, 2019 at 5:20 PM vignesh C wrote: > > > > Hi, > > > > I found couple of crashes in reorderbuffer while review/testing of > > logical_work_mem and logical streaming of large in-progress > > transactions. Stack trace of the same

Re: base backup client as auxiliary backend process

On Mon, Oct 28, 2019 at 09:30:52AM +0100, Peter Eisentraut wrote: > On 2019-09-18 10:31, Michael Paquier wrote: >> -* Verify XLOG status looks valid. >> +* Check that contents look valid. >> */ >> - if (ControlFile->state < DB_SHUTDOWNED || >> - ControlFile->state >

Re: Problem during Windows service start

On Thu, Sep 05, 2019 at 07:09:45PM -0400, Alvaro Herrera from 2ndQuadrant wrote: > Can't we have pg_ctl just continue to wait indefinitely? So we'd set > SERVICE_START_PENDING when wait_for_postmaster is out of patience, then > loop again -- until recovery completes. Exiting pg_ctl on timeout

Re: TAP tests aren't using the magic words for Windows file access

On Thu, Nov 07, 2019 at 11:13:32AM +1300, Thomas Munro wrote: > Not a Windows or Perl person, but I see that you can redefine core > functions with *CORE::GLOBAL::open = , if you > wanted to make a version of open() that does that FILE_SHARE_READ > dance. FWIW, I would have gone with a solution

Re: [HACKERS] Block level parallel vacuum

On Wed, 6 Nov 2019, 20:07 Masahiko Sawada, wrote: > On Wed, 6 Nov 2019 at 20:29, Dilip Kumar wrote: > > > > On Wed, Nov 6, 2019 at 3:50 PM Masahiko Sawada > > wrote: > > > > > > On Wed, 6 Nov 2019 at 18:42, Dilip Kumar > wrote: > > > > > > > > On Wed, Nov 6, 2019 at 2:01 PM Mahendra Singh >

Re: dropdb --force

On Wed, Nov 6, 2019 at 11:46 PM Pavel Stehule wrote: > > st 6. 11. 2019 v 14:59 odesílatel Tom Lane napsal: >> >> Amit Kapila writes: >> > I think there is still a window where the same problem can happen, say >> > the signal has been sent by SendProcSignal to the required process and >> > it

Re: Missing test of SPI copy functionality

On Wed, Nov 06, 2019 at 04:16:14PM -0800, Mark Dilger wrote: > While working on cleaning up the SPI interface, I found that one of the SPI > error codes, SPI_ERROR_COPY, is never encountered in any test case when > running `make check-world`. This case is certainly reachable by a user, as > is

Re: RFC: split OBJS lines to one object per line

On Tue, Nov 05, 2019 at 02:47:55PM -0800, Andres Freund wrote: > Pushed a patch going with the former. Let's see what the buildfarm > says... Thanks Andres. On a rather related note, would it make sense to do the same for regression and isolation tests in our in-core modules? -- Michael

Re: Checking return value of SPI_execute

On Wed, Nov 06, 2019 at 07:35:18AM -0800, Mark Dilger wrote: > Other code that checks the return value from an SPI function is inconsistent > about whether it checks for SPI_OK_SELECT or simply checks for a negative > result. I was on the fence about which precedent to follow, and was just >

Re: [PATCH] Do not use StdRdOptions in Access Methods

On Thu, Nov 7, 2019 at 10:54 AM Michael Paquier wrote: > On Thu, Nov 07, 2019 at 10:49:38AM +0900, Amit Langote wrote: > > I looked around but don't understand why these macros need to be > > exposed. I read this comment: > > > > * Note that this is more or less the same that fillRelOptions

Re: [PATCH] Do not use StdRdOptions in Access Methods

On Thu, Nov 07, 2019 at 10:49:38AM +0900, Amit Langote wrote: > I looked around but don't understand why these macros need to be > exposed. I read this comment: > > * Note that this is more or less the same that fillRelOptions does, so only > * use this if you need to do something

Re: [PATCH] Do not use StdRdOptions in Access Methods

On Tue, Nov 5, 2019 at 9:22 AM Michael Paquier wrote: > On Thu, Oct 31, 2019 at 05:55:55PM +0900, Michael Paquier wrote: > > Thanks. I exactly did the same thing on my local branch. > > Hearing nothing more, I have done some adjustments to the patch and > committed it. Thank you. > Please

Re: SKIP_LOCKED test causes random buildfarm failures

On Wed, Nov 06, 2019 at 03:01:11PM -0800, Andres Freund wrote: > I don't know what lead us to doing so, but it doesn't seem reasonable to > allow the user to see whether the table has actually been vacuumed. I > would assume that one uses SKIP_LOCKED partially to avoid unnecessary > impacts in

Re: ssl passphrase callback

On Fri, Nov 1, 2019 at 01:57:29PM -0400, Andrew Dunstan wrote: > > On 11/1/19 11:01 AM, Robert Haas wrote: > > On Thu, Oct 31, 2019 at 11:37 AM Andrew Dunstan > > wrote: > >> This patch provides a hook for a function that can supply an SSL > >> passphrase. The hook can be filled in by a shared

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On Sat, Nov 2, 2019 at 01:34:41PM +0100, Antonin Houska wrote: > Robert Haas wrote: > > > On Tue, Aug 6, 2019 at 10:36 AM Bruce Momjian wrote: > > > Seems reasonable (not that I am an encryption expert). > > > > > For WAL, we effectively create a 16MB bitstream, though we can create it > > >

Re: TAP tests aren't using the magic words for Windows file access

On 11/6/19 4:43 PM, Tom Lane wrote: > =?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?= > writes: >> Please find attached a patch that adds the FILE_SHARE options to >> TestLib::slurp_file using Win32API::File. > Ick. Are we going to need Windows-droppings like this all over the > TAP tests?

Missing test of SPI copy functionality

Hackers, While working on cleaning up the SPI interface, I found that one of the SPI error codes, SPI_ERROR_COPY, is never encountered in any test case when running `make check-world`. This case is certainly reachable by a user, as is shown in the attached patch. Is this tested from some

Re: [proposal] recovery_target "latest"

On 11/6/19 1:55 PM, Grigory Smolkin wrote: On 11/6/19 12:56 PM, Fujii Masao wrote: On Wed, Nov 6, 2019 at 6:33 PM Grigory Smolkin wrote: On 11/6/19 10:39 AM, Peter Eisentraut wrote: This seems to also be related to this discussion:

Re: function calls optimization

Hi, On 2019-11-03 21:56:31 +0100, Andrzej Barszcz wrote: > Main goal of this patch is to avoid repeated calls of immutable/stable > functions. > This patch is against version 10.10. > I guess same logic could be implemented up till version 12. If you want actual development feedback, you're more

Re: SKIP_LOCKED test causes random buildfarm failures

Hi, On 2019-11-06 16:54:38 -0500, Tom Lane wrote: > Every once in awhile we get failures like this one: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gull=2019-11-05%2008%3A27%3A27 > > diff -U3 >

Re: question

Hi, Please keep the discussion on the list... Also, on PG lists we try to quote inline, and trim messages nicely. On 2019-11-06 23:03:06 +0100, Andrzej Barszcz wrote: > Your answer make me a bit confused. I thought that ExprState is in one to > one relation with ExprContext. They're definitely

Re: TAP tests aren't using the magic words for Windows file access

On Thu, Nov 7, 2019 at 10:43 AM Tom Lane wrote: > =?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?= > writes: > > Please find attached a patch that adds the FILE_SHARE options to > > TestLib::slurp_file using Win32API::File. > > Ick. Are we going to need Windows-droppings like this all over

SKIP_LOCKED test causes random buildfarm failures

Every once in awhile we get failures like this one: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gull=2019-11-05%2008%3A27%3A27 diff -U3 /home/pgsql/build-farm/buildroot-clang/HEAD/pgsql.build/../pgsql/src/test/regress/expected/vacuum.out

Re: question

Hi, On 2019-11-06 22:12:28 +0100, Andrzej Barszcz wrote: > Having ExprContext is it possible to know which ExprState is linked with it No. And there commonly are multiple ExprState evaluated using the same ExprContext. What's the reason for you asking? Greetings, Andres Freund

Re: TAP tests aren't using the magic words for Windows file access

=?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?= writes: > Please find attached a patch that adds the FILE_SHARE options to > TestLib::slurp_file using Win32API::File. Ick. Are we going to need Windows-droppings like this all over the TAP tests? I'm not sure I believe that slurp_file is the

Re: PostgreSQL 12 installation fails because locale name contained non-english characters

I wrote: >> I wonder whether we need to relax the matching code to be entirely >> agnostic about spaces and punctuation in the Windows locale name. > After googling a little bit, I could not find any indication that > Microsoft promises anything at all about the stability of these > long-form

question

Having ExprContext is it possible to know which ExprState is linked with it ?

Re: TAP tests aren't using the magic words for Windows file access

On Wed, Nov 6, 2019 at 4:38 PM Alvaro Herrera wrote: > On 2019-Nov-05, Michael Paquier wrote: > > > On Sun, Nov 03, 2019 at 10:53:00PM -0500, Tom Lane wrote: > > > That is, TestLib::slurp_file is failing to read a file. Almost > > > certainly, "permission denied" doesn't really mean a

Re: Using multiple extended statistics for estimates

On Wed, Nov 06, 2019 at 08:54:40PM +0100, Tomas Vondra wrote: On Mon, Oct 28, 2019 at 04:20:48PM +0100, Tomas Vondra wrote: Hi, PostgreSQL 10 introduced extended statistics, allowing us to consider correlation between columns to improve estimates, and PostgreSQL 12 added support for MCV

Re: Using multiple extended statistics for estimates

On Mon, Oct 28, 2019 at 04:20:48PM +0100, Tomas Vondra wrote: Hi, PostgreSQL 10 introduced extended statistics, allowing us to consider correlation between columns to improve estimates, and PostgreSQL 12 added support for MCV statistics. But we still had the limitation that we only allowed

Re: define bool in pgtypeslib_extern.h

Andrew Gierth writes: > I'm wondering whether we should actually go the opposite way and say > that c.h's "bool" definition should be backend only, and that in > frontend code we should define a PG_bool type or something of that ilk > for when we want "PG's 1-byte bool" and otherwise let the

Re: idea: log_statement_sample_rate - bottom limit for sampling

On Wed, Nov 06, 2019 at 08:00:57PM +0100, Adrien Nayrat wrote: On 11/6/19 7:21 PM, Tomas Vondra wrote: I've pushed the reworked version of log_statement_sample_rate patch [1]. If I understand correctly, that makes this patch unnecessary, and we should mark it as rejected. Or do we still need

Re: idea: log_statement_sample_rate - bottom limit for sampling

On 11/6/19 7:21 PM, Tomas Vondra wrote: > I've pushed the reworked version of log_statement_sample_rate patch [1]. > If I understand correctly, that makes this patch unnecessary, and we > should mark it as rejected. Or do we still need it? Yes, the goal of this patch was to disable sampling and

Re: Does 'instead of delete' trigger support modification of OLD

On Tue, Oct 29, 2019 at 05:54:36PM +0200, Eugen Konkov wrote: > Hi. > > This is not clear from doc, so I have asked on IRC too. > > from the DOC: https://www.postgresql.org/docs/current/trigger-definition.html > In the case of INSTEAD OF triggers, the possibly-modified row returned by > each

Re: Log statement sample - take two

On 11/6/19 7:16 PM, Tomas Vondra wrote: > Pushed, with some minor tweaks and rewording to the documentation. > > The first bit, documenting the log_transaction_sample_rate as PG_SUSET, > got backpatched to 12, where it was introduced. > > regards > Thanks Tomas! -- Adrien

Re: [Patch] optimizer - simplify $VAR1 IS NULL AND $VAR1 IS NOT NULL

Andrew Gierth writes: > "Pierre" == Pierre Ducroquet writes: > Pierre> The attached patch handles both situations. When flattening and > Pierre> simplifying the AND clauses, a list of the NullChecks is built, > Pierre> and subsequent NullChecks are compared to the list. If opposite > Pierre>

Re: idea: log_statement_sample_rate - bottom limit for sampling

On Sun, Aug 04, 2019 at 11:41:54PM +0200, Tomas Vondra wrote: On Sun, Aug 04, 2019 at 10:48:48PM +0200, Tomas Vondra wrote: On Sun, Aug 04, 2019 at 04:25:12PM -0400, Tom Lane wrote: Tomas Vondra writes: On Sun, Aug 04, 2019 at 03:16:12PM -0400, Tom Lane wrote: Isn't the issue here the

Re: dropdb --force

st 6. 11. 2019 v 14:59 odesílatel Tom Lane napsal: > Amit Kapila writes: > > I think there is still a window where the same problem can happen, say > > the signal has been sent by SendProcSignal to the required process and > > it releases the ProcArrayLock. Now, the target process exits and a

Re: Log statement sample - take two

Pushed, with some minor tweaks and rewording to the documentation. The first bit, documenting the log_transaction_sample_rate as PG_SUSET, got backpatched to 12, where it was introduced. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support,

Re: [Patch] optimizer - simplify $VAR1 IS NULL AND $VAR1 IS NOT NULL

> "Pierre" == Pierre Ducroquet writes: Pierre> Hello Pierre> In several queries relying on views, I noticed that the Pierre> optimizer miss a quite simple to implement optimization. My Pierre> views contain several branches, with different paths that are Pierre> simplified by the

[Patch] optimizer - simplify $VAR1 IS NULL AND $VAR1 IS NOT NULL

Hello In several queries relying on views, I noticed that the optimizer miss a quite simple to implement optimization. My views contain several branches, with different paths that are simplified by the caller of the view. This simplification is based on columns to be null or not. Today, even

Re: tableam vs. TOAST

Hi, On 2019-11-06 11:49:10 -0500, Robert Haas wrote: > On Wed, Nov 6, 2019 at 11:25 AM Andres Freund wrote: > > I think it's more than just that. It's also that I think presenting a > > hardcoded value to the outside of / above an AM is architecturally > > wrong. If anything this is an

Re: tableam vs. TOAST

Hi, On 2019-11-06 10:38:58 -0500, Robert Haas wrote: > Yeah. I've been nervous about trying to proceed with this patch > because Andres seemed confident there was a better approach than what > I did here, but as I wrote about back on September 12th, it doesn't > seem like his idea will work. I'm

Re: tableam vs. TOAST

On Wed, Nov 6, 2019 at 11:25 AM Andres Freund wrote: > I think it's more than just that. It's also that I think presenting a > hardcoded value to the outside of / above an AM is architecturally > wrong. If anything this is an implementation detail of the AM, that the > AM ought to be concerned

Re: [Patch] Optimize dropping of relation buffers using dlist

On Tue, Nov 5, 2019 at 10:34 AM Tomas Vondra wrote: > 2) This adds another hashtable maintenance to BufferAlloc etc. but > you've only done tests / benchmark for the case this optimizes. I > think we need to see a benchmark for workload that allocates and > invalidates lot of buffers.

Re: tableam vs. TOAST

Hi, On 2019-11-06 10:01:40 +0100, Peter Eisentraut wrote: > On 2019-10-04 20:32, Robert Haas wrote: > > Here's the last patch back, rebased over that renaming. Although I > > think that Andres (and Tom) are probably right that there's room for > > improvement here, I currently don't see a way

Re: v12 and pg_restore -f-

Robert Haas writes: > On Tue, Nov 5, 2019 at 10:07 AM Alvaro Herrera > wrote: >> I think this teapot doesn't need the tempest, and nobody's drowning in >> it anyway. > Yeah, I think we're getting awfully worked up over not much. Seems like that's getting to be the consensus opinion. Let's

Re: v12 and pg_restore -f-

On Tue, Nov 5, 2019 at 10:07 AM Alvaro Herrera wrote: > I think this teapot doesn't need the tempest, and nobody's drowning in > it anyway. Yeah, I think we're getting awfully worked up over not much. If I had been reviewing this feature initially, I believe I would have voted for making -f- go

Re: let's make the list of reportable GUCs configurable (was Re: Add %r substitution for psql prompts to show recovery status)

On Tue, Nov 5, 2019 at 10:02 AM Alvaro Herrera wrote: > There's a reason the SQL standard defines SET SESSION AUTHORIZATION but > no RESET SESSION AUTHORIZATION: once you enter a security context, you > cannot escape it. ISTM that essentially we broke feature F321 "User > authorization" by

Re: [Proposal] Global temporary tables

On 06.11.2019 16:24, 曾文旌(义从) wrote: Dear Hackers I attached the patch of GTT implementationI base on PG12. The GTT design came from my first email. Some limitations in patch will be eliminated in later versions. Later, I will comment on Konstantin's patch and make some proposals for

Re: let's make the list of reportable GUCs configurable (was Re: Add %r substitution for psql prompts to show recovery status)

On Tue, Nov 5, 2019 at 9:06 AM Peter Eisentraut wrote: > Yeah, the problem I see here is this: Client 1 uses language driver A, > client 2 uses language driver B. Connection pooling is in use, and they > both connect to the same pool. Everyone is happy. > > Now this feature gets introduced.

Re: Checking return value of SPI_execute

st 6. 11. 2019 v 16:38 odesílatel Mark Dilger napsal: > > > On 11/5/19 9:54 PM, Pavel Stehule wrote: > > > > > > st 6. 11. 2019 v 5:28 odesílatel Michael Paquier > > napsal: > > > > On Tue, Nov 05, 2019 at 05:21:25PM -0800, Mark Dilger wrote: > > > please

Re: tableam vs. TOAST

On Wed, Nov 6, 2019 at 4:01 AM Peter Eisentraut wrote: > This patch seems sound as far as the API restructuring goes. Thanks. And thanks for weighing in. > If I may summarize the remaining discussion: This patch adds a field > toast_max_chunk_size to TableAmRoutine, to take the place of the >

Re: Checking return value of SPI_execute

On 11/5/19 9:54 PM, Pavel Stehule wrote: st 6. 11. 2019 v 5:28 odesílatel Michael Paquier > napsal: On Tue, Nov 05, 2019 at 05:21:25PM -0800, Mark Dilger wrote: > please find attached a patch fixing a problem previously discussed [1] about >

Re: TAP tests aren't using the magic words for Windows file access

On 2019-Nov-05, Michael Paquier wrote: > On Sun, Nov 03, 2019 at 10:53:00PM -0500, Tom Lane wrote: > > That is, TestLib::slurp_file is failing to read a file. Almost > > certainly, "permission denied" doesn't really mean a permissions > > problem, but failure to specify the file-opening flags

Re: Checking return value of SPI_execute

On 11/5/19 8:27 PM, Michael Paquier wrote: On Tue, Nov 05, 2019 at 05:21:25PM -0800, Mark Dilger wrote: please find attached a patch fixing a problem previously discussed [1] about the code inappropriately ignoring the return value from SPI_execute. I will be adding this to

Re: Checking return value of SPI_execute

On 2019-Nov-06, Pavel Stehule wrote: > My comment was about maybe obsolescence of this API. Probably it was > designed before exception introduction. > > For example - syntax error is ended by exception. Wrong numbers of argument > is signalized by error status. I didn't study this code, but

Re: Removing pg_pltemplate and creating "trustable" extensions

Peter Eisentraut writes: > On 2019-08-21 21:29, Tom Lane wrote: >> Patch 0001 below addresses this problem by inventing a concept of >> "trustable" (not necessarily trusted) extensions. An extension that >> would normally require superuser permissions (e.g., because it creates >> C functions)

Re: define bool in pgtypeslib_extern.h

Amit Kapila writes: > On Mon, Oct 28, 2019 at 11:27 PM Tom Lane wrote: >> A plausible alternative is to do >> >> -#define bool char >> +#define bool unsigned char >> >> which is correct on platforms where we don't use , >> and is at least no worse than now on those where we do. In >>

Re: alternative to PG_CATCH

Peter Eisentraut writes: > On 2019-11-04 16:01, Tom Lane wrote: >> Now that I've actually looked at the patched code, there's a far >> more severe problem with it. Namely, that use of PG_FINALLY >> means that the "finally" segment is run without having popped >> the error context stack, which

Re: [HACKERS] Block level parallel vacuum

On Wed, 6 Nov 2019 at 20:29, Dilip Kumar wrote: > > On Wed, Nov 6, 2019 at 3:50 PM Masahiko Sawada > wrote: > > > > On Wed, 6 Nov 2019 at 18:42, Dilip Kumar wrote: > > > > > > On Wed, Nov 6, 2019 at 2:01 PM Mahendra Singh wrote: > > > > > > > > Hi > > > > I took all attached patches(v32-01 to

Re: Add a GUC variable that control logical replication

On 2019/11/1 20:49, Peter Eisentraut wrote: On 2019-10-20 00:23, Euler Taveira wrote: You can probably achieve that using ALTER PUBLICATION to disable publication of deletes or truncates, as the case may be, either permanently or just for the duration of the operations you want to skip. ...

Re: dropdb --force

Amit Kapila writes: > I think there is still a window where the same problem can happen, say > the signal has been sent by SendProcSignal to the required process and > it releases the ProcArrayLock. Now, the target process exits and a > new process gets the same pid before the signal is

Re: TAP tests aren't using the magic words for Windows file access

On 11/4/19 10:41 PM, Michael Paquier wrote: > On Sun, Nov 03, 2019 at 10:53:00PM -0500, Tom Lane wrote: >> That is, TestLib::slurp_file is failing to read a file. Almost >> certainly, "permission denied" doesn't really mean a permissions >> problem, but failure to specify the file-opening flags

Re: segmentation fault when cassert enabled

On 2019-11-05 17:29, Jehan-Guillaume de Rorthais wrote: My best bet so far is that logicalrep_relmap_invalidate_cb is not called after the DDL on the subscriber so the relmap cache is not invalidated. So we end up with slot->tts_tupleDescriptor->natts superior than rel->remoterel->natts in

Re: Should we make scary sounding, but actually routine, errors less scary?

Greetings, * Andres Freund (and...@anarazel.de) wrote: > There's a few errors that we issue that are, often, much less bad than > they sound. The most common cases I immediately can recall are: Agreed. > 1) Mentioning crash, once for each backend, when shutting down > immediately. Currently the

Re: Collation versioning

On 2019-11-04 04:58, Thomas Munro wrote: * We'd need to track dependencies on the default collation once we have versioning for that (see https://www.postgresql.org/message-id/flat/5e756dd6-0e91-d778-96fd-b1bcb06c161a%402ndquadrant.com). That is how most people actually consume collations out

Re: pause recovery if pitr target not reached

>"Peter Eisentraut" skrev 6. november 2019 >kl. 08:32: > >> Btw., this discussion/patch seems related: >> https://www.postgresql.org/message-id/flat/a3f650f1-fb0f-c913-a000-a4671f12a...@postgrespro.ru I have read through this other proposal. As far as I could see in the suggested patch, it

Re: Reorderbuffer crash during recovery

On Wed, Nov 6, 2019 at 5:20 PM vignesh C wrote: > > Hi, > > I found couple of crashes in reorderbuffer while review/testing of > logical_work_mem and logical streaming of large in-progress > transactions. Stack trace of the same are given below: > Issue 1: > #0 0x7f985c7d8337 in raise ()

Reorderbuffer crash during recovery

Hi, I found couple of crashes in reorderbuffer while review/testing of logical_work_mem and logical streaming of large in-progress transactions. Stack trace of the same are given below: Issue 1: #0 0x7f985c7d8337 in raise () from /lib64/libc.so.6 #1 0x7f985c7d9a28 in abort () from

Re: [HACKERS] Block level parallel vacuum

On Wed, Nov 6, 2019 at 3:50 PM Masahiko Sawada wrote: > > On Wed, 6 Nov 2019 at 18:42, Dilip Kumar wrote: > > > > On Wed, Nov 6, 2019 at 2:01 PM Mahendra Singh wrote: > > > > > > Hi > > > I took all attached patches(v32-01 to v32-4) and one Dilip's patch from > > > "Questions/Observations

Re: [PATCH][DOC] Fix for PREPARE TRANSACTION doc and postgres_fdw message.

Hi Michael-san, On Wed, Nov 6, 2019 at 4:35 PM Michael Paquier wrote: > On Wed, Nov 06, 2019 at 03:12:04PM +0900, Etsuro Fujita wrote: > > On Wed, Nov 6, 2019 at 1:13 PM Michael Paquier wrote: > >> "postgres_fdw foreign tables" sounds weird to me. Could "foreign > >> tables using postgres_fdw"

Re: pgbench - rework variable management

Patch v4 is a just a rebase. -- Fabien.diff --git a/src/bin/pgbench/Makefile b/src/bin/pgbench/Makefile index f402fe7b91..e1d3ef9bb3 100644 --- a/src/bin/pgbench/Makefile +++ b/src/bin/pgbench/Makefile @@ -10,6 +10,7 @@ include $(top_builddir)/src/Makefile.global OBJS = \ $(WIN32RES) \

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Mon, Nov 4, 2019 at 5:22 PM Amit Kapila wrote: > > On Wed, Oct 30, 2019 at 9:38 AM vignesh C wrote: > > > > On Tue, Oct 22, 2019 at 10:52 PM Tomas Vondra > > wrote: > > > > > > I think the patch should do the simplest thing possible, i.e. what it > > > does today. Otherwise we'll never get

Re: [proposal] recovery_target "latest"

On 11/6/19 12:56 PM, Fujii Masao wrote: On Wed, Nov 6, 2019 at 6:33 PM Grigory Smolkin wrote: On 11/6/19 10:39 AM, Peter Eisentraut wrote: This seems to also be related to this discussion: Yes, in a way.

Re: [Proposal] Arbitrary queries in postgres_fdw

On Tue, Nov 5, 2019 at 7:41 PM David Fetter wrote: > Could you use IMPORT FOREIGN SCHEMA for that? I seem to recall that > I've managed to import information_schema successfully. Yes, I tried it and I can import and operate on the information_schema, which actually covers part of my needs. It

Re: [HACKERS] Block level parallel vacuum

On Wed, 6 Nov 2019 at 18:42, Dilip Kumar wrote: > > On Wed, Nov 6, 2019 at 2:01 PM Mahendra Singh wrote: > > > > Hi > > I took all attached patches(v32-01 to v32-4) and one Dilip's patch from > > "Questions/Observations related to Gist vacuum" mail thread. On the top of > > all these patches,

Re: ICU for global collation

On 2019-11-01 19:18, Daniel Verite wrote: Even if the FTS code is improved in that matter, any extension code with libc functions depending on LC_CTYPE is still going to be potentially problematic. In particular when it happens to be set to a different encoding than the database. I think the

Re: Allow CREATE OR REPLACE VIEW to rename the columns

On Thu, Oct 31, 2019 at 9:34 PM Ibrar Ahmed wrote: > > > > On Thu, Oct 31, 2019 at 5:28 PM Ibrar Ahmed wrote: >> >> >> >> On Thu, Oct 31, 2019 at 5:11 PM Ibrar Ahmed wrote: >>> >>> >>> >>> On Thu, Oct 31, 2019 at 5:01 PM Fujii Masao wrote: On Thu, Oct 31, 2019 at 7:59 PM Ibrar Ahmed

Re: [proposal] recovery_target "latest"

On Wed, Nov 6, 2019 at 6:33 PM Grigory Smolkin wrote: > > > On 11/6/19 10:39 AM, Peter Eisentraut wrote: > > This seems to also be related to this discussion: > > > > Yes, in a way. Strengthening current lax

Re: fe-utils - share query cancellation code

It looks like don't define sigint_interrupt_jmp and sigint_interrupt_enabled on Windows, yet they are still declared and referenced? Indeed, I put it on the wrong side of a "#ifndef WIN32". Basically it is a false constant under WIN32, which it seems does not have sigint handler, but the

Re: [HACKERS] Block level parallel vacuum

On Wed, Nov 6, 2019 at 2:01 PM Mahendra Singh wrote: > > Hi > I took all attached patches(v32-01 to v32-4) and one Dilip's patch from > "Questions/Observations related to Gist vacuum" mail thread. On the top of > all these patches, I created one more patch to test parallel vacuum >

Re: Checking return value of SPI_execute

st 6. 11. 2019 v 8:56 odesílatel Michael Paquier napsal: > On Wed, Nov 06, 2019 at 06:54:16AM +0100, Pavel Stehule wrote: > > Is generic question if this exception should not be raised somewhere in > > spi.c - maybe at SPI_execute. > > > > When you look to SPI_execute_plan, then checked errors

Re: d25ea01275 and partitionwise join

On Wed, Nov 6, 2019 at 2:00 AM Tom Lane wrote: > > Amit Langote writes: > > On Mon, Oct 14, 2019 at 5:02 AM Justin Pryzby wrote: > >> I can't say much about the patch; there's a little typo: > >> "The nullability of inner relation keys prevents them to" > >> ..should say "prevent them from". >

Re: define bool in pgtypeslib_extern.h

On Mon, Oct 28, 2019 at 11:27 PM Tom Lane wrote: > > Amit Kapila writes: > > On Sat, Oct 26, 2019 at 10:49 PM Tom Lane wrote: > >> I'm inclined to think that we need to make ecpglib.h's bool-related > >> definitions exactly match c.h, which will mean that it has to pull in > >> on most

Re: [proposal] recovery_target "latest"

On 11/6/19 10:39 AM, Peter Eisentraut wrote: This seems to also be related to this discussion: Yes, in a way. Strengthening current lax recovery behavior is a very good idea. I like this idea. I don't

  1   2   >