On Fri, Oct 18, 2019 at 8:45 AM Dilip Kumar wrote:
>
> On Thu, Oct 17, 2019 at 4:00 PM Amit Kapila wrote:
> >
> > On Thu, Oct 17, 2019 at 3:25 PM Dilip Kumar wrote:
> > >
> > > On Thu, Oct 17, 2019 at 2:12 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Thu, Oct 17, 2019 at 5:30 PM Amit
On Fri, Oct 18, 2019 at 7:32 AM Michael Paquier wrote:
>
> On Thu, Oct 17, 2019 at 08:00:15PM +0200, Julien Rouhaud wrote:
> > Jehan-Guillaume (in Cc) reported me today a problem with logical
> > replication, where in case of network issue the walsender is correctly
> > terminating at the given
On Thu, Oct 17, 2019 at 08:00:15PM +0200, Julien Rouhaud wrote:
> Jehan-Guillaume (in Cc) reported me today a problem with logical
> replication, where in case of network issue the walsender is correctly
> terminating at the given wal_sender_timeout but the logical worker
> kept waiting
On Fri, Oct 18, 2019 at 9:41 AM Dilip Kumar wrote:
>
> On Wed, Oct 16, 2019 at 7:22 PM Heikki Linnakangas wrote:
> >
> > On 16 October 2019 12:57:03 CEST, Amit Kapila
> > wrote:
> > >On Tue, Oct 15, 2019 at 7:13 PM Heikki Linnakangas
> > >wrote:
> > >> All things
> > >> considered, I'm not
On Fri, Oct 18, 2019 at 9:34 AM Dilip Kumar wrote:
>
> On Thu, Oct 17, 2019 at 6:32 PM Dilip Kumar wrote:
> >
> > On Thu, 17 Oct 2019, 14:59 Amit Kapila, wrote:
> >>
> >> On Thu, Oct 17, 2019 at 1:47 PM Dilip Kumar wrote:
> >> >
> >> > On Thu, Oct 17, 2019 at 12:27 PM Heikki Linnakangas
> >>
On Thu, Oct 17, 2019 at 10:51 AM Thomas Munro wrote:
>
> On Fri, Sep 13, 2019 at 1:35 AM Robert Haas wrote:
> > On Thu, Sep 12, 2019 at 8:55 AM Amit Kapila wrote:
> > > Robert, Thomas, do you have any more suggestions related to this. I
> > > am planning to commit the above-discussed patch
On Wed, Oct 16, 2019 at 7:22 PM Heikki Linnakangas wrote:
>
> On 16 October 2019 12:57:03 CEST, Amit Kapila wrote:
> >On Tue, Oct 15, 2019 at 7:13 PM Heikki Linnakangas
> >wrote:
> >> All things
> >> considered, I'm not sure which is better.
> >
> >Yeah, this is a tough call to make, but if we
On Thu, Oct 17, 2019 at 6:32 PM Dilip Kumar wrote:
>
> On Thu, 17 Oct 2019, 14:59 Amit Kapila, wrote:
>>
>> On Thu, Oct 17, 2019 at 1:47 PM Dilip Kumar wrote:
>> >
>> > On Thu, Oct 17, 2019 at 12:27 PM Heikki Linnakangas
>> > wrote:
>> > >
>> > > On 17/10/2019 05:31, Amit Kapila wrote:
>> > >
Hi all,
How to fetch certain number of tuples from a postgres table.
Same I am doing in oracle using following lines by setting prefetch attribute.
For oracle
// Prepare query
if( OCIStmtPrepare( myOciStatement, myOciError, (text *)aSqlStatement,
// Get statement type
OCIAttrGet(
On Fri, Oct 18, 2019, 11:43 Amit Kapila wrote:
> On Thu, Oct 17, 2019 at 3:10 PM Tom Lane wrote:
> >
> > Amit Kapila writes:
> > > Another idea could be each index AM tell whether it uses
> > > maintainence_work_mem or not and based on that we can do the
> > > computation (divide the
On Thu, Oct 17, 2019 at 4:00 PM Amit Kapila wrote:
>
> On Thu, Oct 17, 2019 at 3:25 PM Dilip Kumar wrote:
> >
> > On Thu, Oct 17, 2019 at 2:12 PM Masahiko Sawada
> > wrote:
> > >
> > > On Thu, Oct 17, 2019 at 5:30 PM Amit Kapila
> > > wrote:
> > > >
> > > > Another point in this regard is
On Thu, Oct 17, 2019 at 10:10:17PM +0200, Lars Kanis wrote:
> That's why I changed connectDBComplete() only, instead of setting the
> status directly in parse_int_param().
Yes, you shouldn't do that as the keepalive parameters and
tcp_user_timeout have some specific handling when it comes to
On Thu, Oct 17, 2019 at 4:58 PM Kyotaro Horiguchi
wrote:
>
> At Thu, 17 Oct 2019 16:30:02 +0900, Michael Paquier
> wrote in
> > On Thu, Oct 17, 2019 at 06:37:11PM +1300, Thomas Munro wrote:
> > > -1 for these macros.
> > >
> > > These are basic facts about the C language. I hope C eventually
>
On Thu, Oct 17, 2019 at 3:10 PM Tom Lane wrote:
>
> Amit Kapila writes:
> > Another idea could be each index AM tell whether it uses
> > maintainence_work_mem or not and based on that we can do the
> > computation (divide the maintainence_work_mem by the number of such
> > indexes during
On Thu, Oct 17, 2019 at 6:05 PM Masahiko Sawada wrote:
>
> On Thu, Oct 17, 2019 at 6:13 PM Amit Kapila wrote:
> >
> > On Wed, Oct 16, 2019 at 5:35 PM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, Oct 16, 2019 at 3:48 PM Amit Kapila
> > > wrote:
> > > >
> > > >
> > > > It is not that
On Fri, Oct 18, 2019 at 1:21 AM Tom Lane wrote:
> Thomas Munro writes:
> > On Tue, Oct 15, 2019 at 1:55 PM Tom Lane wrote:
> >> and now prairiedog has shown it too:
> >> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog=2019-10-14%2021%3A45%3A47
> >> which is positively
On Thu, Oct 17, 2019 at 06:56:48AM -0300, Alvaro Herrera wrote:
> On 2019-Oct-17, Michael Paquier wrote:
>> pgstat_progress_end_command() is done for REINDEX CONCURRENTLY after
>> the concurrent drop, so it made sense to me to still report any PID
>> REINDEX CONC is waiting for at this stage.
>
>
Dear Tom Lane
Thank you so much for your comment.
> * Upthread you asked about changing the lock level to be AccessExclusiveLock
> if
> the trigger already exists, but the patch doesn't actually do that. Which is
> fine by
> me, because that sounds like a perfectly bad idea.
Why I suggested
On Thu, Oct 17, 2019 at 12:34:44PM +0100, Dagfinn Ilmari Mannsåker wrote:
> Would it be possible to wrap them in some #if(n)def guard so that
> they're available when building out-of-tree extensions, but not when
> building postgres itself?
Not sure that's worth the trouble. If there are no
Greetings,
* Justin Pryzby (pry...@telsasoft.com) wrote:
> On Thu, Oct 17, 2019 at 12:24:10PM +0200, Tom Lane wrote:
> > Alternatively, we could revoke the requirement to use "-f -" in 12,
> > and wait a couple releases before enforcing it. The fundamental
> > problem here is that we tried to go
On Thu, Oct 17, 2019 at 3:52 PM Thomas Munro wrote:
> I rebased this patch, and tweaked get_collation_action_version() very
> slightly so that you get collation version change detection (of the
> ersatz kind provided by commit d5ac14f9) for the default collation
> even when not using ICU. Please
I verified that all other integer parameters properly set CONNECTION_BAD
in case of invalid values. These are:
* port
* keepalives_idle
* keepalives_interval
* keepalives_count
* tcp_user_timeout
That's why I changed connectDBComplete() only, instead of setting the
status directly in
Greetings,
libpq since PostgreSQL-12 has stricter checks for integer values in
connection parameters. They were introduced by commit
https://github.com/postgres/postgres/commit/e7a2217978d9cbb2149bfcb4ef1e45716cfcbefb
.
However in case of "connect_timeout" such an invalid integer value leads
to
Hello,
Jehan-Guillaume (in Cc) reported me today a problem with logical
replication, where in case of network issue the walsender is correctly
terminating at the given wal_sender_timeout but the logical worker
kept waiting indefinitely.
The issue is apparently a simple thinko, the timestamp of
I'm not sure if this can be considered a bug or not, but it is perhaps
unexpected. I found that when using a view that is simply select * from
table, then doing INSERT ... ON CONFLICT ON CONSTRAINT constraint_name on
that view, it does not find the constraint and errors out. But it does
find the
On 2019-Oct-10, Ildar Musin wrote:
> 1. Unlike FDW API, in pluggable storage API there are no routines like
> "begin modify table" and "end modify table" and there is no shared
> state between insert/update/delete calls.
Hmm. I think adding a begin/end to modifytable is a reasonable thing to
do
On Thu, Oct 17, 2019 at 12:24:10PM +0200, Tom Lane wrote:
> Alternatively, we could revoke the requirement to use "-f -" in 12,
> and wait a couple releases before enforcing it. The fundamental
> problem here is that we tried to go from "-f - doesn't work" to
> "you must use -f -" with no grace
> 2019年10月11日 下午9:50，Konstantin Knizhnik 写道：
>
>
>
> On 11.10.2019 15:15, 曾文旌(义从) wrote:
>> Dear Hackers,
>>
>> This propose a way to develop global temporary tables in PostgreSQL.
>>
>> I noticed that there is an "Allow temporary tables to exist as empty by
>> default in all sessions" in
}
out:
return ret;
}
I logs I have:
N:NDRX:5:b86e6a53:
3940:7f4ccc218300:012:20191017:091547294:a_open_entry:tmi/xa.c:0365:atmi_xa_open_entry
RMID=1
N:NDRX:5:b86e6a53:
3940:7f4ccc218300:012:20191017:091547294:a_open_entry:switch.c:0295:Connection
name: [20191017-91547294-11]
N:NDRX:5:b86e
On 2019-Sep-26, Alvaro Herrera wrote:
> On 2019-Sep-26, Jeff Janes wrote:
> > Hi Alvaro, does this count as a review?
>
> Well, I'm already a second pair of eyes for Craig's code, so I think it
> does :-) I would have liked confirmation from Craig that my change
> looks okay to him too, but
On Thu, 17 Oct 2019, 14:59 Amit Kapila, wrote:
> On Thu, Oct 17, 2019 at 1:47 PM Dilip Kumar wrote:
> >
> > On Thu, Oct 17, 2019 at 12:27 PM Heikki Linnakangas
> wrote:
> > >
> > > On 17/10/2019 05:31, Amit Kapila wrote:
> > > >
> > > > The patch looks good to me. I have slightly modified the
On Thu, Oct 17, 2019 at 6:13 PM Amit Kapila wrote:
>
> On Wed, Oct 16, 2019 at 5:35 PM Masahiko Sawada wrote:
> >
> > On Wed, Oct 16, 2019 at 3:48 PM Amit Kapila wrote:
> > >
> > >
> > > It is not that currently, other indexes don't use any additional
> > > memory (except for
Thomas Munro writes:
> On Tue, Oct 15, 2019 at 1:55 PM Tom Lane wrote:
>> and now prairiedog has shown it too:
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog=2019-10-14%2021%3A45%3A47
>> which is positively fascinating, because prairiedog is running a
>> bronze-age version
Andres Freund writes:
> Hi,
>
> On 2019-10-17 06:58:27 -0300, Alvaro Herrera wrote:
>> On 2019-Oct-17, Michael Paquier wrote:
>>
>> > On Thu, Oct 17, 2019 at 01:04:50AM -0700, Andres Freund wrote:
>> > > Wonder if it's worth removing the backward compat ones from master? I
>> > > don't quite
At Thu, 17 Oct 2019 16:30:02 +0900, Michael Paquier wrote
in
> On Thu, Oct 17, 2019 at 06:37:11PM +1300, Thomas Munro wrote:
> > -1 for these macros.
> >
> > These are basic facts about the C language. I hope C eventually
> > supports {} like C++, so that you don't have to think hard about
>
Hello,
Failed regression test. It's necessary to change the first a in “allowed
step characters are” to uppercase A in the regression test of
002_pgbench_no_server.pl.
Argh. I think I ran the test, then stupidly updated the message afterwards
to better match best practices, without
Hi,
On 2019-10-17 06:58:27 -0300, Alvaro Herrera wrote:
> On 2019-Oct-17, Michael Paquier wrote:
>
> > On Thu, Oct 17, 2019 at 01:04:50AM -0700, Andres Freund wrote:
> > > Wonder if it's worth removing the backward compat ones from master? I
> > > don't quite think so, but...
> >
> > I would
On Thu, Oct 17, 2019 at 3:25 PM Dilip Kumar wrote:
>
> On Thu, Oct 17, 2019 at 2:12 PM Masahiko Sawada wrote:
> >
> > On Thu, Oct 17, 2019 at 5:30 PM Amit Kapila wrote:
> > >
> > > Another point in this regard is that the user anyway has an option to
> > > turn off the cost-based vacuum. By
On 2019-Oct-17, Michael Paquier wrote:
> On Thu, Oct 17, 2019 at 01:04:50AM -0700, Andres Freund wrote:
> > Wonder if it's worth removing the backward compat ones from master? I
> > don't quite think so, but...
>
> I would vote for the removal so as we'll never see that again in
> core. Let's
On 2019-Oct-17, Michael Paquier wrote:
> On Thu, Oct 17, 2019 at 05:33:22AM -0300, Alvaro Herrera wrote:
> > Hmm, I wonder if it isn't the right solution to set 'progress' to false
> > in that spot, instead. index_drop says it must only be called by the
> > dependency machinery; are we depending
On Thu, Oct 17, 2019 at 2:12 PM Masahiko Sawada wrote:
>
> On Thu, Oct 17, 2019 at 5:30 PM Amit Kapila wrote:
> >
> > On Thu, Oct 17, 2019 at 12:21 PM Amit Kapila
> > wrote:
> > >
> > > On Thu, Oct 17, 2019 at 10:56 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > I guess that the concepts of
Amit Kapila writes:
> Another idea could be each index AM tell whether it uses
> maintainence_work_mem or not and based on that we can do the
> computation (divide the maintainence_work_mem by the number of such
> indexes during parallel vacuum).
FWIW, that seems like a perfectly reasonable API
On Thu, Oct 17, 2019 at 1:47 PM Dilip Kumar wrote:
>
> On Thu, Oct 17, 2019 at 12:27 PM Heikki Linnakangas wrote:
> >
> > On 17/10/2019 05:31, Amit Kapila wrote:
> > >
> > > The patch looks good to me. I have slightly modified the comments and
> > > removed unnecessary initialization.
> > >
> >
On Wed, Oct 16, 2019 at 5:35 PM Masahiko Sawada wrote:
>
> On Wed, Oct 16, 2019 at 3:48 PM Amit Kapila wrote:
> >
> >
> > It is not that currently, other indexes don't use any additional
> > memory (except for maintainence_work_mem). For example, Gist index
> > can use memory for collecting
At Fri, 11 Oct 2019 23:27:54 -0500, Joe Nelson wrote in
> Here's v6 of the patch.
>
> [x] Rebase on 20961ceaf0
> [x] Don't call exit(1) after pg_fatal()
> [x] Use Tom Lane's suggestion for %lld in _() string
> [x] Allow full unsigned 16-bit range for ports (don't disallow ports 0-1023)
> [x]
On Thu, Oct 17, 2019 at 05:33:22AM -0300, Alvaro Herrera wrote:
> Hmm, I wonder if it isn't the right solution to set 'progress' to false
> in that spot, instead. index_drop says it must only be called by the
> dependency machinery; are we depending on that to pass-through the need
> to update
On Thu, Oct 17, 2019 at 5:30 PM Amit Kapila wrote:
>
> On Thu, Oct 17, 2019 at 12:21 PM Amit Kapila wrote:
> >
> > On Thu, Oct 17, 2019 at 10:56 AM Masahiko Sawada
> > wrote:
> > >
> > > I guess that the concepts of vacuum delay contradicts the concepts of
> > > parallel vacuum. The concepts
On 15/10/2019 13:49, Ashutosh Sharma wrote:
Hi,
I got chance to spend some time looking into the recent changes done
in the zedstore code, basically the functions for packing datums into
the attribute streams and handling attribute leaf pages. I didn't find
any issues but there are some minor
Hi,
When g is specified, null is inserted in the filler column of
pgbentch_tellrs, acounts, branches.
But when G is specified, empty string is inserted.
Do you have any intention of this difference?
--
Anna
On 2019-Oct-17, Michael Paquier wrote:
> You may not have a backtrace, but I think that you are right:
> WaitForLockers() gets called in index_drop() with progress reporting
> enabled. index_drop() would also be taken by REINDEX CONCURRENTLY
> through performMultipleDeletions() but we cannot
On Thu, Oct 17, 2019 at 12:21 PM Amit Kapila wrote:
>
> On Thu, Oct 17, 2019 at 10:56 AM Masahiko Sawada
> wrote:
> >
> > I guess that the concepts of vacuum delay contradicts the concepts of
> > parallel vacuum. The concepts of parallel vacuum would be to use more
> > resource to make vacuum
On Thu, Oct 17, 2019 at 01:04:50AM -0700, Andres Freund wrote:
> Wonder if it's worth removing the backward compat ones from master? I
> don't quite think so, but...
I would vote for the removal so as we'll never see that again in
core. Let's see what others think here.
--
Michael
On 2019-Oct-05, Alvaro Herrera wrote:
> While playing around I noticed that depending on the number of parallel
> workers in pg_restore compared to the number of partitions a table has,
> restoring an FK fails because the FK itself is restored before the index
> partitions have completed
On Thu, Oct 17, 2019 at 12:27 PM Heikki Linnakangas wrote:
>
> On 17/10/2019 05:31, Amit Kapila wrote:
> > On Wed, Oct 16, 2019 at 11:20 AM Dilip Kumar wrote:
> >>
> >> On Tue, Oct 15, 2019 at 7:13 PM Heikki Linnakangas wrote:
> >>>
> >>> On 15/10/2019 09:37, Amit Kapila wrote:
> While
Andres Freund writes:
> On 2019-10-17 10:47:06 +0900, Michael Paquier wrote:
>> I have just bumped into $subject, and we now use the table_*
>> equivalents in the code. Any objections to the simple patch attached
>> to clean up that?
> They're not really "remaining", as much as having been
Hi,
On 2019-10-17 10:47:06 +0900, Michael Paquier wrote:
> I have just bumped into $subject, and we now use the table_*
> equivalents in the code. Any objections to the simple patch attached
> to clean up that?
They're not really "remaining", as much as having been introduced after
the
On Mon, Oct 14, 2019 at 10:27:14AM +0200, Peter Eisentraut wrote:
> I propose this patch to remove the information schema tables
> SQL_LANGUAGES, which was eliminated in SQL:2008, and SQL_PACKAGES, which
> was eliminated in SQL:2011. Since they were dropped by the SQL
> standard, the information
On Thu, Oct 17, 2019 at 06:37:11PM +1300, Thomas Munro wrote:
> -1 for these macros.
>
> These are basic facts about the C language. I hope C eventually
> supports {} like C++, so that you don't have to think hard about
> whether the first member is another struct, and recursively so … but
>
On Tue, Oct 15, 2019 at 09:00:23AM +0200, Peter Eisentraut wrote:
> This doesn't make much sense (anymore?) since MinGW surely has sed and
> MSVC doesn't use this (and has Perl). I think this is a leftover from
> various ancient client-only ad-hoc Windows build provisions (those
> win32.mak files
On 17/10/2019 05:31, Amit Kapila wrote:
On Wed, Oct 16, 2019 at 11:20 AM Dilip Kumar wrote:
On Tue, Oct 15, 2019 at 7:13 PM Heikki Linnakangas wrote:
On 15/10/2019 09:37, Amit Kapila wrote:
While reviewing a parallel vacuum patch [1], we noticed a few things
about $SUBJECT implemented in
On Thu, Oct 17, 2019 at 10:56 AM Masahiko Sawada wrote:
>
> On Wed, Oct 16, 2019 at 3:02 PM Amit Kapila wrote:
> >
> > On Wed, Oct 16, 2019 at 6:50 AM Masahiko Sawada
> > wrote:
> > >
> > > On Tue, Oct 15, 2019 at 6:33 PM Amit Kapila
> > > wrote:
> > > >
> > >
> > > Attached updated patch
On Thu, Oct 17, 2019 at 3:18 PM Mahendra Singh wrote:
>
> Hi
> I applied all 3 patches and ran regression test. I was getting one regression
> failure.
>
>> diff -U3
>> /home/mahendra/postgres_base_rp/postgres/src/test/regress/expected/vacuum.out
>>
Hi
I applied all 3 patches and ran regression test. I was getting one
regression failure.
diff -U3
> /home/mahendra/postgres_base_rp/postgres/src/test/regress/expected/vacuum.out
> /home/mahendra/postgres_base_rp/postgres/src/test/regress/results/vacuum.out
> ---
>
63 matches
Mail list logo
