Re: Change of email address

On Tue, Feb 19, 2019 at 6:54 PM Shawn Debnath wrote: > On Tue, Feb 19, 2019 at 03:54:59PM +1300, Thomas Munro wrote: > > This change is just to avoid sending automated corporate footer messages > > that are intended for a different audience, in line with standard mailing > > list etiquette. > > >

RE: Protect syscache from bloating with negative cache entries

From: 'Bruce Momjian' [mailto:br...@momjian.us] > I think, in general, smaller is better, as long as making something > smaller doesn't remove data that is frequently accessed. Having a timer > to expire only old entries seems like it accomplished this goal. > > Having a minimum size and not

Some thoughts on NFS

Hello hackers, As discussed in various threads, PostgreSQL-on-NFS is viewed with suspicion. Perhaps others knew this already, but I first learned of the specific mechanism (or at least one of them) for corruption from Craig Ringer's writing[1] about fsync() on Linux. The problem is that close()

RE: SQL statement PREPARE does not work in ECPG

Hi I think SQL statement PREPARE *without* parameter is supported, but one with parameter is not supported (or has some fatal bugs). Because route for SQL statement PREPARE (line-1837 of preproc.y) always has output an invalid SQL statement and there is no regression test for SQL statement

RE: Protect syscache from bloating with negative cache entries

Hi Horiguchi-san, This is the rest of my review comments. (5) patch 0003 CatcacheClockTimeoutPending = 0; + + /* Update timetamp then set up the next timeout */ + false is better than 0, to follow other **Pending variables. timetamp -> timestamp (6) patch 0003

Re: 2019-03 CF Summary / Review - Tranche #2

On 2/19/19 1:23 AM, Tom Lane wrote: Andrew Dunstan writes: On 2/18/19 12:43 PM, Tom Lane wrote: Andres Freund writes: It's CF app nannyism. One can't move a patch to the next CF that's waiting-on-author. I've complained about that a number of times, but... So change it to another state,

Re: Prevent extension creation in temporary schemas

Michael Paquier writes: > On Mon, Feb 18, 2019 at 05:39:09AM +, Kuroda, Hayato wrote: >> I'm not sure why extensions contained by temporary schemas are >> acceptable. > Because there are cases where they actually work. More to the point, it doesn't seem that hard to think of cases where

Re: [Bug Fix] ECPG: could not use set xxx to default statement

I wrote: > "Higuchi, Daisuke" writes: >> [ missing semicolon in gram.y breaks ecpg parsing of same construct ] > That's pretty nasty. The fix in gram.y is certainly needed, but I'm > unexcited by the regression test additions you propose. What I really > want to know is why a syntax error in

Re: Offline enabling/disabling of data checksums

On Sun, Feb 17, 2019 at 07:31:38PM +0100, Michael Banck wrote: > New patch attached. - * src/bin/pg_verify_checksums/pg_verify_checksums.c + * src/bin/pg_checksums/pg_checksums.c That's lacking a rename, or this comment is incorrect. +#if PG_VERSION_NUM >= 10 +

Re: Prepared transaction releasing locks before deregistering its GID

On Tue, Feb 19, 2019 at 01:07:06AM -0300, Alvaro Herrera wrote: > On 2019-Feb-19, Michael Paquier wrote: >> extern GlobalTransaction MarkAsPreparing(TransactionId xid, const char *gid, > > Hmm, ABI break ... Well, sure. I always post patches for HEAD first. And I was actually wondering if

Re: Prevent extension creation in temporary schemas

On Mon, Feb 18, 2019 at 08:02:54PM +0900, Masahiko Sawada wrote: > I'd vote for accepting the extension creation in temporary schemas and > fixing \dx and \dx+. Thanks. > However the error raised by creating extensions > in temporary schema still looks strange to me. Since we don't search >

Re: Prevent extension creation in temporary schemas

On Mon, Feb 18, 2019 at 05:39:09AM +, Kuroda, Hayato wrote: > I seem this patch is enough, but could you explain the reason > you drop initial proposal more detail? > I'm not sure why extensions contained by temporary schemas are > acceptable. Because there are cases where they actually

Re: [Bug Fix] ECPG: could not use set xxx to default statement

"Higuchi, Daisuke" writes: > [ missing semicolon in gram.y breaks ecpg parsing of same construct ] That's pretty nasty. The fix in gram.y is certainly needed, but I'm unexcited by the regression test additions you propose. What I really want to know is why a syntax error in gram.y wasn't

Re: Prepared transaction releasing locks before deregistering its GID

On 2019-Feb-19, Michael Paquier wrote: > diff --git a/src/include/access/twophase.h b/src/include/access/twophase.h > index 6228b091d8..2dcd08e9fa 100644 > --- a/src/include/access/twophase.h > +++ b/src/include/access/twophase.h > @@ -34,7 +34,7 @@ extern void TwoPhaseShmemInit(void); > extern

[Bug Fix] ECPG: could not use set xxx to default statement

Hi, I found ECPG's bug which SET xxx = DEFAULT statement could not be used. [PROBLEM] When the source code (*.pgc) has "EXEC SQL set xxx = default;", created c program by ECPG has no " = default". For example, "EXEC SQL set search_path = default;" in *.pgc will be converted to "{

Re: Reaping Temp tables to avoid XID wraparound

On Tue, Feb 19, 2019 at 10:52:54AM +1100, James Sewell wrote: > I agree the use case is narrow - but it's also pretty critical. Yeah.. > I suppose an in-core way of disconnecting idle sessions after x time would > work too - but that seems like a sledgehammer approach. Such solutions at SQL

Re: Prepared transaction releasing locks before deregistering its GID

On Mon, Feb 18, 2019 at 05:05:13PM +0100, Oleksii Kliukin wrote: > That looks like a race condition to me. What happens is that another > transaction with the name identical to the running one can start and proceed > to the prepare phase while the original one commits, failing at last instead > of

Re: Speed up transaction completion faster after many relations are accessed in a transaction

Hi, On 2019-02-18 20:29:29 -0500, Tom Lane wrote: > Andres Freund writes: > > but it's smaller (althoug there's plenty trailing space). > > I think you're supposing that these things are independently palloc'd, but > they aren't --- dynahash lays them out in arrays without palloc padding. I

RE: libpq debug log

Hi Iwata-san, Currently, the patch fails to build according to CF app. As you know, it has something to do with the misspelling of function. GetTimezoneInformation --> GetTimeZoneInformation It sounds more logical to me if there is a parameter that switches on/off the logging similar to other

Change of email address

Hello hackers, I am switching to this new email address for PostgreSQL mailing lists. I just wanted you to know that I'm still reachable at my EnterpriseDB address and I'm still happily employed by EnterpriseDB, working on PostgreSQL! This change is just to avoid sending automated corporate

Re: crash in pg_identify_object_as_address

On Mon, Feb 18, 2019 at 05:13:27PM -0500, Tom Lane wrote: > Hm, does this overlap with Paquier's much-delayed patch in > https://commitfest.postgresql.org/22/1947/ It partially overlaps, still my patch set would crash as well in that case. Treating object_names the same way as object_args sounds

RE: [PATCH] Fix Proposal - Deadlock Issue in Single User Mode When IO Failure Occurs

Thank you so much Amit! I have created the patch below: https://commitfest.postgresql.org/22/2003/ Please let me know should you have more suggestions. Thank you! Best regards, -- Chengchao Yu Software Engineer | Microsoft | Azure Database for PostgreSQL

Re: speeding up planning with partitions

"Imai, Yoshikazu" writes: > ISTM the 0004 patch eventually removes these codes from multiple places > (set_append_rel_size and set_inherited_target_rel_sizes) so we might be > better to not be struggling here? Yeah, Amit just pointed that out (and I'd not read 0004 before reacting to 0001).

Re: Speed up transaction completion faster after many relations are accessed in a transaction

Andres Freund writes: > On 2019-02-18 19:24:54 -0500, Tom Lane wrote: >> Yeah, but if we want to rearrange the members into an illogical order >> to save some space, we should do that independently of this patch --- > Sure, we should do that. I don't buy the "illogical" bit, just moving >

RE: [PROPOSAL]a new data type 'bytea' for ECPG

Meskes-san > This looks very good. Committed to HEAD. Thank you so match. Regards Ryo Matsumura

SQL statement PREPARE does not work in ECPG

Hi, In the PostgreSQL Documentation, both ECPG PREPARE and SQL statement PREPARE can be used in ECPG [1]. However, SQL statement PREPARE does not work. I wrote the source code as follows. EXEC SQL PREPARE test_prep (int) AS SELECT id from test_table where id =

Re: speeding up planning with partitions

Thanks for looking. On 2019/02/19 2:27, Tom Lane wrote: > Amit Langote writes: >> [ v22 patch set ] > > I started to look at this, and immediately choked on the 0001 patch: > > if (childpruned || > !apply_child_basequals(root, rel, childrel, childRTE, appinfo) || >

RE: speeding up planning with partitions

On Mon, Feb 18, 2019 at 5:28 PM, Tom Lane wrote: > Frankly, that code is just horrid. Having a function with side effects > in an if-test is questionable at the best of times, and having it be the > second of three conditions (which the third condition silently depends > on) is unreadable and

Re: Speed up transaction completion faster after many relations are accessed in a transaction

Hi, On 2019-02-18 19:24:54 -0500, Tom Lane wrote: > Yeah, but if we want to rearrange the members into an illogical order > to save some space, we should do that independently of this patch --- Sure, we should do that. I don't buy the "illogical" bit, just moving hashcode up to after tag isn't

Re: Speed up transaction completion faster after many relations are accessed in a transaction

Andres Freund writes: > On 2019-02-18 18:42:32 -0500, Tom Lane wrote: >> Do we really want a dlist here at all? I'm concerned that bloating >> LOCALLOCK will cost us when there are many locks involved. This patch >> increases the size of LOCALLOCK by 25% if I counted right, which does >> not

Re: Speed up transaction completion faster after many relations are accessed in a transaction

Hi, On 2019-02-18 19:13:31 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2019-02-18 19:01:06 -0500, Tom Lane wrote: > >> Mmm ... AIUI, the patches currently proposed can only help for what > >> David called "point lookup" queries. There are still going to be > >> queries that scan a

Re: Delay locking partitions during query execution

On Tue, 19 Feb 2019 at 12:50, Tom Lane wrote: > > [ reposting some questions asked in the wrong thread ] > > What I'd like to understand about this patch is how it relates > to Amit L.'s work on making the planner faster for partitioned > UPDATE/DELETE cases

Re: Speed up transaction completion faster after many relations are accessed in a transaction

Hi, On 2019-02-18 18:42:32 -0500, Tom Lane wrote: > "Tsunakawa, Takayuki" writes: > > The attached patch speeds up transaction completion when any prior > > transaction accessed many relations in the same session. > > Hm. Putting a list header for a purely-local data structure into shared >

Re: Speed up transaction completion faster after many relations are accessed in a transaction

Andres Freund writes: > On 2019-02-18 19:01:06 -0500, Tom Lane wrote: >> Mmm ... AIUI, the patches currently proposed can only help for what >> David called "point lookup" queries. There are still going to be >> queries that scan a large proportion of a partition tree, so if you've >> got tons

Re: Speed up transaction completion faster after many relations are accessed in a transaction

Hi, On 2019-02-18 19:01:06 -0500, Tom Lane wrote: > Andres Freund writes: > > Isn't a large portion of benefits in this patch going to be mooted by > > the locking improvements discussed in the other threads? I.e. there's > > hopefully not going to be a ton of cases with low overhead where we >

Re: Speed up transaction completion faster after many relations are accessed in a transaction

On Tue, 19 Feb 2019 at 12:56, Andres Freund wrote: > Isn't a large portion of benefits in this patch going to be mooted by > the locking improvements discussed in the other threads? I.e. there's > hopefully not going to be a ton of cases with low overhead where we > acquire a lot of locks and

RE: [Bug Fix] ECPG: could not use some CREATE TABLE AS syntax

Hi, Meskes-san > Thank you, committed. Thank you! By the way, I have found another bugs which are related to ECPG , so I will post that later. Regards, Daisuke, Higuchi

Re: Speed up transaction completion faster after many relations are accessed in a transaction

David Rowley writes: > On Tue, 19 Feb 2019 at 12:42, Tom Lane wrote: >> My own thought about how to improve this situation was just to destroy >> and recreate LockMethodLocalHash at transaction end (or start) >> if its size exceeded $some-value. Leaving it permanently bloated seems >> like

Re: Speed up transaction completion faster after many relations are accessed in a transaction

Hi, On 2019-02-19 12:52:08 +1300, David Rowley wrote: > On Tue, 19 Feb 2019 at 12:42, Tom Lane wrote: > > My own thought about how to improve this situation was just to destroy > > and recreate LockMethodLocalHash at transaction end (or start) > > if its size exceeded $some-value. Leaving it

Re: Speed up transaction completion faster after many relations are accessed in a transaction

On Tue, 19 Feb 2019 at 12:42, Tom Lane wrote: > My own thought about how to improve this situation was just to destroy > and recreate LockMethodLocalHash at transaction end (or start) > if its size exceeded $some-value. Leaving it permanently bloated seems > like possibly a bad idea, even if we

Re: Reaping Temp tables to avoid XID wraparound

On Mon, 18 Feb 2019 at 12:31, Michael Paquier wrote: > On Sun, Feb 17, 2019 at 05:47:09PM +0100, Magnus Hagander wrote: > > We could I guess add a field specifically for temp_namespace_xid or such. > > The question is if it's worth the overhead to do that. > > That would mean an extra 4 bytes in

Re: Delay locking partitions during query execution

[ reposting some questions asked in the wrong thread ] What I'd like to understand about this patch is how it relates to Amit L.'s work on making the planner faster for partitioned UPDATE/DELETE cases (https://commitfest.postgresql.org/22/1778/). I think that that might render this moot? Amit's

RE: Protect syscache from bloating with negative cache entries

Hi Horiguchi-san, I've looked through your patches. This is the first part of my review results. Let me post the rest after another work today. BTW, how about merging 0003 and 0005, and separating and deferring 0004 in another thread? That may help to relieve other community members by

Re: Speed up transaction completion faster after many relations are accessed in a transaction

"Tsunakawa, Takayuki" writes: > The attached patch speeds up transaction completion when any prior > transaction accessed many relations in the same session. Hm. Putting a list header for a purely-local data structure into shared memory seems quite ugly. Isn't there a better place to keep

Re: Delay locking partitions during INSERT and UPDATE

On Tue, 19 Feb 2019 at 12:15, Tom Lane wrote: > > David Rowley writes: > > Looks like you're looking at the patch from the "Delay locking > > partitions during query execution" thread [1]. Different thing > > altogether, although the names are confusingly similar. > > My apologies --- I

Re: Delay locking partitions during INSERT and UPDATE

On Tue, 19 Feb 2019 at 12:15, Tom Lane wrote: > Now that I've looked at *this* thread's patch, I agree that having > the executor acquire locks based on find_all_inheritors() is a > pretty horrid idea. However, it still seems like this is being > done in a vacuum without attention to locks

Re: 2019-03 CF Summary / Review - Tranche #2

Andrew Dunstan writes: > On 2/18/19 12:43 PM, Tom Lane wrote: >> Andres Freund writes: >>> It's CF app nannyism. One can't move a patch to the next CF that's >>> waiting-on-author. I've complained about that a number of times, but... >> So change it to another state, push it, change it again.

Re: 2019-03 CF Summary / Review - Tranche #2

On 2/18/19 12:43 PM, Tom Lane wrote: > Andres Freund writes: >> On 2019-02-18 12:37:27 -0500, Tom Lane wrote: >>> Can't you do it now? The status summary line already shows one >>> patch as having been pushed to the next CF. >> It's CF app nannyism. One can't move a patch to the next CF that's

Re: Delay locking partitions during INSERT and UPDATE

David Rowley writes: > On Tue, 19 Feb 2019 at 11:47, Tom Lane wrote: >> Are we talking about the same patch? The one I'm looking at seems >> to be mostly planner and plancache changes: > Looks like you're looking at the patch from the "Delay locking > partitions during query execution" thread

Re: Inadequate executor locking of indexes

On Tue, 12 Feb 2019 at 09:58, Julien Rouhaud wrote: > > On Mon, Feb 11, 2019 at 5:32 AM David Rowley > wrote: > > 1. Adding a new field to RangeTblEntry to indicate the operation type > > that's being performed on the relation; or > > 2. Adding a Bitmapset field to PlannerGlobal that sets the

Re: Delay locking partitions during INSERT and UPDATE

On Tue, 19 Feb 2019 at 11:47, Tom Lane wrote: > Are we talking about the same patch? The one I'm looking at seems > to be mostly planner and plancache changes: > > src/backend/catalog/dependency.c | 1 + > src/backend/commands/createas.c | 1 + >

Re: Delay locking partitions during INSERT and UPDATE

Hi, On 2019-02-18 17:47:07 -0500, Tom Lane wrote: > David Rowley writes: > > Not sure what you mean here. This is an executor change. What does > > the planner care about what the executor does? > > Are we talking about the same patch? The one I'm looking at seems > to be mostly planner and

Re: Missing Column names with multi-insert

On 2/18/19 2:34 PM, Liz Frost wrote: > Hello all, > > I'm working on a foreign data wrapper that uses INSERT, and I noticed > some odd behaviour. If I insert just one row, the > TupleDesc->attr[0]->attname.data has the column names in it. However, > in a multi-row string, all those are empty

Re: Delay locking partitions during INSERT and UPDATE

David Rowley writes: > On Tue, 19 Feb 2019 at 11:11, Tom Lane wrote: >> What I'd like to understand about this patch is how it relates >> to Amit L.'s work on making the planner faster for partitioned >> UPDATE/DELETE cases (https://commitfest.postgresql.org/22/1778/). >> I think that that might

Re: Delay locking partitions during INSERT and UPDATE

On Tue, 19 Feb 2019 at 11:11, Tom Lane wrote: > > What I'd like to understand about this patch is how it relates > to Amit L.'s work on making the planner faster for partitioned > UPDATE/DELETE cases (https://commitfest.postgresql.org/22/1778/). It's close to being unrelated and completely

Re: proposal: pg_restore --convert-to-text

Euler Taveira writes: > Since no one has stepped up, I took a stab at it. It will prohibit > standard output unless '-f -' be specified. -l option also has the > same restriction. Hm, don't really see the need to break -l usage here. Pls add to next CF, if you didn't already.

Re: proposal: pg_restore --convert-to-text

Em qui, 14 de fev de 2019 às 22:41, Andreas Karlsson escreveu: > Agreed, "-f -" would be acceptable. I use pg_restore to stdout a lot, > but almost always manually and would have to have to remember and type > "--convert-to-text". > Since no one has stepped up, I took a stab at it. It will

Re: crash in pg_identify_object_as_address

Alvaro Herrera writes: > I just came across a crash while debugging some corrupted system > catalogs; pg_identify_object_as_address fails to cope with some NULL > input, causing a crash. Attached patch fixes it. Naturally, the output > array will contain NULL members in the output, but that's

Re: Delay locking partitions during INSERT and UPDATE

What I'd like to understand about this patch is how it relates to Amit L.'s work on making the planner faster for partitioned UPDATE/DELETE cases (https://commitfest.postgresql.org/22/1778/). I think that that might render this moot? And if it doesn't, how much does it really matter? You can't

Re: Proving IS NOT NULL inference for ScalarArrayOpExpr's

James Coleman writes: > I forgot to update in v8 so attaching v9. So ... this is actively wrong. This case shows that you can't ignore the empty-array possibility for a ScalarArrayOpExpr with useOr = false, because "SELECT null::int = all(array[]::int[])" yields TRUE: contrib_regression=#

crash in pg_identify_object_as_address

Hello I just came across a crash while debugging some corrupted system catalogs; pg_identify_object_as_address fails to cope with some NULL input, causing a crash. Attached patch fixes it. Naturally, the output array will contain NULL members in the output, but that's better than crashing ...

Re: unconstify equivalent for volatile

Hi, On 2019-02-18 16:39:25 +0100, Peter Eisentraut wrote: > diff --git a/src/backend/storage/ipc/latch.c b/src/backend/storage/ipc/latch.c > index 7da337d11f..fa7d72ef76 100644 > --- a/src/backend/storage/ipc/latch.c > +++ b/src/backend/storage/ipc/latch.c > @@ -381,7 +381,7 @@

Re: unconstify equivalent for volatile

Petr Jelinek writes: > On 18/02/2019 16:43, Tom Lane wrote: >> Umm ... wouldn't this amount to papering over actual bugs? > I'd argue that it's not making it easier to do but rather easier to spot > (vs normal type casting) which is IMO a good thing from patch review > perspective. Yeah, fair

Re: unconstify equivalent for volatile

On 18/02/2019 16:43, Tom Lane wrote: > Peter Eisentraut writes: >> I propose to add an equivalent to unconstify() for volatile. When >> working on this, I picked the name unvolatize() mostly as a joke, but it >> appears it's a real word. Other ideas? > > Umm ... wouldn't this amount to

Re: Missing Column names with multi-insert

Liz Frost writes: > I'm working on a foreign data wrapper that uses INSERT, and I noticed some > odd behaviour. If I insert just one row, the > TupleDesc->attr[0]->attname.data has the column names in it. However, in a > multi-row string, all those are empty strings: There's not really any

Re: Missing Column names with multi-insert

Hi, On 2019-02-18 14:34:43 -0500, Liz Frost wrote: > I'm working on a foreign data wrapper that uses INSERT, and I noticed some > odd behaviour. If I insert just one row, the > TupleDesc->attr[0]->attname.data has the column names in it. However, in a > multi-row string, all those are empty

Re: speeding up planning with partitions

Amit Langote writes: > [ v22 patch set ] I did some review of the 0002 patch. I like the general idea, but there are a lot of details I don't much like. Probably the biggest complaint is that I don't like what you did to the API of grouping_planner(): it's ugly and unprincipled. Considering

Missing Column names with multi-insert

Hello all, I'm working on a foreign data wrapper that uses INSERT, and I noticed some odd behaviour. If I insert just one row, the TupleDesc->attr[0]->attname.data has the column names in it. However, in a multi-row string, all those are empty strings: I added this debugging code to

Re: automatically assigning catalog toast oids

On 2019-02-18 12:45:10 +0900, Michael Paquier wrote: > On Sat, Feb 16, 2019 at 04:50:51PM +0100, John Naylor wrote: > > I just noticed a small typo in transam.h. Patch attached. > > Thanks, fixed. Thx.

Re: 2019-03 CF Summary / Review - Tranche #2

Andres Freund writes: > On 2019-02-18 12:37:27 -0500, Tom Lane wrote: >> Can't you do it now? The status summary line already shows one >> patch as having been pushed to the next CF. > It's CF app nannyism. One can't move a patch to the next CF that's > waiting-on-author. I've complained about

Re: 2019-03 CF Summary / Review - Tranche #2

On 2019-02-18 12:37:27 -0500, Tom Lane wrote: > David Steele writes: > > Even so, I'll push it when I can to get it out of my hair, as it were. > > I'll be spending a lot of time look at that list next month. > > Can't you do it now? The status summary line already shows one > patch as having

Re: 2019-03 CF Summary / Review - Tranche #2

David Steele writes: > Even so, I'll push it when I can to get it out of my hair, as it were. > I'll be spending a lot of time look at that list next month. Can't you do it now? The status summary line already shows one patch as having been pushed to the next CF.

Re: speeding up planning with partitions

Amit Langote writes: > [ v22 patch set ] I started to look at this, and immediately choked on the 0001 patch: if (childpruned || !apply_child_basequals(root, rel, childrel, childRTE, appinfo) || relation_excluded_by_constraints(root, childrel, childRTE))

Re: WAL insert delay settings

Greetings, * Tomas Vondra (tomas.von...@2ndquadrant.com) wrote: > On 2/15/19 7:41 PM, Andres Freund wrote: > > On 2019-02-15 08:50:03 -0500, Stephen Frost wrote: > >> * Andres Freund (and...@anarazel.de) wrote: > >>> On 2019-02-14 11:02:24 -0500, Stephen Frost wrote: > On Thu, Feb 14, 2019

Re: 2019-03 CF Summary / Review - Tranche #2

On 2/18/19 7:03 PM, Andres Freund wrote: Hi, On 2019-02-18 18:59:22 +0200, David Steele wrote: On 2/16/19 7:45 AM, Andres Freund wrote: - Add timeline to partial WAL segments WOA: Seems to need a good bit more work, and touches sensitive bits. Andres: +0.5 for punting to v13 I

Re: 2019-03 CF Summary / Review - Tranche #2

Hi, On 2019-02-18 18:59:22 +0200, David Steele wrote: > On 2/16/19 7:45 AM, Andres Freund wrote: > > > - Add timeline to partial WAL segments > > > >WOA: Seems to need a good bit more work, and touches sensitive bits. > > > >Andres: +0.5 for punting to v13 > I have labelled this patch

Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line

On 18.02.2019 19:49, Alvaro Herrera wrote: On 16.02.2019 6:41, Andres Freund wrote: It sounds like a seriously bad idea to use a different parser for pg_rewind. Why don't you just use postgres for it? As in /path/to/postgres -D /path/to/datadir/ -C shared_buffers ? Eh, this is what I

Re: 2019-03 CF Summary / Review - Tranche #2

On 2/16/19 7:45 AM, Andres Freund wrote: - Add timeline to partial WAL segments WOA: Seems to need a good bit more work, and touches sensitive bits. Andres: +0.5 for punting to v13 I have labelled this patch v13 and I'll push it as soon as the CF app allows me to do so. I think this

Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line

On 2019-Feb-18, Andres Freund wrote: > Hi, > > On 2019-02-18 16:26:55 +0300, Alexey Kondratov wrote: > > Hi Andres, > > > > Thank you for your feedback. > > > > On 16.02.2019 6:41, Andres Freund wrote: > > > It sounds like a seriously bad idea to use a different parser for > > > pg_rewind.

Re: Progress reporting for pg_verify_checksums

Hi, Am Montag, den 18.02.2019, 13:42 -0300 schrieb Alvaro Herrera: > On 2019-Feb-18, Bernd Helmle wrote: > > > Am Montag, den 18.02.2019, 16:52 +0100 schrieb Michael Banck: > > > > Surely we know at that point whether this first scan is needed, and > > > > we can skip it if not? > > > > > >

Re: Progress reporting for pg_verify_checksums

On 2019-Feb-18, Bernd Helmle wrote: > Am Montag, den 18.02.2019, 16:52 +0100 schrieb Michael Banck: > > > Surely we know at that point whether this first scan is needed, and > > we > > > can skip it if not? > > > > Yeah - new patch attached. > > Maybe i'm wrong, but my thought is that this

Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line

Hi, On 2019-02-18 16:26:55 +0300, Alexey Kondratov wrote: > Hi Andres, > > Thank you for your feedback. > > On 16.02.2019 6:41, Andres Freund wrote: > > It sounds like a seriously bad idea to use a different parser for > > pg_rewind. Why don't you just use postgres for it? As in > >

Re: unconstify equivalent for volatile

Hi, On 2019-02-18 10:43:50 -0500, Tom Lane wrote: > Peter Eisentraut writes: > > I propose to add an equivalent to unconstify() for volatile. When > > working on this, I picked the name unvolatize() mostly as a joke, but it > > appears it's a real word. Other ideas? > > Umm ... wouldn't this

Re: Use varargs macro for CACHEDEBUG

Hi, On 2019-02-18 13:56:52 +0100, Peter Eisentraut wrote: > I propose the attached patch to replace the CACHEX_elog() macros with a > single varargs version. +1 Greetings, Andres Freund

Re: Copy function for logical replication slots

Hi, On 2019-02-18 16:57:07 +0900, Masahiko Sawada wrote: > > Stupid question, but couldn't we optimize this to something like: > > > > /* > > * First copy current data of the slot. Then install those in the > > * new slot. The src slot could have progressed while installing, > >

Re: Reporting script runtimes in pg_regress

Alvaro Herrera writes: > On 2019-Feb-18, Peter Eisentraut wrote: >>> We should also strive to align "FAILED" properly. >> Yeah, not strictly required, but someone might want to play around with >> it a bit. > FWIW I don't think we localize pg_regress output currently, so that > argument seems

Prepared transaction releasing locks before deregistering its GID

Hello, We have an app that copies some metrics between predefined tables on the source and destination clusters, truncating the table at the source afterward. The app locks both the source and the destination table at the beginning and then, once copy concludes, prepares a transaction on each of

Re: Progress reporting for pg_verify_checksums

Am Montag, den 18.02.2019, 16:52 +0100 schrieb Michael Banck: > > Surely we know at that point whether this first scan is needed, and > we > > can skip it if not? > > Yeah - new patch attached. Maybe i'm wrong, but my thought is that this breaks the SIGUSR1 business, since there seems no code

boolean and bool in documentation

HI, I realized that 'boolean' and 'bool' are mixed as SQL data type in the documentation. Here is the quick check result; $ git grep -c "bool" doc doc/src/sgml/bki.sgml:1 doc/src/sgml/btree-gin.sgml:1 doc/src/sgml/catalogs.sgml:88 doc/src/sgml/datatype.sgml:1 doc/src/sgml/ecpg.sgml:2

Re: Progress reporting for pg_verify_checksums

Hi, Am Montag, den 18.02.2019, 11:18 -0300 schrieb Alvaro Herrera: > On 2019-Feb-17, Michael Banck wrote: > > + /* > > +* As progress status information may be requested, we need to scan the > > +* directory tree(s) twice, once to get the idea how much data we need > > to > > +*

Re: unconstify equivalent for volatile

Peter Eisentraut writes: > I propose to add an equivalent to unconstify() for volatile. When > working on this, I picked the name unvolatize() mostly as a joke, but it > appears it's a real word. Other ideas? Umm ... wouldn't this amount to papering over actual bugs? I can think of legitimate

Re: unconstify equivalent for volatile

Hi, On February 18, 2019 7:39:25 AM PST, Peter Eisentraut wrote: >I propose to add an equivalent to unconstify() for volatile. When >working on this, I picked the name unvolatize() mostly as a joke, but >it >appears it's a real word. Other ideas? Shouldn't we just remove just about all those

unconstify equivalent for volatile

I propose to add an equivalent to unconstify() for volatile. When working on this, I picked the name unvolatize() mostly as a joke, but it appears it's a real word. Other ideas? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA,

Re: FOP warnings about id attributes in title tags

Andrew Dunstan writes: > Over on our shiny new PDF builder at > >   > FOP is complaining about a bunch of unresolved ID references. > It appears that these are due to title elements having

Re: FOP warnings about id attributes in title tags

On 2019-02-18 16:12, Andrew Dunstan wrote: > Over on our shiny new PDF builder at > >   > FOP is complaining about a bunch of unresolved ID references. Yes, this is an ancient issue. The

Re: [PATCH v20] GSSAPI encryption support

Greetings, * Robbie Harwood (rharw...@redhat.com) wrote: > Andres Freund writes: > > > On 2018-12-18 14:12:46 -0500, Robbie Harwood wrote: > > > >> Subject: [PATCH] libpq GSSAPI encryption support > > > > Could some of these be split into separate patches that could be more > > eagerly merged?

FOP warnings about id attributes in title tags

Over on our shiny new PDF builder at   FOP is complaining about a bunch of unresolved ID references. It appears that these are due to title elements having id tags. At

Re: [PATCH v20] GSSAPI encryption support

Andres Freund writes: > On 2018-12-18 14:12:46 -0500, Robbie Harwood wrote: > >> Subject: [PATCH] libpq GSSAPI encryption support > > Could some of these be split into separate patches that could be more > eagerly merged? This is a somewhat large patch... What splits do you propose? (It's been

Re: Reporting script runtimes in pg_regress

On 2019-Feb-18, Peter Eisentraut wrote: > On 2019-02-15 15:54, Tom Lane wrote: > >> We should also strive to align "FAILED" properly. > > Hmm. The reasonable ways to accomplish that look to be either > > (a) pad "ok" to the width of "FAILED", or (b) rely on emitting a tab. > > I don't much like

Re: Problems with plan estimates in postgres_fdw

Etsuro Fujita wrote: > (2019/02/15 21:46), Antonin Houska wrote: > > ok, I understand now. I assume that the patch > > > > https://www.postgresql.org/message-id/5C66A056.60007%40lab.ntt.co.jp > > > > obsoletes the code snippet we discussed above. > > Sorry, I don't understand this. Could you

  1   2   >