On 2017-04-15 04:47, Erik Rijkers wrote:
0001-Reserve-global-xmin-for-create-slot-snasphot-export.patch +
0002-Don-t-use-on-disk-snapshots-for-snapshot-export-in-l.patch+
0003-Prevent-snapshot-builder-xmin-from-going-backwards.patch +
0004-Fix-xl_running_xacts-usage-in-snapshot-builder.patch
On 15 April 2017 at 21:30, Jeff Janes wrote:
> On Fri, Apr 14, 2017 at 9:33 PM, Pavan Deolasee
> wrote:
>
>>
>> Since all those offsets fall on a page boundary, my guess is that we're
>> somehow failing to handle a new page correctly.
>>
>> Looking at the patch itself, my feeling is that the foll
On Sun, Apr 16, 2017 at 1:19 PM, Noah Misch wrote:
> On Fri, Apr 14, 2017 at 11:58:23PM -0400, Noah Misch wrote:
>> On Wed, Apr 05, 2017 at 09:51:02PM -0400, Noah Misch wrote:
>> > On Thu, Apr 06, 2017 at 12:48:56AM +0900, Fujii Masao wrote:
>>
>> > > > On Mon, Dec 19, 2016 at 09:49:58PM +0900, Fu
Noah Misch writes:
> On Wed, Apr 12, 2017 at 02:41:09PM -0400, Tom Lane wrote:
>> This is 100% wrong. It's failing to recurse into the subexpressions of
>> the SubPlan, which could very easily include parallel-unsafe function
>> calls. Example:
> The above-described topic is currently a Postgre
Craig Ringer writes:
> On 12 April 2017 at 13:34, Kuntal Ghosh wrote:
>> For backend_type=background worker, application_name shows the name of
>> the background worker (BackgroundWorker->bgw_name). I think we need
>> some way to distinguish among different background workers. But,
>> application
2017-04-12 1:42 GMT+02:00 Fabien COELHO :
>
> Hmmm. Although I do not buy this, it could work as a replacement for \set
>>> which it seems cannot be upgraded because some people may rely on it to
>>> just store whatever comes after it in a variable.
>>>
>>
>> I have no strong opinion on how expres
On 2017-04-16 10:46:21 +0200, Erik Rijkers wrote:
> On 2017-04-15 04:47, Erik Rijkers wrote:
> >
> > 0001-Reserve-global-xmin-for-create-slot-snasphot-export.patch +
> > 0002-Don-t-use-on-disk-snapshots-for-snapshot-export-in-l.patch+
> > 0003-Prevent-snapshot-builder-xmin-from-going-backwards.pat
On 04/10/2017 01:28 PM, Fujii Masao wrote:
Hi,
src/backend/replication/logical/launcher.c
* Worker started and attached to our shmem. This check is safe
* because only launcher ever starts the workers, so nobody can steal
* the worker slot.
The tablesync
On 16/04/17 20:41, Andres Freund wrote:
> On 2017-04-16 10:46:21 +0200, Erik Rijkers wrote:
>> On 2017-04-15 04:47, Erik Rijkers wrote:
>>>
>>> 0001-Reserve-global-xmin-for-create-slot-snasphot-export.patch +
>>> 0002-Don-t-use-on-disk-snapshots-for-snapshot-export-in-l.patch+
>>> 0003-Prevent-snap
On 16/04/17 18:47, Tom Lane wrote:
> Craig Ringer writes:
>> On 12 April 2017 at 13:34, Kuntal Ghosh wrote:
>>> For backend_type=background worker, application_name shows the name of
>>> the background worker (BackgroundWorker->bgw_name). I think we need
>>> some way to distinguish among differen
On 16/04/17 21:27, Steve Singer wrote:
> On 04/10/2017 01:28 PM, Fujii Masao wrote:
>> Hi,
>>
>> src/backend/replication/logical/launcher.c
>> * Worker started and attached to our shmem. This check is safe
>> * because only launcher ever starts the workers, so nobody
>
On 04/16/2017 03:14 AM, Tom Lane wrote:
1. Back-patch that patch, probably also including the followup adjustments
in 86029b31e and 36a3be654.
2. Add #if's to use 31cf1a1a4's coding with OpenSSL >= 1.1, while keeping
the older code for use when built against older OpenSSLs.
3. Conditionall
Andreas Karlsson writes:
> On 04/16/2017 03:14 AM, Tom Lane wrote:
>> 1. Back-patch that patch, probably also including the followup adjustments
>> in 86029b31e and 36a3be654.
> Given that I cannot recall seeing any complaints about the behavior of
> 9.4 compared to 9.3 I am leaning towards #1.
I checked the pgbench expr related code.
2. move pgbench expressions to separate module
Probably already existing "fe_utils".
3. teach pgbench expressions booleans
See https://commitfest.postgresql.org/14/985/
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
On 4/15/17 12:33, Andrew Dunstan wrote:
> Sure. Just means putting this code a bit later in the file. "make check"
> is only one initdb, so it won't cost much. I'm still inclined to force a
> TAP test for initdb with no TZ set, though.
How much is this going to buy overall? Is it worth the compli
On 4/15/17 11:26, Masahiko Sawada wrote:
> Attached patch for $subject.
>
> s/apruptly/abruptly
Fixed, thanks.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hack
On 04/16/2017 07:43 PM, Peter Eisentraut wrote:
> On 4/15/17 12:33, Andrew Dunstan wrote:
>> Sure. Just means putting this code a bit later in the file. "make check"
>> is only one initdb, so it won't cost much. I'm still inclined to force a
>> TAP test for initdb with no TZ set, though.
> How mu
On Sun, Apr 16, 2017 at 6:02 PM, Simon Riggs wrote:
> On 15 April 2017 at 21:30, Jeff Janes wrote:
>> On Fri, Apr 14, 2017 at 9:33 PM, Pavan Deolasee
>> wrote:
>>
>>>
>>> Since all those offsets fall on a page boundary, my guess is that we're
>>> somehow failing to handle a new page correctly.
>
On Thu, Apr 13, 2017 at 04:56:05AM +, Noah Misch wrote:
> On Tue, Apr 11, 2017 at 02:28:44AM +0900, Fujii Masao wrote:
> > src/backend/replication/logical/launcher.c
> > * Worker started and attached to our shmem. This check is safe
> > * because only launcher ever st
On Thu, Apr 13, 2017 at 12:58:12AM -0400, Noah Misch wrote:
> On Wed, Apr 12, 2017 at 10:21:51AM -0700, Andres Freund wrote:
> > On 2017-04-12 11:03:57 -0400, Peter Eisentraut wrote:
> > > On 4/12/17 02:31, Noah Misch wrote:
> > > >>> But I hope you mean to commit these snapbuild patches before the
On Fri, Apr 14, 2017 at 9:59 PM, Petr Jelinek
wrote:
> On 14/04/17 14:30, Michael Paquier wrote:
>> On Fri, Apr 14, 2017 at 9:19 PM, Petr Jelinek
>> wrote:
>>> I am not quite sure adding more GUCs is all that great option. When
>>> writing the patches I was wondering if we should perhaps rename t
On 2017/04/15 3:53, Peter Eisentraut wrote:
> On 4/13/17 06:48, Amit Langote wrote:
>> That is an important consideration because of pg_dump. See below:
>>
>> create table foo (a int);
>> create table bar () inherits (foo);
>> create publication mypub for table foo; -- bar is added too.
>>
>> $ p
On 2017/04/15 8:53, Peter Eisentraut wrote:
> On 4/13/17 06:23, Amit Langote wrote:
>> create table bar (a int);
>> create publication mypub for table bar;
>> alter publication mypub add table bar;
>> ERROR: relation "bar" is already member of publication "mypub"
>>
>> 2nd command should be a no-o
2017-04-17 1:00 GMT+02:00 Fabien COELHO :
>
> I checked the pgbench expr related code.
>>
>
> 2. move pgbench expressions to separate module
>>
>
> Probably already existing "fe_utils".
>
> 3. teach pgbench expressions booleans
>>
>
> See https://commitfest.postgresql.org/14/985/
so some work is
On Sun, Apr 16, 2017 at 9:30 PM, Tom Lane wrote:
> Noah Misch writes:
>> On Wed, Apr 12, 2017 at 02:41:09PM -0400, Tom Lane wrote:
>>> This is 100% wrong. It's failing to recurse into the subexpressions of
>>> the SubPlan, which could very easily include parallel-unsafe function
>>> calls. Exam
On Sat, Apr 15, 2017 at 5:27 AM, Peter Eisentraut
wrote:
> On 4/10/17 06:18, Ashutosh Bapat wrote:
>> This isn't exactly about this particular thread. But I noticed, that
>> after we introduced RELKIND_PARTITIONED_TABLE, we required to change a
>> number of conditions to include this relkind. We m
Amit Kapila writes:
> On Sun, Apr 16, 2017 at 9:30 PM, Tom Lane wrote:
>> FYI, I have this on my to-look-at list, and expect to fix it before Robert
>> returns from vacation.
> Let me know if an initial patch by someone else can be helpful?
Sure, have a go at it. I won't get to this for a day
On Mon, Apr 17, 2017 at 1:24 AM, Tom Lane wrote:
> Amit Kapila writes:
>> On Sun, Apr 16, 2017 at 9:30 PM, Tom Lane wrote:
>>> FYI, I have this on my to-look-at list, and expect to fix it before Robert
>>> returns from vacation.
>
>> Let me know if an initial patch by someone else can be helpful
At Fri, 14 Apr 2017 18:26:37 -0400, Peter Eisentraut
wrote in
<052f4ce0-159a-1666-f136-91977d326...@2ndquadrant.com>
> On 4/14/17 04:28, Kyotaro HORIGUCHI wrote:
> > =# select distinct attname from pg_attribute where attname like '%lsn%';
> >attname
> > -
> >
On Sun, Apr 16, 2017 at 11:58 PM, Amit Langote
wrote:
> By the way, Petr said in the other thread that it could be made a no-op
> (presumably without requiring IF NOT EXISTS) on the grounds that
> membership of table in publication is "soft object" or "property" rather
> than real object.
I don't
Hello,
When developping new features for pgbench, I usually write some tests
which are lost when the feature is committed. Given that I have submitted
some more features and that part of pgbench code may be considered for
sharing with pgsql, I think that improving the abysmal state of tests
At Sat, 15 Apr 2017 12:56:32 -0400, Robert Haas wrote
in
> On Fri, Apr 14, 2017 at 6:52 PM, Tom Lane wrote:
> > Peter Eisentraut writes:
> >> If we're talking about making things easier to understand, wouldn't a
> >> random user rather know what a WAL "location" is instead of a WAL "LSN"?
> >
On 2017/04/17 14:46, Robert Haas wrote:
> On Sun, Apr 16, 2017 at 11:58 PM, Amit Langote
> wrote:
>> By the way, Petr said in the other thread that it could be made a no-op
>> (presumably without requiring IF NOT EXISTS) on the grounds that
>> membership of table in publication is "soft object" or
Hello Pavel,
A more detailed answer to your many points.
The pgbench expression language is perfect for us - there is not any new
dependency - it is working on all supported platforms.
Can be nice, if we can reuse pgbench expressions in psql - there are some
task that should be solved first (
Hello Tatsuo-san,
Thank you for the patch. I tested a little bit and found that it does
not allow value replacement against non ascii variables in given SQL
statements . Is it intentional?
No, this is a bug.
If not, I think you need to fix parseVariable() as well.
Indeed. Here is v2.
--
It seems the new feature \gset doesn't work with tables having none
ascii column names:
Indeed. The same error is triggered with the \set syntax, which does not
involve any query execution.
I have added a sentence mentionning the restriction when variables are first
discussed in the docume
36 matches
Mail list logo
