Hello Ryohei,
4. The client wants to close the connection while leaving the job to
the server.
In this case, "statement_timeout" can't satisfy at line 4.
Why?
ISTM that "leaving the job" to the server with a client-side connection
closed is basically an abort, no different from what
(2018/12/17 22:09), Etsuro Fujita wrote:
Here is a set of WIP patches for pushing down ORDER BY LIMIT to the remote:
For some regression test cases with ORDER BY and/or LIMIT, I noticed
that these patches still cannot push down those clause to the remote. I
guess it would be needed to tweak
On Sat, Nov 24, 2018 at 11:29:22AM -0500, Jeff Janes wrote:
> I noticed that the existing codebase does not have a consensus on what to
> pass to WaitLatch for the timeout when the timeout isn't relevant. I picked
> 0, but -1L also has precedent.
WaitLatch enforces the timeout to -1 if WL_TIMEOUT
st 26. 12. 2018 v 6:09 odesílatel Michael Paquier
napsal:
> On Wed, Dec 19, 2018 at 07:04:50AM +0100, Pavel Stehule wrote:
> > I can imagine some tracking extension, that will do some
> > initializations on plpgsql_stmt_block statement hook - but the most
> > important will not be called ever.
>
On Tue, Oct 30, 2018 at 11:44:42AM +0100, Daniel Gustafsson wrote:
> Circling back to this, I updated the patch with providing another
> option as I couldn’t think of another way to do it cleanly. I’ll
> add the patch to the next CF but as it’s just about to start it
> should be moved to the next
On Wed, Dec 26, 2018 at 02:05:26PM +0900, Tatsuro Yamada wrote:
> Do you mean my "fix_manual_of_alter_index_v2.patch"?
Nope. This patch is only a proposal for the documentation. The main
patch to extend psql completion so as column numbers are suggested
fails to apply.
--
Michael
On Wed, Dec 19, 2018 at 07:04:50AM +0100, Pavel Stehule wrote:
> I can imagine some tracking extension, that will do some
> initializations on plpgsql_stmt_block statement hook - but the most
> important will not be called ever.
I was just studying this stuff and reviewing this patch with fresh
On 2018/12/26 13:50, Michael Paquier wrote:
On Tue, Dec 25, 2018 at 02:27:03PM +0900, Michael Paquier wrote:
Thanks, I have committed this one after making the logic to ignore
column numbers a bit smarter, one problem being that "ALTER INDEX foo
ALTER COLUMN" would try to suggest SET STATISTICS
On 2018/12/25 14:27, Michael Paquier wrote:
On Tue, Dec 25, 2018 at 10:56:04AM +0900, Tatsuro Yamada wrote:
Hmm... Okey, I agree. Why I implemented the exotic part of the
feature is that it is for user-friendly. However, I suppose that
user know the syntax because the syntax is used by an
On Tue, Dec 25, 2018 at 02:27:03PM +0900, Michael Paquier wrote:
> Thanks, I have committed this one after making the logic to ignore
> column numbers a bit smarter, one problem being that "ALTER INDEX foo
> ALTER COLUMN" would try to suggest SET STATISTICS directly, which is
> incorrect. Instead
On Fri, Dec 07, 2018 at 07:48:39PM +0100, Lætitia Avrot wrote:
> Here's the patch.
> The patch should apply to MASTER. I built and tested it successfully on my
> laptop.
>
> I'll add it to January's commitfest.
What's proposed here looks good to me, and all the grounds are
covered, so I am
Thank you Imai-san.
On 2018/12/25 16:47, Imai, Yoshikazu wrote:
> Here's the continuation of the review. Almost all of below comments are
> little fixes.
>
> ---
> 0001: line 76-77
> In commit message:
> exclusion for target child relation, which is no longer
> is no longer needed.
Hi Fabien.
On Wed, Dec 26, 2018 at 3:02 AM, Fabien COELHO wrote:
> About the patches: you are expected to send consistent patches, i.e. one
> feature with its associated documentation, not two separate features and
> another patch for documenting them.
Thank you for teaching me.
I rewrote patches
Hi!
On Tue, Dec 25, 2018 at 7:05 PM Alvaro Herrera wrote:
> But then I'm not clear *why* you would like to do a non-concurrent
> refresh.
I mostly wanted to support if for two reasons:
- completeness: maybe we cannot imagine the use case yet, but somebody
might in the future
- getting trigger
On 2018-Dec-25, Mitar wrote:
> On Tue, Dec 25, 2018 at 6:47 PM Alvaro Herrera
> wrote:
> > > I made another version of the patch. This one does UPDATEs for changed
> > > row instead of DELETE/INSERT.
> > >
> > > All existing regression tests are still passing (make check).
> >
> > Okay, but you
Hi!
On Tue, Dec 25, 2018 at 6:47 PM Alvaro Herrera wrote:
> > I made another version of the patch. This one does UPDATEs for changed
> > row instead of DELETE/INSERT.
> >
> > All existing regression tests are still passing (make check).
>
> Okay, but you don't add any for your new feature, which
On 2018-Dec-24, Mitar wrote:
> I made another version of the patch. This one does UPDATEs for changed
> row instead of DELETE/INSERT.
>
> All existing regression tests are still passing (make check).
Okay, but you don't add any for your new feature, which is not good.
--
Álvaro Herrera
On 2018-Dec-26, Michael Paquier wrote:
> + /*
> +* If we are reporting to a terminal, send a carriage return so that we
> +* stay on the same line. If not, send a newline.
> +*/
> + if (isatty(fileno(stderr)))
> + fprintf(stderr, "\r");
> + else
> + fprintf(stderr,
Hi,
On Tue, Dec 25, 2018 at 2:59 AM, Fabien COELHO wrote:
> >> 4. The client wants to close the connection while leaving the job to
> >> the server.
> >> In this case, "statement_timeout" can't satisfy at line 4.
>
> Why?
> ISTM that "leaving the job" to the server with a client-side connection
>
Hi,
On Fri, Dec 21, 2018 at 5:08 PM, Tom Lane wrote:
> I don't think I buy that argument; it falls down as soon as you consider
> characters above U+. I worry that by supporting UTF16, we'd basically
> be encouraging users to write code that fails on such characters, which
> doesn't seem
On Tue, Dec 25, 2018 at 07:05:30PM +0100, Fabien COELHO wrote:
> You use 1024² bytes. What about 100 bytes per MB, as the unit is about
> stored files?
>
> Also, you did not answer to my other points:
> - use "instr_time.h" for better precision
> - invert sizeonly
> - reuse a test
It
On Tue, Dec 25, 2018 at 10:32:34AM +0100, Fabien COELHO wrote:
> Joyeuses fêtes !
Merci. You too Happy New Year and Merry christmas. (Sentence valid
for all folks reading this email, as well as folks not reading it).
--
Michael
signature.asc
Description: PGP signature
On Tue, Dec 25, 2018 at 10:22:30AM -0500, Tom Lane wrote:
> The text still seems a bit awkward. Maybe "... to be used when initdb
> is run without the ..."
like the attached perhaps? At the same time I am thinking about
reformulating the second sentence as well..
--
Michael
diff --git
On Wed, Dec 19, 2018 at 4:17 AM REIX, Tony wrote:
> Here is the patch we are using now on AIX for enabling SysV shm for AIX,
> which improves greatly the performance on AIX.
>
> It is compile time.
>
> It seems to me that you'd like this to become a shared_memory_type GUC.
> Correct? However, I
On Tue, Dec 25, 2018 at 4:32 AM Alexander Korotkov
wrote:
> On Tue, Dec 25, 2018 at 12:19 AM Alexander Korotkov
> wrote:
> > So, we're checking for conflict on tree root for every entry insert.
> > That's right for posting tree, but completely unneeded for entry tree.
> > I'm intended to change
On 12/25/18 3:48 AM, David Rowley wrote:
> On Tue, 25 Dec 2018 at 13:46, Tomas Vondra
> wrote:
>> I however observe failures on 4 regression test suites - inherit,
>> equivclass, partition_join and partition_prune (diff attached). That's a
>> bit surprising, because AFAICS the patch merely
Hi!
On Tue, Dec 25, 2018 at 10:03 AM David Fetter wrote:
> If it helps you think about it better, all NOTIFICATIONs are sent on
> COMMIT, i.e. you don't need to worry as much about what things should
> or shouldn't have arrived. The down side, such as it is, is that they
> don't convey premature
I think MB indeed makes more sense than kB, so I have changed that now
in V7, per attached.
You use 1024² bytes. What about 100 bytes per MB, as the unit is about
stored files?
Also, you did not answer to my other points:
- use "instr_time.h" for better precision
- invert sizeonly
-
On Mon, Dec 24, 2018 at 04:13:44PM -0800, Mitar wrote:
> Hi!
>
> Thanks for reply!
>
> On Mon, Dec 24, 2018 at 2:20 PM David Fetter wrote:
> > You've got the right mailing list, a description of what you want, and
> > a PoC patch. You also got the patch in during the time between
> >
Hi,
Am Dienstag, den 25.12.2018, 12:12 +0100 schrieb Fabien COELHO:
> > Given the speed of verifying checksums and its storage-oriented status, I
> > also still think that a (possibly fractional) MB (1,000,000 bytes), or even
> > GB, is the right unit to use for reporting this progress. On my
Bonjour Daniel,
But the copy-workflow and non-copy-workflow are different, and in
order to know which one to start, \g would need to analyze the query
It turns out I was wrong on this. The workflows are different but when
psql receives the first PGresult, it's still time to handle the I/O
Michael Paquier writes:
> On Mon, Dec 24, 2018 at 01:05:25PM +0900, Ian Barwick wrote:
>> Attached is mainly to fix a comment in $subject which has a typo in
>> the referenced initdb option ("--walsegsize", should be
>> "--wal-segsize"), and while I'm there also adds a couple of "the"
>> for
こんにちは Royhei,
About the patches: you are expected to send consistent patches, i.e. one
feature with its associated documentation, not two separate features and
another patch for documenting them.
--
Fabien.
I'm not sure I understand the use case you have that needs these new
extensions.
If you face the following situation, this parameter will be needed.
1. The connection between the server and the client has been established
normally.
2. A server process has been received SQL statement.
3. The
Hello Surafel,
Thank you for informing, Here is an updated patch against current master
Patch applies cleanly, compiles, "make check" is okay, but given that the
feature is not tested...
Feature should be tested somewhere.
ISTM that command-line switches with optional arguments should
Given the speed of verifying checksums and its storage-oriented status, I
also still think that a (possibly fractional) MB (1,000,000 bytes), or even
GB, is the right unit to use for reporting this progress. On my laptop (SSD),
verifying runs at least at 1.26 GB/s (on one small test), there
Hallo Michael,
V5 attached.
Patch applies cleanly, compiles, global & local make check are ok.
Given that the specific output is not checked, I do not think that the -P
check deserves a test on its own, I think that the -P option could simply
be added to any of the existing tests.
I'm
Is there any way that one of the Postgres Background process may go down?
meaning the process getting stopped?
For example, can the wal sender process alone stop working? If it does so,
which part of the logs I must check to proceed further.
-
--
Thanks,
Rajan.
--
Sent from:
Hi!
Sometimes materialized views are used to cache a complex query on
which a client works. But after client disconnects, the materialized
view could be deleted. Regular VIEWs and TABLEs both have support for
temporary versions which get automatically dropped at the end of the
session. It seems
Bonjour Michaël,
I do not see Michaël's issue [...]
Sorry for the noise.
No big deal!
-- PostgreSQL database "foo" dump
Or "pg_dumpall" could issue a comment line in the output telling which
database is being considered.
Mentioning which database dump has been completed in the end
Hallo Michael,
Yeah, new rebased version attached.
Patch v8 applies cleanly, compiles, global & local make check are ok.
A few comments:
About added tests: the node is left running at the end of the script,
which is not very clean. I'd suggest to either move the added checks
before
On Tue, Dec 25, 2018 at 09:36:05AM +0100, Fabien COELHO wrote:
> I do not see Michaël's issue, and do not see how it could be so, for me the
> whole database-specific section generated by the underlying "pg_dump" call
> is removed, as expected.
>
> All is well for me, I turned the patch as ready.
On Tue, 25 Dec 2018 at 08:04, Dean Rasheed wrote:
> Take a look at this code in AfterTriggerSaveEvent():
>
Note that the intention behind that code is that in the (fairly
common) case where an insert or update operation is known to not lead
to any potential PK/UNIQUE index violations, the
Hello Andrew,
Rebased and updated patch attached.
Here is a review of v5, sorry for the delay.
Patch applies cleanly, compiles, "make check" is ok.
I do not see Michaël's issue, and do not see how it could be so, for me
the whole database-specific section generated by the underlying
On Fri, Nov 30, 2018 at 12:24:04PM +1300, Thomas Munro wrote:
> The tests pass and show the feature working correctly. I think this
> is getting close to committable. I see that Magnus has signed up as
> committer.
It has been one month since this message, and the patch is marked as
ready for
On Mon, 24 Dec 2018 at 23:57, Corey Huinker wrote:
>
> So I took a first pass at this, and I got stuck.
>
> [snip]
>
> Any idea where I went wrong?
Take a look at this code in AfterTriggerSaveEvent():
/*
* If the trigger is a deferred unique constraint check trigger, only
46 matches
Mail list logo
