On 10/4/14, 3:25 PM, Bruce Momjian wrote:
On Sat, Oct 4, 2014 at 03:01:45PM -0500, Jim Nasby wrote:
On 10/4/14, 2:58 PM, Bruce Momjian wrote:
I've committed changes for this in advance of the upcoming 9.4beta3
release. Hopefully, if this is seriously bad for anyone, we'll hear
about it from
On Fri, Oct 3, 2014 at 4:58 PM, Alvaro Herrera wrote:
> Robert Haas wrote:
>> I'm not really very convinced that it's a good idea to expose this
>> instead of just figuring out a way to parse the object identity.
>
> That's the first thing I tried. But it's not pretty: you have to
> extract schem
> "Tom" == Tom Lane writes:
>>> The spec clearly says one value per row, not one per statement;
>>> so command ID is very definitely not the right thing.
>> I think (command ID, estate->es_processed) would work.
Tom> Not terribly well, eg each new transaction starts over at
Tom> comman
On Sat, Oct 4, 2014 at 7:03 PM, Michael Paquier
wrote:
> On Sun, Oct 5, 2014 at 12:09 AM, Andres Freund wrote:
>> Any opinion on whether we should accept both --create and --create-slot
>> or only the latter? Accepting both would get rid of problems due to
>> potential usages of the old syntax -
On Sun, Oct 5, 2014 at 12:09 AM, Andres Freund wrote:
> Any opinion on whether we should accept both --create and --create-slot
> or only the latter? Accepting both would get rid of problems due to
> potential usages of the old syntax - and it's easier to type...
My vote goes for only --create-slo
Thomas Munro writes:
> On 3 October 2014 00:18, Tom Lane wrote:
>> The spec clearly says one value per row, not one per statement; so
>> command ID is very definitely not the right thing.
> I think (command ID, estate->es_processed) would work.
Not terribly well, eg each new transaction starts
Bruce Momjian writes:
> How are Russians supposed to deploy Postgres on October 26 if they use
> abbeviations? At midnight?
Pretty much. The only bright spot is that the tznames files are just
text and can be edited easily, so you can change them when you need to.
This isn't the first time thi
On 3 October 2014 00:18, Tom Lane wrote:
> Thomas Munro writes:
>> I suppose one approach would be to use command
>> IDs as the scope.
>
> The spec clearly says one value per row, not one per statement; so
> command ID is very definitely not the right thing.
I think (command ID, estate->es_proce
On Sat, Oct 4, 2014 at 05:03:24PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Sat, Oct 4, 2014 at 02:21:24PM -0400, Tom Lane wrote:
> >> I've committed changes for this in advance of the upcoming 9.4beta3
> >> release. Hopefully, if this is seriously bad for anyone, we'll hear
> >> ab
Bruce Momjian writes:
> On Sat, Oct 4, 2014 at 02:21:24PM -0400, Tom Lane wrote:
>> I've committed changes for this in advance of the upcoming 9.4beta3
>> release. Hopefully, if this is seriously bad for anyone, we'll hear
>> about it from beta testers before it gets into any official back-branc
On Sat, Oct 4, 2014 at 03:01:45PM -0500, Jim Nasby wrote:
> On 10/4/14, 2:58 PM, Bruce Momjian wrote:
> >>I've committed changes for this in advance of the upcoming 9.4beta3
> >>>release. Hopefully, if this is seriously bad for anyone, we'll hear
> >>>about it from beta testers before it gets int
On 10/2/14, 7:28 AM, Robert Haas wrote:
On Thu, Oct 2, 2014 at 4:49 AM, Heikki Linnakangas
wrote:
>An origin column in the table itself helps tremendously to debug issues with
>the replication system. In many if not most scenarios, I think you'd want to
>have that extra column, even if it's no
On 10/4/14, 1:21 PM, Jeff Janes wrote:
On Thu, Oct 2, 2014 at 6:21 AM, Michael Banck mailto:michael.ba...@credativ.de>> wrote:
Hi,
we have seen repeatedly that users can be confused about why PostgreSQL
is not shutting down even though they requested it. Usually, this is
because
On 10/4/14, 2:58 PM, Bruce Momjian wrote:
I've committed changes for this in advance of the upcoming 9.4beta3
>release. Hopefully, if this is seriously bad for anyone, we'll hear
>about it from beta testers before it gets into any official back-branch
>releases.
The changes for the Russian Fede
On Sat, Oct 4, 2014 at 02:21:24PM -0400, Tom Lane wrote:
> I wrote:
> > Martijn van Oosterhout writes:
> >> Indeed, this has been a pain in the ass for a long long time.
>
> > It's good news that people think this will be an improvement.
>
> > I've not dug into the change details to be sure, bu
On 10/3/14, 4:02 PM, David G Johnston wrote:
Should we also allow:
SELECT
, col1
, col2
, col3
FROM ...
?
I would say yes, if we're going to do this. I don't see it being any worse than
trailing commas.
If we are going to do this, we need to do it EVERYWHERE.
FWIW, the way I normally "work
On 10/2/14, 11:06 PM, David G Johnston wrote:
Jim Nasby-5 wrote
On 10/2/14, 6:51 AM, Pavel Stehule wrote:
EXECUTE format('UPDATE tbl SET %I = newvalue WHERE key = %L',
colname, keyvalue)
or
-1, because of quoting issues
EXECUTE format('UPDATE tbl SET %I = newvalue WHERE k
I wrote:
> Martijn van Oosterhout writes:
>> Indeed, this has been a pain in the ass for a long long time.
> It's good news that people think this will be an improvement.
> I've not dug into the change details to be sure, but I think probably
> I was overthinking it upthread. We seem to already
On Thu, Oct 2, 2014 at 6:21 AM, Michael Banck
wrote:
> Hi,
>
> we have seen repeatedly that users can be confused about why PostgreSQL
> is not shutting down even though they requested it. Usually, this is
> because `log_checkpoints' is not enabled and the final checkpoint is
> being written, de
Am Freitag, den 03.10.2014, 12:07 -0300 schrieb Alvaro Herrera:
> Michael Banck wrote:
> > diff --git a/src/backend/access/transam/xlog.c
> > b/src/backend/access/transam/xlog.c
> > index 5a4dbb9..f2716ae 100644
> > --- a/src/backend/access/transam/xlog.c
> > +++ b/src/backend/access/transam/xlog.
On Sat, Oct 4, 2014 at 05:08:17PM +0200, Andres Freund wrote:
> On 2014-10-04 11:07:13 -0400, Bruce Momjian wrote:
> > On Fri, Oct 3, 2014 at 08:04:08PM -0400, Bruce Momjian wrote:
> > > On Sat, Oct 4, 2014 at 01:57:01AM +0200, Andres Freund wrote:
> > > > On 2014-10-03 19:54:36 -0400, Tom Lane
On 2014-10-04 14:25:27 +0900, Michael Paquier wrote:
> On Sat, Oct 4, 2014 at 9:24 AM, Michael Paquier
> wrote:
>
> >
> >
> > On Sat, Oct 4, 2014 at 6:48 AM, Andres Freund
> > wrote:
> >
> >> On 2014-10-03 14:02:08 -0400, Robert Haas wrote:
> >> > On Fri, Oct 3, 2014 at 7:57 AM, Andres Freund
>
On 2014-10-04 09:24:07 +0900, Michael Paquier wrote:
> On Sat, Oct 4, 2014 at 6:48 AM, Andres Freund
> wrote:
>
> > On 2014-10-03 14:02:08 -0400, Robert Haas wrote:
> > > On Fri, Oct 3, 2014 at 7:57 AM, Andres Freund
> > wrote:
> > > > I do wonder whether --create/--drop aren't somewhat wierd fo
On 2014-10-04 11:07:13 -0400, Bruce Momjian wrote:
> On Fri, Oct 3, 2014 at 08:04:08PM -0400, Bruce Momjian wrote:
> > On Sat, Oct 4, 2014 at 01:57:01AM +0200, Andres Freund wrote:
> > > On 2014-10-03 19:54:36 -0400, Tom Lane wrote:
> > > > Bruce Momjian writes:
> > > > > Agreeed. Also, reality
On Fri, Oct 3, 2014 at 08:04:08PM -0400, Bruce Momjian wrote:
> On Sat, Oct 4, 2014 at 01:57:01AM +0200, Andres Freund wrote:
> > On 2014-10-03 19:54:36 -0400, Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > Agreeed. Also, reality check --- we can't change postgresql.conf easily
> > > > wit
> Heikki Linnakangas writes:
> > On 10/03/2014 07:08 AM, Kouhei Kaigai wrote:
> >> What is the best way to solve the problem?
>
> > How about creating a separate ResourceOwner for these buffer pins, and
> > doing a wholesale ResourceOwnerRelease() on it when you're done?
>
> That's a thought. A
> On 03/10/2014 05:53, Kouhei Kaigai wrote:
> > Yep, that's my pain. Even though usual query does not take many
> > buffers pinned, my use case needs to fetch megabytes scale data at
> > once because of performance reason; page-by-page synchronous scan makes
> GPU being idle.
> Doesn't your GPU hav
27 matches
Mail list logo
