On Mon, Mar 21, 2016 at 4:18 AM, Matthias Schmitt
wrote:
> Hello,
>
> sorry for the late response.
>
>> On 15 Mar 2016, at 18:59, rob stone wrote:
>>
>> I'm running Debian 4.3.5-1 (2016-02-06) x86_64 GNU/Linux.
>>
>> Backups are done via a shell
You can use schema name as a prefix:
postgres=# \d+
List of relations
Schema | Name | Type | Owner |Size| Description
---+--+---+--++-
pg_temp_1 | t| table | postgres | 8192 bytes |
(1 row)
postgres=#
On 03/20/2016 08:24 AM, Matthias Schmitt wrote:
> Hello,
>
>> On 16 Mar 2016, at 14:55, Adrian Klaver wrote:
>>
>> On 03/15/2016 08:10 AM, Matthias Schmitt wrote:
>>> Hello,
>>>
>>> since two weeks I am trying to get PostgreSQL 9.5.1 to run on Debian 8.3.
>>>
Hello,
> On 16 Mar 2016, at 14:55, Adrian Klaver wrote:
>
> On 03/15/2016 08:10 AM, Matthias Schmitt wrote:
>> Hello,
>>
>> since two weeks I am trying to get PostgreSQL 9.5.1 to run on Debian 8.3.
>> Everything is fine except the daily backup. When calling pg_dump
Hello,
sorry for the late response.
> On 15 Mar 2016, at 18:59, rob stone wrote:
>
> I'm running Debian 4.3.5-1 (2016-02-06) x86_64 GNU/Linux.
>
> Backups are done via a shell script using double hyphen syntax, as in
> e.g.:-
>
> pg_dump --port=5433
Albe Laurenz schrieb am 16.03.2016 um 14:38:
>>> waits for ShareLock on transaction; blocked by process 24342.
Process 24342 waits for ShareLock on transaction 39632974; blocked
by process 23912.
Process 23912: UPDATE alpha SET some_flag = $1 WHERE (id = $2)
> Sorry I sent the mail a little too fast. The list is at the end of the
> page.
Thank you for your reply. I saw the list and it helped me a lot :)
> On 19/03/2016 15:58, Julien Rouhaud wrote:
> > Hello,
> >
> > On 19/03/2016 15:41, Yi, Yi wrote:
> >> Hello,
> >>
> >> I had an issue with the
On Sat, Mar 19, 2016 at 11:42 PM, Robert Haas wrote:
> On Thu, Mar 10, 2016 at 1:40 AM, David G. Johnston
> wrote:
>> Adding -hackers for consideration in the Commitfest.
>
> I don't much like how this patch uses the arbitrary constant 50 in no
In Postgres 9.5.1 with a shared_buffer cache of 7Gb, a SELECT from
a single table that uses an index appears to read the table into the
shared_buffer cache. Then, as many times as the exact same SELECT is
repeated in the same session, it runs blazingly fast and doesn't even
touch the disk. All
On Mar 18, 2016 10:59 AM, "Tom Lane" wrote:
> Offhand I do not believe that any part of the core PG code would attempt
> to access such a file. Maybe you've got some extensions in there that
> would do so?
Thanks Tom, thought this was a PG issue. I'll dig more into the guts
David Steele writes:
> On 3/17/16 5:07 PM, David G. Johnston wrote:
>> Figured out it had to be added to 2016-09...done
> Hmm ... this patch is currently marked "needs review" in CF 2016-03. Am
> I missing something, should this have been closed?
The message I saw was
Sorry guys... *WRONG *email
On 17 March 2016 at 14:29, drum.lu...@gmail.com
wrote:
>
>>>
>> SELECT 'test_' || substring(uuid_generate_v4()::text, 1, 1);
>>
>> Or use a sequence, or just compute "ROW_NUMBER() OVER ()" and tack that
>> on.
>>
>> David J.
>>
>>
>>
>
Replying to Adrian because I'm not seeing some of Ranier's posts.
>On 03/18/2016 08:49 AM, Ranier VF wrote:
>
>> Would be possible, example code in C, to format BIGINT
>> param with msvc 32 bits compiler?
>> > Subject: Re: [GENERAL] Error: insufficient data in the message
>> > To:
On Wed, Mar 16, 2016 at 9:34 PM, drum.lu...@gmail.com
wrote:
> The problem is that I need to do that at the same time, because of a
> constraint:
>
>
Mark your constraint as deferrable, and then defer the constraints within
your transaction.
On 03/16/2016 07:58 AM, Dang Minh Huong wrote:
Hi,
Why does log temp files are created twice when query is executed in PL/pgSQL
function?
Would you please explain it to me?
As below test result. Log temp files are created twice when SELECT statement is
put
into a PL/pgSQL function. It led
15 matches
Mail list logo