Re: [Proposal] Global temporary tables

Hi looks so this patch is broken again. Please, can you do rebase? Regards Pavel čt 16. 9. 2021 v 8:28 odesílatel wenjing napsal: > > > > > > > > >

Re: Added schema level support for publication.

On Wed, Sep 15, 2021 at 4:45 PM Greg Nancarrow wrote: > > On Tue, Sep 14, 2021 at 6:38 PM vignesh C wrote: > > > > I have handled this in the patch attached. > > > > Regarding the following function in the v28-0002 patch: > > +/* > + * Check if the relation schema is member of the schema list. >

Re: Allow escape in application_name

On 2021/09/16 12:36, kuroda.hay...@fujitsu.com wrote: you mean that this is not strtoXXX, right? Yes, the behavior of process_log_prefix_padding() is different from strtoint() or pg_strtoint32(). For example, how the heading space characters are handled is different. If we use the name like

Re: Column Filtering in Logical Replication

On Thu, Sep 16, 2021 at 8:45 AM Amit Kapila wrote: > > On Wed, Sep 15, 2021 at 6:06 PM Alvaro Herrera > wrote: > > > > On 2021-Sep-15, vignesh C wrote: > > > The patch > > > Generic_object_type_parser_002_table_schema_publication.patch has the > > > changes that were used to handle the parsing.

Re: proposal: possibility to read dumped table's name from file

Hi In yesterday's patch I used strndup, which is not available on win. I am sending update when I used pnstrdup instead. Regards Pavel diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml index 7682226b99..1b74c0eadd 100644 --- a/doc/src/sgml/ref/pg_dump.sgml +++ b/doc/src/

Re: right join with partitioned table crash

On Wed, Sep 15, 2021 at 07:53:49PM -0400, Tom Lane wrote: > Jaime Casanova writes: > > Here's another crash caught by sqlsmith. > > Fun. Looks like it fails back to v12, but not in v11, > so it's some optimization we added in v12 that's at fault. It seems to be a regression (?) in 12.6 (2021-02

Re: Hook for extensible parsing.

On Thu, Sep 16, 2021 at 5:40 AM Andres Freund wrote: > > > I don't have any better ideas to offer :-( ... but I very much fear > > that the approach proposed here is a dead end. > > I unfortunately don't see a good way forward without changing the way we do > parsing on a more fundamental level :(

Re: Added schema level support for publication.

On Wed, Sep 15, 2021 at 12:30 PM Amit Kapila wrote: > > On Tue, Sep 14, 2021 at 2:08 PM vignesh C wrote: > > > > I have handled this in the patch attached. > > > > 4. > AlterPublicationSchemas() > { > .. > + /* > + * If the table option was not specified remove the existing tables > + * from the

Re: Signed vs Unsigned (take 2) (src/backend/storage/ipc/procarray.c)

On 2021/09/15 21:27, Ranier Vilela wrote: I found this in the commit log in the patch. I agree that these patches are refactoring ones. But I'm thinking that it's worth doing back-patch, to make future back-patching easy. Thought? Thanks for picking this. Pushed. Thanks! Regard

Re: improve pg_receivewal code

> Here's the v2 with above modifications. I was looking at this patch, and I agree that checking for the system ID and the timeline by setting sysidentifier beforehand looks like an improvement. The extra IDENTIFY_SYSTEM done at the beginning of StreamLog() is not a performance bottleneck as we r

RE: Allow escape in application_name

Dear Fujii-san, Thanks for comments! > >> Thanks for the new version. I don't object for reusing > >> process_log_prefix_padding, but I still find it strange that the > >> function with the name 'process_padding' is in string.c. If we move > >> it to string.c, I'd like to name it "pg_fast_strto

RE: Added schema level support for publication.

On Tuesday, September 14, 2021 4:39 PM vignesh C wrote: > > I have handled this in the patch attached. Thanks for updating the patch. Here are some comments. 1) +static void +AlterPublicationSchemas(AlterPublicationStmt *stmt, Relation rel, ... + /* +* If the table

Re: Column Filtering in Logical Replication

On Wed, Sep 15, 2021 at 8:19 PM Euler Taveira wrote: > > On Wed, Sep 15, 2021, at 9:19 AM, vignesh C wrote: > > I have extracted the parser code and attached it here, so that it will > be easy to go through. We wanted to support the following syntax as in > [1]: > CREATE PUBLICATION pub1 FOR > TAB

Re: Column Filtering in Logical Replication

On Wed, Sep 15, 2021 at 6:06 PM Alvaro Herrera wrote: > > On 2021-Sep-15, vignesh C wrote: > > The patch > > Generic_object_type_parser_002_table_schema_publication.patch has the > > changes that were used to handle the parsing. Schema and Relation both > > are different objects, schema is of stri

Re: Column Filtering in Logical Replication

On Tue, Sep 7, 2021 at 3:51 AM Alvaro Herrera wrote: > ... > I pushed the clerical part of this -- namely the addition of > PublicationTable node and PublicationRelInfo struct. I attach the part > of your v4 patch that I didn't include. It contains a couple of small > corrections, but I didn't d

Re: Estimating HugePages Requirements?

On Wed, Sep 15, 2021 at 10:31:20PM +, Bossart, Nathan wrote: > +This can be used on a running server for most parameters. However, > +the server must be shut down for some runtime-computed parameters > +(e.g., , and > +). > > nitpick: I think you can remove the

RE: Column Filtering in Logical Replication

On Wednesday, September 15, 2021 8:19 PM vignesh C wrote: > I have extracted the parser code and attached it here, so that it will be > easy to > go through. We wanted to support the following syntax as in > [1]: > CREATE PUBLICATION pub1 FOR > TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2, SEQUENCE

RE: [BUG] Unexpected action when publishing partition tables

On Tuesday, September 14, 2021 10:41 PM vignesh C wrote: > On Tue, Sep 7, 2021 at 11:38 AM houzj.f...@fujitsu.com > wrote: > > > > > > Attach new version patches which addressed the comment. > > Thanks for fixing this issue. The bug gets fixed by the patch, I did not find > any > issues in my

RE: Logical replication keepalive flood

From Tuesday, September 14, 2021 1:39 PM Greg Nancarrow wrote: > However, the problem I found is that, with the patch applied, there is > a test failure when running “make check-world”: > > t/006_logical_decoding.pl 4/14 > # Failed test 'pg_recvlogical acknowledged changes' > #

Re: prevent immature WAL streaming

On 2021-Sep-15, Kyotaro Horiguchi wrote: > + CopyXLogRecordToWAL(rechdr->xl_tot_len, isLogSwitch, > + flags & > XLOG_SET_ABORTED_PARTIAL, > + rdata, StartPos, > EndPos); > > The n

Re: right join with partitioned table crash

Jaime Casanova writes: > Here's another crash caught by sqlsmith. Fun. Looks like it fails back to v12, but not in v11, so it's some optimization we added in v12 that's at fault. (That being the case, this isn't a blocker for 14rc1, though of course it'd be nice if we fix it in time for that.)

Re: Deduplicate code updating ControleFile's DBState.

On Wed, Sep 15, 2021 at 10:49:39PM +, Bossart, Nathan wrote: > Ah, I was missing this context. Perhaps this should be included in > the patch set for the other thread, especially if it will need to be > exported. This part of the patch is mentioned at the top of the thread: - LWLockAcquire(

Re: pgstat_send_connstats() introduces unnecessary timestamp and UDP overhead

On Wed, Sep 15, 2021 at 01:48:09PM -0700, Andres Freund wrote: > Will do. Although I do wish the original committer would have chimed in at > some point... Thanks, Andres. -- Michael signature.asc Description: PGP signature

Re: EXPLAIN(VERBOSE) to CTE with SEARCH BREADTH FIRST fails

I wrote: > I do not think that patch is a proper solution, but we do need to do > something about this. I poked into this and decided it's an ancient omission within ruleutils.c. The reason we've not seen it before is probably that you can't get to the case through the parser. The SEARCH stuff is

right join with partitioned table crash

Hi everyone, Here's another crash caught by sqlsmith. """ drop table if exists fkpart3_pk5 cascade; drop table if exists inet_tbl; create table fkpart3_pk5 ( a integer not null primary key ) partition by range (a); create table fkpart3_pk51 partition of fkpart3_pk5 for values from (

Re: Deduplicate code updating ControleFile's DBState.

On 9/15/21, 4:47 AM, "Amul Sul" wrote: > On Wed, Sep 15, 2021 at 12:52 AM Bossart, Nathan wrote: >> It looks like ebdf5bf intentionally made sure that we hold >> ControlFileLock while updating SharedRecoveryInProgress (now >> SharedRecoveryState after 4e87c48). The thread for this change [0] >>

Re: Estimating HugePages Requirements?

On 9/14/21, 8:06 PM, "Michael Paquier" wrote: > Attached is a refreshed patch (commit message is the same as v9 for > now), with some minor tweaks and the tests. > > Thoughts? LGTM +This can be used on a running server for most parameters. However, +the server must be shut down

Re: decoupling table and index vacuum

On Wed, Apr 21, 2021 at 8:21 AM Robert Haas wrote: > Now, the reason for this is that when we discover dead TIDs, we only > record them in memory, not on disk. So, as soon as VACUUM ends, we > lose all knowledge of whether those TIDs were and must rediscover > them. Suppose we didn't do this, and

Re: Hook for extensible parsing.

Hi, On 2021-09-15 16:51:37 -0400, Tom Lane wrote: > The other problem here is that a simple call-this-instead-of-that > top-level hook doesn't seem all that useful anyway, because it leaves > you with the task of duplicating a huge amount of functionality that > you're then going to make some twea

Re: Polyphase merge is obsolete

On 16/09/2021 00:12, Jaime Casanova wrote: On Sat, Sep 11, 2021 at 01:35:27AM -0500, Jaime Casanova wrote: On Wed, Jul 14, 2021 at 06:04:14PM +0300, Heikki Linnakangas wrote: On 14/07/2021 15:12, vignesh C wrote: On Sat, Jan 23, 2021 at 3:49 AM Heikki Linnakangas wrote: Here's an updated ver

Re: Polyphase merge is obsolete

On Sat, Sep 11, 2021 at 01:35:27AM -0500, Jaime Casanova wrote: > On Wed, Jul 14, 2021 at 06:04:14PM +0300, Heikki Linnakangas wrote: > > On 14/07/2021 15:12, vignesh C wrote: > > > On Sat, Jan 23, 2021 at 3:49 AM Heikki Linnakangas > > > wrote: > > > > Here's an updated version that fixes one bu

Re: Hook for extensible parsing.

Andres Freund writes: > Agreed - it doesn't make sense to me to have a hook that only replaces raw > parsing, without also hooking into parse-analysis. ISTM that the least a > patchset going for a parser hook would have to do is to do sufficient > restructuring so that one could hook together into

Re: pgstat_send_connstats() introduces unnecessary timestamp and UDP overhead

On 2021-09-15 10:47:33 -0400, Andrew Dunstan wrote: > this is an open item for release 14. Is someone going to commit? Will do. Although I do wish the original committer would have chimed in at some point...

Re: Hook for extensible parsing.

Hi, On 2021-09-15 16:35:53 -0400, Jonah H. Harris wrote: > On Wed, Sep 15, 2021 at 3:55 PM Andres Freund wrote: > > On 2021-09-15 12:57:00 -0400, Tom Lane wrote: > > Agreed - it doesn't make sense to me to have a hook that only replaces raw > > parsing, without also hooking into parse-analysis. I

Re: Hook for extensible parsing.

On Wed, Sep 15, 2021 at 3:55 PM Andres Freund wrote: > On 2021-09-15 12:57:00 -0400, Tom Lane wrote: > > That's not what the patch actually does, though. It only replaces > > the grammar, not semantic analysis. So you couldn't associate the > > (+)-decorated WHERE clause with the appropriate jo

mem context is not reset between extended stats

Memory allocation appeared be O(1) WRT the number of statistics objects, which was not expected to me. This is true in v13 (and probably back to v10). It seems to work fine to reset the memory context within the loop, so long as the statslist is allocated in the parent context. |DROP TABLE t; CR

Re: Hook for extensible parsing.

Hi, On 2021-09-15 12:57:00 -0400, Tom Lane wrote: > That's not what the patch actually does, though. It only replaces > the grammar, not semantic analysis. So you couldn't associate the > (+)-decorated WHERE clause with the appropriate join. (And no, > I will not accept that it's okay to perfor

Re: pg_upgrade test for binary compatibility of core data types

On 9/13/21 9:20 AM, Andrew Dunstan wrote: > On 9/12/21 2:41 PM, Andrew Dunstan wrote: >> On 9/11/21 8:51 PM, Justin Pryzby wrote: >>> @Andrew: did you have any comment on this part ? >>> >>> |Subject: buildfarm xversion diff >>> |Forking >>> https://www.postgresql.org/message-id/20210328231433.g

Re: Getting ERROR "subplan "SubPlan 1" was not initialized" in EXISTS subplan when using for list partition.

Em qua., 15 de set. de 2021 às 16:16, Ranier Vilela escreveu: > Em qua., 15 de set. de 2021 às 15:35, Tom Lane > escreveu: > >> Ranier Vilela writes: >> > Em qua., 15 de set. de 2021 às 12:00, Tom Lane >> escreveu: >> >> We could, in fact, not bother with removing the no-longer-referenced >> >

Re: Getting ERROR "subplan "SubPlan 1" was not initialized" in EXISTS subplan when using for list partition.

Em qua., 15 de set. de 2021 às 15:35, Tom Lane escreveu: > Ranier Vilela writes: > > Em qua., 15 de set. de 2021 às 12:00, Tom Lane > escreveu: > >> We could, in fact, not bother with removing the no-longer-referenced > >> subplans, and it probably wouldn't be all that awful. But the intent >

Re: automatically generating node support functions

On 17.08.21 16:36, Peter Eisentraut wrote: Here is another set of preparatory patches that clean up various special cases and similar in the node support. This set of patches has been committed. I'll close this commit fest entry and come back with the main patch series in the future.

Re: Getting ERROR "subplan "SubPlan 1" was not initialized" in EXISTS subplan when using for list partition.

Ranier Vilela writes: > Em qua., 15 de set. de 2021 às 12:00, Tom Lane escreveu: >> We could, in fact, not bother with removing the no-longer-referenced >> subplans, and it probably wouldn't be all that awful. But the intent >> of the original patch was to save the executor startup time for such

Re: proposal: possibility to read dumped table's name from file

po 13. 9. 2021 v 15:11 odesílatel Justin Pryzby napsal: > On Wed, Jul 28, 2021 at 09:28:17AM +0200, Pavel Stehule wrote: > > Here is an updated implementation of filter's file, that implements > syntax > > proposed by you. > > Thanks. > > If there's any traction for this approach. I have some co

Re: Getting ERROR "subplan "SubPlan 1" was not initialized" in EXISTS subplan when using for list partition.

Em qua., 15 de set. de 2021 às 12:00, Tom Lane escreveu: > We could, in fact, not bother with removing the no-longer-referenced > subplans, and it probably wouldn't be all that awful. But the intent > of the original patch was to save the executor startup time for such > subplans, so I wanted to

Re: Hook for extensible parsing.

On Thu, Sep 16, 2021 at 1:23 AM Julien Rouhaud wrote: > > On Thu, Sep 16, 2021 at 12:57 AM Tom Lane wrote: > > > > > The requirement is that the parser can't leak any > > > node that the rest of the system doesn't know about, but you can do > > > what you want inside the parser. > > > > That's no

Re: proposal: possibility to read dumped table's name from file

Hi po 13. 9. 2021 v 15:01 odesílatel Daniel Gustafsson napsal: > > On 28 Jul 2021, at 09:28, Pavel Stehule wrote: > > út 13. 7. 2021 v 1:16 odesílatel Tom Lane t...@sss.pgh.pa.us>> napsal: > > > Hence I suggest > > > > include table PATTERN > > exclude table PATTERN > > > > whi

Re: Hook for extensible parsing.

On Thu, Sep 16, 2021 at 12:57 AM Tom Lane wrote: > > > The requirement is that the parser can't leak any > > node that the rest of the system doesn't know about, but you can do > > what you want inside the parser. > > That's not what the patch actually does, though. It only replaces > the grammar

Re: Hook for extensible parsing.

Julien Rouhaud writes: > I'm not sure why you couldn't implement an Oracle-style outer join > with such a hook? Try it. > The requirement is that the parser can't leak any > node that the rest of the system doesn't know about, but you can do > what you want inside the parser. That's not what th

Re: Partial index "microvacuum"

On Wed, Sep 15, 2021 at 7:18 AM Marko Tiikkaja wrote: > So I've been looking at issues we used to have in production some time > ago which eventually lead us to migrating away from partial indexes in > some cases. In the end, I'm surprised how easy this (or at least a > similar case) was to repro

Re: Getting ERROR "subplan "SubPlan 1" was not initialized" in EXISTS subplan when using for list partition.

Em qua., 15 de set. de 2021 às 12:00, Tom Lane escreveu: > Ranier Vilela writes: > > I would like to ask if this alternative fix (attached) would also solve > the > > problem or not. > > If I'm reading the patch correctly, that fixes it by failing to drop > unused subplans at all --- the second

Re: Hook for extensible parsing.

On Wed, Sep 15, 2021 at 11:26 PM Tom Lane wrote: > > In the case at hand, what's troubling me is that I don't see any > particular use in merely substituting a new bison grammar, if it > still has to produce parse trees that the rest of the system will > understand. Yeah, you could make some very

Re: [Patch] ALTER SYSTEM READ ONLY

On Wed, Sep 15, 2021 at 10:32 AM Robert Haas wrote: > Putting these changes into 0001 seems to make no sense. It seems like > they should be part of 0003, or maybe a new 0004 patch. After looking at this a little bit more, I think it's really necessary to separate out all of your changes into sep

Re: mark the timestamptz variant of date_bin() as stable

On Wed, Sep 1, 2021 at 3:25 PM Tom Lane wrote: > > John Naylor writes: > > On Wed, Sep 1, 2021 at 2:44 PM Tom Lane wrote: > >> I see that these two answers are both exactly multiples of 24 hours away > >> from the given origin. But if I'm binning on the basis of "days" or > >> larger units, I w

Re: Trigger position

We can run triggers using position only, this way we don´t have these few cycles to determine ordering. On creation time we populate position, even if it's not set, so for the first time position will match trigger names. When user changes a trigger position we sum 1 to the followers. regards, Mar

Re: Trigger position

On 09/15/21 06:28, Marcos Pegoraro wrote: > Oracle and SQL Server have FOLLOWS and PRECEDES when defining trigger > execution order. Firebird has POSITION, which I like it more. Between those two, I think my vote would come down the other way, assuming FOLLOWS and PRECEDES work the way I am guess

Re: Trigger position

On 2021-Sep-15, Pavel Stehule wrote: > Triggers that depend on execution order are pretty hell. It is a clean > signal of some crazy design and overusing of triggers. Yeah. The only case I've seen where order of triggers was important (beyond the "before" / "after" classification) is where you h

Re: EXPLAIN(VERBOSE) to CTE with SEARCH BREADTH FIRST fails

Andrew Dunstan writes: > On 9/10/21 10:10 AM, torikoshia wrote: >> I've attached the patch for the changes made for this test for your >> reference, but I'm not sure it's appropriate for creating a new >> CoercionForm to fix the issue.. > This is listed as an open item for release 14. Is it plann

Re: Hook for extensible parsing.

Jim Mlodgenski writes: > On Wed, Sep 15, 2021 at 9:25 AM Simon Riggs > wrote: >> The general rule has always been that we don't just put hooks in, we >> always require an in-core use for those hooks. I was reminded of that >> myself recently. > That's not historically what has happened. There ar

Re: Trigger position

st 15. 9. 2021 v 17:14 odesílatel Euler Taveira napsal: > On Wed, Sep 15, 2021, at 10:51 AM, Alvaro Herrera wrote: > > In a computer system, alphabet letters are just a different way to > present numbers, so you just choose ASCII letters that match what you > want. You can use "AA_first_trigger"

Re: Trigger position

On Wed, Sep 15, 2021, at 10:51 AM, Alvaro Herrera wrote: > In a computer system, alphabet letters are just a different way to > present numbers, so you just choose ASCII letters that match what you > want. You can use "AA_first_trigger", "BB_second_trigger", > "AB_nope_this_is_second" and you'll b

Re: Trigger position

When I was writing my initial email I was remembering exactly this, my first basic programs. I would like this feature more because I sometimes have a mess of triggers when this trigger function is fired on several tables and it needs to be the first on this table but not on that table. And usually

Re: Hook for extensible parsing.

st 15. 9. 2021 v 16:55 odesílatel Julien Rouhaud napsal: > On Wed, Sep 15, 2021 at 10:14 PM Jim Mlodgenski wrote: > > > > On Wed, Sep 15, 2021 at 9:25 AM Simon Riggs > > wrote: > > > > > > The general rule has always been that we don't just put hooks in, we > > > always require an in-core use f

Re: EXPLAIN(VERBOSE) to CTE with SEARCH BREADTH FIRST fails

On 9/10/21 10:10 AM, torikoshia wrote: > On 2021-09-09 19:03, Peter Eisentraut wrote: >> On 07.09.21 20:31, Tom Lane wrote: >>> torikoshia writes: While working on [1], we found that EXPLAIN(VERBOSE) to CTE with SEARCH BREADTH FIRST ends up ERROR. >>> >>> Yeah.  It's failing here:

Re: Getting ERROR "subplan "SubPlan 1" was not initialized" in EXISTS subplan when using for list partition.

Ranier Vilela writes: > I would like to ask if this alternative fix (attached) would also solve the > problem or not. If I'm reading the patch correctly, that fixes it by failing to drop unused subplans at all --- the second loop you have has no external effect. We could, in fact, not bother wit

Re: Hook for extensible parsing.

On Wed, Sep 15, 2021 at 02:25:17PM +0100, Simon Riggs wrote: > On Sat, 1 May 2021 at 08:24, Julien Rouhaud wrote: > > > Being able to extend core parser has been requested multiple times, and > > AFAICT > > all previous attempts were rejected not because this isn't wanted but > > because > > th

Re: Hook for extensible parsing.

On Wed, Sep 15, 2021 at 10:14 PM Jim Mlodgenski wrote: > > On Wed, Sep 15, 2021 at 9:25 AM Simon Riggs > wrote: > > > > The general rule has always been that we don't just put hooks in, we > > always require an in-core use for those hooks. I was reminded of that > > myself recently. > > > That's

Re: [PATCH] Proof of concept for GUC improvements

Updated version attached with comment fixes and updated for new GUC. special-guc-values-v2.patch Description: Binary data

Re: Column Filtering in Logical Replication

On Wed, Sep 15, 2021, at 9:19 AM, vignesh C wrote: > I have extracted the parser code and attached it here, so that it will > be easy to go through. We wanted to support the following syntax as in > [1]: > CREATE PUBLICATION pub1 FOR > TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2, > SEQUENCE seq1,seq

Re: pgstat_send_connstats() introduces unnecessary timestamp and UDP overhead

On 9/8/21 12:11 AM, Laurenz Albe wrote: > On Fri, 2021-09-03 at 17:04 -0700, Andres Freund wrote: >> Here's how I think that would look like. While writing up this draft, I found >> two more issues: >> >> - On windows / 32 bit systems, the session time would overflow if idle for >>   longer than

Re: Getting ERROR "subplan "SubPlan 1" was not initialized" in EXISTS subplan when using for list partition.

Em ter., 14 de set. de 2021 às 17:11, Tom Lane escreveu: > Zhihong Yu writes: > > In the fix, isUsedSubplan is used to tell whether any given subplan is > used. > > Since only one subplan is used, I wonder if the array can be replaced by > > specifying the subplan is used. > > That doesn't seem

RE: [PATCH] support tab-completion for single quote input with equal sign

On Saturday, September 4, 2021 11:58 PM, Tom Lane wrote: >Actually ... those are just implementation details, and now that >I've thought about it a little more, I question the entire concept >of making single-quoted strings be single words in tab-complete's >view. I think it's quite intentional t

Re: Release 14 Schedule

On 9/15/21 10:20 AM, Robert Haas wrote: > On Wed, Sep 15, 2021 at 8:56 AM Andrew Dunstan wrote: >> The Release Management Team (Michael Paquier, Peter Geoghegan and >> myself) in consultation with the release team proposes the following >> release schedule: >> >> * PostgreSQL 14 Release Candidat

Re: [Patch] ALTER SYSTEM READ ONLY

On Wed, Sep 15, 2021 at 6:49 AM Amul Sul wrote: > Initially, I thought to > use SharedRecoveryState which is always set to RECOVERY_STATE_ARCHIVE, > if the archive recovery requested. But there is another case where > SharedRecoveryState could be RECOVERY_STATE_ARCHIVE irrespective of > ArchiveR

Re: Release 14 Schedule

On Wed, Sep 15, 2021 at 8:56 AM Andrew Dunstan wrote: > The Release Management Team (Michael Paquier, Peter Geoghegan and > myself) in consultation with the release team proposes the following > release schedule: > > * PostgreSQL 14 Release Candidate 1 (RC1) will be released on September 23, > 20

Partial index "microvacuum"

So I've been looking at issues we used to have in production some time ago which eventually lead us to migrating away from partial indexes in some cases. In the end, I'm surprised how easy this (or at least a similar case) was to reproduce. The attached program does some UPDATEs where around ever

Re: Hook for extensible parsing.

On Wed, Sep 15, 2021 at 9:25 AM Simon Riggs wrote: > > The general rule has always been that we don't just put hooks in, we > always require an in-core use for those hooks. I was reminded of that > myself recently. > That's not historically what has happened. There are several hooks with no in cor

Re: Trigger position

On 2021-Sep-15, Marcos Pegoraro wrote: > This problem can raise ... there is a trigger foo using position 1, please > choose another This is reminiscent of the old BASIC programming language, where you eventually learn to choose line numbers that aren't consecutive, so that if you later have to a

Re: On login trigger: take three

On Wed, Sep 8, 2021 at 10:56 PM Daniel Gustafsson wrote: > > I took a look at this, and while I like the proposed feature I think the patch > has a bit more work required. > Thanks for reviewing the patch. I am not the original patch author (who no longer seems active) but I've been contributing

Re: Hook for extensible parsing.

On Sat, 1 May 2021 at 08:24, Julien Rouhaud wrote: > Being able to extend core parser has been requested multiple times, and AFAICT > all previous attempts were rejected not because this isn't wanted but because > the proposed implementations required plugins to reimplement all of the core > gram

Release 14 Schedule

Greetings The Release Management Team (Michael Paquier, Peter Geoghegan and myself) in consultation with the release team proposes the following release schedule: * PostgreSQL 14 Release Candidate 1 (RC1) will be released on September 23, 2021. * In the absence of any critical issues, Postgr

Re: Trigger position

Correct, we need a field tgposition on pg_trigger and when it´s null we follow normal ordering select * from pg_trigger where tgrelid = X and tgtype = Y order by tgposition nulls last, tgname regards, Marcos Em qua., 15 de set. de 2021 às 09:35, Andreas Karlsson escreveu: > On 9/15/21 1:40 PM,

Re: SSL/TLS instead of SSL in docs

Since the approach taken wasn't to anyones liking, attached is a v4 (partly extracted from the previous patch) which only adds notes that SSL is used interchangeably with TLS in our documentation and configuration. -- Daniel Gustafsson https://vmware.com/ v4-0001-doc-Clarify-that-

Re: Column Filtering in Logical Replication

On 2021-Sep-15, vignesh C wrote: > I have extracted the parser code and attached it here, so that it will > be easy to go through. We wanted to support the following syntax as in > [1]: > CREATE PUBLICATION pub1 FOR > TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2, > SEQUENCE seq1,seq2, ALL SEQUENCES

Re: Trigger position

On 9/15/21 1:40 PM, Tom Lane wrote: Marcos Pegoraro writes: Alphabetical order of triggers sometimes makes me write a_Recalc or z_Calc to be sure it´ll be the first or the last trigger with same event of that table Oracle and SQL Server have FOLLOWS and PRECEDES when defining trigger executi

Re: Signed vs Unsigned (take 2) (src/backend/storage/ipc/procarray.c)

Em qua., 15 de set. de 2021 às 01:08, Fujii Masao < masao.fu...@oss.nttdata.com> escreveu: > > > On 2021/09/11 12:21, Fujii Masao wrote: > > > > > > On 2021/07/23 20:07, Ranier Vilela wrote: > >> Em sex., 23 de jul. de 2021 às 07:02, Aleksander Alekseev < > aleksan...@timescale.com

Re: Column Filtering in Logical Replication

On Wed, Sep 15, 2021 at 5:20 PM Alvaro Herrera wrote: > > On 2021-Sep-15, Amit Kapila wrote: > > > On Mon, Sep 6, 2021 at 11:21 PM Alvaro Herrera > > wrote: > > > > > > I pushed the clerical part of this -- namely the addition of > > > PublicationTable node and PublicationRelInfo struct. > > > >

Re: Trigger position

This way would be interesting for those are migrating from these databases too. But ok, I´ll forget it. Em qua., 15 de set. de 2021 às 08:40, Tom Lane escreveu: > Marcos Pegoraro writes: > > Alphabetical order of triggers sometimes makes me write a_Recalc or > z_Calc > > to be sure it´ll be the

Re: Trigger position

This problem can raise ... there is a trigger foo using position 1, please choose another Atenciosamente, Em qua., 15 de set. de 2021 às 07:59, Daniel Gustafsson escreveu: > > On 15 Sep 2021, at 12:28, Marcos Pegoraro wrote: > > > CREATE TRIGGER RECALC_THAT BEFORE UPDATE POSITION 1 ON ORDER

Re: BUG #15293: Stored Procedure Triggered by Logical Replication is Unable to use Notification Events

On Wed, Sep 15, 2021 at 2:57 AM Tom Lane wrote: > Hearing no comments, I pushed that. Thank you! > > I'm inclined to think we should flat-out reject LISTEN in any process > > that is not attached to a frontend, at least until somebody takes the > > trouble to add infrastructure that would let it

Re: Column Filtering in Logical Replication

On 2021-Sep-15, Amit Kapila wrote: > On Mon, Sep 6, 2021 at 11:21 PM Alvaro Herrera > wrote: > > > > I pushed the clerical part of this -- namely the addition of > > PublicationTable node and PublicationRelInfo struct. > > One point to note here is that we are developing a generic grammar for >

Re: Deduplicate code updating ControleFile's DBState.

On Wed, Sep 15, 2021 at 12:52 AM Bossart, Nathan wrote: > > On 9/13/21, 11:06 PM, "Amul Sul" wrote: > > The patch is straightforward but the only concern is that in > > StartupXLOG(), SharedRecoveryState now gets updated only with spin > > lock; earlier it also had ControlFileLock in addition to

Re: Trigger position

Marcos Pegoraro writes: > Alphabetical order of triggers sometimes makes me write a_Recalc or z_Calc > to be sure it´ll be the first or the last trigger with same event of that > table > Oracle and SQL Server have FOLLOWS and PRECEDES when defining trigger > execution order. Firebird has POSITION

Re: .ready and .done files considered harmful

Hi, Thanks for the feedback. > I wonder if this can be simplified even further. If we don't bother > trying to catch out-of-order .ready files in XLogArchiveNotify() and > just depend on the per-checkpoint/restartpoint directory scans, we can > probably remove lastReadySegNo from archiver state

Re: Added schema level support for publication.

On Tue, Sep 14, 2021 at 6:38 PM vignesh C wrote: > > I have handled this in the patch attached. > Regarding the following function in the v28-0002 patch: +/* + * Check if the relation schema is member of the schema list. + */ +static void +RelSchemaIsMemberOfSchemaList(List *rels, List *schemaid

Re: Trigger position

> On 15 Sep 2021, at 12:28, Marcos Pegoraro wrote: > CREATE TRIGGER RECALC_THAT BEFORE UPDATE POSITION 1 ON ORDERS... > CREATE TRIGGER DO_OTHER_CALC BEFORE UPDATE POSITION 2 ON ORDERS... For those not familiar with Firebird: triggers are executing in alphabetical order within a position number,

Re: [Patch] ALTER SYSTEM READ ONLY

, On Sat, Jul 24, 2021 at 1:33 AM Robert Haas wrote: > > On Thu, Jun 17, 2021 at 1:23 AM Amul Sul wrote: > > Attached is rebase for the latest master head. Also, I added one more > > refactoring code that deduplicates the code setting database state in the > > control file. The same code set the

Trigger position

Hi Hackers, Alphabetical order of triggers sometimes makes me write a_Recalc or z_Calc to be sure it´ll be the first or the last trigger with same event of that table Oracle and SQL Server have FOLLOWS and PRECEDES when defining trigger execution order. Firebird has POSITION, which I like it more

RE: Remove double check when field_name is not NULL in be-secure-openssl.c

On Wednesday, September 15, 2021 6:54 PM, Daniel Gustafsson wrote: >The proposal removes a second == NULL check on field_name in the case where >OBJ_nid2sn() returns an ASN1_OBJECT. This is not in a hot path, and the ASM >generated is equal under optimization levels so I don't see the value in t

Re: Remove double check when field_name is not NULL in be-secure-openssl.c

> On 15 Sep 2021, at 10:06, tanghy.f...@fujitsu.com wrote: > Attached a small fix to remove double check when field_name is not NULL in > be-secure-openssl.c. > The double check is introduced in 13cfa02f7 for "Improve error handling in > backend OpenSSL implementation". The proposal removes a s

Re: Physical replication from x86_64 to ARM64

> On Tue, Sep 14, 2021 at 08:07:19AM -0700, Andres Freund wrote: > > >Yeah. As far as the hardware goes, if you have the same endianness, > >struct alignment rules, and floating-point format [1], then physical > >replication ought to work. Where things get far stickier is if the > >operating syst

  1   2   >