On Fri, Apr 11, 2014 at 12:13 PM, Pavel Stehule wrote:
> Hello
>
> I propose a enhancing of EXPLAIN statement about possibility get a plan of
> other PostgreSQL process.
Does this mean that you want to track plan (and other info Explain
provides) of statements running in particular backend?
Could
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Ick. That's just plain sloppy. Please create a separate production,
> *and* a separate comment header.
Done.
> Commit d86d51a95 was pretty damn awful in this regard as well, but
> let's clean them both up, not make it worse.
Yeah, I think I noticed this
The attached patch fixes a couple of compiler warnings seen by the MSVC
build.
contrib\pg_trgm\trgm_regexp.c(234): warning C4305: 'initializing' :
truncation from 'double' to 'const float4' [D:\Postgres\b\pg_trgm.vcxproj]
contrib\pg_trgm\trgm_regexp.c(235): warning C4305: 'initializing' :
trun
On Sat, Apr 12, 2014 at 12:36 PM, Christian Ullrich
wrote:
> * From: Amit Kapila
>
>> Another thing to decide about this fix is that whether it is okay to fix
>> it for CTRL+C and leave the problem open for CTRL+BREAK?
>> (The current option used (CREATE_NEW_PROCESS_GROUP) will handle only
>> CTRL
Greg,
* Gregory Smith (gregsmithpg...@gmail.com) wrote:
> Now that Tom has given some guidance on the row locking weirdness,
> maybe it's time for me to start updating those into make check form.
If you have time, that'd certainly be helpful.
> The documentation has been in a similar holding pat
All,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Yeah, the point of the "gotcha" is that a FOR UPDATE specified *outside* a
> security-barrier view would act as though it had appeared *inside* the
> view, since it effectively gets pushed down even though outer quals don't.
Alright, I've committed th
On Fri, Apr 11, 2014 at 10:28 AM, Andres Freund wrote:
> VACUUM sometimes waits synchronously for a cleanup lock on a heap
> page. Sometimes for a long time. Without reporting it externally.
> Rather confusing ;).
>
> Since we only take cleanup locks around vacuum, how about we report at
> least i
Andres Freund writes:
> On 2014-04-12 19:45:59 +0200, Marco Atzeri wrote:
>> so it is only failing on recent trunk
> Does it work on a commit before
> fc752505a99a4e2c781a070d3d42a25289c22e3c?
In principle, that commit shouldn't have affected behavior for pg_hba
entries with numeric address fiel
On 12/04/2014 19:48, Andres Freund wrote:
On 2014-04-12 19:45:59 +0200, Marco Atzeri wrote:
- same test, few days ago, on trunk was fine
so it is only failing on recent trunk
Does it work on a commit before
fc752505a99a4e2c781a070d3d42a25289c22e3c?
E.g. f33a71a7865a1dd54f04b370e2637f88665f8d
On 04/12/14 10:03, Andres Freund wrote:
On 2014-04-12 09:47:24 -0400, Tom Lane wrote:
Heikki Linnakangas writes:
> On 04/12/2014 12:07 AM, Jan Wieck wrote:
>> the Slony team has been getting seldom reports of a problem with the
>> txid_snapshot data type.
>> The symptom is that a txid_snapshot
On 2014-04-12 19:45:59 +0200, Marco Atzeri wrote:
> On 12/04/2014 19:11, Andrew Dunstan wrote:
>
> >Why can't it resolve "localhost"? That's a local issue you need to fix.
> >
> >cheers
> >
> >andrew
> >
>
> Andrew,
> just to be clear
>
> - localhost is resolved to 127.0.0.1
>
> - 127.0.0.1 is
On 12/04/2014 19:11, Andrew Dunstan wrote:
Why can't it resolve "localhost"? That's a local issue you need to fix.
cheers
andrew
Andrew,
just to be clear
- localhost is resolved to 127.0.0.1
- 127.0.0.1 is pingable
- same test on 9.3.4 works
All 135 tests passed.
- same test, fe
On 04/12/2014 12:39 PM, Marco Atzeri wrote:
Anyone seeing similar failure ?
testing on latest
$ git log |head
commit 3c41b812c5578fd7bd5c2de42941012d7d56dde2
Author: Bruce Momjian
Date: Thu Apr 10 17:16:22 2014 -0400
docs: psql '--' comments are not passed to the server
C-style b
On 2014-04-12 18:39:54 +0200, Marco Atzeri wrote:
> LOG: invalid IP address "127.0.0.1": Non-recoverable failure in name
> resolution
That sounds like a local setup problem. Is 127.0.0.1 pingable?
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Devel
Anyone seeing similar failure ?
testing on latest
$ git log |head
commit 3c41b812c5578fd7bd5c2de42941012d7d56dde2
Author: Bruce Momjian
Date: Thu Apr 10 17:16:22 2014 -0400
docs: psql '--' comments are not passed to the server
C-style block comments are passed to the server.
$ ca
On 04/12/14 11:18, Andres Freund wrote:
On 2014-04-12 11:15:09 -0400, Jan Wieck wrote:
On 04/12/14 10:09, Greg Stark wrote:
>A pg_restore would start a new xid space from FirstNormalXid which would
>obviously not work with any stored txids.
>
http://www.postgresql.org/docs/9.3/static/app-pgres
On 2014-04-12 11:15:09 -0400, Jan Wieck wrote:
> On 04/12/14 10:09, Greg Stark wrote:
>
> >A pg_restore would start a new xid space from FirstNormalXid which would
> >obviously not work with any stored txids.
> >
>
> http://www.postgresql.org/docs/9.3/static/app-pgresetxlog.html
Using that as pa
On 04/12/14 10:09, Greg Stark wrote:
A pg_restore would start a new xid space from FirstNormalXid which would
obviously not work with any stored txids.
http://www.postgresql.org/docs/9.3/static/app-pgresetxlog.html
Regards,
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
S
On 12 Apr 2014 08:35, "Jan Wieck" wrote:
>
> On 04/12/14 03:27, Heikki Linnakangas wrote:
>>
>> On 04/12/2014 12:07 AM, Jan Wieck wrote:
>>>
>>> Hackers,
>> Hmm. Do we snapshots to be stored in tables, and included in a dump? I
>> don't think we can guarantee that will work, at least not across
>
On 2014-04-12 09:47:24 -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
> > On 04/12/2014 12:07 AM, Jan Wieck wrote:
> >> the Slony team has been getting seldom reports of a problem with the
> >> txid_snapshot data type.
> >> The symptom is that a txid_snapshot on output lists the same txid
> >
Heikki Linnakangas writes:
> On 04/12/2014 12:07 AM, Jan Wieck wrote:
>> the Slony team has been getting seldom reports of a problem with the
>> txid_snapshot data type.
>> The symptom is that a txid_snapshot on output lists the same txid
>> multiple times in the xip list part of the external repr
On 04/12/14 08:38, Andres Freund wrote:
Since it's sorted there, that should be fairly straightforward. Won't
fix already created and stored datums tho. Maybe _in()/parse_snapshot()
should additionally skip over duplicate values? Looks easy enough.
There is the sort ... missed that when glanci
On 2014-04-12 10:27:16 +0300, Heikki Linnakangas wrote:
> On 04/12/2014 12:07 AM, Jan Wieck wrote:
> >The symptom is that a txid_snapshot on output lists the same txid
> >multiple times in the xip list part of the external representation. This
> >string is later rejected by txid_snapshot_in() when
On 04/12/14 03:27, Heikki Linnakangas wrote:
On 04/12/2014 12:07 AM, Jan Wieck wrote:
Hackers,
the Slony team has been getting seldom reports of a problem with the
txid_snapshot data type.
The symptom is that a txid_snapshot on output lists the same txid
multiple times in the xip list part of
Hi,
The last week I twice had the need to see how many backends had some
buffers pinned. Once during development and once while analyzing a stuck
vacuum (waiting for a cleanup lock).
I'd like to add a column to pg_buffercache exposing that. The name I've
come up with is 'pinning_backends' to refle
Hello, Amit san, Tom san,
I'm sorry for my late response. I've just caught up with the discussion.
I'm almost convinced.
Please find attached the revised patch. I'd like to follow the idea of
adding a switch to pg_ctl. The newly added ""-e event_source" sets the
event source name for pg_c
On 04/12/2014 12:07 AM, Jan Wieck wrote:
Hackers,
the Slony team has been getting seldom reports of a problem with the
txid_snapshot data type.
The symptom is that a txid_snapshot on output lists the same txid
multiple times in the xip list part of the external representation. This
string is la
* From: Amit Kapila
> Another thing to decide about this fix is that whether it is okay to fix
> it for CTRL+C and leave the problem open for CTRL+BREAK?
> (The current option used (CREATE_NEW_PROCESS_GROUP) will handle only
> CTRL+C).
I can think of three situations in which a postgres process c
28 matches
Mail list logo
