On 05/10/2018 15:26, Peter Eisentraut wrote:
> It looked for a moment that
>
> isCompleteQuery = (context <= PROCESS_UTILITY_QUERY)
>
> in ProcessUtilitySlow() might be a problem, since that omits
> PROCESS_UTILITY_QUERY_NONATOMIC, but it's not actually a problem, since
> the commands that ru
On 02/10/2018 00:06, Alvaro Herrera wrote:
> Re-reading the implementation in standard_ProcessUtility, I wonder what
> is PROCESS_UTILITY_QUERY_NONATOMIC -- there seems to be a maze through
> SPI that determines whether this flag is set or not, which could affect
> whether the event trigger is usef
On 2018-Oct-01, Peter Eisentraut wrote:
> The following appears to work:
>
> CREATE FUNCTION evt_automatic_restart_point() RETURNS event_trigger
> LANGUAGE plpgsql
> AS $$
> BEGIN
> PERFORM pg_create_restore_point(tg_tag);
> END
> $$;
>
> CREATE EVENT TRIGGER automatic_restart_point ON ddl_com
On 01/10/2018 05:34, Alvaro Herrera wrote:
> I don't see it as clear cut as all that ... particularly considering
> that a useful event trigger runs *after* the DDL command in question has
> already written all its WAL, so such a restore point would be completely
> useless. (Or are ddl_command_sta
On 2018-Jul-02, Jaime Casanova wrote:
> You can also create a normal trigger BEFORE TRUNCATE to create a
> restore point just before running the TRUNCATE command.
On every single table?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DB
On 2018-Sep-30, Michael Paquier wrote:
> On Fri, Sep 28, 2018 at 09:13:17PM +0200, Peter Eisentraut wrote:
> > I think this should be done using event triggers. Right now, you just
> > have it hardcoded to TRUNCATE and DROP TABLE, which seems somewhat
> > arbitrary. With event triggers, you have
On Fri, Sep 28, 2018 at 09:13:17PM +0200, Peter Eisentraut wrote:
> I think this should be done using event triggers. Right now, you just
> have it hardcoded to TRUNCATE and DROP TABLE, which seems somewhat
> arbitrary. With event triggers, you have the full flexibility to do
> what you want. Yo
On 06/09/2018 02:16, Yotsunaga, Naoki wrote:
> -Original Message-
> From: Yotsunaga, Naoki [mailto:yotsunaga.na...@jp.fujitsu.com]
> Sent: Tuesday, June 26, 2018 10:18 AM
> To: Postgres hackers
> Subject: automatic restore point
>
>> Hi, I attached a patch
-Original Message-
From: Yotsunaga, Naoki [mailto:yotsunaga.na...@jp.fujitsu.com]
Sent: Tuesday, June 26, 2018 10:18 AM
To: Postgres hackers
Subject: automatic restore point
>Hi, I attached a patch to output the LSN before execution to the server log
>>when executing a specifi
2018-08-31 10:14 GMT+02:00 Yotsunaga, Naoki
:
> -Original Message-
> From: Yotsunaga, Naoki [mailto:yotsunaga.na...@jp.fujitsu.com]
> Sent: Tuesday, June 26, 2018 10:18 AM
> To: Postgres hackers
> Subject: automatic restore point
>
> Hi, I attached a patch to
-Original Message-
From: Yotsunaga, Naoki [mailto:yotsunaga.na...@jp.fujitsu.com]
Sent: Tuesday, June 26, 2018 10:18 AM
To: Postgres hackers
Subject: automatic restore point
Hi, I attached a patch to output the LSN before execution to the server log
when executing a specific command
On Fri, Jul 13, 2018 at 08:16:00AM +, Yotsunaga, Naoki wrote:
> Do you feel it is too complicated?
In short, yes.
--
Michael
signature.asc
Description: PGP signature
>-Original Message-
>From: Michael Paquier [mailto:mich...@paquier.xyz]
>Sent: Wednesday, July 11, 2018 3:34 PM
>Well, if you put in place correct measures from the start you would not have
>problems.
>It seems to me that there is no point in implementing something which is a
>solutio
On Wed, Jul 11, 2018 at 06:11:01AM +, Yotsunaga, Naoki wrote:
> I want to hear about the following in addition to the previous
> comment. What would you do if your customer dropped the table and asked you
> to
> restore it?
I can think of 4 reasons on top of my mind:
1) Don't do that.
2) Im
rs,
>but it is troubled if another table B disappears. So, when the table B is
>dropped, automatic restore point works. In the table A, automatic restore
>point does not work.
>So, it is difficult to implement that automatic restore point in postgresql by
>default.
>Is my inte
>-Original Message-
>From: Jaime Casanova [mailto:jaime.casan...@2ndquadrant.com]
>Sent: Tuesday, July 3, 2018 11:06 AM
>Thinking on Michael's suggestion of using event triggers, you can create an
>event >trigger to run pg_create_restore_point() on DROP, here's a simple
>example of how
t the application (user) is interested in which table?
For example, there are two tables A. It is ok even if one table disappears, but
it is troubled if another table B disappears. So, when the table B is dropped,
automatic restore point works. In the table A, automatic restore point does not
wor
On Mon, 2 Jul 2018 at 20:07, Yotsunaga, Naoki
wrote:
>
> Hi. Thanks for comments.
>
> Explanation of the background of the function proposal was inadequate.
> So, I explain again.
>
> I assume the following situation.
> User needs to make a quick, seemingly simple fix to an important production
>
On Tue, Jul 03, 2018 at 01:06:31AM +, Yotsunaga, Naoki wrote:
>> I'd rather spend effort making the initial execution of said commands
>> less likely.
>
> I think that the function to prohibit DELETE and UPDATE without a
> WHERE clause in the later response is good way.
This has popped up alre
On Tue, Jul 03, 2018 at 01:07:41AM +, Yotsunaga, Naoki wrote:
>> There is also recovery_target_lsn which is new as of v10.
> In this method, it is necessary to look at a lsn position before operating.
> But I assume the user who did not look it before operating.
> So I think that this method
uesday, June 26, 2018 2:31 PM
To: Yotsunaga, Naoki/四ツ永 直輝
Cc: Postgres hackers
Subject: Re: automatic restore point
On Tue, Jun 26, 2018 at 01:17:31AM +, Yotsunaga, Naoki wrote:
> The following is a description of "automatic restore point".
> 【Background】
> When DBA'
possibility of executing the wrong
command, but I thought that the possibility could not be completely eliminated.
So I proposed the “automatic restore point”.
With this function, user can recover quickly and reliably even if you perform a
failure operation.
> I'd rather spend effort ma
On Tue, Jun 26, 2018 at 01:17:31AM +, Yotsunaga, Naoki wrote:
> The following is a description of "automatic restore point".
> 【Background】
> When DBA's operation failure, for example DBA accidently drop table,
> the database is restored from the file system back
On Mon, Jun 25, 2018 at 11:01:06PM -0400, Isaac Morland wrote:
> I think an optional setting making DELETE and UPDATE without a WHERE clause
> illegal would be handy. Obviously this would have to be optional for
> backward compatibility. Perhaps even just a GUC setting, with the intent
> being that
> On Jun 26, 2018, at 12:37 AM, Justin Pryzby wrote:
>
> I think you'll get that behavior with ON_ERROR_ROLLBACK.
>
Awesome. Thanks!
On Tue, Jun 26, 2018 at 12:04:59AM -0400, Rui DeSousa wrote:
> Why not use auto commit off in the session or .psqlrc file or begin and then
> use rollback? \set AUTOCOMMIT off
>
> What would be nice is if a syntax error didn’t abort the transaction when
> auto commit is off — being a bad typist
Why not use auto commit off in the session or .psqlrc file or begin and then
use rollback? \set AUTOCOMMIT off
What would be nice is if a syntax error didn’t abort the transaction when auto
commit is off — being a bad typist.
On 25 June 2018 at 21:33, David G. Johnston
wrote:
> On Mon, Jun 25, 2018 at 6:17 PM, Yotsunaga, Naoki <
> yotsunaga.na...@jp.fujitsu.com> wrote:
>
>>
>> So what do you think about it? Do you think is it useful?
>>
>
> I'd rather spend effort making the initial execution of said commands les
On Mon, Jun 25, 2018 at 6:17 PM, Yotsunaga, Naoki <
yotsunaga.na...@jp.fujitsu.com> wrote:
>
> So what do you think about it? Do you think is it useful?
>
The cost/benefit ratio seems low...
Also, when recovering with the current specification, tables other than the
> returned table also re
Hi, I'm a newbie to the hackers but I'd like to propose the "automatic restore
point" feature.
This feature automatically create backup label just before making a huge change
to DB. It's useful when this change is accidental case.
The following is a description of
30 matches
Mail list logo
