Peter, all,
* Stephen Frost (sfr...@snowman.net) wrote:
> * Peter Eisentraut (pete...@gmx.net) wrote:
> > Add pg_sequence system catalog
>
> The query this added to dumpSequence() seems to think that sequence
> names are unique across databases:
Just FYI, I've added this to the PG10 open items l
On 1/22/17 3:47 AM, Michael Paquier wrote:
> It would be nice at least to avoid an error, still even if we decide
> to keep it an error I can add a couple of locales in hamster and
> dangomushi and we are good to go in the buildfarm. Regarding the
> warning, I have found it useful a couple of times
On Mon, Jan 23, 2017 at 1:26 PM, Fabien COELHO wrote:
>
> \quit 4
>>>
>>
> As \q does not currently have an argument, this seems an easy and
> reasonnable extension.
>
> However, currently there are 4 existing exit status for psql: 0 (ok), 1
> (fatal error), 2 (connection error), 3 (script error.
On Mon, Jan 23, 2017 at 9:50 AM, Dagfinn Ilmari Mannsåker
wrote:
> [new patch addressing issues raised]
Thanks!
>> In releases prior to this patch, max_pred_locks_per_relation was
>> calculated as "max_pred_locks_per_transaction / 2". I know that
>> people have sometimes increased max_pred_loc
On Mon, Jan 23, 2017 at 11:16 AM, Fabien COELHO wrote:
>
> [...] Obviously the \if stuff is things we don't have yet either, but it
>>> seems less likely to have surprising side-effects.
>>>
>>
> I agree, a more generic solution seems better than an ad-hoc one.
>
> Currently the value of a non ex
\quit 4
As \q does not currently have an argument, this seems an easy and
reasonnable extension.
However, currently there are 4 existing exit status for psql: 0 (ok), 1
(fatal error), 2 (connection error), 3 (script error...). +128 status are
also already used when killing a psql process.
On Mon, Jan 23, 2017 at 9:50 AM, Dagfinn Ilmari Mannsåker
wrote:
> Kevin Grittner writes:
>
>> (1) The new GUCs are named max_pred_locks_per_*, but the
>> implementation passes them unmodified from a function specifying at
>> what count the lock should be promoted. We either need to change
>> t
2017-01-23 19:09 GMT+01:00 Corey Huinker :
> Another suggestion to come out of the \quit_if discussion was that someone
> might want to send a return code other than 0 back. Something like this:
>
> \quit 4
>
> or even:
>
>
> \set exit_code 127
> \quit :exit_code
>
> This isn't a personal need of
[...] Obviously the \if stuff is things we don't have yet either, but
it seems less likely to have surprising side-effects.
I agree, a more generic solution seems better than an ad-hoc one.
Currently the value of a non existing psql-variable is... its own
reference:-(
psql> \echo :x
>
Another suggestion to come out of the \quit_if discussion was that someone
might want to send a return code other than 0 back. Something like this:
\quit 4
or even:
\set exit_code 127
\quit :exit_code
This isn't a personal need of mine, but I figured it was an idea worth
discussing on its own.
2017-01-23 18:53 GMT+01:00 Tom Lane :
> Corey Huinker writes:
> > I was giving some thought to how psql handles undefined variables.
> > I would like an option where either psql can provide an alternate value
> > when an undefined variable is referenced, or a way to detect that a
> > specific var
On Mon, Jan 23, 2017 at 12:53 PM, Tom Lane wrote:
> Corey Huinker writes:
> > I was giving some thought to how psql handles undefined variables.
> > I would like an option where either psql can provide an alternate value
> > when an undefined variable is referenced, or a way to detect that a
> >
On Jan 22, 2017 11:13 AM, "Magnus Hagander" wrote:
Yes, this means the entire db will end up in the transaction log since
everything is rewritten. That's not great, but for a lot of people that
will be a trade they're willing to make since it's a one-time thing. Yes,
this background process migh
Corey Huinker writes:
> I was giving some thought to how psql handles undefined variables.
> I would like an option where either psql can provide an alternate value
> when an undefined variable is referenced, or a way to detect that a
> specific variable is undefined and replace it with a defined
On Mon, Jan 23, 2017 at 12:49 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> I have followed the "\if" thread that closely but IIRC that was part of
> the discussion there.
>
>
Yes, I'm trying to split some of those side-thoughts into their own threads.
On Mon, Jan 23, 2017 at 10:34 AM, Corey Huinker
wrote:
> I was giving some thought to how psql handles undefined variables.
>
> I would like an option where either psql can provide an alternate value
> when an undefined variable is referenced, or a way to detect that a
> specific variable is unde
On 23/01/17 05:37, Michael Paquier wrote:
> Hi all,
>
> When spawning a new instance, I found the following thing, which is
> surprising at first sight:
> postgres: bgworker: logical replication launcher
>
> There is perhaps no problem to keep that enabled by default until the
> release 10 wraps
On Mon, Jan 23, 2017 at 1:55 AM, Andrew Borodin wrote:
> Proposed patch, on a contrary, simplifies code. There is more code
> deleted than added. It does not affect WAL, changes nothing in page
> layout.
I appreciate that it is fewer lines of code. My hesitation comes from
a couple areas:
1. I h
On Sun, Jan 15, 2017 at 1:27 AM, Pavel Stehule
wrote:
> Hi
>
> Proposed result:
> postgres=# select foo(0, 100);
> ERROR: division by zero
> CONTEXT: PL/pgSQL function foo(double precision) line 3 at RETURN
> ARGUMENTS: a=0, b=100
>
+1 This would be useful in cases where an app calls one proce
I was giving some thought to how psql handles undefined variables.
I would like an option where either psql can provide an alternate value
when an undefined variable is referenced, or a way to detect that a
specific variable is undefined and replace it with a defined variable.
My first thought th
> On Jan 23, 2017, at 10:53 AM, Simon Riggs wrote:
>
> On 23 January 2017 at 16:32, David Christensen wrote:
>
>> ** Handling checksums on a standby:
>>
>> How to handle checksums on a standby is a bit trickier since checksums are
>> inherently a local cluster state and not WAL logged but we
On 23/01/17 17:19, Fujii Masao wrote:
> On Sat, Jan 21, 2017 at 1:39 AM, Petr Jelinek
> wrote:
>> On 20/01/17 17:33, Jaime Casanova wrote:
>>> On 20 January 2017 at 11:25, Petr Jelinek
>>> wrote:
On 20/01/17 17:05, Fujii Masao wrote:
> On Fri, Jan 20, 2017 at 11:08 PM, Peter Eisentraut
On 23 January 2017 at 16:32, David Christensen wrote:
> ** Handling checksums on a standby:
>
> How to handle checksums on a standby is a bit trickier since checksums are
> inherently a local cluster state and not WAL logged but we are storing state
> in the system tables for each database we n
On Fri, Jan 20, 2017 at 6:24 AM, Masahiko Sawada wrote:
> On Thu, Jan 19, 2017 at 8:31 PM, Claudio Freire
> wrote:
>> On Thu, Jan 19, 2017 at 6:33 AM, Anastasia Lubennikova
>> wrote:
>>> 28.12.2016 23:43, Claudio Freire:
>>>
>>> Attached v4 patches with the requested fixes.
>>>
>>>
>>> Sorry fo
All,
* Alexander Korotkov (a.korot...@postgrespro.ru) wrote:
> Also, we need to decide who would
> be our admin this year.
I don't see anyone jumping at the bit to be the admin (it's not exactly
a fun and exciting job, after all), so, unless someone really wants it
(or someone wishs to object), I
So as mentioned on IRC, I have a patch that I am working to rebase on HEAD with
the following design. It is very similar to what you have proposed, so maybe
we can use my development notes as a jumping-off point for
discussion/refinement.
* Incremental Checksums
PostgreSQL users should have a
I wrote:
> Ashutosh Bapat writes:
>> UNKNOWN is not exactly a pseudo-type.
> Well, as I said to Michael just now, I think we should turn it into one
> now that we're disallowing it in tables, because "cannot be used as a
> table column" is more or less the definition of a pseudotype.
I experimen
On Sat, Jan 21, 2017 at 1:39 AM, Petr Jelinek
wrote:
> On 20/01/17 17:33, Jaime Casanova wrote:
>> On 20 January 2017 at 11:25, Petr Jelinek
>> wrote:
>>> On 20/01/17 17:05, Fujii Masao wrote:
On Fri, Jan 20, 2017 at 11:08 PM, Peter Eisentraut
wrote:
> On 1/19/17 5:01 PM, Petr Jel
I think this patch no longer applies because of conflicts with the one I
just pushed. Please rebase.
Thanks
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hacker
I pushed this patch after rewriting it rather completely. I added
tracing notices to inspect the blocks it was prefetching and observed
that the original coding was failing to prefetch the final streak of
blocks in the table, which is an important oversight considering that it
may very well be tha
On Mon, Jan 23, 2017 at 2:56 PM, Ashutosh Sharma wrote:
> Hi,
>
> Please find the attached v4 patch rebased on a latest commitID in
> head. I had to rebase it as the following git commit has some changes
> in pgstatindex.c file due to which 'git apply' was failing.
>
I've looked at the patch. It l
Kevin Grittner writes:
> (1) The new GUCs are named max_pred_locks_per_*, but the
> implementation passes them unmodified from a function specifying at
> what count the lock should be promoted. We either need to change
> the names or (probably better, only because I can't think of a good
> name
On 5 January 2017 at 01:21, Craig Ringer wrote:
> On 5 January 2017 at 09:19, Craig Ringer wrote:
>
>> so here's a rebased series on top of master. No other changes.
>
> Now with actual patches.
Patch 5 no longer applies:
patching file src/include/pgstat.h
Hunk #1 FAILED at 745.
1 out of 1 hunk
Etsuro Fujita writes:
> This seems odd to me; we would not need the bottom-level Nestloop.
> Attached is a small patch for fixing that.
Pushed, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
Tom, Andrew,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Andrew Dunstan writes:
> > On 01/20/2017 01:22 PM, Tom Lane wrote:
> >> It looks like at least part of the answer is that the buildfarm isn't
> >> running this test. AFAICS, it runs "make installcheck" not
> >> "make check" in src/test/module
Andrew Dunstan writes:
> On 01/23/2017 09:03 AM, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> On 01/20/2017 01:22 PM, Tom Lane wrote:
It looks like at least part of the answer is that the buildfarm isn't
running this test. AFAICS, it runs "make installcheck" not
"make check" in s
On 01/23/2017 09:03 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 01/20/2017 01:22 PM, Tom Lane wrote:
>>> It looks like at least part of the answer is that the buildfarm isn't
>>> running this test. AFAICS, it runs "make installcheck" not
>>> "make check" in src/test/modules. I don't kno
On 1/22/17 5:03 PM, Tom Lane wrote:
Ok, after reading the code I see I only partly understood what you were
saying. In any case, it might still be useful to do some testing with
CATCACHE_STATS defined to see if there's caches that don't accumulate a
lot of negative entries.
There definitely are,
Andrew Dunstan writes:
> On 01/20/2017 01:22 PM, Tom Lane wrote:
>> It looks like at least part of the answer is that the buildfarm isn't
>> running this test. AFAICS, it runs "make installcheck" not
>> "make check" in src/test/modules. I don't know whether any of the
>> critters would have dupl
Andres Freund writes:
> There's a buildfarm failure (just on sittella so far) that I can't quite
> interpret from here. Timing wise it looks like it might be correlated
> with ea15e18677fc2eff3135023e27f69ed8821554ed - "Remove obsoleted code
> relating to targetlist SRF evaluation." but I'm not qu
On Mon, Jan 23, 2017 at 6:57 PM, Tomas Vondra
wrote:
> On 01/23/2017 01:40 PM, Amit Kapila wrote:
>>
>> On Mon, Jan 23, 2017 at 3:56 PM, Tomas Vondra
>> wrote:
>>>
>>> On 01/23/2017 09:57 AM, Amit Kapila wrote:
On Mon, Jan 23, 2017 at 1:18 PM, Tomas Vondra
wrote:
>
>
On 01/20/2017 01:22 PM, Tom Lane wrote:
> Pavan Deolasee writes:
>> I'm surprised nobody reported this problem earlier.
> It looks like at least part of the answer is that the buildfarm isn't
> running this test. AFAICS, it runs "make installcheck" not
> "make check" in src/test/modules. I don
On 01/23/2017 01:40 PM, Amit Kapila wrote:
On Mon, Jan 23, 2017 at 3:56 PM, Tomas Vondra
wrote:
On 01/23/2017 09:57 AM, Amit Kapila wrote:
On Mon, Jan 23, 2017 at 1:18 PM, Tomas Vondra
wrote:
On 01/23/2017 08:30 AM, Amit Kapila wrote:
I think if we can get data for pgbench read-write w
Ashutosh Bapat writes:
> Following error message might be misleading,
> postgres=# create table t1 (a unknown);
> ERROR: column "a" has pseudo-type unknown
> UNKNOWN is not exactly a pseudo-type.
Well, as I said to Michael just now, I think we should turn it into one
now that we're disallowing
Michael Paquier writes:
> One thing though: even with this patch, it is still possible to define
> a domain with unknown as underlying type and have a table grab it:
> create domain name as unknown;
> create table foo_name (a name);
> I think that this case should be restricted as well, and pg_upg
On Mon, Jan 23, 2017 at 3:56 PM, Tomas Vondra
wrote:
> On 01/23/2017 09:57 AM, Amit Kapila wrote:
>>
>> On Mon, Jan 23, 2017 at 1:18 PM, Tomas Vondra
>> wrote:
>>>
>>> On 01/23/2017 08:30 AM, Amit Kapila wrote:
I think if we can get data for pgbench read-write workload when da
On 23 January 2017 at 01:11, Petr Jelinek wrote:
> On 20/01/17 22:30, Petr Jelinek wrote:
>> Since it's not exactly straight forward to find when these need to be
>> initialized based on commands, I decided to move the initialization code
>> to exec_replication_command() since that's always called
On Mon, Jan 23, 2017 at 4:23 AM, Tom Lane wrote:
> I wrote:
>> I spent some time fooling with this today and came up with the attached
>> patch. I think this is basically the direction we should go in, but
>> there are various loose ends:
>
> Here's an updated patch that's rebased against today's
Hi Stas,
>
> So, here is brand new implementation of the same thing.
>
> Now instead of creating pgproc entry for prepared transaction during recovery,
> I just store recptr/xid correspondence in separate 2L-list and
> deleting entries in that
> list if redo process faced commit/abort. In case of
Thank you for reviews and suggested improvements.
I rewrote patch to make it more stable.
Changes
===
I've made a few changes:
1) WAITLSN now doesn`t depend on snapshot
2) Check current replayed LSN rather than in xact_redo_commit
3) Add syntax WAITLSN_INFINITE '0/693FF800' - for infinite wai
On 2017/01/19 5:25, Robert Haas wrote:
> On Wed, Jan 11, 2017 at 10:53 PM, Amit Langote wrote:
>> On 2017/01/06 20:23, Amit Langote wrote:
>>>
>>> If a single BulkInsertState object is passed to
>>> heap_insert()/heap_multi_insert() for different heaps corresponding to
>>> different partitions (fro
On 01/23/2017 09:57 AM, Amit Kapila wrote:
On Mon, Jan 23, 2017 at 1:18 PM, Tomas Vondra
wrote:
On 01/23/2017 08:30 AM, Amit Kapila wrote:
I think if we can get data for pgbench read-write workload when data
doesn't fit in shared buffers but fit in RAM, that can give us some
indication. We
While working on a bug in postgres_fdw, I found this:
NestLoop
-> Seq Scan on SmallTable1 A
NestLoop
-> Seq Scan on SmallTable2 B
NestLoop
-> Index Scan using XYIndex on LargeTable C
Index Condition: C.X = A.
On Wed, Jan 18, 2017 at 3:24 PM, Ashutosh Sharma wrote:
>
>> 4.
>> +Datum
>> +hash_page_items(PG_FUNCTION_ARGS)
>> +{
>> + bytea *raw_page = PG_GETARG_BYTEA_P(0);
>>
>>
>> +Datum
>> +hash_bitmap_info(PG_FUNCTION_ARGS)
>> +{
>> + Oid indexRelid = PG_GETARG_OID(0);
>> + uint32 ovflblkno = PG_GETAR
On 2017/01/20 14:24, Ashutosh Bapat wrote:
On Thu, Jan 19, 2017 at 10:38 PM, Robert Haas wrote:
On Wed, Jan 18, 2017 at 10:26 PM, Ashutosh Bapat
wrote:
Yes, I think that's broadly the approach Tom was recommending.
I don't have problem with that approach, but the latest patch has
following
Hi!
2017-01-23 11:32 GMT+05:00 Jeff Davis :
> I have some reservations about the complexity and novelty of the
> approach. I don't think I've seen an approach quite like this one
> before. It seems like the main reason you are using this approach is
> because the btree structure was too simple (no
On Wed, Jan 18, 2017 at 11:31 AM, Rushabh Lathia
wrote:
>
The patch needs a rebase after the commit 69f4b9c85f168ae006929eec4.
--
Thanks & Regards,
Kuntal Ghosh
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to y
Hi,
Please find the attached v4 patch rebased on a latest commitID in
head. I had to rebase it as the following git commit has some changes
in pgstatindex.c file due to which 'git apply' was failing.
commit f21a563d25dbae153937aec062161184189478b8
Author: Peter Eisentraut
Date: Fri Jan 20 20:
On Mon, Jan 23, 2017 at 9:47 AM, Tatsuo Ishii wrote:
>> I've found a mistake in a comment of StrategyNotifyBgWriter
>> in freelist.c. bgwriterLatch was replaced by bgwprocno in
>> the following commit, but this is remained in the comment.
>>
>> commit d72731a70450b5e7084991b9caa15cb58a2820df
>> Au
On Fri, Jan 13, 2017 at 4:25 PM, Rafia Sabih
wrote:
>
> Please let me know your feedback over the same.
>
I've looked into the patch. I've some comments regarding that.
+#define PARALLEL_KEY_QUERY_TEXTUINT64CONST(0xE010)
It should be UINT64CONST(0xE00A)
+ qu
On Mon, Jan 23, 2017 at 1:18 PM, Tomas Vondra
wrote:
> On 01/23/2017 08:30 AM, Amit Kapila wrote:
>>
>>
>> I think if we can get data for pgbench read-write workload when data
>> doesn't fit in shared buffers but fit in RAM, that can give us some
>> indication. We can try by varying the ratio of
On Mon, Jan 23, 2017 at 3:42 PM, Dilip Kumar wrote:
> On Thu, Jan 19, 2017 at 12:26 AM, Robert Haas
> wrote:
> >> Patch 0001 and 0003 required to rebase on the latest head. 0002 is
> >> still the same.
> >
> > I've committed the first half of 0001.
> Thanks. 0001 and 0003 required rebasing afte
On Sat, Jan 21, 2017 at 8:01 AM, Tom Lane wrote:
> Haribabu Kommi writes:
> > [ pg_hba_rules_10.patch ]
>
> I took a quick look over this.
>
Thanks for the review.
> * I'm not exactly convinced that the way you approached the error message
> reporting, ie duplicating the logged message, is go
101 - 163 of 163 matches
Mail list logo
