Re: [BUGS] BUG #7484: while restore database backup error is raised
On 08/08/2012 02:54 PM, John R Pierce wrote: On 08/07/12 11:10 PM, Craig Ringer wrote: Please examine the PostgreSQL server logs for error details. I think they're in /var/lib/pgsql/data/pg_log on CentOS, as that's where they are on Fedora. the PGDG rpm/yum repo of 9.1 defaults logs to /var/lib/pgsql/9.1/data/pg_log other things of potential interest in this bug report would be any unusual or exceptionally large settings in postgresql.conf, is this a 32 bit or 64 bit install Good point. Please show: SELECT version() and the output of this query: http://wiki.postgresql.org/wiki/Server_Configuration -- Craig Ringer
Re: [BUGS] BUG #7484: while restore database backup error is raised
On 08/07/12 11:10 PM, Craig Ringer wrote: Please examine the PostgreSQL server logs for error details. I think they're in /var/lib/pgsql/data/pg_log on CentOS, as that's where they are on Fedora. the PGDG rpm/yum repo of 9.1 defaults logs to /var/lib/pgsql/9.1/data/pg_log other things of potential interest in this bug report would be any unusual or exceptionally large settings in postgresql.conf, is this a 32 bit or 64 bit install -- john r pierceN 37, W 122 santa cruz ca mid-left coast -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7481: DB installer Not progress
Hello Junho, We have fixed some issues related to the bug you posted, They will be available in the next upcoming PostgreSQL point release. On Tue, Aug 7, 2012 at 6:02 AM, wrote: > The following bug has been logged on the website: > > Bug reference: 7481 > Logged by: Junho Kim > Email address: junho1@lge.com > PostgreSQL version: 9.1.3 > Operating system: Windows XP sp3 > Description: > > I have run the postgresql-9.1.3-2-windows.exe at command window. > (postgresql-9.1.3-2-windows.exe --prefix "C:\PostgreSQL\9.1" --datadir > "C:\PostgreSQL\9.1\data" --mode unattended --serviceaccount postgres) When > installer's step came to the Initialising the database cluster, Did not > progress anymore. > I waited one hour. But installation did not complete. > Eventually, I canceled DB installer. > > My OS version is Windows XP 32bit servicepack3 > > Best regards. > Jun > > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs > -- Regards, Sachin Srivastava EnterpriseDB, India
Re: [BUGS] BUG #7484: while restore database backup error is raised
On 08/08/2012 02:06 PM, sudhir...@hotmail.com wrote: The following bug has been logged on the website: Bug reference: 7484 Logged by: sudhir Email address: sudhir...@hotmail.com PostgreSQL version: 9.1.4 Operating system: centos Description: pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore: [archiver (db)] Error from TOC entry 832; 1255 1816123 FUNCTION ad_column_identifier_ref_sql(character varying, character varying, character varying, character varying, character varying) tad pg_restore: [archiver (db)] could not execute query: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. Please examine the PostgreSQL server logs for error details. I think they're in /var/lib/pgsql/data/pg_log on CentOS, as that's where they are on Fedora. It'd help to know your CentOS version, how you installed PostgreSQL, etc. Are you using any extensions? PostGIS? -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #7484: while restore database backup error is raised
The following bug has been logged on the website: Bug reference: 7484 Logged by: sudhir Email address: sudhir...@hotmail.com PostgreSQL version: 9.1.4 Operating system: centos Description: pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore: [archiver (db)] Error from TOC entry 832; 1255 1816123 FUNCTION ad_column_identifier_ref_sql(character varying, character varying, character varying, character varying, character varying) tad pg_restore: [archiver (db)] could not execute query: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] renaming+recreating table w/default sequence causes dependency seq issue
Todd Kover writes:
> I saw issues around renaming tables and not renaming sequences in the TODO
> list but did not see anything about this. Apologies if I missed it.
> This is with a 9.1.4 server (enterprisedb download on mac os/x lion) and also
> seen on 9.1.3 built from netbsd pkgsrc.
> It appears that something is amiss if you try to drop a table that has been
> renamed that used to have a default mapping to a sequence:
> Given this:
> --
> drop table IF EXISTS foo;
> drop table IF EXISTS foo_v26;
> create table foo (id serial not null, bar integer );
> alter table foo alter column id drop default;
> alter table foo rename to foo_v26;
> create table foo (id integer not null, bar integer );
> alter table foo alter id SET DEFAULT nextval('foo_id_seq');
> drop table foo_v26;
> --
> everthing works as expected until the final drop, which says:
> jazzhands=> drop table foo_v26;
> ERROR: cannot drop table foo_v26 because other objects depend on it
> DETAIL: default for table foo column id depends on sequence foo_id_seq
> HINT: Use DROP ... CASCADE to drop the dependent objects too.
I don't see any bug there. The ALTER DROP DEFAULT command does not
remove the sequence's dependence on foo.id; nor for that matter does
ALTER SET DEFAULT create an auto-drop dependency on the new table.
See ALTER SEQUENCE OWNED BY if you want to dissociate a serial column's
sequence from the column, or reattach it to another column.
Formally speaking, a "serial column" is shorthand for creating an
integer (or bigint) column, creating a sequence, associating them
as though by ALTER SEQUENCE OWNED BY, and setting the column's default
to nextval('sequence-name').
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] renaming+recreating table w/default sequence causes dependency seq issue
Excerpts from Todd Kover's message of mar ago 07 20:10:25 -0400 2012:
> Given this:
> --
> drop table IF EXISTS foo;
> drop table IF EXISTS foo_v26;
>
> create table foo (id serial not null, bar integer );
> alter table foo alter column id drop default;
>
> alter table foo rename to foo_v26;
>
> create table foo (id integer not null, bar integer );
>
> alter table foo alter id SET DEFAULT nextval('foo_id_seq');
>
> drop table foo_v26;
> --
>
> everthing works as expected until the final drop, which says:
>
> jazzhands=> drop table foo_v26;
> ERROR: cannot drop table foo_v26 because other objects depend on it
> DETAIL: default for table foo column id depends on sequence foo_id_seq
> HINT: Use DROP ... CASCADE to drop the dependent objects too.
I think you need an ALTER SEQUENCE .. OWNED BY to fix up dependencies
for the sequence.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Small bug in psqlodbc-09.01 prevents interoperability with LISTSERV
On 08/04/2012 11:43 PM, Eric Thomas wrote: Because we have customers who think Excel is an RDBMS, our product LISTSERV religiously queries ODBC capabilities at startup and prints warnings as appropriate. A customer tried to use PostgreSQL on Windows and got the following (these are our messages not yours, I am pasting them to show all the version numbers): Hi As there's been no response on -bugs I've passed your report on to the pgsql-odbc mailing list. There seems to be little activity on the ODBC driver these days. It might well be worth your time to grab the psqlODBC sources, patch them to resolve your issues, and post the patch as a proposed change on the pgsql-odbc list. I don't work with ODBC (or Windows very much) so I'm not sure I can be of much direct help. -- Craig Ringer
[BUGS] renaming+recreating table w/default sequence causes dependency seq issue
I saw issues around renaming tables and not renaming sequences in the TODO
list but did not see anything about this. Apologies if I missed it.
This is with a 9.1.4 server (enterprisedb download on mac os/x lion) and also
seen on 9.1.3 built from netbsd pkgsrc.
It appears that something is amiss if you try to drop a table that has been
renamed that used to have a default mapping to a sequence:
Given this:
--
drop table IF EXISTS foo;
drop table IF EXISTS foo_v26;
create table foo (id serial not null, bar integer );
alter table foo alter column id drop default;
alter table foo rename to foo_v26;
create table foo (id integer not null, bar integer );
alter table foo alter id SET DEFAULT nextval('foo_id_seq');
drop table foo_v26;
--
everthing works as expected until the final drop, which says:
jazzhands=> drop table foo_v26;
ERROR: cannot drop table foo_v26 because other objects depend on it
DETAIL: default for table foo column id depends on sequence foo_id_seq
HINT: Use DROP ... CASCADE to drop the dependent objects too.
however...
jazzhands=> \d foo;
Table "public.foo"
Column | Type |Modifiers
+-+--
id | integer | not null default nextval('foo_id_seq'::regclass)
jazzhands=> \d foo_v26;
Table "public.foo_v26"
Column | Type | Modifiers
+-+---
id | integer | not null
Interestingly, I can drop table foo without any complaints.
It seems like the dependency did not move (it also seems like its
backwards but that's probably all me).
Sadly, if I move setting the default to after I drop the old table, the
sequence goes away, so I am still digging into a work around.
thanks,
-Todd
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] event triggers patch breaks with -DCLOBBER_CACHE_ALWAYS
On Mon, Jul 23, 2012 at 8:16 PM, Jeff Davis wrote: > Compiling 3a0e4d with -DCLOBBER_CACHE_ALWAYS causes initdb to segfault. > > It looks like the tuple was allocated in the EventTriggerCacheContext, > and before the tuple was freed, another invalidation event came along > and wiped out that context. > > It seems like the cleanest fix would be to explicitly allocate things in > the EventTriggerCacheContext, rather than switching the context. > > However, it's not 100% clear to me that this is really a problem with > the event trigger patch itself. RelationBuildDesc is doing an allocation > in whatever the caller's context is, and freeing it. But in the > meantime, it does it's own catalog accesses and otherwise executes quite > a lot of code, and assumes that the memory context will stay intact the > entire time. Maybe that's a reasonable assumption, but as seen here, it > leaves room for error. Yeah. Essentially, BuildRelationDesc wants the caller's memory context to be short-lived (so that any leaks go away) but not so short-lived that the tuple can get clobbered before the function gets done using it. It's worked up until now but it seems kinda fragile. However, even if we fixed that, I don't think it would fix this problem completely, because BuildEventTriggerCache() is itself unprepared for the possibility of a cache reset in the middle of a rebuild. After some thought, I think the right fix is to add a three-valued flag indicating whether the cache is (1) stale (the starting state), (2) rebuild started, or (3) valid. (1) At the beginning of BuildEventTriggerCache, we unconditionally set the state to "rebuild started". At the end, if the state is still "rebuild started", we set it to "valid". (2) InvalidateEventCacheCallback should blow the cache away only if the current state is something other than "rebuild started". It should then unconditionally set the flag to "stale". (3) EventCacheLookup should rebuild the cache whenever the state is not "valid". That way, if an invalidation event arrives in the middle of a rebuild, we finish the rebuild without blowing up, but leave the cache marked as stale, so that the next lookup will rebuild it again. The "rebuild started" state could exist even when no rebuild is in progress if the rebuild errors out, but it doesn't really matter; the next rebuild will fix it. Anyone see a hole in that, or have better ideas? > While looking at it, I observe that no context is passed to > hash_create(), and no hash_destroy() is called. Unless I'm missing > something, that's a leak in TopMemoryContext. I've pushed a fix for this; thanks for catching it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7483: uuid-ossp does not compile on OS X 10.8
dcarm...@dcarmichael.net writes: > I'm compiling PostgreSQL 9.1.4 on OS X 10.8, and the uuid-ossp extension > doesn't compile properly, as follows: Yeah, we've heard that already. It appears that OSSP needs to fix their code for Mountain Lion --- Apple seem to have changed in a way OSSP wasn't expecting. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #7483: uuid-ossp does not compile on OS X 10.8
The following bug has been logged on the website:
Bug reference: 7483
Logged by: Douglas Carmichael
Email address: dcarm...@dcarmichael.net
PostgreSQL version: 9.1.4
Operating system: OS X 10.8 (Mountain Lion)
Description:
I'm compiling PostgreSQL 9.1.4 on OS X 10.8, and the uuid-ossp extension
doesn't compile properly, as follows:
:info:build /usr/bin/clang -pipe -O2 -arch x86_64 -Wall -Wmissing-prototypes
-Wp
ointer-arith -Wdeclaration-after-statement -Wendif-labels -Wformat-security
-fno
-strict-aliasing -fwrapv -I. -I. -I../../src/include -I/opt/local/include
-I/op
t/local/include/ossp -I/opt/local/include/libxml2 -I/opt/local/include -c
-o u
uid-ossp.o uuid-ossp.c
:info:build In file included from uuid-ossp.c:24:
:info:build In file included from /opt/local/include/ossp/uuid.h:38:
:info:build /usr/include/unistd.h:689:26: error: expected identifier
:info:build int gethostuuid(uuid_t, const struct timespec *)
__OSX_AVAILABL
E_STARTING(__MAC_10_5, __IPHONE_2_0);
:info:build ^
:info:build In file included from uuid-ossp.c:24:
:info:build /opt/local/include/ossp/uuid.h:94:24: error: typedef
redefinition wi
th different types ('struct uuid_st' vs '__darwin_uuid_t' (aka 'unsigned
char [16]'))
:info:build typedef struct uuid_st uuid_t;
:info:build^
:info:build /usr/include/uuid/uuid.h:42:25: note: previous definition is
here
:info:build typedef __darwin_uuid_t uuid_t;
:info:build ^
:info:build In file included from uuid-ossp.c:24:
:info:build /opt/local/include/ossp/uuid.h:107:22: error: conflicting types
for 'uuid_compare'
:info:build extern uuid_rc_t uuid_compare (const uuid_t *_uuid, const
uuid_t *_uuid2, int *_result);
:info:build ^
:info:build /usr/include/uuid/uuid.h:59:5: note: previous declaration is
here
:info:build int uuid_compare(const uuid_t uu1, const uuid_t uu2);
:info:build ^
:info:build 3 errors generated.
:info:build gnumake: *** [uuid-ossp.o] Error 1
I'm compiling using MacPorts (http://www.macports.org/), and I've also
reported this to them.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #7481: DB installer Not progress
The following bug has been logged on the website: Bug reference: 7481 Logged by: Junho Kim Email address: junho1@lge.com PostgreSQL version: 9.1.3 Operating system: Windows XP sp3 Description: I have run the postgresql-9.1.3-2-windows.exe at command window. (postgresql-9.1.3-2-windows.exe --prefix "C:\PostgreSQL\9.1" --datadir "C:\PostgreSQL\9.1\data" --mode unattended --serviceaccount postgres) When installer's step came to the Initialising the database cluster, Did not progress anymore. I waited one hour. But installation did not complete. Eventually, I canceled DB installer. My OS version is Windows XP 32bit servicepack3 Best regards. Jun -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #7482: lack of quotation marks in pg_env script
The following bug has been logged on the website: Bug reference: 7482 Logged by: Maciej Skrzypkowski Email address: m.skrzypkow...@o2.pl PostgreSQL version: 9.1.4 Operating system: Windows XP Description: In main application directory, inside pg_env.bat script there is lack of quotation marks for PGDATA and PGLOCALEDIR variables. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4958: Stats collector hung on WaitForMultipleObjectsEx while attempting to recv a datagram
Robert Haas writes: > We just had a customer hit a very similar problem on 9.1.3, running on > Windows Server 2008 SP2. ... > The customer finds that they can reproduce this on a variety of > systems under heavy load. > Now, it looks to me like for this stack trace to happen, > PgstatCollectorMain() has got to call pgwin32_waitforsinglesocket (at > line 3002), and that function has to return true, so that got_data > gets set to true. Then PgstatCollectorMain() will call recv(), which > on Windows will really be pgwin32_recv, which will call > pgwin32_waitforsinglesocket, which must now hang. The fact that the > first pgwin32_waitforsinglesocket call returned true should mean that > the stats collector socket is ready for read, while the fact that the > second one did not return seems to imply that it's not ready for read, > close, or accept. So it almost looks like Windows can change its mind > about whether the socket is readable. > Or maybe we're telling it to change its mind. This sounds an awful > lot like something that could have been caused by the oversights fixed > in commit b85427f2276d02756b558c0024949305ea65aca5. Was there a > reason we didn't back-patch that? Sure: it was unproven that that fixed anything at all, much less that it was bug-free enough to be safe to backpatch. Neither of those things has changed since May. If you want you can try making up a 9.1 with those changes and giving it to this customer to see if it fixes their problems --- but without some field testing of the sort, I'm pretty hesitant to put it into back branches. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6126: CC parameter in to_char() behaves incorrectly
On Mon, Aug 6, 2012 at 03:20:18PM -0400, Bruce Momjian wrote:
> On Sat, Aug 4, 2012 at 10:34:14AM -0400, Bruce Momjian wrote:
> > > I am thinking it is too late to apply this for 9.2 because users might
> > > have already tested their applications, though I doubt many are using BC
> > > dates. Feedback?
> >
> > There is never just one bug in formatting.c --- the input side was also
> > broken for BC/negative centuries. The attached patch fixes the input
> > side as well, and shows the old/fixed output for BC centuries. The test
> > queries were:
> >
> > SELECT to_date('-6 4', 'CC YY');
> > SELECT to_date(' 6 4', 'CC YY');
> > SELECT to_date('-6 00', 'CC YY');
> > SELECT to_date(' 6 00', 'CC YY');
> > SELECT to_date('-6', 'CC');
> > SELECT to_date(' 6', 'CC');
> >
> > I believe this is all for 9.3-only.
>
> OK, I found another bug in our code; the output of:
>
> SELECT to_date(' 6 BC', 'CC BC');
>
> returned 501BC, instead of the start of the century, 600BC, like SELECT
> to_date('-6', 'CC') does.
>
> I also allowed negative BC dates to map to AD dates, just like negative
> AD dates map to BC dates.
>
> Attached is an updated patch and output diff.
Applied.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6739: PGAdmin 3 Should allow to select multiple tables in the left tree
On Mon, Jul 16, 2012 at 6:43 AM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6739
> Logged by: Stuart Axon
> Email address: stua...@yahoo.com
> PostgreSQL version: 9.1.0
> Operating system: Linux
> Description:
>
> If you go to Database>{db}>Schemas>public>Tables
>
> You can only select one table (to then drop/whatever).
>
> However if you use the list of tables under properties on the right you
> *can* select multiple tables.
>
> The inconsistancy is confusing and a little inconvenient (at first I didn't
> realise it was possible to perform actions on more than one table).
I think that you're talking about a problem with PgAdmin rather than
PostgreSQL itself, so please report your bug here:
http://www.pgadmin.org/support/list.php
http://archives.postgresql.org/pgadmin-support/
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6738: pg_dump does not handle extensions properly/invalid pg_dump output
On Sat, Jul 14, 2012 at 1:44 PM, wrote: > Here is a feature that pg_dump needs: An option needs to be added to > explicitly suppress or allow backing up all or selected extensions. I agree. > Reason and associated bug: > The current behavior may by fine with extensions that do not add or change > tables, schemas, functions, etc when installed, however some extensions such > as postgis does. Restoring to a spatially enabled database will cause > errors when the postgis provided rules and schema "topology" is encountered > and probably the postgis provided public.spatial_ref_sys table (see > ancilliary bug #3). Restoring to a non-spatially enabled database does work > since pg_restore does install the postgis extension and spatially enable the > database. However pg_restore still throws errors over already existing > rules created by postgis as earlier initiated by pg_restore. But this sounds like a problem with the PostGIS extension doing things improperly, rather than a problem with the extension mechanism itself. More specifics would be helpful. > Ancilliary bug#1 : pg_dump dumps the postgis table data > public.spatial_ref_sys. This cannot be suppressed with the --schema-only > flag. This may be a problem if the restored database has an upgraded > postgis and the public.spatial_ref_sys table has been updated in some way. > The newer table may be overwritten with old data. The extension mechanism is designed in such a way that extensions can declare which tables should be dumped in their entirety or just partially. Sounds like something isn't right here. > Ancilliary bug#2: I was unable to test the above since pg_restore made no > apparant attempt to restore public.spatial_ref_sys, at least there was no > mention at all listed in the pg_restore output of any attempt to restore > that table even though that table had been dumped in violation of the > --schema-only flag. The backup was in tar format created as follows: > > pg_dump.exe --host localhost --port 5432 --username "postgres" --format tar > --verbose --schema-only --file "C:\other\postgres-bak\transfer\data.backup" > oec That sounds like a bug, assuming someone else can reproduce it. > Ancilliary bug#3: pg_restore was unable to restore an otherwise identical > plain text version of the backup file generated by: > > pg_dump.exe --host localhost --port 5432 --username "postgres" --format > plain --verbose --schema-only --file > "C:\other\postgres-bak\transfer\data.backup" oec pg_restore only handles custom and tar format backups. Plain format backups can just be fed to psql. Maybe we could give a nicer error message, but this isn't a bug. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4958: Stats collector hung on WaitForMultipleObjectsEx while attempting to recv a datagram
On Fri, Jul 31, 2009 at 10:59 AM, Luke Koops wrote: > -- postgres.exe!mainCRTStartup -- > ntoskrnl.exe!KiSwapContext+0x26 > ntoskrnl.exe!KiSwapThread+0x2e5 > ntoskrnl.exe!KeWaitForSingleObject+0x346 > ntoskrnl.exe!KiSuspendThread+0x18 > ntoskrnl.exe!KiDeliverApc+0x117 > ntoskrnl.exe!KiSwapThread+0x300 > ntoskrnl.exe!KeWaitForMultipleObjects+0x3d7 > ntoskrnl.exe!ObpWaitForMultipleObjects+0x202 > ntoskrnl.exe!NtWaitForMultipleObjects+0xe9 > ntoskrnl.exe!KiFastCallEntry+0xfc > ntdll.dll!KiFastSystemCallRet > ntdll.dll!NtWaitForMultipleObjects+0xc > kernel32.dll!WaitForMultipleObjectsEx+0x11a > postgres.exe!pgwin32_waitforsinglesocket+0x1ed > postgres.exe!pgwin32_recv+0x90 > postgres.exe!PgstatCollectorMain+0x17f > postgres.exe!SubPostmasterMain+0x33a > postgres.exe!main+0x168 > postgres.exe!__tmainCRTStartup+0x10f > kernel32.dll!BaseProcessStart+0x23 We just had a customer hit a very similar problem on 9.1.3, running on Windows Server 2008 SP2. They were able to extract the following stack trace: ntoskrnl.exe!KiSwapContext+0x7a ntoskrnl.exe!KiCommitThreadWait+0x1d2 ntoskrnl.exe!KeWaitForMultipleObjects+0x271 ntoskrnl.exe!ObpWaitForMultipleObjects+0x294 ntoskrnl.exe!NtWaitForMultipleObjects+0xe5 ntoskrnl.exe!KiSystemServiceCopyEnd+0x13 ntdll.dll!ZwWaitForMultipleObjects+0xa KERNELBASE.dll!WaitForMultipleObjectsEx+0xe8 kernel32.dll!WaitForMultipleObjectsExImplementation+0xb3 postgres.exe!pgwin32_waitforsinglesocket+0x26d postgres.exe!pgwin32_recv+0xf0 postgres.exe!PgstatCollectorMain+0x1cc postgres.exe!SubPostmasterMain+0x4c2 postgres.exe!main+0x1d0 postgres.exe!__tmainCRTStartup+0x11a kernel32.dll!BaseThreadInitThunk+0xd ntdll.dll!RtlUserThreadStart+0x1d The customer finds that they can reproduce this on a variety of systems under heavy load. However, removing the load doesn't fix the problem; the system continues to spew pgstat wait timeout messages into the logs. Autovacuum fails to DTRT due to lack of current stats and things go downhill rapidly from there. Terminating the stats collector process resolves the issue; the postmaster starts a new one within 60 seconds and after that the pgstat wait timeout messages cease and vacuuming consequently resumes. Now, it looks to me like for this stack trace to happen, PgstatCollectorMain() has got to call pgwin32_waitforsinglesocket (at line 3002), and that function has to return true, so that got_data gets set to true. Then PgstatCollectorMain() will call recv(), which on Windows will really be pgwin32_recv, which will call pgwin32_waitforsinglesocket, which must now hang. The fact that the first pgwin32_waitforsinglesocket call returned true should mean that the stats collector socket is ready for read, while the fact that the second one did not return seems to imply that it's not ready for read, close, or accept. So it almost looks like Windows can change its mind about whether the socket is readable. Or maybe we're telling it to change its mind. This sounds an awful lot like something that could have been caused by the oversights fixed in commit b85427f2276d02756b558c0024949305ea65aca5. Was there a reason we didn't back-patch that? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Error on pg_settings.bytea_output for pg9.1
On Tue, Jul 31, 2012 at 9:07 AM, Guillaume Lelarge wrote: > On Tue, 2012-07-31 at 14:06 +0800, Craig Ringer wrote: >> On 07/31/2012 01:50 PM, Guillaume Lelarge wrote: >> >> Check the PgAdmin-III preferences; there may be an option to control its >> >> preferred bytea format. >> >> >> > There's no option to control this. >> > >> Thanks for confirming that. >> >> Is it really best for PgAdmin-III to have a different default than Pg >> its self? >> > > Well, we didn't until we had an issue to get informations from the > tgargs column of the pg_trigger catalog. I don't remember the details > right now, and I still didn't check how psql works with this, so I may > be wrong. The only way I could find to fix the issue was to set > bytea_output to escape. It probably is specific to pgAdmin. > > If we can't fix this another way, we can have a workaround. We only need > this setting for pgAdmin's browser. Not the query tool. It would be a > nice and quick workaround. I wouldn't call that a workaround, I would call it an actual fix. And I would call the current state a bug, because it overrides the users settings. Even if the user has changed it with e.g. ALTER ROLE SET, pgadmin will override it. We should try to keep the environment for the query tool connection as clean as possible. So if it's reasonably easy to do this (I haven't looked at the code, but I would assume it is), then I suggest doing that *and* backpatching it so it'll go into the next version of the stable branch. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
